< draft-ietf-ace-oauth-authz-13.txt   draft-ietf-ace-oauth-authz-14.txt >
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft RISE SICS Internet-Draft RISE SICS
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: January 3, 2019 Ericsson Expires: March 23, 2019 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
July 2, 2018 September 19, 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-13 draft-ietf-ace-oauth-authz-14
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 January 3, 2019. This Internet-Draft will expire on March 23, 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 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . 18 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. Audience . . . . . . . . . . . . . . . . . . . . 25 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 25
5.6.4.2. Grant Type . . . . . . . . . . . . . . . . . . . 25 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 26
5.6.4.3. Token Type . . . . . . . . . . . . . . . . . . . 26 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 26
5.6.4.4. Profile . . . . . . . . . . . . . . . . . . . . . 26 5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 26
5.6.4.5. Confirmation . . . . . . . . . . . . . . . . . . 27 5.7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 27
5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 27 5.7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 28
5.7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . 28 5.7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 28
5.7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . 29 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 29
5.7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . 30 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 30
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 31 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 31
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 31 5.8.1. The 'Authorization Information' Endpoint . . . . . . 31
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 32 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 32
5.8.1. The 'Authorization Information' Endpoint . . . . . . 33 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 33
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 34 6.1. Unprotected AS Information . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 35
6.1. Unprotected AS Information . . . . . . . . . . . . . . . 36 6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 35
6.2. Use of Nonces for Replay Protection . . . . . . . . . . . 37 6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 36
6.3. Combining profiles . . . . . . . . . . . . . . . . . . . 37 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
6.4. Error responses . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 8.1. Authorization Server Information . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8.2. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 37
8.1. Authorization Server Information . . . . . . . . . . . . 38 8.3. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 38
8.2. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 39 8.4. OAuth Access Token Types . . . . . . . . . . . . . . . . 38
8.3. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 39 8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 39
8.4. OAuth Access Token Types . . . . . . . . . . . . . . . . 40 8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 39
8.5. OAuth Token Type CBOR Mappings . . . . . . . . . . . . . 40 8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 39
8.5.1. Initial Registry Contents . . . . . . . . . . . . . . 41 8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 40
8.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 41 8.8. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 40
8.7. OAuth Parameter Registration . . . . . . . . . . . . . . 41 8.9. OAuth Introspection Response Parameter Registration . . . 41
8.8. OAuth CBOR Parameter Mappings Registry . . . . . . . . . 42 8.10. Introspection Endpoint CBOR Mappings Registry . . . . . . 41
8.9. OAuth Introspection Response Parameter Registration . . . 43 8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 42
8.10. Introspection Endpoint CBOR Mappings Registry . . . . . . 43 8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 42
8.11. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 44 8.13. Media Type Registrations . . . . . . . . . . . . . . . . 43
8.12. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 44 8.13.1. Media Type Registration . . . . . . . . . . . . . . 43
8.14. CoAP Content-Format Registry . . . . . . . . . . . . . . 44
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 45 10.1. Normative References . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Design Justification . . . . . . . . . . . . . . . . 49 Appendix A. Design Justification . . . . . . . . . . . . . . . . 49
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 52 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 52
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 54 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 54
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 55 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 55
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 55 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 55
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 56 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 56
E.2. Introspection Aided Token Validation . . . . . . . . . . 60 E.2. Introspection Aided Token Validation . . . . . . . . . . 60
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 64 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 64
F.1. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 64 F.1. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 64
F.2. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 64 F.2. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 64
F.3. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 65 F.3. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 65
F.4. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 65 F.4. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 65
F.5. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 65 F.5. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 65
F.6. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 65 F.6. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 65
F.7. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 66 F.7. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 65
F.8. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 66 F.8. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 66
F.9. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 66 F.9. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 66
F.10. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 66 F.10. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 66
F.11. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 66 F.11. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 67
F.12. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 67 F.12. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 67
F.13. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 67 F.13. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 67
F.14. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
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
skipping to change at page 15, line 11 skipping to change at page 15, line 11
Profiles MUST specify how mutual authentication is done, depending Profiles MUST specify how mutual authentication is done, depending
e.g. on the communication protocol and the credentials used by the e.g. on the communication protocol and the credentials used by the
client or the RS. client or the RS.
In OAuth 2.0 the communication with the Token and the Introspection In OAuth 2.0 the communication with the Token and the Introspection
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. The Content-format depends on the payload of the POST request. Profiles that use CBOR encoding of
security applied to the content and MUST be specified by the profile protocol message parameters MUST use the media format 'application/
that is used. ace+cbor', unless the protocol message is wrapped in another Content-
Format (e.g. object security). If CoAP is used for communication,
the Content-Format MUST be abbreviated with the ID: 19 (see
Section 8.14.
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 16, line 36 skipping to change at page 16, line 38
/-------+----------+-------------\ /-------+----------+-------------\
| Name | CBOR Key | Value Type | | Name | CBOR Key | Value Type |
|-------+----------+-------------| |-------+----------+-------------|
| AS | 0 | text string | | AS | 0 | text string |
| nonce | 5 | byte string | | nonce | 5 | byte string |
\-------+----------+-------------/ \-------+----------+-------------/
Figure 2: AS Information parameters Figure 2: AS Information parameters
Note that the schema part of the AS parameter may need to be adapted
to the security protocol that is used between the client and the AS.
Thus the example AS value "coap://as.example.com/token" might need to
be transformed to "coaps://as.example.com/token". It is assumed that
the client can determine the correct schema part on its own depending
on the way it communicates with the AS.
Figure 3 shows an example for an AS Information message payload using Figure 3 shows an example for an AS Information message payload using
CBOR [RFC7049] diagnostic notation, using the parameter names instead CBOR [RFC7049] diagnostic notation, using the parameter names instead
of the CBOR keys for better human readability. of the CBOR keys for better human readability.
4.01 Unauthorized 4.01 Unauthorized
Content-Format: application/ace+cbor Content-Format: application/ace+cbor
{AS: "coaps://as.example.com/token", {AS: "coaps://as.example.com/token",
nonce: h'e0a156bb3f'} nonce: h'e0a156bb3f'}
Figure 3: AS Information payload example Figure 3: AS Information payload example
skipping to change at page 19, line 4 skipping to change at page 19, line 20
help the client and RS to establish shared keys or to exchange their help the client and RS to establish shared keys or to exchange their
public keys. Furthermore, this framework defines encodings using public keys. Furthermore, this framework defines encodings using
CBOR, as a substitute for JSON. CBOR, as a substitute for JSON.
The endpoint may, however, be exposed over HTTPS as in classical The endpoint may, however, be exposed over HTTPS as in classical
OAuth or even other transports. A profile MUST define the details of OAuth or even other transports. A profile MUST define the details of
the mapping between the fields described below, and these transports. the mapping between the fields described below, and these transports.
If HTTPS is used, JSON or CBOR payloads may be supported. If JSON If HTTPS is used, JSON or CBOR payloads may be supported. If JSON
payloads are used, the semantics of Section 4 of the OAuth 2.0 payloads are used, the semantics of Section 4 of the OAuth 2.0
specification MUST be followed (with additions as described below). specification MUST be followed (with additions as described below).
If CBOR payload is supported, the semantics described below MUST be If CBOR payload is supported, the semantics described below MUST be
followed. followed.
For the AS to be able to issue a token, the client MUST be For the AS to be able to issue a token, the client MUST be
authenticated and present a valid grant for the scopes requested. authenticated and present a valid grant for the scopes requested.
Profiles of this framework MUST specify how the AS authenticates the Profiles of this framework MUST specify how the AS authenticates the
client and how the communication between client and AS is protected. client and how the communication between client and AS is protected.
The default name of this endpoint in an url-path is 'token', however The default name of this endpoint in an url-path is '/token', however
implementations are not required to use this name and can define implementations are not required to use this name and can define
their own instead. their own instead.
The figures of this section use CBOR diagnostic notation without the The figures of this section use CBOR diagnostic notation without the
integer abbreviations for the parameters or their values for integer abbreviations for the parameters or their values for
illustrative purposes. Note that implementations MUST use the illustrative purposes. Note that implementations MUST use the
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 the Content-Type and wrapping of the payload. profile MUST specify how the communication is protected. The content
The content of the request consists of the parameters specified in of the request consists of the parameters specified in Section 4 of
Section 4 of the OAuth 2.0 specification [RFC6749]. the OAuth 2.0 specification [RFC6749].
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.
where the "scope" parameter can additionally be formatted as a byte The "scope" parameter can be formatted as specified in [RFC6749] and
array, in order to allow compact encoding of complex scope additionally as a byte array, in order to allow compact encoding of
structures. 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.
In addition to these parameters, this framework defines the following In addition to these parameters the parameters from
parameters for requesting an access token from a token endpoint: [I-D.ietf-ace-oauth-params] can be used for requesting an access
token from a token endpoint.
aud:
OPTIONAL. Specifies the audience for which the client is
requesting an access token. If this parameter is missing, it is
assumed that the client and the AS have a pre-established
understanding of the audience that an access token should address.
If a client submits a request for an access token without
specifying an "aud" parameter, and the AS does not have an
implicit understanding of the "aud" value for this client, then
the AS MUST respond with an error message using a response code
equivalent to the CoAP response code 4.00 (Bad Request).
cnf:
OPTIONAL. This field contains information about the key the
client would like to bind to the access token for proof-of-
possession. It is RECOMMENDED that an AS reject a request
containing a symmetric key value in the 'cnf' field, since the AS
is expected to be able to generate better symmetric keys than a
potentially constrained client. See Section 5.6.4.5 for more
details on the formatting of the 'cnf' parameter.
The following examples illustrate different types of requests for The following examples illustrate different types of requests for
proof-of-possession tokens. proof-of-possession tokens.
Figure 5 shows a request for a token with a symmetric proof-of- Figure 5 shows a request for a token with a symmetric proof-of-
possession key. Note that in this example it is assumed that possession key. The content is displayed in CBOR diagnostic
transport layer communication security is used with a CBOR payload, notation, without abbreviations for better readability.
therefore the Content-Type is "application/cbor". The content is
displayed in CBOR diagnostic 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-Type: "application/cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"client_id" : "myclient", "client_id" : "myclient",
"aud" : "tempSensor4711" "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-Type is "application/cose". object-security, therefore the Content-Format is "application/cose"
wrapping the "application/ace+cbor" type content.
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-Type: "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:
{ {
skipping to change at page 21, line 35 skipping to change at page 21, line 35
"crv" : "P-256", "crv" : "P-256",
"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
} }
} }
} }
Figure 6: Example token request bound to an asymmetric key. Figure 6: Example token request bound to an asymmetric key.
Figure 7 shows a request for a token where a previously communicated Figure 7 shows a request for a token where a previously communicated
proof-of-possession key is only referenced. Note that a transport proof-of-possession key is only referenced. Note that the client
layer based communication security profile with a CBOR payload is performs a password based authentication in this example by
assumed in this example, therefore the Content-Type is "application/ submitting its client_secret (see Section 2.3.1 of [RFC6749]).
cbor". Also note that the client performs a password based
authentication in this example by submitting its client_secret (see
Section 2.3.1 of [RFC6749]).
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-Type: "application/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", "aud" : "valve424",
"scope" : "read", "scope" : "read",
"cnf" : { "cnf" : {
"kid" : b64'6kg0dXJM13U' "kid" : b64'6kg0dXJM13U'
} }
skipping to change at page 22, line 41 skipping to change at page 22, line 41
error response as described in Section 5.6.3. error response as described in Section 5.6.3.
Note that the AS decides which token type and profile to use when Note that the AS decides which token type and profile to use when
issuing a successful response. It is assumed that the AS has prior issuing a successful response. It is assumed that the AS has prior
knowledge of the capabilities of the client and the RS (see knowledge of the capabilities of the client and the RS (see
Appendix D. This prior knowledge may, for example, be set by the use Appendix D. This prior knowledge may, for example, be set by the use
of a dynamic client registration protocol exchange [RFC7591]. of a dynamic client registration protocol exchange [RFC7591].
The content of the successful reply is the Access Information. When The content of the successful reply is the Access Information. When
using CBOR payloads, the content MUST be encoded as CBOR map, using CBOR payloads, the content MUST be encoded as CBOR map,
containing parameters as specified in Section 5.1 of [RFC6749]. In containing parameters as specified in Section 5.1 of [RFC6749], with
addition to these parameters, the following parameters are also part the following additions and changes:
of a successful response:
profile: profile:
OPTIONAL. This indicates the profile that the client MUST use OPTIONAL. This indicates the profile that the client MUST use
towards the RS. See Section 5.6.4.4 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.
cnf:
REQUIRED if the token type is "pop" and a symmetric key is used.
MUST NOT be present otherwise. This field contains the symmetric
proof-of-possession key the client is supposed to use. See
Section 5.6.4.5 for details on the use of this parameter.
rs_cnf:
OPTIONAL if the token type is "pop" and asymmetric keys are used.
MUST NOT be present otherwise. This field contains information
about the public key used by the RS to authenticate. See
Section 5.6.4.5 for details on the use of this parameter. If this
parameter is absent, the AS assumes that the client already knows
the public key of the RS.
token_type: token_type:
OPTIONAL. By default implementations of this framework SHOULD This parameter is OPTIONAL, as opposed to 'required' in [RFC6749].
assume that the token_type is "pop". If a specific use case By default implementations of this framework SHOULD assume that
requires another token_type (e.g., "Bearer") to be used then this the token_type is "pop". If a specific use case requires another
parameter is REQUIRED. token_type (e.g., "Bearer") to be used then this parameter is
REQUIRED.
Note that if CBOR Web Tokens [RFC8392] are used, the access token Furthermore [I-D.ietf-ace-oauth-params] defines further parameters
also contains a "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession]. the AS can use when responding to a request to the token endpoint.
This claim is however consumed by a different party. The access
token is created by the AS and processed by the RS (and opaque to the
client) whereas the Access Information is created by the AS and
processed by the client; it is never forwarded to the resource
server.
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. Information.
/-------------------+-----------------\ /-------------------+-------------------------------\
| Parameter name | Specified in | | Parameter name | Specified in |
|-------------------+-----------------| |-------------------+-------------------------------|
| access_token | RFC 6749 | | access_token | RFC 6749 |
| token_type | RFC 6749 | | token_type | RFC 6749 |
| expires_in | RFC 6749 | | expires_in | RFC 6749 |
| refresh_token | RFC 6749 | | refresh_token | RFC 6749 |
| scope | RFC 6749 | | scope | RFC 6749 |
| state | RFC 6749 | | state | RFC 6749 |
| error | RFC 6749 | | error | RFC 6749 |
| error_description | RFC 6749 | | error_description | RFC 6749 |
| error_uri | RFC 6749 | | error_uri | RFC 6749 |
| profile | [this document] | | profile | [this document] |
| cnf | [this document] | \-------------------+-------------------------------/
| rs_cnf | [this document] |
\-------------------+-----------------/
Figure 8: Access Information parameters Figure 8: Access Information parameters
Figure 9 shows a response containing a token and a "cnf" parameter Figure 9 shows a response containing a token and a "cnf" parameter
with a symmetric proof-of-possession key. Note that transport layer with a symmetric proof-of-possession key.
security with CBOR encoding is assumed in this example, therefore the
Content-Type is "application/cbor".
Header: Created (Code=2.01) Header: Created (Code=2.01)
Content-Type: "application/cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"access_token" : b64'SlAV32hkKG ... "access_token" : b64'SlAV32hkKG ...
(remainder of CWT omitted for brevity; (remainder of CWT omitted for brevity;
CWT contains COSE_Key in the "cnf" claim)', CWT contains COSE_Key in the "cnf" claim)',
"profile" : "coap_dtls", "profile" : "coap_dtls",
"expires_in" : "3600", "expires_in" : "3600",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "Symmetric", "kty" : "Symmetric",
skipping to change at page 24, line 34 skipping to change at page 24, line 32
Figure 9: Example AS response with an access token bound to a Figure 9: Example AS response with an access token bound to a
symmetric key. symmetric key.
5.6.3. Error Response 5.6.3. Error Response
The error responses for CoAP-based interactions with the AS are The error responses for CoAP-based interactions with the AS are
equivalent to the ones for HTTP-based interactions as defined in equivalent to the ones for HTTP-based interactions as defined in
Section 5.2 of [RFC6749], with the following differences: Section 5.2 of [RFC6749], with the following differences:
o The Content-Type MUST be specified by the communication security o When using CBOR the raw payload before being processed by the
profile used between client and AS. When using CoAP the raw communication security protocol MUST be encoded as a CBOR map.
payload before being processed by the communication security
protocol MUST be encoded as a CBOR map.
o A response code equivalent to the CoAP code 4.00 (Bad Request) o A response code equivalent to the CoAP code 4.00 (Bad Request)
MUST be used for all error responses, except for invalid_client MUST be used for all error responses, except for invalid_client
where a response code equivalent to the CoAP code 4.01 where a response code equivalent to the CoAP code 4.01
(Unauthorized) MAY be used under the same conditions as specified (Unauthorized) MAY be used under the same conditions as specified
in Section 5.2 of [RFC6749]. in Section 5.2 of [RFC6749].
o The parameters "error", "error_description" and "error_uri" MUST o The parameters "error", "error_description" and "error_uri" MUST
be abbreviated using the codes specified in Figure 12, when a CBOR be abbreviated using the codes specified in Figure 12, when a CBOR
encoding is used. encoding is used.
o The error code (i.e., value of the "error" parameter) MUST be o The error code (i.e., value of the "error" parameter) MUST be
abbreviated as specified in Figure 10, when a CBOR encoding is abbreviated as specified in Figure 10, when a CBOR encoding is
used. used.
/------------------------+-------------\ /------------------------+-------------\
| Name | CBOR Values | | Name | CBOR Values |
|------------------------+-------------| |------------------------+-------------|
| invalid_request | 0 | | invalid_request | 1 |
| invalid_client | 1 | | invalid_client | 2 |
| invalid_grant | 2 | | invalid_grant | 3 |
| unauthorized_client | 3 | | unauthorized_client | 4 |
| unsupported_grant_type | 4 | | unsupported_grant_type | 5 |
| invalid_scope | 5 | | invalid_scope | 6 |
| unsupported_pop_key | 6 | | unsupported_pop_key | 7 |
\------------------------+-------------/ \------------------------+-------------/
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: If the client
submits an asymmetric key in the token request that the RS cannot submits an asymmetric key in the token request that the RS cannot
process, the AS MUST reject that request with a response code process, the AS MUST reject that request with a response code
equivalent to the CoAP code 4.00 (Bad Request) including the error equivalent to the CoAP code 4.00 (Bad Request) including the error
code "unsupported_pop_key" defined in Figure 10. code "unsupported_pop_key" 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. Audience 5.6.4.1. Grant Type
This parameter specifies for which audience the client is requesting
a token. The formatting and semantics of these strings are
application specific.
When encoded as a CBOR payload it is represented as a CBOR text
string.
5.6.4.2. Grant Type
The abbreviations in Figure 11 MUST be used in CBOR encodings instead The abbreviations in Figure 11 MUST be used in CBOR encodings instead
of the string values defined in [RFC6749], if CBOR payloads are used. of the string values defined in [RFC6749], if CBOR payloads are used.
/--------------------+------------+------------------------\ /--------------------+------------+------------------------\
| Name | CBOR Value | Original Specification | | Name | CBOR Value | Original Specification |
|--------------------+------------+------------------------| |--------------------+------------+------------------------|
| password | 0 | RFC6749 | | password | 0 | RFC6749 |
| authorization_code | 1 | RFC6749 | | authorization_code | 1 | RFC6749 |
| client_credentials | 2 | RFC6749 | | client_credentials | 2 | RFC6749 |
| refresh_token | 3 | RFC6749 | | refresh_token | 3 | RFC6749 |
\--------------------+------------+------------------------/ \--------------------+------------+------------------------/
Figure 11: CBOR abbreviations for common grant types Figure 11: CBOR abbreviations for common grant types
5.6.4.3. Token Type 5.6.4.2. Token Type
The "token_type" parameter, defined in [RFC6749], allows the AS to The "token_type" parameter, defined in [RFC6749], allows the AS to
indicate to the client which type of access token it is receiving indicate to the client which type of access token it is receiving
(e.g., a bearer token). (e.g., a bearer token).
This document registers the new value "pop" for the OAuth Access This document registers the new value "pop" for the OAuth Access
Token Types registry, specifying a proof-of-possession token. How Token Types registry, specifying a proof-of-possession token. How
the proof-of-possession by the client to the RS is performed MUST be the proof-of-possession by the client to the RS is performed MUST be
specified by the profiles. specified by the profiles.
The values in the "token_type" parameter MUST be CBOR text strings, The values in the "token_type" parameter MUST be CBOR text strings,
if a CBOR encoding is used. if a CBOR encoding is used.
In this framework the "pop" value for the "token_type" parameter is In this framework the "pop" value for the "token_type" parameter is
the default. The AS may, however, provide a different value. the default. The AS may, however, provide a different value.
5.6.4.4. Profile 5.6.4.3. Profile
Profiles of this framework MUST define the communication protocol and Profiles of this framework MUST define the communication protocol and
the communication security protocol between the client and the RS. the communication security protocol between the client and the RS.
The security protocol MUST provide encryption, integrity and replay The security protocol MUST provide encryption, integrity and replay
protection. Furthermore profiles MUST define proof-of-possession protection. Furthermore profiles MUST define proof-of-possession
methods, if they support proof-of-possession tokens. methods, if they support proof-of-possession tokens.
A profile MUST specify an identifier that MUST be used to uniquely A profile MUST specify an identifier that MUST be used to uniquely
identify itself in the "profile" parameter. The textual identify itself in the "profile" parameter. The textual
representation of the profile identifier is just intended for human representation of the profile identifier is just intended for human
readability and MUST NOT be used in parameters and claims.. readability and MUST NOT be used in parameters and claims.
Profiles MAY define additional parameters for both the token request Profiles MAY define additional parameters for both the token request
and the Access Information in the access token response in order to and the Access Information in the access token response in order to
support negotiation or signaling of profile specific parameters. support negotiation or signaling of profile specific parameters.
5.6.4.5. Confirmation
The "cnf" parameter identifies or provides the key used for proof-of-
possession, while the "rs_cnf" parameter provides the raw public key
of the RS. Both parameters use the same formatting and semantics as
the "cnf" claim specified in [I-D.ietf-ace-cwt-proof-of-possession]
when used with a CBOR encoding. When these parameters are used in
JSON then the formatting and semantics of the "cnf" claim specified
in RFC 7800 [RFC7800].
In addition to the use as a claim in a CWT, the "cnf" parameter is
used in the following contexts with the following meaning:
o In the token request C -> AS, to indicate the client's raw public
key, or the key-identifier of a previously established key between
C and RS.
o In the token response AS -> C, to indicate the symmetric key
generated by the AS for proof-of-possession.
o In the introspection response AS -> RS, to indicate the proof-of-
possession key bound to the introspected token.
Note that the COSE_Key structure in a "cnf" claim or parameter may
contain an "alg" or "key_ops" parameter. If such parameters are
present, a client MUST NOT use a key that is not compatible with the
profile or proof-of-possession algorithm according to those
parameters. An RS MUST reject a proof-of-possession using such a
key.
Also note that the "rs_cnf" parameter is supposed to indicate the key
that the RS uses to authenticate. If the access token is issued for
an audience that includes several RS, this parameter MUST NOT be
used, since the client cannot determine for which RS the key applies.
This framework recommends to specify a different endpoint that the
client can use to acquire RS authentication keys in such cases. The
specification of such an endpoint is out of scope for this framework.
5.6.5. Mapping Parameters to CBOR 5.6.5. Mapping Parameters to CBOR
If CBOR encoding is used, all OAuth parameters in access token If CBOR encoding is used, all OAuth parameters in access token
requests and responses MUST be mapped to CBOR types as specified in requests and responses MUST be mapped to CBOR types as specified in
Figure 12, using the given integer abbreviation for the map keys. Figure 12, using the given integer abbreviation for the map keys.
Note that we have aligned these abbreviations with the claim Note that we have aligned these abbreviations with the claim
abbreviations defined in [RFC8392]. abbreviations defined in [RFC8392].
/-------------------+----------+---------------------\ /-------------------+----------+---------------------\
| Name | CBOR Key | Value Type | | Name | CBOR Key | Value Type |
|-------------------+----------+---------------------| |-------------------+----------+---------------------|
| aud | 3 | text string | | scope | 9 | text or byte string |
| client_id | 8 | text string | | profile | 10 | unsigned integer |
| client_secret | 9 | byte string | | error | 11 | unsinged integer |
| response_type | 10 | text string | | grant_type | 12 | unsigned integer |
| redirect_uri | 11 | text string | | access_token | 13 | byte string |
| scope | 12 | text or byte string | | token_type | 14 | unsigned integer |
| state | 13 | text string | | client_id | 24 | text string |
| code | 14 | byte string | | client_secret | 25 | byte string |
| error | 15 | unsinged integer | | response_type | 26 | text string |
| error_description | 16 | text string | | state | 27 | text string |
| error_uri | 17 | text string | | redirect_uri | 28 | text string |
| grant_type | 18 | unsigned integer | | error_description | 29 | text string |
| access_token | 19 | byte string | | error_uri | 30 | text string |
| token_type | 20 | unsigned integer | | code | 31 | byte string |
| expires_in | 21 | unsigned integer | | expires_in | 32 | unsigned integer |
| username | 22 | text string | | username | 33 | text string |
| password | 23 | text string | | password | 34 | text string |
| refresh_token | 24 | byte string | | refresh_token | 35 | byte string |
| cnf | 25 | map |
| profile | 26 | unsigned integer |
| rs_cnf | 31 | map |
\-------------------+----------+---------------------/ \-------------------+----------+---------------------/
Figure 12: CBOR mappings used in token requests Figure 12: CBOR mappings used in token requests
5.7. The 'Introspect' Endpoint 5.7. The 'Introspect' Endpoint
Token introspection [RFC7662] can be OPTIONALLY provided by the AS, Token introspection [RFC7662] can be OPTIONALLY provided by the AS,
and is then used by the RS and potentially the client to query the AS and is then used by the RS and potentially the client to query the AS
for metadata about a given token, e.g., validity or scope. Analogous for metadata about a given token, e.g., validity or scope. Analogous
to the protocol defined in RFC 7662 [RFC7662] for HTTP and JSON, this to the protocol defined in RFC 7662 [RFC7662] for HTTP and JSON, this
skipping to change at page 29, line 5 skipping to change at page 27, line 48
profile. profile.
Communication between the RS and the introspection endpoint at the AS Communication between the RS and the introspection endpoint at the AS
MUST be integrity protected and encrypted. Furthermore AS and RS MUST be integrity protected and encrypted. Furthermore AS and RS
MUST perform mutual authentication. Finally the AS SHOULD verify MUST perform mutual authentication. Finally the AS SHOULD verify
that the RS has the right to access introspection information about that the RS has the right to access introspection information about
the provided token. Profiles of this framework that support the provided token. Profiles of this framework that support
introspection MUST specify how authentication and communication introspection MUST specify how authentication and communication
security between RS and AS is implemented. security between RS and AS is implemented.
The default name of this endpoint in an url-path is 'introspect', The default name of this endpoint in an url-path is '/introspect',
however implementations are not required to use this name and can however implementations are not required to use this name and can
define their own instead. define their own instead.
The figures of this section uses CBOR diagnostic notation without the The figures of this section uses CBOR diagnostic notation without the
integer abbreviations for the parameters or their values for better integer abbreviations for the parameters or their values for better
readability. readability.
Note that supporting introspection is OPTIONAL for implementations of Note that supporting introspection is OPTIONAL for implementations of
this framework. this framework.
5.7.1. RS-to-AS Request 5.7.1. RS-to-AS Request
The RS sends a POST request to the introspection endpoint at the AS, The RS sends a POST request to the introspection endpoint at the AS,
the profile MUST specify the Content-Type and wrapping of the the profile MUST specify how the communication is protected. If CBOR
payload. If CBOR is used, the payload MUST be encoded as a CBOR map is used, the payload MUST be encoded as a CBOR map with a "token"
with a "token" entry containing either the access token or a entry containing either the access token or a reference to the token
reference to the token (e.g., the cti). Further optional parameters (e.g., the cti). Further optional parameters representing additional
representing additional context that is known by the RS to aid the AS context that is known by the RS to aid the AS in its response MAY be
in its response MAY be included. included.
The same parameters are required and optional as in Section 2.1 of The same parameters are required and optional as in Section 2.1 of
RFC 7662 [RFC7662]. RFC 7662 [RFC7662].
For example, Figure 13 shows a RS calling the token introspection For example, Figure 13 shows a RS calling the token introspection
endpoint at the AS to query about an OAuth 2.0 proof-of-possession endpoint at the AS to query about an OAuth 2.0 proof-of-possession
token. Note that object security based on COSE is assumed in this token. Note that object security based on COSE is assumed in this
example, therefore the Content-Type is "application/cose+cbor". example, therefore the Content-Format is "application/cose".
Figure 14 shows the decoded payload. Figure 14 shows the decoded payload.
Header: POST (Code=0.02) Header: POST (Code=0.02)
Uri-Host: "as.example.com" Uri-Host: "as.example.com"
Uri-Path: "introspect" Uri-Path: "introspect"
Content-Type: "application/cose+cbor" Content-Format: "application/cose"
Payload: Payload:
... COSE content ... ... COSE content ...
Figure 13: Example introspection request. Figure 13: Example introspection request.
{ {
"token" : b64'7gj0dXJQ43U', "token" : b64'7gj0dXJQ43U',
"token_type_hint" : "pop" "token_type_hint" : "pop"
} }
skipping to change at page 30, line 15 skipping to change at page 29, line 9
5.7.2. AS-to-RS Response 5.7.2. AS-to-RS Response
If the introspection request is authorized and successfully If the introspection request is authorized and successfully
processed, the AS sends a response with the response code equivalent processed, the AS sends a response with the response code equivalent
to the CoAP code 2.01 (Created). If the introspection request was to the CoAP code 2.01 (Created). If the introspection request was
invalid, not authorized or couldn't be processed the AS returns an invalid, not authorized or couldn't be processed the AS returns an
error response as described in Section 5.7.3. error response as described in Section 5.7.3.
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 additions: Section 2.2 of RFC 7662 [RFC7662] with the following addition:
cnf OPTIONAL. This field contains information about the proof-of-
possession key that binds the client to the access token. See
Section 5.6.4.5 for more details on the use of the "cnf"
parameter.
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.4 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.
rs_cnf OPTIONAL. If the RS has several keys it can use to
authenticate towards the client, the AS can give the RS a hint Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that
using this parameter, as to which key it should use (e.g., if the the AS can use when responding to a request to the introspection
AS previously informed the client about a public key the RS is endpoint.
holding). See Section 5.6.4.5 for more details on the use of this
parameter.
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. Note that transport layer security is assumed request in Figure 13.
in this example, therefore the Content-Type is "application/cbor".
Header: Created Code=2.01) Header: Created Code=2.01)
Content-Type: "application/cbor" Content-Format: "application/ace+cbor"
Payload: Payload:
{ {
"active" : true, "active" : true,
"scope" : "read", "scope" : "read",
"profile" : "coap_dtls", "profile" : "coap_dtls",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kty" : "Symmetric", "kty" : "Symmetric",
"kid" : b64'39Gqlw', "kid" : b64'39Gqlw',
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
skipping to change at page 31, line 11 skipping to change at page 29, line 46
} }
Figure 15: Example introspection response. Figure 15: Example introspection response.
5.7.3. Error Response 5.7.3. Error Response
The error responses for CoAP-based interactions with the AS are The error responses for CoAP-based interactions with the AS are
equivalent to the ones for HTTP-based interactions as defined in equivalent to the ones for HTTP-based interactions as defined in
Section 2.3 of [RFC7662], with the following differences: Section 2.3 of [RFC7662], with the following differences:
o If content is sent, the Content-Type MUST be set according to the o If content is sent and CBOR is used the payload MUST be encoded as
specification of the communication security profile. If CoAP is a CBOR map and the Content-Format "application/ace+cbor" MUST be
used the payload MUST be encoded as a CBOR map. used.
o If the credentials used by the RS are invalid the AS MUST respond o If the credentials used by the RS are invalid the AS MUST respond
with the response code equivalent to the CoAP code 4.01 with the response code equivalent to the CoAP code 4.01
(Unauthorized) and use the required and optional parameters from (Unauthorized) and use the required and optional parameters from
Section 5.2 in RFC 6749 [RFC6749]. Section 5.2 in RFC 6749 [RFC6749].
o If the RS does not have the right to perform this introspection o If the RS does not have the right to perform this introspection
request, the AS MUST respond with a response code equivalent to request, the AS MUST respond with a response code equivalent to
the CoAP code 4.03 (Forbidden). In this case no payload is the CoAP code 4.03 (Forbidden). In this case no payload is
returned. returned.
o The parameters "error", "error_description" and "error_uri" MUST o The parameters "error", "error_description" and "error_uri" MUST
be abbreviated using the codes specified in Figure 12. be abbreviated using the codes specified in Figure 12.
skipping to change at page 32, line 15 skipping to change at page 30, line 40
/-----------------+----------+----------------------------------\ /-----------------+----------+----------------------------------\
| Parameter name | CBOR Key | Value Type | | Parameter name | CBOR Key | Value Type |
|-----------------+----------+----------------------------------| |-----------------+----------+----------------------------------|
| iss | 1 | text string | | iss | 1 | text string |
| sub | 2 | text string | | sub | 2 | text string |
| aud | 3 | text string | | aud | 3 | text string |
| exp | 4 | integer or floating-point number | | exp | 4 | integer or floating-point number |
| nbf | 5 | integer or floating-point number | | nbf | 5 | integer or floating-point number |
| iat | 6 | integer or floating-point number | | iat | 6 | integer or floating-point number |
| cti | 7 | byte string | | cti | 7 | byte string |
| client_id | 8 | text string | | scope | 9 | text OR byte string |
| scope | 12 | text OR byte string | | token_type | 13 | text string |
| token_type | 20 | text string | | token | 14 | byte string |
| username | 22 | text string | | active | 15 | True or False |
| cnf | 25 | map | | profile | 16 | unsigned integer |
| profile | 26 | unsigned integer | | client_id | 24 | text string |
| token | 27 | byte string | | username | 33 | text string |
| token_type_hint | 28 | text string | | token_type_hint | 36 | text string |
| active | 29 | True or False |
| rs_cnf | 30 | map |
\-----------------+----------+----------------------------------/ \-----------------+----------+----------------------------------/
Figure 16: CBOR Mappings to Token Introspection Parameters. Figure 16: CBOR Mappings to Token Introspection Parameters.
5.8. The Access Token 5.8. The Access Token
This framework RECOMMENDS the use of CBOR web token (CWT) as This framework RECOMMENDS the use of CBOR web token (CWT) as
specified in [RFC8392]. specified in [RFC8392].
In order to facilitate offline processing of access tokens, this In order to facilitate offline processing of access tokens, this
skipping to change at page 32, line 48 skipping to change at page 31, line 24
The "scope" claim explicitly encodes the scope of a given access The "scope" claim explicitly encodes the scope of a given access
token. This claim follows the same encoding rules as defined in token. This claim follows the same encoding rules as defined in
Section 3.3 of [RFC6749], but in addition implementers MAY use byte Section 3.3 of [RFC6749], but in addition implementers MAY use byte
arrays as scope values, to achieve compact encoding of large scope arrays as scope values, to achieve compact encoding of large scope
elements. The meaning of a specific scope value is application elements. The meaning of a specific scope value is application
specific and expected to be known to the RS running that application. specific and expected to be known to the RS running that application.
If the AS needs to convey a hint to the RS about which key it should If the AS needs to convey a hint to the RS about which key it should
use to authenticate towards the client, the rs_cnf claim MAY be used use to authenticate towards the client, the rs_cnf claim MAY be used
with the same syntax and semantics as defined in Section 5.6.4.5. with the same syntax and semantics as defined in
[I-D.ietf-ace-oauth-params].
If the AS needs to convey a hint to the RS about which profile it If the AS needs to convey a hint to the RS about which profile it
should use to communicate with the client, the AS MAY include a should use to communicate with the client, the AS MAY include a
"profile" claim in the access token, with the same syntax and "profile" claim in the access token, with the same syntax and
semantics as defined in Section 5.6.4.4. semantics as defined in Section 5.6.4.3.
5.8.1. The 'Authorization Information' Endpoint 5.8.1. The 'Authorization Information' Endpoint
The access token, containing authorization information and The access token, containing authorization information and
information about the key used by the client, needs to be transported information about the key used by the client, needs to be transported
to the RS so that the RS can authenticate and authorize the client to the RS so that the RS can authenticate and authorize the client
request. request.
This section defines a method for transporting the access token to This section defines a method for transporting the access token to
the RS using a RESTful protocol such as CoAP. Profiles of this the RS using a RESTful protocol such as CoAP. Profiles of this
skipping to change at page 33, line 48 skipping to change at page 32, line 26
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 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 how the authz-info endpoint is protected, Profiles MUST specify whether the authz-info endpoint is protected,
including how error responses from this endpoint are protected. Note including wheter error responses from this endpoint are protected.
that since the token contains information that allow the client and Note that since the token contains information that allow the client
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',
however implementations are not required to use this name and can however implementations are not required to use this name and can
define their own instead. define their own instead.
5.8.2. Client Requests to the RS 5.8.2. Client Requests to the RS
A RS receiving a client request MUST first verify that it has an If an RS receives a request from a client, and the target resource
requires authorization, the RS MUST first verify that it has an
access token that authorizes this request, and that the client has access token that authorizes this request, and that the client has
performed the proof-of-possession for that token. performed the proof-of-possession for that token.
The response code MUST be 4.01 (Unauthorized) in case the client has The response code MUST be 4.01 (Unauthorized) in case the client has
not performed the proof-of-possession, or if RS has no valid access not performed the proof-of-possession, or if RS has no valid access
token for the client. If RS has an access token for the client but token for the client. If RS has an access token for the client but
not for the resource that was requested, RS MUST reject the request not for the resource that was requested, RS MUST reject the request
with a 4.03 (Forbidden). If RS has an access token for the client with a 4.03 (Forbidden). If RS has an access token for the client
but it does not cover the action that was requested on the resource, but it does not cover the action that was requested on the resource,
RS MUST reject the request with a 4.05 (Method Not Allowed). RS MUST reject the request with a 4.05 (Method Not Allowed).
skipping to change at page 41, line 44 skipping to change at page 40, line 21
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.7. OAuth Parameter Registration
This section registers the following parameters in the "OAuth This section registers the following parameter in the "OAuth
Parameters" registry [IANA.OAuthParameters]: Parameters" registry [IANA.OAuthParameters]:
o Name: "aud"
o Parameter Usage Location: authorization request, token request
o Change Controller: IESG
o Reference: Section 5.6.1 of [this document]
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.4 of [this document] o Reference: Section 5.6.4.3 of [this document]
o Name: "cnf"
o Parameter Usage Location: token request, token response
o Change Controller: IESG
o Reference: Section 5.6.4.5 of [this document]
o Name: "rs_cnf"
o Parameter Usage Location: token response
o Change Controller: IESG
o Reference: Section 5.6.4.5 of [this document]
8.8. OAuth CBOR Parameter Mappings Registry 8.8. OAuth CBOR Parameter Mappings Registry
This section establishes the IANA "Token Endpoint CBOR Mappings" This section establishes the IANA "Token Endpoint CBOR Mappings"
registry. The registry has been created to use the "Expert Review registry. The registry has been created to use the "Expert Review
Required" registration procedure [RFC8126]. It should be noted that, Required" registration procedure [RFC8126]. It should be noted that,
in addition to the expert review, some portions of the registry in addition to the expert review, some portions of the registry
require a specification, potentially a Standards Track RFC, be require a specification, potentially a Standards Track RFC, be
supplied as well. supplied as well.
skipping to change at page 43, line 7 skipping to change at page 41, line 13
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.9. OAuth Introspection Response Parameter Registration
This section registers the following parameters in the OAuth Token This section registers the following parameter in the OAuth Token
Introspection Response registry [IANA.TokenIntrospectionResponse]. Introspection Response registry [IANA.TokenIntrospectionResponse].
o Name: "cnf"
o Description: Key to prove the right to use a PoP token.
o Change Controller: IESG
o Reference: Section 5.7.2 of [this document]
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.10. Introspection Endpoint CBOR Mappings Registry
This section establishes the IANA "Introspection Endpoint CBOR This section 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
skipping to change at page 44, line 17 skipping to change at page 42, line 17
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]
o Claim Name: "profile"
o Claim Description: The profile a token is supposed to be used
with.
o Change Controller: IESG
o Reference: Section 5.8 of [this document]
o Claim Name: "rs_cnf"
o Claim Description: The public key the RS is supposed to use to
authenticate to the client wielding this token.
o Change Controller: IESG
o Reference: Section 5.8 of [this document]
8.12. CBOR Web Token Claims 8.12. 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): 0 (uint), 2 (byte string), 3 (text string) o Claim Value Type(s): byte string or text string
o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "profile"
o Claim Description: The profile a token is supposed to be used
with.
o JWT Claim Name: N/A
o Claim Key: 16
o Claim Value Type(s): integer
o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document]
o Claim Name: "rs_cnf"
o Claim Description: The public key the RS is supposed to use to
authenticate to the client wielding this token.
o JWT Claim Name: N/A
o Claim Key: 17
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
This document registres a media type for messages of the protocols
defined in this document carrying parameters encoded in CBOR. This
registration follows the procedures specified in [RFC6838].
8.13.1. Media Type Registration
Type name: application
Subtype name: ace+cbor
Required parameters: none
Optional parameters: none
Encoding considerations: Must be encoded as CBOR map containg the
protocol parameters defined in [this document].
Security considerations: See Section 6 of this document.
Interoperability considerations: n/a
Published specification: [this document]
Applications that use this media type: The type is used by
authorization servers, clients and resource servers that support the
ACE framework as specified in [this document].
Additional information:
Magic number(s): n/a
File extension(s): .ace
Macintosh file type code(s): n/a
Person & email address to contact for further information: Ludwig
Seitz <ludwig.seitz@ri.se>
Intended usage: COMMON
Restrictions on usage: None
Author: Ludwig Seitzs <ludwig.setiz@ri.se>
Change controller: IESG
8.14. CoAP Content-Format Registry
This document registers the following entry to the "CoAP Content-
Formats" registry:
Media Type: application/ace+cbor
Encoding
ID: 19
Reference: [this document]
9. Acknowledgments 9. Acknowledgments
This document is a product of the ACE working group of the IETF. This document is a product of the ACE working group of the IETF.
Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and
UMA in IoT scenarios, Robert Taylor for his discussion input, and UMA in IoT scenarios, Robert Taylor for his discussion input, and
Malisa Vucinic for his input on the predecessors of this proposal. Malisa Vucinic for his input on the predecessors of this proposal.
Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from
where large parts of the security considerations where copied. where large parts of the security considerations where copied.
skipping to change at page 45, line 10 skipping to change at page 45, line 6
Thanks to Jim Schaad and Mike Jones for their comprehensive reviews. Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.
Ludwig Seitz and Goeran Selander worked on this document as part of Ludwig Seitz and Goeran Selander worked on this document as part of
the CelticPlus project CyberWI, with funding from Vinnova. the CelticPlus project CyberWI, with funding from Vinnova.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession] [I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Wahlstroem, E., Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
proof-of-possession-02 (work in progress), March 2018. possession-03 (work in progress), June 2018.
[I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-00 (work in progress), September 2018.
[IANA.CborWebTokenClaims] [IANA.CborWebTokenClaims]
IANA, "CBOR Web Token (CWT) Claims", IANA, "CBOR Web Token (CWT) Claims",
<https://www.iana.org/assignments/cwt/cwt.xhtml#claims- <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
registry>. registry>.
[IANA.JsonWebTokenClaims] [IANA.JsonWebTokenClaims]
IANA, "JSON Web Token Claims", IANA, "JSON Web Token Claims",
<https://www.iana.org/assignments/jwt/jwt.xhtml#claims>. <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>.
skipping to change at page 46, line 5 skipping to change at page 46, line 5
[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>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<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>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 47, line 8 skipping to change at page 47, line 8
[I-D.ietf-ace-actors] [I-D.ietf-ace-actors]
Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
architecture for authorization in constrained architecture for authorization in constrained
environments", draft-ietf-ace-actors-06 (work in environments", draft-ietf-ace-actors-06 (work in
progress), November 2017. 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-12 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), March 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-10 Constrained Devices", draft-ietf-oauth-device-flow-12
(work in progress), June 2018. (work in progress), August 2018.
[Margi10impact] [Margi10impact]
Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr, Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr,
M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold,
"Impact of Operating Systems on Wireless Sensor Networks "Impact of Operating Systems on Wireless Sensor Networks
(Security) Applications and Testbeds", Proceedings of (Security) Applications and Testbeds", Proceedings of
the 19th International Conference on Computer the 19th International Conference on Computer
Communications and Networks (ICCCN), 2010 August. Communications and Networks (ICCCN), 2010 August.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
skipping to change at page 54, line 49 skipping to change at page 54, line 49
using introspection (if this is possible.) using introspection (if this is possible.)
* Send a response following the agreed upon communication * Send a response following the agreed upon communication
security. security.
Appendix C. Requirements on Profiles Appendix C. Requirements on Profiles
This section lists the requirements on profiles of this framework, This section lists the requirements on profiles of this framework,
for the convenience of profile designers. for the convenience of profile designers.
o Specify the communication protocol the client and RS the must use o Specify the communication protocol the client and RS the must use
(e.g., CoAP). Section 5 and Section 5.6.4.4 (e.g., CoAP). Section 5 and Section 5.6.4.3
o Specify the security protocol the client and RS must use to o Specify the security protocol the client and RS must use to
protect their communication (e.g., OSCORE or DTLS over CoAP). protect their communication (e.g., OSCORE or DTLS over CoAP).
This must provide encryption, integrity and replay protection. This must provide encryption, integrity and replay protection.
Section 5.6.4.4 Section 5.6.4.3
o Specify how the client and the RS mutually authenticate. o Specify how the client and the RS mutually authenticate.
Section 4 Section 4
o Specify the Content-format of the protocol messages (e.g.,
"application/cbor" or "application/cose+cbor"). Section 4
o Specify the proof-of-possession protocol(s) and how to select one, o Specify the proof-of-possession protocol(s) and how to select one,
if several are available. Also specify which key types (e.g., if several are available. Also specify which key types (e.g.,
symmetric/asymmetric) are supported by a specific proof-of- symmetric/asymmetric) are supported by a specific proof-of-
possession protocol. Section 5.6.4.3 possession protocol. Section 5.6.4.2
o Specify a unique profile identifier. Section 5.6.4.4 o Specify a unique profile identifier. Section 5.6.4.3
o If introspection is supported: Specify the communication and o If introspection is supported: Specify the communication and
security protocol for introspection.Section 5.7 security protocol for introspection.Section 5.7
o Specify the communication and security protocol for interactions o Specify the communication and security protocol for interactions
between client and AS. Section 5.6 between client and AS. Section 5.6
o Specify how/if the authz-info endpoint is protected, including how o Specify how/if the authz-info endpoint is protected, including how
error responses are protected. Section 5.8.1 error responses are protected. Section 5.8.1
o Optionally define other methods of token transport than the authz- o Optionally define other methods of token transport than the authz-
info endpoint. Section 5.8.1 info endpoint. Section 5.8.1
Appendix D. Assumptions on AS knowledge about C and RS Appendix D. Assumptions on AS knowledge about C and RS
skipping to change at page 57, line 6 skipping to change at page 57, line 4
the client and the RS. The issued token will have a short the client and the RS. The issued token will have a short
validity time, i.e., "exp" close to "iat", to protect the RS from validity time, i.e., "exp" close to "iat", to protect the RS from
replay attacks. The token includes the claim such as "scope" with replay attacks. The token includes the claim such as "scope" with
the authorized access that an owner of the temperature device can the authorized access that an owner of the temperature device can
enjoy. In this example, the "scope" claim, issued by the AS, enjoy. In this example, the "scope" claim, issued by the AS,
informs the RS that the owner of the token, that can prove the informs the RS that the owner of the token, that can prove the
possession of a key is authorized to make a GET request against possession of a key is authorized to make a GET request against
the /temperature resource and a POST request on the /firmware the /temperature resource and a POST request on the /firmware
resource. Note that the syntax and semantics of the scope claim resource. Note that the syntax and semantics of the scope claim
are application specific. are application specific.
Note: In this example it is assumed that the client knows what Note: In this example it is assumed that the client knows what
resource it wants to access, and is therefore able to request resource it wants to access, and is therefore able to request
specific audience and scope claims for the access token. specific audience and scope claims for the access token.
Authorization Authorization
Client Server Client Server
| | | |
|<=======>| DTLS Connection Establishment |<=======>| DTLS Connection Establishment
| | to identify the AS | | to identify the AS
| | | |
A: +-------->| Header: POST (Code=0.02) A: +-------->| Header: POST (Code=0.02)
| POST | Uri-Path:"token" | POST | Uri-Path:"token"
| | Content-Type: application/cbor | | Content-Format: application/ace+cbor
| | Payload: <Request-Payload> | | Payload: <Request-Payload>
| | | |
B: |<--------+ Header: 2.05 Content B: |<--------+ Header: 2.05 Content
| 2.05 | Content-Type: application/cbor | 2.05 | Content-Format: application/ace+cbor
| | Payload: <Response-Payload> | | Payload: <Response-Payload>
| | | |
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. Note that a TLS/DTLS-based Payload is shown in Figure 18.
communication security profile is used in this example. Hence, the
Content-Type is "application/cbor".
Request-Payload : Request-Payload :
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"aud" : "tempSensorInLivingRoom", "aud" : "tempSensorInLivingRoom",
"client_id" : "myclient", "client_id" : "myclient",
"client_secret" : "qwerty" "client_secret" : "qwerty"
"cnf" : {
"COSE_Key" : {
"kid" : b64'1Bg8vub9tLe1gHMzV76e8',
"kty" : "EC",
"crv" : "P-256",
"x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
"y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
}
}
} }
Response-Payload : Response-Payload :
{ {
"access_token" : b64'SlAV32hkKG ...', "access_token" : b64'SlAV32hkKG ...',
"token_type" : "pop", "token_type" : "pop",
"csp" : "DTLS", "csp" : "DTLS",
"rs_cnf" : { "rs_cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk', "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
skipping to change at page 61, line 4 skipping to change at page 61, line 21
A: The client sends the request using POST to the token endpoint A: The client sends the request using POST to the token endpoint
at AS. The request contains the Audience parameter set to at AS. The request contains the Audience parameter set to
"PACS1337" (PACS, Physical Access System), a value the that the "PACS1337" (PACS, Physical Access System), a value the that the
online door in question identifies itself with. The AS generates online door in question identifies itself with. The AS generates
an access token as an opaque string, which it can match to the an access token as an opaque string, which it can match to the
specific client, a targeted audience and a symmetric key. The specific client, a targeted audience and a symmetric key. The
security is provided by identifying the AS on transport layer security is provided by identifying the AS on transport layer
using a pre shared security context (psk, rpk or certificate) and using a pre shared security context (psk, rpk or certificate) and
then the client is identified using client_id and client_secret as then the client is identified using client_id and client_secret as
in classic OAuth. in classic OAuth.
B: The AS responds with the an access token and Access B: The AS responds with the an access token and Access
Information, the latter containing a symmetric key. Communication Information, the latter containing a symmetric key. Communication
security between C and RS will be DTLS and PreSharedKey. The PoP security between C and RS will be DTLS and PreSharedKey. The PoP
key is used as the PreSharedKey. key is used as the PreSharedKey.
Authorization Authorization
Client Server Client Server
| | | |
| | | |
A: +-------->| Header: POST (Code=0.02) A: +-------->| Header: POST (Code=0.02)
| POST | Uri-Path:"token" | POST | Uri-Path:"token"
| | Content-Type: application/cbor | | Content-Format: application/ace+cbor
| | Payload: <Request-Payload> | | Payload: <Request-Payload>
| | | |
B: |<--------+ Header: 2.05 Content B: |<--------+ Header: 2.05 Content
| | Content-Type: application/cbor | | Content-Format: application/ace+cbor
| 2.05 | Payload: <Response-Payload> | 2.05 | Payload: <Response-Payload>
| | | |
Figure 22: Token Request and Response using Client Credentials. Figure 22: 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 23. Payload is shown in Figure 23.
Request-Payload: Request-Payload:
{ {
"grant_type" : "client_credentials", "grant_type" : "client_credentials",
"aud" : "lockOfDoor4711",
"client_id" : "keyfob", "client_id" : "keyfob",
"client_secret" : "qwerty" "client_secret" : "qwerty"
} }
Response-Payload: Response-Payload:
{ {
"access_token" : b64'SlAV32hkKG ...' "access_token" : b64'VGVzdCB0b2tlbg==',
"token_type" : "pop", "token_type" : "pop",
"csp" : "DTLS", "csp" : "DTLS",
"cnf" : { "cnf" : {
"COSE_Key" : { "COSE_Key" : {
"kid" : b64'c29tZSBwdWJsaWMga2V5IGlk', "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk',
"kty" : "oct", "kty" : "oct",
"alg" : "HS256", "alg" : "HS256",
"k": b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE' "k": b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
} }
} }
} }
Figure 23: Request and Response Payload for C offline Figure 23: Request and Response Payload for C offline
The access token in this case is just an opaque string referencing The access token in this case is just an opaque byte string
the authorization information at the AS. referencing the authorization information at the AS.
C: Next, the client POSTs the access token to the authz-info C: Next, the client POSTs the access token to the authz-info
endpoint in the RS. This is a plain CoAP request, i.e., no DTLS endpoint in the RS. This is a plain CoAP request, i.e., no DTLS
between client and RS. Since the token is an opaque string, the between client and RS. Since the token is an opaque string, the
RS cannot verify it on its own, and thus defers to respond the RS cannot verify it on its own, and thus defers to respond the
client with a status code until after step E. client with a status code until after step E.
D: The RS forwards the token to the introspection endpoint on the D: The RS forwards the token to the introspection endpoint on the
AS. Introspection assumes a secure connection between the AS and AS. Introspection assumes a secure connection between the AS and
the RS, e.g., using transport of application layer security. In the RS, e.g., using transport of application layer security. In
the example AS is identified using pre shared security context the example AS is identified using pre shared security context
skipping to change at page 63, line 10 skipping to change at page 63, line 10
(cnf) parameter that allows the RS to verify the client's proof of (cnf) parameter that allows the RS to verify the client's proof of
possession in step F. possession in step F.
After receiving message E, the RS responds to the client's POST in After receiving message E, the RS responds to the client's POST in
step C with the CoAP response code 2.01 (Created). step C with the CoAP response code 2.01 (Created).
Resource Resource
Client Server Client Server
| | | |
C: +-------->| Header: POST (T=CON, Code=0.02) C: +-------->| Header: POST (T=CON, Code=0.02)
| POST | Uri-Path:"authz-info" | POST | Uri-Path:"authz-info"
| | Content-Type: "application/cbor" | | Content-Format: "application/ace+cbor"
| | Payload: b64'SlAV32hkKG ...'' | | Payload: b64'VGVzdCB0b2tlbg=='
| | | |
| | Authorization | | Authorization
| | Server | | Server
| | | | | |
| D: +--------->| Header: POST (Code=0.02) | D: +--------->| Header: POST (Code=0.02)
| | POST | Uri-Path: "introspect" | | POST | Uri-Path: "introspect"
| | | Content-Type: "application/cbor" | | | Content-Format: "application/ace+cbor"
| | | Payload: <Request-Payload> | | | Payload: <Request-Payload>
| | | | | |
| E: |<---------+ Header: 2.05 Content | E: |<---------+ Header: 2.05 Content
| | 2.05 | Content-Type: "application/cbor" | | 2.05 | Content-Format: "application/ace+cbor"
| | | Payload: <Response-Payload> | | | Payload: <Response-Payload>
| | | | | |
| | | |
|<--------+ Header: 2.01 Created |<--------+ Header: 2.01 Created
| 2.01 | | 2.01 |
| | | |
Figure 24: Token Introspection for C offline Figure 24: Token Introspection for C offline
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 25. Payload is shown in Figure 25.
Request-Payload: Request-Payload:
{ {
"token" : b64'SlAV32hkKG...', "token" : b64'VGVzdCB0b2tlbg==',
"client_id" : "FrontDoor", "client_id" : "FrontDoor",
"client_secret" : "ytrewq" "client_secret" : "ytrewq"
} }
Response-Payload: Response-Payload:
{ {
"active" : true, "active" : true,
"aud" : "lockOfDoor4711", "aud" : "lockOfDoor4711",
"scope" : "open, close", "scope" : "open, close",
"iat" : 1311280970, "iat" : 1311280970,
"cnf" : { "cnf" : {
"kid" : b64'JDLUhTMjU2IiwiY3R5Ijoi ...' "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk'
} }
} }
Figure 25: Request and Response Payload for Introspection Figure 25: Request and Response Payload for Introspection
The client uses the symmetric PoP key to establish a DTLS The client uses the symmetric PoP key to establish a DTLS
PreSharedKey secure connection to the RS. The CoAP request PUT is PreSharedKey secure connection to the RS. The CoAP request PUT is
sent to the uri-path /state on the RS, changing the state of the sent to the uri-path /state on the RS, changing the state of the
door to locked. door to locked.
F: The RS responds with a appropriate over the secure DTLS F: The RS responds with a appropriate over the secure DTLS
skipping to change at page 64, line 32 skipping to change at page 64, 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 -12 to -13 F.1. Version -13 to -14
o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to
[I-D.ietf-ace-oauth-params]
o Introduced the "application/ace+cbor" Content-Type.
o Added claim registrations from 'profile' and 'rs_cnf'.
o Added note on schema part of AS Information Section 5.1.2
o Realigned the parameter abbreviations to push rarely used ones to
the 2-byte encoding size of CBOR integers.
F.2. 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.2. Version -11 to -12 F.3. 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.3. Version -10 to -11 F.4. 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.4. Version -09 to -10 F.5. 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.5. Version -08 to -09 F.6. 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.6. Version -07 to -08 F.7. 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.
o Added text to clarify that introspection must not be delayed, in o Added text to clarify that introspection must not be delayed, in
case the RS has to return a client token. case the RS has to return a client token.
o Added security considerations about leakage through unprotected AS o Added security considerations about leakage through unprotected AS
discovery information, combining profiles and leakage through discovery information, combining profiles and leakage through
error responses. error responses.
o Added privacy considerations about leakage through unprotected AS o Added privacy considerations about leakage through unprotected AS
discovery. discovery.
o Added text that clarifies that introspection is optional. o Added text that clarifies that introspection is optional.
skipping to change at page 66, line 4 skipping to change at page 66, line 20
discovery information, combining profiles and leakage through discovery information, combining profiles and leakage through
error responses. error responses.
o Added privacy considerations about leakage through unprotected AS o Added privacy considerations about leakage through unprotected AS
discovery. discovery.
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.7. Version -06 to -07 F.8. Version -06 to -07
o Various clarifications added. o Various clarifications added.
o Fixed erroneous author email. o Fixed erroneous author email.
F.8. Version -05 to -06 F.9. 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.9. Version -04 to -05 F.10. 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.
skipping to change at page 66, line 37 skipping to change at page 67, line 4
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.10. Version -03 to -04 F.11. 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.11. Version -02 to -03 F.12. 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.12. Version -01 to -02 F.13. 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.13. Version -00 to -01 F.14. 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. 105 change blocks. 
355 lines changed or deleted 352 lines changed or added

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