draft-ietf-ace-oauth-authz-15.txt   draft-ietf-ace-oauth-authz-16.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft RISE Internet-Draft RISE
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: March 31, 2019 Ericsson Expires: April 5, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
September 27, 2018 October 2, 2018
Authentication and Authorization for Constrained Environments (ACE) Authentication and Authorization for Constrained Environments (ACE)
using the OAuth 2.0 Framework (ACE-OAuth) using the OAuth 2.0 Framework (ACE-OAuth)
draft-ietf-ace-oauth-authz-15 draft-ietf-ace-oauth-authz-16
Abstract Abstract
This specification defines a framework for authentication and This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE- authorization in Internet of Things (IoT) environments called ACE-
OAuth. The framework is based on a set of building blocks including OAuth. The framework is based on a set of building blocks including
OAuth 2.0 and CoAP, thus making a well-known and widely used OAuth 2.0 and CoAP, thus making a well-known and widely used
authorization solution suitable for IoT devices. Existing authorization solution suitable for IoT devices. Existing
specifications are used where possible, but where the constraints of specifications are used where possible, but where the constraints of
IoT devices require it, extensions are added and profiles are IoT devices require it, extensions are added and profiles are
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2019. This Internet-Draft will expire on April 5, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Discovering Authorization Servers . . . . . . . . . . . . 15 5.1. Discovering Authorization Servers . . . . . . . . . . . . 15
5.1.1. Unauthorized Resource Request Message . . . . . . . . 15 5.1.1. Unauthorized Resource Request Message . . . . . . . . 15
5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16 5.1.2. AS Information . . . . . . . . . . . . . . . . . . . 16
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 17
5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 18
5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 18
5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 18 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 18
5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 19
5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 19 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 19
5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 22 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 22
5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 24 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 24
5.6.4. Request and Response Parameters . . . . . . . . . . . 25 5.6.4. Request and Response Parameters . . . . . . . . . . . 25
5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 25 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 25
5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 26 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 26
5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 26 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 26
5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 26 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27
5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 27 5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 27
5.7.1. Introspection Request . . . . . . . . . . . . . . . . 28 5.7.1. Introspection Request . . . . . . . . . . . . . . . . 28
5.7.2. Introspection Response . . . . . . . . . . . . . . . 28 5.7.2. Introspection Response . . . . . . . . . . . . . . . 29
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 29 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 30
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 30 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 30
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31
5.8.1. The Authorization Information Endpoint . . . . . . . 31 5.8.1. The Authorization Information Endpoint . . . . . . . 32
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 32 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 33
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 33 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
6.1. Unprotected AS Information . . . . . . . . . . . . . . . 35 6.1. Unprotected AS Information . . . . . . . . . . . . . . . 35
6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 35 6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 36
6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 35 6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 36
6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 36 6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 36
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8.1. Authorization Server Information . . . . . . . . . . . . 37 8.1. Authorization Server Information . . . . . . . . . . . . 37
8.2. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 37 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 38
8.3. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 38 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 38
8.4. OAuth Access Token Types . . . . . . . . . . . . . . . . 38 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 39
8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 39 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 39
8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39 8.6. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 39
8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 39 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 40
8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 40 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 40
8.8. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 40 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 41
8.9. OAuth Introspection Response Parameter Registration . . . 41 8.9. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 41
8.10. Introspection Endpoint CBOR Mappings Registry . . . . . . 41 8.10. OAuth Introspection Response Parameter Registration . . . 42
8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42 8.11. Introspection Endpoint CBOR Mappings Registry . . . . . . 42
8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42
8.13. Media Type Registrations . . . . . . . . . . . . . . . . 43 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 43
8.14. CoAP Content-Format Registry . . . . . . . . . . . . . . 44 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 44
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 45
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Normative References . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . 45
Appendix A. Design Justification . . . . . . . . . . . . . . . . 49 10.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 52 Appendix A. Design Justification . . . . . . . . . . . . . . . . 50
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 54 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 53
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 55 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 55
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 55 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 56
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 56 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 56
E.2. Introspection Aided Token Validation . . . . . . . . . . 60 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 57
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 64 E.2. Introspection Aided Token Validation . . . . . . . . . . 61
F.1. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 64 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 65
F.2. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 64 F.1. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 65
F.3. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 65 F.2. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 65
F.4. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 65 F.3. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 65
F.5. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 65 F.4. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 66
F.6. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 65 F.5. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 66
F.7. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 65 F.6. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 66
F.8. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 66 F.7. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 66
F.9. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 66 F.8. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 66
F.10. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 66 F.9. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 67
F.11. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 66 F.10. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 67
F.12. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 67 F.11. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 67
F.13. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 67 F.12. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 67
F.14. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 67 F.13. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 68
F.15. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 68 F.14. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 F.15. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 68
F.16. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
Authorization is the process for granting approval to an entity to Authorization is the process for granting approval to an entity to
access a resource [RFC4949]. The authorization task itself can best access a resource [RFC4949]. The authorization task itself can best
be described as granting access to a requesting client, for a be described as granting access to a requesting client, for a
resource hosted on a device, the resource server (RS). This exchange resource hosted on a device, the resource server (RS). This exchange
is mediated by one or multiple authorization servers (AS). Managing is mediated by one or multiple authorization servers (AS). Managing
authorization for a large number of devices and users can be a authorization for a large number of devices and users can be a
complex task. complex task.
skipping to change at page 5, line 21 skipping to change at page 5, line 23
capitals, as shown here. capitals, as shown here.
Certain security-related terms such as "authentication", Certain security-related terms such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message "authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify" are taken from [RFC4949]. authentication code", and "verify" are taken from [RFC4949].
Since exchanges in this specification are described as RESTful Since exchanges in this specification are described as RESTful
protocol interactions, HTTP [RFC7231] offers useful terminology. protocol interactions, HTTP [RFC7231] offers useful terminology.
Terminology for entities in the architecture is defined in OAuth 2.0 Terminology for entities in the architecture is defined in OAuth 2.0
[RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource [RFC6749] such as client (C), resource server (RS), and authorization
server (RS), and authorization server (AS). server (AS).
Note that the term "endpoint" is used here following its OAuth Note that the term "endpoint" is used here following its OAuth
definition, which is to denote resources such as token and definition, which is to denote resources such as token and
introspection at the AS and authz-info at the RS (see Section 5.8.1 introspection at the AS and authz-info at the RS (see Section 5.8.1
for a definition of the authz-info endpoint). The CoAP [RFC7252] for a definition of the authz-info endpoint). The CoAP [RFC7252]
definition, which is "An entity participating in the CoAP protocol" definition, which is "An entity participating in the CoAP protocol"
is not used in this specification. is not used in this specification.
Since this specification focuses on the problem of access control to
resources, the actors has been simplified by assuming that the client
authorization server (CAS) functionality is not stand-alone but
subsumed by either the authorization server or the client (see
Section 2.2 in [I-D.ietf-ace-actors]).
The specifications in this document is called the "framework" or "ACE The specifications in this document is called the "framework" or "ACE
framework". When referring to "profiles of this framework" it refers framework". When referring to "profiles of this framework" it refers
to additional specifications that define the use of this to additional specifications that define the use of this
specification with concrete transport, and communication security specification with concrete transport, and communication security
protocols (e.g., CoAP over DTLS). protocols (e.g., CoAP over DTLS).
We use the term "Access Information" for parameters other than the We use the term "Access Information" for parameters other than the
access token provided to the client by the AS to enable it to access access token provided to the client by the AS to enable it to access
the RS (e.g. public key of the RS, profile supported by RS). the RS (e.g. public key of the RS, profile supported by RS).
skipping to change at page 15, line 25 skipping to change at page 15, line 22
endpoints at the AS is assumed to be via HTTP and may use Uri-query endpoints at the AS is assumed to be via HTTP and may use Uri-query
parameters. When profiles of this framework use CoAP instead, this parameters. When profiles of this framework use CoAP instead, this
framework REQUIRES the use of the following alternative instead of framework REQUIRES the use of the following alternative instead of
Uri-query parameters: The sender (client or RS) encodes the Uri-query parameters: The sender (client or RS) encodes the
parameters of its request as a CBOR map and submits that map as the parameters of its request as a CBOR map and submits that map as the
payload of the POST request. Profiles that use CBOR encoding of payload of the POST request. Profiles that use CBOR encoding of
protocol message parameters MUST use the media format 'application/ protocol message parameters MUST use the media format 'application/
ace+cbor', unless the protocol message is wrapped in another Content- ace+cbor', unless the protocol message is wrapped in another Content-
Format (e.g. object security). If CoAP is used for communication, Format (e.g. object security). If CoAP is used for communication,
the Content-Format MUST be abbreviated with the ID: 19 (see the Content-Format MUST be abbreviated with the ID: 19 (see
Section 8.14. Section 8.15.
The OAuth 2.0 AS uses a JSON structure in the payload of its The OAuth 2.0 AS uses a JSON structure in the payload of its
responses both to client and RS. If CoAP is used, this framework responses both to client and RS. If CoAP is used, this framework
REQUIRES the use of CBOR [RFC7049] instead of JSON. Depending on the REQUIRES the use of CBOR [RFC7049] instead of JSON. Depending on the
profile, the CBOR payload MAY be enclosed in a non-CBOR cryptographic profile, the CBOR payload MAY be enclosed in a non-CBOR cryptographic
wrapper. wrapper.
5.1. Discovering Authorization Servers 5.1. Discovering Authorization Servers
In order to determine the AS in charge of a resource hosted at the In order to determine the AS in charge of a resource hosted at the
skipping to change at page 20, line 5 skipping to change at page 19, line 48
integer abbreviations and the binary CBOR encoding, if the CBOR integer abbreviations and the binary CBOR encoding, if the CBOR
encoding is used. encoding is used.
5.6.1. Client-to-AS Request 5.6.1. Client-to-AS Request
The client sends a POST request to the token endpoint at the AS. The The client sends a POST request to the token endpoint at the AS. The
profile MUST specify how the communication is protected. The content profile MUST specify how the communication is protected. The content
of the request consists of the parameters specified in Section 4 of of the request consists of the parameters specified in Section 4 of
the OAuth 2.0 specification [RFC6749]. the OAuth 2.0 specification [RFC6749].
In addition to these parameters the parameters from In addition to these parameters, a client MUST be able to use the
[I-D.ietf-ace-oauth-params] can be used for requesting an access parameters from [I-D.ietf-ace-oauth-params] in an access token
token from a token endpoint. request to the token endpoint and the AS MUST be able to process
these additional parameters.
If CBOR is used then this parameter MUST be encoded as a CBOR map. If CBOR is used then this parameter MUST be encoded as a CBOR map.
The "scope" parameter can be formatted as specified in [RFC6749] and The "scope" parameter can be formatted as specified in [RFC6749] and
additionally as a byte array, in order to allow compact encoding of additionally as a byte array, in order to allow compact encoding of
complex scopes. complex scopes.
When HTTP is used as a transport then the client makes a request to When HTTP is used as a transport then the client makes a request to
the token endpoint by sending the parameters using the "application/ the token endpoint by sending the parameters using the "application/
x-www-form-urlencoded" format with a character encoding of UTF-8 in x-www-form-urlencoded" format with a character encoding of UTF-8 in
the HTTP request entity-body, as defined in RFC 6749. the HTTP request entity-body, as defined in RFC 6749.
skipping to change at page 20, line 34 skipping to change at page 20, line 30
notation, without abbreviations for better readability. notation, without abbreviations for better readability.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"client_id" : "myclient", "client_id" : "myclient",
"aud" : "tempSensor4711" "req_aud" : "tempSensor4711"
} }
Figure 5: Example request for an access token bound to a symmetric Figure 5: Example request for an access token bound to a symmetric
key. key.
Figure 6 shows a request for a token with an asymmetric proof-of- Figure 6 shows a request for a token with an asymmetric proof-of-
possession key. Note that in this example COSE is used to provide possession key. Note that in this example COSE is used to provide
object-security, therefore the Content-Format is "application/cose" object-security, therefore the Content-Format is "application/cose"
wrapping the "application/ace+cbor" type content. wrapping the "application/ace+cbor" type content. Also note that in
this example the audience is implicitly known by both client and AS.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/cose" Content-Format: "application/cose"
Payload: Payload:
16( # COSE_ENCRYPTED 16( # COSE_ENCRYPTED
[ h'a1010a', # protected header: {"alg" : "AES-CCM-16-64-128"} [ h'a1010a', # protected header: {"alg" : "AES-CCM-16-64-128"}
{5 : b64'ifUvZaHFgJM7UmGnjA'}, # unprotected header, IV {5 : b64'ifUvZaHFgJM7UmGnjA'}, # unprotected header, IV
b64'WXThuZo6TMCaZZqi6ef/8WHTjOdGk8kNzaIhIQ' # ciphertext b64'WXThuZo6TMCaZZqi6ef/8WHTjOdGk8kNzaIhIQ' # ciphertext
] ]
) )
Decrypted payload: Decrypted payload:
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"client_id" : "myclient", "client_id" : "myclient",
"cnf" : { "req_cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "EC", "kty" : "EC",
"kid" : h'11', "kid" : h'11',
"crv" : "P-256", "crv" : "P-256",
"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
} }
} }
} }
skipping to change at page 22, line 14 skipping to change at page 22, line 14
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "token" Uri-Path: "token"
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"client_id" : "myclient", "client_id" : "myclient",
"client_secret" : "mysecret234", "client_secret" : "mysecret234",
"aud" : "valve424", "req_aud" : "valve424",
"scope" : "read", "scope" : "read",
"cnf" : { "req_cnf" : {
"kid" : b64'6kg0dXJM13U' "kid" : b64'6kg0dXJM13U'
} }
} }
Figure 7: Example request for an access token bound to a key Figure 7: Example request for an access token bound to a key
reference. reference.
Refresh tokens are typically not stored as securely as proof-of- Refresh tokens are typically not stored as securely as proof-of-
possession keys in requesting clients. Proof-of-possession based possession keys in requesting clients. Proof-of-possession based
refresh token requests MUST NOT request different proof-of-possession refresh token requests MUST NOT request different proof-of-possession
skipping to change at page 23, line 16 skipping to change at page 23, line 16
towards the RS. See Section 5.6.4.3 for the formatting of this towards the RS. See Section 5.6.4.3 for the formatting of this
parameter. If this parameter is absent, the AS assumes that the parameter. If this parameter is absent, the AS assumes that the
client implicitly knows which profile to use towards the RS. client implicitly knows which profile to use towards the RS.
token_type: token_type:
This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]. This parameter is OPTIONAL, as opposed to 'required' in [RFC6749].
By default implementations of this framework SHOULD assume that By default implementations of this framework SHOULD assume that
the token_type is "pop". If a specific use case requires another the token_type is "pop". If a specific use case requires another
token_type (e.g., "Bearer") to be used then this parameter is token_type (e.g., "Bearer") to be used then this parameter is
REQUIRED. REQUIRED.
Furthermore [I-D.ietf-ace-oauth-params] defines further parameters Furthermore [I-D.ietf-ace-oauth-params] defines additional parameters
the AS can use when responding to a request to the token endpoint. that the AS MUST be able to use when responding to a request to the
token endpoint.
Figure 8 summarizes the parameters that may be part of the Access Figure 8 summarizes the parameters that may be part of the Access
Information. This does not include the additional parameters Information. This does not include the additional parameters
specified in [I-D.ietf-ace-oauth-params]. specified in [I-D.ietf-ace-oauth-params].
/-------------------+-------------------------------\ /-------------------+-------------------------------\
| Parameter name | Specified in | | Parameter name | Specified in |
|-------------------+-------------------------------| |-------------------+-------------------------------|
| access_token | RFC 6749 | | access_token | RFC 6749 |
| token_type | RFC 6749 | | token_type | RFC 6749 |
skipping to change at page 25, line 15 skipping to change at page 25, line 15
/------------------------+-------------\ /------------------------+-------------\
| Name | CBOR Values | | Name | CBOR Values |
|------------------------+-------------| |------------------------+-------------|
| invalid_request | 1 | | invalid_request | 1 |
| invalid_client | 2 | | invalid_client | 2 |
| invalid_grant | 3 | | invalid_grant | 3 |
| unauthorized_client | 4 | | unauthorized_client | 4 |
| unsupported_grant_type | 5 | | unsupported_grant_type | 5 |
| invalid_scope | 6 | | invalid_scope | 6 |
| unsupported_pop_key | 7 | | unsupported_pop_key | 7 |
| incompatible_profiles | 8 |
\------------------------+-------------/ \------------------------+-------------/
Figure 10: CBOR abbreviations for common error codes Figure 10: CBOR abbreviations for common error codes
In addition to the error responses defined in OAuth 2.0, the In addition to the error responses defined in OAuth 2.0, the
following behavior MUST be implemented by the AS: If the client following behavior MUST be implemented by the AS:
submits an asymmetric key in the token request that the RS cannot
process, the AS MUST reject that request with a response code o If the client submits an asymmetric key in the token request that
equivalent to the CoAP code 4.00 (Bad Request) including the error the RS cannot process, the AS MUST reject that request with a
code "unsupported_pop_key" defined in Figure 10. response code equivalent to the CoAP code 4.00 (Bad Request)
including the error code "unsupported_pop_key" defined in
Figure 10.
o If the client and the RS it has requested an access token for do
not share a common profile, the AS MUST reject that request with a
response code equivalent to the CoAP code 4.00 (Bad Request)
including the error code "incompatible_profiles" defined in
Figure 10.
5.6.4. Request and Response Parameters 5.6.4. Request and Response Parameters
This section provides more detail about the new parameters that can This section provides more detail about the new parameters that can
be used in access token requests and responses, as well as be used in access token requests and responses, as well as
abbreviations for more compact encoding of existing parameters and abbreviations for more compact encoding of existing parameters and
common parameter values. common parameter values.
5.6.4.1. Grant Type 5.6.4.1. Grant Type
skipping to change at page 29, line 16 skipping to change at page 29, line 29
In a successful response, the AS encodes the response parameters in a In a successful response, the AS encodes the response parameters in a
map including with the same required and optional parameters as in map including with the same required and optional parameters as in
Section 2.2 of RFC 7662 [RFC7662] with the following addition: Section 2.2 of RFC 7662 [RFC7662] with the following addition:
profile OPTIONAL. This indicates the profile that the RS MUST use profile OPTIONAL. This indicates the profile that the RS MUST use
with the client. See Section 5.6.4.3 for more details on the with the client. See Section 5.6.4.3 for more details on the
formatting of this parameter. formatting of this parameter.
Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that
the AS can use when responding to a request to the introspection the AS MUST be able to use when responding to a request to the
endpoint. introspection endpoint.
For example, Figure 15 shows an AS response to the introspection For example, Figure 15 shows an AS response to the introspection
request in Figure 13. request in Figure 13.
Header: Created Code=2.01) Header: Created Code=2.01)
Content-Format: "application/ace+cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"active" : true, "active" : true,
"scope" : "read", "scope" : "read",
skipping to change at page 32, line 23 skipping to change at page 32, line 43
respond with a response code equivalent to the CoAP code 4.01 respond with a response code equivalent to the CoAP code 4.01
(Unauthorized). If the token is valid but the audience of the token (Unauthorized). If the token is valid but the audience of the token
does not match the RS, the RS MUST respond with a response code does not match the RS, the RS MUST respond with a response code
equivalent to the CoAP code 4.03 (Forbidden). If the token is valid equivalent to the CoAP code 4.03 (Forbidden). If the token is valid
but is associated to claims that the RS cannot process (e.g., an but is associated to claims that the RS cannot process (e.g., an
unknown scope) the RS MUST respond with a response code equivalent to unknown scope) the RS MUST respond with a response code equivalent to
the CoAP code 4.00 (Bad Request). In the latter case the RS MAY the CoAP code 4.00 (Bad Request). In the latter case the RS MAY
provide additional information in the error response, in order to provide additional information in the error response, in order to
clarify what went wrong. clarify what went wrong.
The RS MAY use the error codes from section 3.1 of [RFC6750] when
giving error responses, in order to provide additional detail.
The RS MAY make an introspection request to validate the token before The RS MAY make an introspection request to validate the token before
responding to the POST request to the authz-info endpoint. responding to the POST request to the authz-info endpoint.
Profiles MUST specify whether the authz-info endpoint is protected, Profiles MUST specify whether the authz-info endpoint is protected,
including whether error responses from this endpoint are protected. including whether error responses from this endpoint are protected.
Note that since the token contains information that allow the client Note that since the token contains information that allow the client
and the RS to establish a security context in the first place, mutual and the RS to establish a security context in the first place, mutual
authentication may not be possible at this point. authentication may not be possible at this point.
The default name of this endpoint in an url-path is '/authz-info', The default name of this endpoint in an url-path is '/authz-info',
skipping to change at page 34, line 14 skipping to change at page 34, line 38
If a token that authorizes a long running request such as a CoAP If a token that authorizes a long running request such as a CoAP
Observe [RFC7641] expires, the RS MUST send an error response with Observe [RFC7641] expires, the RS MUST send an error response with
the response code equivalent to the CoAP code 4.01 (Unauthorized) to the response code equivalent to the CoAP code 4.01 (Unauthorized) to
the client and then terminate processing the long running request. the client and then terminate processing the long running request.
6. Security Considerations 6. Security Considerations
Security considerations applicable to authentication and Security considerations applicable to authentication and
authorization in RESTful environments provided in OAuth 2.0 [RFC6749] authorization in RESTful environments provided in OAuth 2.0 [RFC6749]
apply to this work, as well as the security considerations from apply to this work. Furthermore [RFC6819] provides additional
[I-D.ietf-ace-actors]. Furthermore [RFC6819] provides additional
security considerations for OAuth which apply to IoT deployments as security considerations for OAuth which apply to IoT deployments as
well. well.
A large range of threats can be mitigated by protecting the contents A large range of threats can be mitigated by protecting the contents
of the access token by using a digital signature or a keyed message of the access token by using a digital signature or a keyed message
digest (MAC) or an Authenticated Encryption with Associated Data digest (MAC) or an Authenticated Encryption with Associated Data
(AEAD) algorithm. Consequently, the token integrity protection MUST (AEAD) algorithm. Consequently, the token integrity protection MUST
be applied to prevent the token from being modified, particularly be applied to prevent the token from being modified, particularly
since it contains a reference to the symmetric key or the asymmetric since it contains a reference to the symmetric key or the asymmetric
key. If the access token contains the symmetric key, this symmetric key. If the access token contains the symmetric key, this symmetric
skipping to change at page 37, line 11 skipping to change at page 37, line 33
information as possible in an unencrypted response. Means of information as possible in an unencrypted response. Means of
encrypting communication between C and RS already exist, more encrypting communication between C and RS already exist, more
detailed information may be included with an error response to detailed information may be included with an error response to
provide C with sufficient information to react on that particular provide C with sufficient information to react on that particular
error. error.
8. IANA Considerations 8. IANA Considerations
8.1. Authorization Server Information 8.1. Authorization Server Information
This section establishes the IANA "ACE Authorization Server This specification establishes the IANA "ACE Authorization Server
Information" registry. The registry has been created to use the Information" registry. The registry has been created to use the
"Expert Review Required" registration procedure [RFC8126]. It should "Expert Review Required" registration procedure [RFC8126]. It should
be noted that, in addition to the expert review, some portions of the be noted that, in addition to the expert review, some portions of the
registry require a specification, potentially a Standards Track RFC, registry require a specification, potentially a Standards Track RFC,
be supplied as well. be supplied as well.
The columns of the registry are: The columns of the registry are:
Name The name of the parameter Name The name of the parameter
CBOR Key CBOR map key for the parameter. Different ranges of values CBOR Key CBOR map key for the parameter. Different ranges of values
skipping to change at page 37, line 30 skipping to change at page 38, line 4
Name The name of the parameter Name The name of the parameter
CBOR Key CBOR map key for the parameter. Different ranges of values CBOR Key CBOR map key for the parameter. Different ranges of values
use different registration policies [RFC8126]. Integer values use different registration policies [RFC8126]. Integer values
from -256 to 255 are designated as Standards Action. Integer from -256 to 255 are designated as Standards Action. Integer
values from -65536 to -257 and from 256 to 65535 are designated as values from -65536 to -257 and from 256 to 65535 are designated as
Specification Required. Integer values greater than 65535 are Specification Required. Integer values greater than 65535 are
designated as Expert Review. Integer values less than -65536 are designated as Expert Review. Integer values less than -65536 are
marked as Private Use. marked as Private Use.
Value Type The CBOR data types allowable for the values of this Value Type The CBOR data types allowable for the values of this
parameter. parameter.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
This registry will be initially populated by the values in Figure 2. This registry will be initially populated by the values in Figure 2.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.2. OAuth Error Code CBOR Mappings Registry 8.2. OAuth Extensions Error Registration
This section establish the IANA "OAuth Error Code CBOR Mappings" This specification registers the follwoing error values in the OAuth
registry. The registry has been created to use the "Expert Review Extensions Error registry defined in [RFC6749].
Required" registration procedure [RFC8126]. It should be noted that,
in addition to the expert review, some portions of the registry o Error name: "unsupported_pop_key"
require a specification, potentially a Standards Track RFC, be o Error usage location: AS token endpoint error response
supplied as well. o Related protocol extension: The ACE framework [this document]
o Change Controller: IESG
o Specification doucment(s): Section 5.6.3 of [this document]
o Error name: "incompatible_profiles"
o Error usage location: AS token endpoint error response
o Related protocol extension: The ACE framework [this document]
o Change Controller: IESG
o Specification doucment(s): Section 5.6.3 of [this document]
8.3. OAuth Error Code CBOR Mappings Registry
This specification establishes the IANA "OAuth Error Code CBOR
Mappings" registry. The registry has been created to use the "Expert
Review Required" registration procedure [RFC8126]. It should be
noted that, in addition to the expert review, some portions of the
registry require a specification, potentially a Standards Track RFC,
be supplied as well.
The columns of the registry are: The columns of the registry are:
Name The OAuth Error Code name, refers to the name in Section 5.2. Name The OAuth Error Code name, refers to the name in Section 5.2.
of [RFC6749], e.g., "invalid_request". of [RFC6749], e.g., "invalid_request".
CBOR Value CBOR abbreviation for this error code. Different ranges CBOR Value CBOR abbreviation for this error code. Different ranges
of values use different registration policies [RFC8126]. Integer of values use different registration policies [RFC8126]. Integer
values from -256 to 255 are designated as Standards Action. values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than 65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use. -65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
This registry will be initially populated by the values in Figure 10. This registry will be initially populated by the values in Figure 10.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
skipping to change at page 38, line 15 skipping to change at page 39, line 5
Integer values from -65536 to -257 and from 256 to 65535 are Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than 65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use. -65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
This registry will be initially populated by the values in Figure 10. This registry will be initially populated by the values in Figure 10.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.3. OAuth Grant Type CBOR Mappings 8.4. OAuth Grant Type CBOR Mappings
This section establishes the IANA "OAuth Grant Type CBOR Mappings" This specification establishes the IANA "OAuth Grant Type CBOR
registry. The registry has been created to use the "Expert Review Mappings" registry. The registry has been created to use the "Expert
Required" registration procedure [RFC8126]. It should be noted that, Review Required" registration procedure [RFC8126]. It should be
in addition to the expert review, some portions of the registry noted that, in addition to the expert review, some portions of the
require a specification, potentially a Standards Track RFC, be registry require a specification, potentially a Standards Track RFC,
supplied as well. be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The name of the grant type as specified in Section 1.3 of Name The name of the grant type as specified in Section 1.3 of
[RFC6749]. [RFC6749].
CBOR Value CBOR abbreviation for this grant type. Different ranges CBOR Value CBOR abbreviation for this grant type. Different ranges
of values use different registration policies [RFC8126]. Integer of values use different registration policies [RFC8126]. Integer
values from -256 to 255 are designated as Standards Action. values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than 65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use. -65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
Original Specification This contains a pointer to the public Original Specification This contains a pointer to the public
specification of the grant type, if one exists. specification of the grant type, if one exists.
This registry will be initially populated by the values in Figure 11. This registry will be initially populated by the values in Figure 11.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.4. OAuth Access Token Types 8.5. OAuth Access Token Types
This section registers the following new token type in the "OAuth This section registers the following new token type in the "OAuth
Access Token Types" registry [IANA.OAuthAccessTokenTypes]. Access Token Types" registry [IANA.OAuthAccessTokenTypes].
o Name: "PoP" o Name: "PoP"
o Change Controller: IETF o Change Controller: IETF
o Reference: [this document] o Reference: [this document]
8.5. OAuth Token Type CBOR Mappings 8.6. OAuth Token Type CBOR Mappings
This section eatables the IANA "Token Type CBOR Mappings" registry. This specification established the IANA "Token Type CBOR Mappings"
The registry has been created to use the "Expert Review Required" registry. The registry has been created to use the "Expert Review
registration procedure [RFC8126]. It should be noted that, in Required" registration procedure [RFC8126]. It should be noted that,
addition to the expert review, some portions of the registry require in addition to the expert review, some portions of the registry
a specification, potentially a Standards Track RFC, be supplied as require a specification, potentially a Standards Track RFC, be
well. supplied as well.
The columns of this registry are: The columns of this registry are:
Name The name of token type as registered in the OAuth Access Token Name The name of token type as registered in the OAuth Access Token
Types registry, e.g., "Bearer". Types registry, e.g., "Bearer".
CBOR Value CBOR abbreviation for this token type. Different ranges CBOR Value CBOR abbreviation for this token type. Different ranges
of values use different registration policies [RFC8126]. Integer of values use different registration policies [RFC8126]. Integer
values from -256 to 255 are designated as Standards Action. values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than designated as Specification Required. Integer values greater than
65535 are designated as Expert Review. Integer values less than 65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use. -65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
OAuth token type abbreviation, if one exists. OAuth token type abbreviation, if one exists.
Original Specification This contains a pointer to the public Original Specification This contains a pointer to the public
specification of the grant type, if one exists. specification of the grant type, if one exists.
8.5.1. Initial Registry Contents 8.6.1. Initial Registry Contents
o Name: "Bearer" o Name: "Bearer"
o Value: 1 o Value: 1
o Reference: [this document] o Reference: [this document]
o Original Specification: [RFC6749] o Original Specification: [RFC6749]
o Name: "pop" o Name: "pop"
o Value: 2 o Value: 2
o Reference: [this document] o Reference: [this document]
o Original Specification: [this document] o Original Specification: [this document]
8.6. ACE Profile Registry 8.7. ACE Profile Registry
This section establishes the IANA "ACE Profile" registry. The This specification establishes the IANA "ACE Profile" registry. The
registry has been created to use the "Expert Review Required" registry has been created to use the "Expert Review Required"
registration procedure [RFC8126]. It should be noted that, in registration procedure [RFC8126]. It should be noted that, in
addition to the expert review, some portions of the registry require addition to the expert review, some portions of the registry require
a specification, potentially a Standards Track RFC, be supplied as a specification, potentially a Standards Track RFC, be supplied as
well. well.
The columns of this registry are: The columns of this registry are:
Name The name of the profile, to be used as value of the profile Name The name of the profile, to be used as value of the profile
attribute. attribute.
skipping to change at page 40, line 16 skipping to change at page 41, line 4
attribute. attribute.
Description Text giving an overview of the profile and the context Description Text giving an overview of the profile and the context
it is developed for. it is developed for.
CBOR Value CBOR abbreviation for this profile name. Different CBOR Value CBOR abbreviation for this profile name. Different
ranges of values use different registration policies [RFC8126]. ranges of values use different registration policies [RFC8126].
Integer values from -256 to 255 are designated as Standards Integer values from -256 to 255 are designated as Standards
Action. Integer values from -65536 to -257 and from 256 to 65535 Action. Integer values from -65536 to -257 and from 256 to 65535
are designated as Specification Required. Integer values greater are designated as Specification Required. Integer values greater
than 65535 are designated as Expert Review. Integer values less than 65535 are designated as Expert Review. Integer values less
than -65536 are marked as Private Use. than -65536 are marked as Private Use.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
profile abbreviation, if one exists. profile abbreviation, if one exists.
8.7. OAuth Parameter Registration 8.8. OAuth Parameter Registration
This section registers the following parameter in the "OAuth This specification registers the following parameter in the "OAuth
Parameters" registry [IANA.OAuthParameters]: Parameters" registry [IANA.OAuthParameters]:
o Name: "profile" o Name: "profile"
o Parameter Usage Location: token response o Parameter Usage Location: token response
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.6.4.3 of [this document] o Reference: Section 5.6.4.3 of [this document]
8.8. OAuth CBOR Parameter Mappings Registry 8.9. OAuth CBOR Parameter Mappings Registry
This section establishes the IANA "Token Endpoint CBOR Mappings" This specification establishes the IANA "Token Endpoint CBOR
registry. The registry has been created to use the "Expert Review Mappings" registry. The registry has been created to use the "Expert
Required" registration procedure [RFC8126]. It should be noted that, Review Required" registration procedure [RFC8126]. It should be
in addition to the expert review, some portions of the registry noted that, in addition to the expert review, some portions of the
require a specification, potentially a Standards Track RFC, be registry require a specification, potentially a Standards Track RFC,
supplied as well. be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The OAuth Parameter name, refers to the name in the OAuth Name The OAuth Parameter name, refers to the name in the OAuth
parameter registry, e.g., "client_id". parameter registry, e.g., "client_id".
CBOR Key CBOR map key for this parameter. Different ranges of CBOR Key CBOR map key for this parameter. Different ranges of
values use different registration policies [RFC8126]. Integer values use different registration policies [RFC8126]. Integer
values from -256 to 255 are designated as Standards Action. values from -256 to 255 are designated as Standards Action.
Integer values from -65536 to -257 and from 256 to 65535 are Integer values from -65536 to -257 and from 256 to 65535 are
designated as Specification Required. Integer values greater than designated as Specification Required. Integer values greater than
skipping to change at page 41, line 11 skipping to change at page 42, line 5
parameter. parameter.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
This registry will be initially populated by the values in Figure 12. This registry will be initially populated by the values in Figure 12.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
Note that these mappings intentionally coincide with the CWT claim Note that these mappings intentionally coincide with the CWT claim
name mappings from [RFC8392]. name mappings from [RFC8392].
8.9. OAuth Introspection Response Parameter Registration 8.10. OAuth Introspection Response Parameter Registration
This section registers the following parameter in the OAuth Token This specification registers the following parameter in the OAuth
Introspection Response registry [IANA.TokenIntrospectionResponse]. Token Introspection Response registry
[IANA.TokenIntrospectionResponse].
o Name: "profile" o Name: "profile"
o Description: The communication and communication security profile o Description: The communication and communication security profile
used between client and RS, as defined in ACE profiles. used between client and RS, as defined in ACE profiles.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.7.2 of [this document] o Reference: Section 5.7.2 of [this document]
8.10. Introspection Endpoint CBOR Mappings Registry 8.11. Introspection Endpoint CBOR Mappings Registry
This section establishes the IANA "Introspection Endpoint CBOR This specification establishes the IANA "Introspection Endpoint CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review Required" registration procedure [RFC8126]. It should be Review Required" registration procedure [RFC8126]. It should be
noted that, in addition to the expert review, some portions of the noted that, in addition to the expert review, some portions of the
registry require a specification, potentially a Standards Track RFC, registry require a specification, potentially a Standards Track RFC,
be supplied as well. be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The OAuth Parameter name, refers to the name in the OAuth Name The OAuth Parameter name, refers to the name in the OAuth
parameter registry, e.g., "client_id". parameter registry, e.g., "client_id".
skipping to change at page 42, line 5 skipping to change at page 42, line 45
65535 are designated as Expert Review. Integer values less than 65535 are designated as Expert Review. Integer values less than
-65536 are marked as Private Use. -65536 are marked as Private Use.
Value Type The allowable CBOR data types for values of this Value Type The allowable CBOR data types for values of this
parameter. parameter.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
This registry will be initially populated by the values in Figure 16. This registry will be initially populated by the values in Figure 16.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.11. JSON Web Token Claims 8.12. JSON Web Token Claims
This specification registers the following new claims in the JSON Web This specification registers the following new claims in the JSON Web
Token (JWT) registry of JSON Web Token Claims Token (JWT) registry of JSON Web Token Claims
[IANA.JsonWebTokenClaims]: [IANA.JsonWebTokenClaims]:
o Claim Name: "scope" o Claim Name: "scope"
o Claim Description: The scope of an access token as defined in o Claim Description: The scope of an access token as defined in
[RFC6749]. [RFC6749].
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8 of [this document] o Reference: Section 5.8 of [this document]
skipping to change at page 42, line 29 skipping to change at page 43, line 21
with. with.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8 of [this document] o Reference: Section 5.8 of [this document]
o Claim Name: "rs_cnf" o Claim Name: "rs_cnf"
o Claim Description: The public key the RS is supposed to use to o Claim Description: The public key the RS is supposed to use to
authenticate to the client wielding this token. authenticate to the client wielding this token.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8 of [this document] o Reference: Section 5.8 of [this document]
8.12. CBOR Web Token Claims 8.13. CBOR Web Token Claims
This specification registers the following new claims in the "CBOR This specification registers the following new claims in the "CBOR
Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].
o Claim Name: "scope" o Claim Name: "scope"
o Claim Description: The scope of an access token as defined in o Claim Description: The scope of an access token as defined in
[RFC6749]. [RFC6749].
o JWT Claim Name: N/A o JWT Claim Name: N/A
o Claim Key: 12 o Claim Key: 12
o Claim Value Type(s): byte string or text string o Claim Value Type(s): byte string or text string
skipping to change at page 43, line 12 skipping to change at page 44, line 5
o Claim Name: "rs_cnf" o Claim Name: "rs_cnf"
o Claim Description: The public key the RS is supposed to use to o Claim Description: The public key the RS is supposed to use to
authenticate to the client wielding this token. authenticate to the client wielding this token.
o JWT Claim Name: N/A o JWT Claim Name: N/A
o Claim Key: 17 o Claim Key: 17
o Claim Value Type(s): map o Claim Value Type(s): map
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.8 of [this document]
8.13. Media Type Registrations 8.14. Media Type Registrations
This document registers the 'application/ace+cbor' media type for This specification registers the 'application/ace+cbor' media type
messages of the protocols defined in this document carrying for messages of the protocols defined in this document carrying
parameters encoded in CBOR. This registration follows the procedures parameters encoded in CBOR. This registration follows the procedures
specified in [RFC6838]. specified in [RFC6838].
Type name: application Type name: application
Subtype name: ace+cbor Subtype name: ace+cbor
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
skipping to change at page 44, line 4 skipping to change at page 44, line 45
Magic number(s): n/a Magic number(s): n/a
File extension(s): .ace File extension(s): .ace
Macintosh file type code(s): n/a Macintosh file type code(s): n/a
Person & email address to contact for further information: Ludwig Person & email address to contact for further information: Ludwig
Seitz <ludwig.seitz@ri.se> Seitz <ludwig.seitz@ri.se>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Ludwig Seitz <ludwig.setiz@ri.se> Author: Ludwig Seitz <ludwig.setiz@ri.se>
Change controller: IESG Change controller: IESG
8.14. CoAP Content-Format Registry 8.15. CoAP Content-Format Registry
This document registers the following entry to the "CoAP Content- This specification registers the following entry to the "CoAP
Formats" registry: Content-Formats" registry:
Media Type: application/ace+cbor Media Type: application/ace+cbor
Encoding Encoding
ID: 19 ID: 19
Reference: [this document] Reference: [this document]
9. Acknowledgments 9. Acknowledgments
skipping to change at page 45, line 48 skipping to change at page 46, line 43
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, <https://www.rfc-
editor.org/info/rfc6750>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, <https://www.rfc- DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
editor.org/info/rfc7252>. editor.org/info/rfc7252>.
skipping to change at page 46, line 38 skipping to change at page 47, line 43
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
10.2. Informative References 10.2. Informative References
[I-D.erdtman-ace-rpcc] [I-D.erdtman-ace-rpcc]
Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
Key as OAuth client credentials", draft-erdtman-ace- Key as OAuth client credentials", draft-erdtman-ace-
rpcc-02 (work in progress), October 2017. rpcc-02 (work in progress), October 2017.
[I-D.ietf-ace-actors]
Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
architecture for authorization in constrained
environments", draft-ietf-ace-actors-06 (work in
progress), November 2017.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), August 2018. progress), August 2018.
[I-D.ietf-oauth-device-flow] [I-D.ietf-oauth-device-flow]
Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, Denniss, W., Bradley, J., Jones, M., and H. Tschofenig,
"OAuth 2.0 Device Flow for Browserless and Input "OAuth 2.0 Device Flow for Browserless and Input
Constrained Devices", draft-ietf-oauth-device-flow-12 Constrained Devices", draft-ietf-oauth-device-flow-12
skipping to change at page 47, line 32 skipping to change at page 48, line 32
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc- DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013, <https://www.rfc- DOI 10.17487/RFC6819, January 2013, <https://www.rfc-
editor.org/info/rfc6819>. editor.org/info/rfc6819>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
skipping to change at page 58, line 8 skipping to change at page 59, line 8
| | | |
Figure 17: Token Request and Response Using Client Credentials. Figure 17: Token Request and Response Using Client Credentials.
The information contained in the Request-Payload and the Response- The information contained in the Request-Payload and the Response-
Payload is shown in Figure 18. Payload is shown in Figure 18.
Request-Payload : Request-Payload :
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"aud" : "tempSensorInLivingRoom", "req_aud" : "tempSensorInLivingRoom",
"client_id" : "myclient", "client_id" : "myclient",
"client_secret" : "qwerty" "client_secret" : "qwerty"
"cnf" : { "req_cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kid" : b64'1Bg8vub9tLe1gHMzV76e8', "kid" : b64'1Bg8vub9tLe1gHMzV76e8',
"kty" : "EC", "kty" : "EC",
"crv" : "P-256", "crv" : "P-256",
"x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU', "x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
"y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0' "y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
} }
} }
} }
skipping to change at page 64, line 32 skipping to change at page 65, line 32
F: |<--------+ Header: 2.04 Changed F: |<--------+ Header: 2.04 Changed
| 2.04 | Payload: <new state for the lock> | 2.04 | Payload: <new state for the lock>
| | | |
Figure 26: Resource request and response protected by OSCORE Figure 26: Resource request and response protected by OSCORE
Appendix F. Document Updates Appendix F. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION. RFC EDITOR: PLEASE REMOVE THIS SECTION.
F.1. Version -14 to -15 F.1. Version -15 to -16
o Added text the RS using RFC6750 error codes.
o Defined an error code for incompatible token request parameters.
o Removed references to the actors draft.
o Fixed errors in examples.
F.2. Version -14 to -15
o Added text about refresh tokens. o Added text about refresh tokens.
o Added text about protection of credentials. o Added text about protection of credentials.
o Rephrased introspection so that other entities than RS can do it. o Rephrased introspection so that other entities than RS can do it.
o Editorial improvements. o Editorial improvements.
F.2. Version -13 to -14 F.3. Version -13 to -14
o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
o Introduced the "application/ace+cbor" Content-Type. o Introduced the "application/ace+cbor" Content-Type.
o Added claim registrations from 'profile' and 'rs_cnf'. o Added claim registrations from 'profile' and 'rs_cnf'.
o Added note on schema part of AS Information Section 5.1.2 o Added note on schema part of AS Information Section 5.1.2
o Realigned the parameter abbreviations to push rarely used ones to o Realigned the parameter abbreviations to push rarely used ones to
the 2-byte encoding size of CBOR integers. the 2-byte encoding size of CBOR integers.
F.3. Version -12 to -13 F.4. Version -12 to -13
o Changed "Resource Information" to "Access Information" to avoid o Changed "Resource Information" to "Access Information" to avoid
confusion. confusion.
o Clarified section about AS discovery. o Clarified section about AS discovery.
o Editorial changes o Editorial changes
F.4. Version -11 to -12 F.5. Version -11 to -12
o Moved the Request error handling to a section of its own. o Moved the Request error handling to a section of its own.
o Require the use of the abbreviation for profile identifiers. o Require the use of the abbreviation for profile identifiers.
o Added rs_cnf parameter in the introspection response, to inform o Added rs_cnf parameter in the introspection response, to inform
RS' with several RPKs on which key to use. RS' with several RPKs on which key to use.
o Allowed use of rs_cnf as claim in the access token in order to o Allowed use of rs_cnf as claim in the access token in order to
inform an RS with several RPKs on which key to use. inform an RS with several RPKs on which key to use.
o Clarified that profiles must specify if/how error responses are o Clarified that profiles must specify if/how error responses are
protected. protected.
o Fixed label number range to align with COSE/CWT. o Fixed label number range to align with COSE/CWT.
o Clarified the requirements language in order to allow profiles to o Clarified the requirements language in order to allow profiles to
specify other payload formats than CBOR if they do not use CoAP. specify other payload formats than CBOR if they do not use CoAP.
F.5. Version -10 to -11 F.6. Version -10 to -11
o Fixed some CBOR data type errors. o Fixed some CBOR data type errors.
o Updated boilerplate text o Updated boilerplate text
F.6. Version -09 to -10 F.7. Version -09 to -10
o Removed CBOR major type numbers. o Removed CBOR major type numbers.
o Removed the client token design. o Removed the client token design.
o Rephrased to clarify that other protocols than CoAP can be used. o Rephrased to clarify that other protocols than CoAP can be used.
o Clarifications regarding the use of HTTP o Clarifications regarding the use of HTTP
F.7. Version -08 to -09 F.8. Version -08 to -09
o Allowed scope to be byte arrays. o Allowed scope to be byte arrays.
o Defined default names for endpoints. o Defined default names for endpoints.
o Refactored the IANA section for briefness and consistency. o Refactored the IANA section for briefness and consistency.
o Refactored tables that define IANA registry contents for o Refactored tables that define IANA registry contents for
consistency. consistency.
o Created IANA registry for CBOR mappings of error codes, grant o Created IANA registry for CBOR mappings of error codes, grant
types and Authorization Server Information. types and Authorization Server Information.
o Added references to other document sections defining IANA entries o Added references to other document sections defining IANA entries
in the IANA section. in the IANA section.
F.8. Version -07 to -08 F.9. Version -07 to -08
o Moved AS discovery from the DTLS profile to the framework, see o Moved AS discovery from the DTLS profile to the framework, see
Section 5.1. Section 5.1.
o Made the use of CBOR mandatory. If you use JSON you can use o Made the use of CBOR mandatory. If you use JSON you can use
vanilla OAuth. vanilla OAuth.
o Made it mandatory for profiles to specify C-AS security and RS-AS o Made it mandatory for profiles to specify C-AS security and RS-AS
security (the latter only if introspection is supported). security (the latter only if introspection is supported).
o Made the use of CBOR abbreviations mandatory. o Made the use of CBOR abbreviations mandatory.
o Added text to clarify the use of token references as an o Added text to clarify the use of token references as an
alternative to CWTs. alternative to CWTs.
skipping to change at page 66, line 33 skipping to change at page 67, line 33
o Added text that clarifies that introspection is optional. o Added text that clarifies that introspection is optional.
o Made profile parameter optional since it can be implicit. o Made profile parameter optional since it can be implicit.
o Clarified that CoAP is not mandatory and other protocols can be o Clarified that CoAP is not mandatory and other protocols can be
used. used.
o Clarified the design justification for specific features of the o Clarified the design justification for specific features of the
framework in appendix A. framework in appendix A.
o Clarified appendix E.2. o Clarified appendix E.2.
o Removed specification of the "cnf" claim for CBOR/COSE, and o Removed specification of the "cnf" claim for CBOR/COSE, and
replaced with references to [I-D.ietf-ace-cwt-proof-of-possession] replaced with references to [I-D.ietf-ace-cwt-proof-of-possession]
F.9. Version -06 to -07 F.10. Version -06 to -07
o Various clarifications added. o Various clarifications added.
o Fixed erroneous author email. o Fixed erroneous author email.
F.10. Version -05 to -06 F.11. Version -05 to -06
o Moved sections that define the ACE framework into a subsection of o Moved sections that define the ACE framework into a subsection of
the framework Section 5. the framework Section 5.
o Split section on client credentials and grant into two separate o Split section on client credentials and grant into two separate
sections, Section 5.2, and Section 5.3. sections, Section 5.2, and Section 5.3.
o Added Section 5.4 on AS authentication. o Added Section 5.4 on AS authentication.
o Added Section 5.5 on the Authorization endpoint. o Added Section 5.5 on the Authorization endpoint.
F.11. Version -04 to -05 F.12. Version -04 to -05
o Added RFC 2119 language to the specification of the required o Added RFC 2119 language to the specification of the required
behavior of profile specifications. behavior of profile specifications.
o Added Section 5.3 on the relation to the OAuth2 grant types. o Added Section 5.3 on the relation to the OAuth2 grant types.
o Added CBOR abbreviations for error and the error codes defined in o Added CBOR abbreviations for error and the error codes defined in
OAuth2. OAuth2.
o Added clarification about token expiration and long-running o Added clarification about token expiration and long-running
requests in Section 5.8.3 requests in Section 5.8.3
o Added security considerations about tokens with symmetric pop keys o Added security considerations about tokens with symmetric pop keys
valid for more than one RS. valid for more than one RS.
o Added privacy considerations section. o Added privacy considerations section.
o Added IANA registry mapping the confirmation types from RFC 7800 o Added IANA registry mapping the confirmation types from RFC 7800
to equivalent COSE types. to equivalent COSE types.
o Added appendix D, describing assumptions about what the AS knows o Added appendix D, describing assumptions about what the AS knows
about the client and the RS. about the client and the RS.
F.12. Version -03 to -04 F.13. Version -03 to -04
o Added a description of the terms "framework" and "profiles" as o Added a description of the terms "framework" and "profiles" as
used in this document. used in this document.
o Clarified protection of access tokens in section 3.1. o Clarified protection of access tokens in section 3.1.
o Clarified uses of the "cnf" parameter in section 6.4.5. o Clarified uses of the "cnf" parameter in section 6.4.5.
o Clarified intended use of Client Token in section 7.4. o Clarified intended use of Client Token in section 7.4.
F.13. Version -02 to -03 F.14. Version -02 to -03
o Removed references to draft-ietf-oauth-pop-key-distribution since o Removed references to draft-ietf-oauth-pop-key-distribution since
the status of this draft is unclear. the status of this draft is unclear.
o Copied and adapted security considerations from draft-ietf-oauth- o Copied and adapted security considerations from draft-ietf-oauth-
pop-key-distribution. pop-key-distribution.
o Renamed "client information" to "RS information" since it is o Renamed "client information" to "RS information" since it is
information about the RS. information about the RS.
o Clarified the requirements on profiles of this framework. o Clarified the requirements on profiles of this framework.
o Clarified the token endpoint protocol and removed negotiation of o Clarified the token endpoint protocol and removed negotiation of
"profile" and "alg" (section 6). "profile" and "alg" (section 6).
o Renumbered the abbreviations for claims and parameters to get a o Renumbered the abbreviations for claims and parameters to get a
consistent numbering across different endpoints. consistent numbering across different endpoints.
o Clarified the introspection endpoint. o Clarified the introspection endpoint.
o Renamed token, introspection and authz-info to "endpoint" instead o Renamed token, introspection and authz-info to "endpoint" instead
of "resource" to mirror the OAuth 2.0 terminology. of "resource" to mirror the OAuth 2.0 terminology.
o Updated the examples in the appendices. o Updated the examples in the appendices.
F.14. Version -01 to -02 F.15. Version -01 to -02
o Restructured to remove communication security parts. These shall o Restructured to remove communication security parts. These shall
now be defined in profiles. now be defined in profiles.
o Restructured section 5 to create new sections on the OAuth o Restructured section 5 to create new sections on the OAuth
endpoints token, introspection and authz-info. endpoints token, introspection and authz-info.
o Pulled in material from draft-ietf-oauth-pop-key-distribution in o Pulled in material from draft-ietf-oauth-pop-key-distribution in
order to define proof-of-possession key distribution. order to define proof-of-possession key distribution.
o Introduced the "cnf" parameter as defined in RFC7800 to reference o Introduced the "cnf" parameter as defined in RFC7800 to reference
or transport keys used for proof of possession. or transport keys used for proof of possession.
o Introduced the "client-token" to transport client information from o Introduced the "client-token" to transport client information from
the AS to the client via the RS in conjunction with introspection. the AS to the client via the RS in conjunction with introspection.
o Expanded the IANA section to define parameters for token request, o Expanded the IANA section to define parameters for token request,
introspection and CWT claims. introspection and CWT claims.
o Moved deployment scenarios to the appendix as examples. o Moved deployment scenarios to the appendix as examples.
F.15. Version -00 to -01 F.16. Version -00 to -01
o Changed 5.1. from "Communication Security Protocol" to "Client o Changed 5.1. from "Communication Security Protocol" to "Client
Information". Information".
o Major rewrite of 5.1 to clarify the information exchanged between o Major rewrite of 5.1 to clarify the information exchanged between
C and AS in the PoP access token request profile for IoT. C and AS in the PoP access token request profile for IoT.
* Allow the client to indicate preferences for the communication * Allow the client to indicate preferences for the communication
security protocol. security protocol.
* Defined the term "Client Information" for the additional * Defined the term "Client Information" for the additional
information returned to the client in addition to the access information returned to the client in addition to the access
 End of changes. 74 change blocks. 
158 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/