draft-ietf-ace-oauth-authz-33.txt   draft-ietf-ace-oauth-authz-34.txt 
ACE Working Group L. Seitz ACE Working Group L. Seitz
Internet-Draft Combitech Internet-Draft Combitech
Intended status: Standards Track G. Selander Intended status: Standards Track G. Selander
Expires: August 10, 2020 Ericsson Expires: December 25, 2020 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
February 7, 2020 June 23, 2020
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-33 draft-ietf-ace-oauth-authz-34
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 the Constrained Application Protocol (CoAP), thus OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
transforming a well-known and widely used authorization solution into transforming a well-known and widely used authorization solution into
a form suitable for IoT devices. Existing specifications are used a form suitable for IoT devices. Existing specifications are used
where possible, but extensions are added and profiles are defined to where possible, but extensions are added and profiles are defined to
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 10, 2020. This Internet-Draft will expire on December 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 25 skipping to change at page 3, line 25
6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44 6.4. Unprotected AS Request Creation Hints . . . . . . . . . . 44
6.5. Minimal security requirements for communication . 45 6.5. Minimal security requirements for communication . 45
6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46 6.6. Token Freshness and Expiration . . . . . . . . . . . . . 46
6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47 6.7. Combining profiles . . . . . . . . . . . . . . . . . . . 47
6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48
6.10. Denial of service against or with Introspection . . 48 6.10. Denial of service against or with Introspection . . 48
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
8.1. ACE Authorization Server Request Creation Hints . . . . . 50 8.1. ACE Authorization Server Request Creation Hints . . . . . 50
8.2. OAuth Extensions Error Registration . . . . . . . . . . . 51 8.2. CoRE Resource Type registry . . . . . . . . . . . . . . . 51
8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51
8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51 8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51
8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52
8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52
8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 52 8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52
8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53 8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53
8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 53 8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53
8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 53 8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54
8.10. OAuth Introspection Response Parameter Registration . . . 54 8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54
8.11. OAuth Token Introspection Response CBOR Mappings Registry 54 8.11. OAuth Introspection Response Parameter Registration . . . 54
8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.12. OAuth Token Introspection Response CBOR Mappings Registry 55
8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
8.14. Media Type Registrations . . . . . . . . . . . . . . . . 56 8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56
8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 57 8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57
8.16. Expert Review Instructions . . . . . . . . . . . . . . . 58 8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.1. Normative References . . . . . . . . . . . . . . . . . . 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 59
10.2. Informative References . . . . . . . . . . . . . . . . . 62 10.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Design Justification . . . . . . . . . . . . . . . . 64 Appendix A. Design Justification . . . . . . . . . . . . . . . . 65
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71
Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 71
Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 71 Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 72
E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 72
E.2. Introspection Aided Token Validation . . . . . . . . . . 76 E.2. Introspection Aided Token Validation . . . . . . . . . . 76
Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 80
F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81 F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 81
F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81 F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 81
F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81 F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 81
F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81 F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 81
F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81 F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 81
F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81 F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 81
F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82 F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 82
F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 82 F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 82
F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 82 F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 82
skipping to change at page 15, line 29 skipping to change at page 15, line 29
common key infrastructure, so the AS provisions credentials or common key infrastructure, so the AS provisions credentials or
associated information to allow mutual authentication between associated information to allow mutual authentication between
client and RS. The resulting security association between client client and RS. The resulting security association between client
and RS may then also be used to bind these credentials to the and RS may then also be used to bind these credentials to the
access tokens the client uses. access tokens the client uses.
Proof-of-Possession Proof-of-Possession
The ACE framework, by default, implements proof-of-possession for The ACE framework, by default, implements proof-of-possession for
access tokens, i.e., that the token holder can prove being a access tokens, i.e., that the token holder can prove being a
holder of the key bound to the token. The binding is provided by holder of the key bound to the token. The binding is provided by
the "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession] indicating the "cnf" claim [RFC8747] indicating what key is used for proof-
what key is used for proof-of-possession. If a client needs to of-possession. If a client needs to submit a new access token,
submit a new access token, e.g., to obtain additional access e.g., to obtain additional access rights, they can request that
rights, they can request that the AS binds this token to the same the AS binds this token to the same key as the previous one.
key as the previous one.
ACE Profiles ACE Profiles
The client or RS may be limited in the encodings or protocols it The client or RS may be limited in the encodings or protocols it
supports. To support a variety of different deployment settings, supports. To support a variety of different deployment settings,
specific interactions between client and RS are defined in an ACE specific interactions between client and RS are defined in an ACE
profile. In ACE framework the AS is expected to manage the profile. In ACE framework the AS is expected to manage the
matching of compatible profile choices between a client and an RS. matching of compatible profile choices between a client and an RS.
The AS informs the client of the selected profile using the The AS informs the client of the selected profile using the
"ace_profile" parameter in the token response. "ace_profile" parameter in the token response.
skipping to change at page 16, line 28 skipping to change at page 16, line 27
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, it is parameters. When profiles of this framework use CoAP instead, it is
REQUIRED to use of the following alternative instead of Uri-query REQUIRED to use of the following alternative instead of Uri-query
parameters: The sender (client or RS) encodes the parameters of its parameters: The sender (client or RS) encodes the parameters of its
request as a CBOR map and submits that map as the payload of the POST request as a CBOR map and submits that map as the payload of the POST
request. request.
Profiles that use CBOR encoding of protocol message parameters at the Profiles that use CBOR encoding of protocol message parameters at the
outermost encoding layer MUST use the media format 'application/ outermost encoding layer MUST use the media format 'application/
ace+cbor'. If CoAP is used for communication, the Content-Format ace+cbor'. If CoAP is used for communication, the Content-Format
MUST be abbreviated with the ID: 19 (see Section 8.15). MUST be abbreviated with the ID: 19 (see Section 8.16).
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, it is REQUIRED to responses both to client and RS. If CoAP is used, it is REQUIRED to
use CBOR [RFC7049] instead of JSON. Depending on the profile, the use CBOR [RFC7049] instead of JSON. Depending on the profile, the
CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper. CBOR payload MAY be enclosed in a non-CBOR cryptographic 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
RS, C MAY send an initial Unauthorized Resource Request message to RS, C MAY send an initial Unauthorized Resource Request message to
skipping to change at page 28, line 44 skipping to change at page 28, line 44
5.6.4. Request and Response Parameters 5.6.4. Request and Response Parameters
This section provides more detail about the new parameters that can This section provides more detail about the new parameters that can
be used in access token requests and responses, as well as be used in access token requests and responses, as well as
abbreviations for more compact encoding of existing parameters and abbreviations for more compact encoding of existing parameters and
common parameter values. common parameter values.
5.6.4.1. Grant Type 5.6.4.1. Grant Type
The abbreviations specified in the registry defined in Section 8.4 The abbreviations specified in the registry defined in Section 8.5
MUST be used in CBOR encodings instead of the string values defined MUST be used in CBOR encodings instead of the string values defined
in [RFC6749], if CBOR payloads are used. 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] |
skipping to change at page 29, line 28 skipping to change at page 29, line 28
The "token_type" parameter, defined in section 5.1 of [RFC6749], The "token_type" parameter, defined in section 5.1 of [RFC6749],
allows the AS to indicate to the client which type of access token it allows the AS to indicate to the client which type of access token it
is receiving (e.g., a bearer token). is receiving (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 use the CBOR The values in the "token_type" parameter MUST use the CBOR
abbreviations defined in the registry specified by Section 8.6, if a abbreviations defined in the registry specified by Section 8.7, if a
CBOR encoding is used. 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.3. 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. It MUST also provide a binding between requests and protection. It MUST also provide a binding between requests and
responses. Furthermore profiles MUST define a list of allowed proof- responses. Furthermore profiles MUST define a list of allowed proof-
of-possession methods, if they support proof-of-possession tokens. of-possession 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 "ace_profile" parameter. The textual identify itself in the "ace_profile" parameter. The textual
representation of the profile identifier is intended for human representation of the profile identifier is intended for human
readability and for JSON-based interactions, it MUST NOT be used for readability and for JSON-based interactions, it MUST NOT be used for
CBOR-based interactions. Profiles MUST register their identifier in CBOR-based interactions. Profiles MUST register their identifier in
the registry defined in Section 8.7. the registry defined in Section 8.8.
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.
Clients that want the AS to provide them with the "ace_profile" Clients that want the AS to provide them with the "ace_profile"
parameter in the access token response can indicate that by sending a parameter in the access token response can indicate that by sending a
ace_profile parameter with a null value (for CBOR-based interactions) ace_profile parameter with a null value (for CBOR-based interactions)
or an empty string (for JSON based interactions) in the access token or an empty string (for JSON based interactions) in the access token
request. request.
skipping to change at page 30, line 24 skipping to change at page 30, line 24
previously received a "cnonce" parameter in the AS Request Creation previously received a "cnonce" parameter in the AS Request Creation
Hints Section 5.1.2. The parameter is encoded as a byte string for Hints Section 5.1.2. The parameter is encoded as a byte string for
CBOR-based interactions, and as a string (Base64 encoded binary) for CBOR-based interactions, and as a string (Base64 encoded binary) for
JSON-based interactions. It MUST copy the value from the cnonce JSON-based interactions. It MUST copy the value from the cnonce
parameter in the AS Request Creation Hints. parameter in the AS Request Creation Hints.
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
the registry defined by Section 8.9, using the given integer the registry defined by Section 8.10, using the given integer
abbreviation for the map keys. abbreviation for the map keys.
Note that we have aligned the abbreviations corresponding to claims Note that we have aligned the abbreviations corresponding to claims
with the abbreviations defined in [RFC8392]. with the abbreviations defined in [RFC8392].
Note also that abbreviations from -24 to 23 have a 1 byte encoding Note also that abbreviations from -24 to 23 have a 1 byte encoding
size in CBOR. We have thus chosen to assign abbreviations in that size in CBOR. We have thus chosen to assign abbreviations in that
range to parameters we expect to be used most frequently in range to parameters we expect to be used most frequently in
constrained scenarios. constrained scenarios.
skipping to change at page 34, line 47 skipping to change at page 34, line 47
o If the requesting entity does not have the right to perform this o If the requesting entity does not have the right to perform this
introspection request, the AS MUST respond with a response code introspection request, the AS MUST respond with a response code
equivalent to the CoAP code 4.03 (Forbidden). In this case no equivalent to the CoAP code 4.03 (Forbidden). In this case no
payload is returned. payload is 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.
o The error codes MUST be abbreviated using the codes specified in o The error codes MUST be abbreviated using the codes specified in
the registry defined by Section 8.3. the registry defined by Section 8.4.
Note that a properly formed and authorized query for an inactive or Note that a properly formed and authorized query for an inactive or
otherwise invalid token does not warrant an error response by this otherwise invalid token does not warrant an error response by this
specification. In these cases, the authorization server MUST instead specification. In these cases, the authorization server MUST instead
respond with an introspection response with the "active" field set to respond with an introspection response with the "active" field set to
"false". "false".
5.7.4. Mapping Introspection parameters to CBOR 5.7.4. Mapping Introspection parameters to CBOR
If CBOR is used, the introspection request and response parameters If CBOR is used, the introspection request and response parameters
MUST be mapped to CBOR types as specified in the registry defined by MUST be mapped to CBOR types as specified in the registry defined by
Section 8.11, using the given integer abbreviation for the map key. Section 8.12, using the given integer abbreviation for the map key.
Note that we have aligned abbreviations that correspond to a claim Note that we have aligned abbreviations that correspond to a claim
with the abbreviations defined in [RFC8392] and the abbreviations of with the abbreviations defined in [RFC8392] and the abbreviations of
parameters with the same name from Section 5.6.5. parameters with the same name from Section 5.6.5.
/-------------------+----------+-------------------------\ /-------------------+----------+-------------------------\
| 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 |
skipping to change at page 36, line 6 skipping to change at page 36, line 6
\-------------------+----------+-------------------------/ \-------------------+----------+-------------------------/
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
document uses the "cnf" claim from document uses the "cnf" claim from [RFC8747] and the "scope" claim
[I-D.ietf-ace-cwt-proof-of-possession] and the "scope" claim from from [RFC8693] for JWT- and CWT-encoded tokens. In addition to
[RFC8693] for JWT- and CWT-encoded tokens. In addition to string string encoding specified for the "scope" claim, a binary encoding
encoding specified for the "scope" claim, a binary encoding MAY be MAY be used. The syntax of such an encoding is explicitly not
used. The syntax of such an encoding is explicitly not specified specified here and left to profiles or applications, specifically
here and left to profiles or applications, specifically note that a note that a binary encoded scope does not necessarily use the space
binary encoded scope does not necessarily use the space character character '0x20' to delimit scope-tokens.
'0x20' to delimit scope-tokens.
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 an should use to communicate with the client, the AS MAY include an
"ace_profile" claim in the access token, with the same syntax and "ace_profile" claim in the access token, with the same syntax and
semantics as defined in Section 5.6.4.3. semantics as defined in Section 5.6.4.3.
If the client submitted a client-nonce parameter in the access token If the client submitted a client-nonce parameter in the access token
request Section 5.6.4.4, the AS MUST include the value of this request Section 5.6.4.4, the AS MUST include the value of this
parameter in the "cnonce" claim specified here. The "cnonce" claim parameter in the "cnonce" claim specified here. The "cnonce" claim
uses binary encoding. uses binary encoding.
skipping to change at page 50, line 18 skipping to change at page 50, line 18
information as possible in an unencrypted response. If means of information as possible in an unencrypted response. If means of
encrypting communication between C and RS already exist, more encrypting communication between C and RS already exist, more
detailed information may be included with an error response to detailed information may be included with an error response to
provide C with sufficient information to react on that particular provide C with sufficient information to react on that particular
error. error.
8. IANA Considerations 8. IANA Considerations
This document creates several registries with a registration policy This document creates several registries with a registration policy
of "Expert Review"; guidelines to the experts are given in of "Expert Review"; guidelines to the experts are given in
Section 8.16. Section 8.17.
8.1. ACE Authorization Server Request Creation Hints 8.1. ACE Authorization Server Request Creation Hints
This specification establishes the IANA "ACE Authorization Server This specification establishes the IANA "ACE Authorization Server
Request Creation Hints" registry. The registry has been created to Request Creation Hints" registry. The registry has been created to
use the "Expert Review" registration procedure [RFC8126]. It should use the "Expert Review" registration procedure [RFC8126]. It should
be noted that, in addition to the expert review, some portions of the be noted that, in addition to the expert review, some portions of the
registry require a specification, potentially a Standards Track RFC, registry require a specification, potentially a Standards Track RFC,
be supplied as well. be supplied as well.
skipping to change at page 51, line 5 skipping to change at page 51, line 5
Value Type The CBOR data types allowable for the values of this Value Type The CBOR data types allowable for the values of this
parameter. parameter.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
request creation hint abbreviation, if one exists. request creation hint abbreviation, if one exists.
This registry will be initially populated by the values in Figure 2. This registry will be initially populated by the values in Figure 2.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.2. OAuth Extensions Error Registration 8.2. CoRE Resource Type registry
IANA is requested to register a new Resource Type (rt=) Link Target
Attribute in the "Resource Type (rt=) Link Target Attribute Values"
subregistry under the "Constrained RESTful Environments (CoRE)
Parameters" [IANA.CoreParameters] registry:
rt="ace.ai". This resource type describes an ACE-OAuth authz-info
endpoint resource.
Specific ACE-OAuth profiles can use this common resource type for
defining their profile-specific discovery processes.
8.3. OAuth Extensions Error Registration
This specification registers the following error values in the OAuth This specification registers the following error values in the OAuth
Extensions Error registry [IANA.OAuthExtensionsErrorRegistry]. Extensions Error registry [IANA.OAuthExtensionsErrorRegistry].
o Error name: "unsupported_pop_key" o Error name: "unsupported_pop_key"
o Error usage location: token error response o Error usage location: token error response
o Related protocol extension: [this document] o Related protocol extension: [this document]
o Change Controller: IESG o Change Controller: IESG
o Specification document(s): Section 5.6.3 of [this document] o Specification document(s): Section 5.6.3 of [this document]
o Error name: "incompatible_ace_profiles" o Error name: "incompatible_ace_profiles"
o Error usage location: token error response o Error usage location: token error response
o Related protocol extension: [this document] o Related protocol extension: [this document]
o Change Controller: IESG o Change Controller: IESG
o Specification document(s): Section 5.6.3 of [this document] o Specification document(s): Section 5.6.3 of [this document]
8.3. OAuth Error Code CBOR Mappings Registry 8.4. OAuth Error Code CBOR Mappings Registry
This specification establishes the IANA "OAuth Error Code CBOR This specification establishes the IANA "OAuth Error Code CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
The columns of the registry are: The columns of the registry are:
Name The OAuth Error Code name, refers to the name in Section 5.2. Name The OAuth Error Code name, refers to the name in Section 5.2.
of [RFC6749], e.g., "invalid_request". of [RFC6749], e.g., "invalid_request".
CBOR Value CBOR abbreviation for this error code. Integer values CBOR Value CBOR abbreviation for this error code. Integer values
less than -65536 are marked as "Private Use", all other values use less than -65536 are marked as "Private Use", all other values use
the registration policy "Expert Review" [RFC8126]. the registration policy "Expert Review" [RFC8126].
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
error code abbreviation, if one exists. error code abbreviation, if one exists.
This registry will be initially populated by the values in Figure 10. This registry will be initially populated by the values in Figure 10.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.4. OAuth Grant Type CBOR Mappings 8.5. OAuth Grant Type CBOR Mappings
This specification establishes the IANA "OAuth Grant Type CBOR This specification establishes the IANA "OAuth Grant Type CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
The columns of this registry are: The columns of this registry are:
Name The name of the grant type as specified in Section 1.3 of Name The name of the grant type as specified in Section 1.3 of
[RFC6749]. [RFC6749].
skipping to change at page 52, line 16 skipping to change at page 52, line 30
less than -65536 are marked as "Private Use", all other values use less than -65536 are marked as "Private Use", all other values use
the registration policy "Expert Review" [RFC8126]. the registration policy "Expert Review" [RFC8126].
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
grant type abbreviation, if one exists. grant type abbreviation, if one exists.
Original Specification This contains a pointer to the public Original Specification This contains a pointer to the public
specification of the grant type, if one exists. specification of the grant type, if one exists.
This registry will be initially populated by the values in Figure 11. This registry will be initially populated by the values in Figure 11.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
8.5. OAuth Access Token Types 8.6. OAuth Access Token Types
This section registers the following new token type in the "OAuth This section registers the following new token type in the "OAuth
Access Token Types" registry [IANA.OAuthAccessTokenTypes]. Access Token Types" registry [IANA.OAuthAccessTokenTypes].
o Type name: "PoP" o Type name: "PoP"
o Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see o Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see
section 3.3 of [I-D.ietf-ace-oauth-params]. section 3.3 of [I-D.ietf-ace-oauth-params].
o HTTP Authentication Scheme(s): N/A o HTTP Authentication Scheme(s): N/A
o Change Controller: IETF o Change Controller: IETF
o Specification document(s): [this document] o Specification document(s): [this document]
8.6. OAuth Access Token Type CBOR Mappings 8.7. OAuth Access Token Type CBOR Mappings
This specification established the IANA "OAuth Access Token Type CBOR This specification established the IANA "OAuth Access Token Type CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
The columns of this registry are: The columns of this registry are:
Name The name of token type as registered in the OAuth Access Token Name The name of token type as registered in the OAuth Access Token
Types registry, e.g., "Bearer". Types registry, e.g., "Bearer".
skipping to change at page 52, line 39 skipping to change at page 53, line 4
This specification established the IANA "OAuth Access Token Type CBOR This specification established the IANA "OAuth Access Token Type CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
The columns of this registry are: The columns of this registry are:
Name The name of token type as registered in the OAuth Access Token Name The name of token type as registered in the OAuth Access Token
Types registry, e.g., "Bearer". Types registry, e.g., "Bearer".
CBOR Value CBOR abbreviation for this token type. Integer values CBOR Value CBOR abbreviation for this token type. Integer values
less than -65536 are marked as "Private Use", all other values use less than -65536 are marked as "Private Use", all other values use
the registration policy "Expert Review" [RFC8126]. the registration policy "Expert Review" [RFC8126].
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
OAuth token type abbreviation, if one exists. OAuth token type abbreviation, if one exists.
Original Specification This contains a pointer to the public Original Specification This contains a pointer to the public
specification of the OAuth token type, if one exists. specification of the OAuth token type, if one exists.
8.6.1. Initial Registry Contents 8.7.1. Initial Registry Contents
o Name: "Bearer" o Name: "Bearer"
o Value: 1 o Value: 1
o Reference: [this document] o Reference: [this document]
o Original Specification: [RFC6749] o Original Specification: [RFC6749]
o Name: "PoP" o Name: "PoP"
o Value: 2 o Value: 2
o Reference: [this document] o Reference: [this document]
o Original Specification: [this document] o Original Specification: [this document]
8.7. ACE Profile Registry 8.8. ACE Profile Registry
This specification establishes the IANA "ACE Profile" registry. The This specification establishes the IANA "ACE Profile" registry. The
registry has been created to use the "Expert Review" registration registry has been created to use the "Expert Review" registration
procedure [RFC8126]. It should be noted that, in addition to the procedure [RFC8126]. It should be noted that, in addition to the
expert review, some portions of the registry require a specification, expert review, some portions of the registry require a specification,
potentially a Standards Track RFC, be supplied as well. potentially a Standards Track RFC, be supplied as well.
The columns of this registry are: The columns of this registry are:
Name The name of the profile, to be used as value of the profile Name The name of the profile, to be used as value of the profile
skipping to change at page 53, line 36 skipping to change at page 54, line 5
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.
This registry will be initially empty and will be populated by the This registry will be initially empty and will be populated by the
registrations from the ACE framework profiles. registrations from the ACE framework profiles.
8.8. OAuth Parameter Registration 8.9. OAuth Parameter Registration
This specification registers the following parameter in the "OAuth This specification registers the following parameter in the "OAuth
Parameters" registry [IANA.OAuthParameters]: Parameters" registry [IANA.OAuthParameters]:
o Name: "ace_profile" o Name: "ace_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.2 and Section 5.6.4.3 of [this document] o Reference: Section 5.6.2 and Section 5.6.4.3 of [this document]
8.9. OAuth Parameters CBOR Mappings Registry 8.10. OAuth Parameters CBOR Mappings Registry
This specification establishes the IANA "OAuth Parameters CBOR This specification establishes the IANA "OAuth Parameters CBOR
Mappings" registry. The registry has been created to use the "Expert Mappings" registry. The registry has been created to use the "Expert
Review" registration procedure [RFC8126], except for the value range Review" registration procedure [RFC8126], except for the value range
designated for private use. designated for private use.
The columns of this registry are: The columns of this registry are:
Name The OAuth Parameter name, refers to the name in the OAuth Name The OAuth Parameter name, refers to the name in the OAuth
parameter registry, e.g., "client_id". parameter registry, e.g., "client_id".
skipping to change at page 54, line 20 skipping to change at page 54, line 37
-65536 are marked as "Private Use", all other values use the -65536 are marked as "Private Use", all other values use the
registration policy "Expert Review" [RFC8126]. registration policy "Expert Review" [RFC8126].
Value Type The allowable CBOR data types for values of this Value Type The allowable CBOR data types for values of this
parameter. parameter.
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
OAuth parameter abbreviation, if one exists. OAuth parameter 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.
8.10. OAuth Introspection Response Parameter Registration 8.11. OAuth Introspection Response Parameter Registration
This specification registers the following parameters in the OAuth This specification registers the following parameters in the OAuth
Token Introspection Response registry Token Introspection Response registry
[IANA.TokenIntrospectionResponse]. [IANA.TokenIntrospectionResponse].
o Name: "ace_profile" o Name: "ace_profile"
o Description: The ACE profile used between client and RS. o Description: The ACE profile used between client and RS.
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]
skipping to change at page 54, line 46 skipping to change at page 55, line 14
o Reference: Section 5.7.2 of [this document] o Reference: Section 5.7.2 of [this document]
o Name: "exi" o Name: "exi"
o Description: "Expires in". Lifetime of the token in seconds from o Description: "Expires in". Lifetime of the token in seconds from
the time the RS first sees it. Used to implement a weaker from of the time the RS first sees it. Used to implement a weaker from of
token expiration for devices that cannot synchronize their token expiration for devices that cannot synchronize their
internal clocks. internal clocks.
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.11. OAuth Token Introspection Response CBOR Mappings Registry 8.12. OAuth Token Introspection Response CBOR Mappings Registry
This specification establishes the IANA "OAuth Token Introspection This specification establishes the IANA "OAuth Token Introspection
Response CBOR Mappings" registry. The registry has been created to Response CBOR Mappings" registry. The registry has been created to
use the "Expert Review" registration procedure [RFC8126], except for use the "Expert Review" registration procedure [RFC8126], except for
the value range designated for private use. the value range designated for private use.
The columns of this registry are: The columns of this registry are:
Name The OAuth Parameter name, refers to the name in the OAuth Name The OAuth Parameter name, refers to the name in the OAuth
parameter registry, e.g., "client_id". parameter registry, e.g., "client_id".
skipping to change at page 55, line 24 skipping to change at page 55, line 40
Reference This contains a pointer to the public specification of the Reference This contains a pointer to the public specification of the
introspection response parameter abbreviation, if one exists. introspection response parameter abbreviation, if one exists.
This registry will be initially populated by the values in Figure 16. This registry will be initially populated by the values in Figure 16.
The Reference column for all of these entries will be this document. The Reference column for all of these entries will be this document.
Note that the mappings of parameters corresponding to claim names Note that the mappings of parameters corresponding to claim names
intentionally coincide with the CWT claim name mappings from intentionally coincide with the CWT claim name mappings from
[RFC8392]. [RFC8392].
8.12. JSON Web Token Claims 8.13. JSON Web Token Claims
This specification registers the following new claims in the JSON Web This specification registers the following new claims in the JSON Web
Token (JWT) registry of JSON Web Token Claims Token (JWT) registry of JSON Web Token Claims
[IANA.JsonWebTokenClaims]: [IANA.JsonWebTokenClaims]:
o Claim Name: "ace_profile" o Claim Name: "ace_profile"
o Claim Description: The ACE profile a token is supposed to be used o Claim Description: The ACE profile a token is supposed to be used
with. with.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8 of [this document] o Reference: Section 5.8 of [this document]
skipping to change at page 56, line 5 skipping to change at page 56, line 19
o Reference: Section 5.8 of [this document] o Reference: Section 5.8 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: "Expires in". Lifetime of the token in seconds o Claim Description: "Expires in". Lifetime of the token in seconds
from the time the RS first sees it. Used to implement a weaker from the time the RS first sees it. Used to implement a weaker
from of token expiration for devices that cannot synchronize their from of token expiration for devices that cannot synchronize their
internal clocks. internal clocks.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8.3 of [this document] o Reference: Section 5.8.3 of [this document]
8.13. CBOR Web Token Claims 8.14. 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: "ace_profile" o Claim Name: "ace_profile"
o Claim Description: The ACE profile a token is supposed to be used o Claim Description: The ACE profile a token is supposed to be used
with. with.
o JWT Claim Name: ace_profile o JWT Claim Name: ace_profile
o Claim Key: TBD (suggested: 38) o Claim Key: TBD (suggested: 38)
o Claim Value Type(s): integer o Claim Value Type(s): integer
skipping to change at page 56, line 41 skipping to change at page 57, line 7
o JWT Claim Name: exi o JWT Claim Name: exi
o Claim Key: TBD (suggested: 40) o Claim Key: TBD (suggested: 40)
o Claim Value Type(s): integer o Claim Value Type(s): integer
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8.3 of [this document] o Specification Document(s): Section 5.8.3 of [this document]
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: scope o JWT Claim Name: scope
o Claim Key: TBD (suggested: 9) o Claim Key: TBD (suggested: 42)
o Claim Value Type(s): byte string or text string o Claim Value Type(s): byte string or text string
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 4.2 of [RFC8693] o Specification Document(s): Section 4.2 of [RFC8693]
8.14. Media Type Registrations 8.15. Media Type Registrations
This specification registers the 'application/ace+cbor' media type This specification registers the 'application/ace+cbor' media type
for messages of the protocols defined in this document carrying for messages of the protocols defined in this document carrying
parameters encoded in CBOR. This registration follows the procedures parameters encoded in CBOR. This registration follows the procedures
specified in [RFC6838]. specified in [RFC6838].
Type name: application Type name: application
Subtype name: ace+cbor Subtype name: ace+cbor
skipping to change at page 57, line 38 skipping to change at page 58, line 4
Additional information: N/A Additional information: N/A
Person & email address to contact for further information: Person & email address to contact for further information:
<iesg@ietf.org> <iesg@ietf.org>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: Ludwig Seitz <ludwig.seitz@combitech.se> Author: Ludwig Seitz <ludwig.seitz@combitech.se>
Change controller: IESG Change controller: IESG
8.15. CoAP Content-Format Registry 8.16. CoAP Content-Format Registry
This specification registers the following entry to the "CoAP This specification registers the following entry to the "CoAP
Content-Formats" registry: Content-Formats" registry:
Media Type: application/ace+cbor Media Type: application/ace+cbor
Encoding: - Encoding: -
ID: TBD (suggested: 19) ID: TBD (suggested: 19)
Reference: [this document] Reference: [this document]
8.16. Expert Review Instructions 8.17. Expert Review Instructions
All of the IANA registries established in this document are defined All of the IANA registries established in this document are defined
to use a registration policy of Expert Review. This section gives to use a registration policy of Expert Review. This section gives
some general guidelines for what the experts should be looking for, some general guidelines for what the experts should be looking for,
but they are being designated as experts for a reason, so they should but they are being designated as experts for a reason, so they should
be given substantial latitude. be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
o Point squatting should be discouraged. Reviewers are encouraged o Point squatting should be discouraged. Reviewers are encouraged
skipping to change at page 59, line 16 skipping to change at page 59, line 31
contributing their work on AS discovery from draft-gerdes-ace-dcaf- contributing their work on AS discovery from draft-gerdes-ace-dcaf-
authorize (see Section 5.1). authorize (see Section 5.1).
Thanks to Jim Schaad and Mike Jones for their comprehensive reviews. Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.
Thanks to Benjamin Kaduk for his input on various questions related Thanks to Benjamin Kaduk for his input on various questions related
to this work. to this work.
Thanks to Cigdem Sengul for some very useful review comments. Thanks to Cigdem Sengul for some very useful review comments.
Thanks to Carsten Bormann for contributing the text for the CoRE
Resource Type registry.
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. Ludwig the CelticPlus project CyberWI, with funding from Vinnova. Ludwig
Seitz was also received further funding for this work by Vinnova in Seitz was also received further funding for this work by Vinnova in
the context of the CelticNext project Critisec. the context of the CelticNext project Critisec.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-11 (work in progress), October 2019.
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
Seitz, L., "Additional OAuth Parameters for Authorization Seitz, L., "Additional OAuth Parameters for Authorization
in Constrained Environments (ACE)", draft-ietf-ace-oauth- in Constrained Environments (ACE)", draft-ietf-ace-oauth-
params-11 (work in progress), January 2020. params-13 (work in progress), April 2020.
[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.CoreParameters]
IANA, "Constrained RESTful Environments (CoRE)
Parameters", <https://www.iana.org/assignments/core-
parameters/core-parameters.xhtml>.
[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>.
[IANA.OAuthAccessTokenTypes] [IANA.OAuthAccessTokenTypes]
IANA, "OAuth Access Token Types", IANA, "OAuth Access Token Types",
<https://www.iana.org/assignments/oauth-parameters/oauth- <https://www.iana.org/assignments/oauth-parameters/oauth-
parameters.xhtml#token-types>. parameters.xhtml#token-types>.
[IANA.OAuthExtensionsErrorRegistry] [IANA.OAuthExtensionsErrorRegistry]
skipping to change at page 62, line 5 skipping to change at page 62, line 14
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020, DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/info/rfc8693>. <https://www.rfc-editor.org/info/rfc8693>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
10.2. Informative References 10.2. Informative References
[BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1", [BLE] Bluetooth SIG, "Bluetooth Core Specification v5.1",
Section 4.4, January 2019, Section 4.4, January 2019,
<https://www.bluetooth.com/specifications/bluetooth-core- <https://www.bluetooth.com/specifications/bluetooth-core-
specification/>. specification/>.
[I-D.erdtman-ace-rpcc] [I-D.erdtman-ace-rpcc]
Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared- Seitz, L. and S. Erdtman, "Raw-Public-Key and Pre-Shared-
Key as OAuth client credentials", draft-erdtman-ace- Key as OAuth client credentials", draft-erdtman-ace-
rpcc-02 (work in progress), October 2017. rpcc-02 (work in progress), October 2017.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-25 (work and Secure Transport", draft-ietf-quic-transport-29 (work
in progress), January 2020. in progress), June 2020.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-34 (work in progress), 1.3", draft-ietf-tls-dtls13-38 (work in progress), May
November 2019. 2020.
[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), August 2010. Communications and Networks (ICCCN), August 2010.
[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT [MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT
skipping to change at page 67, line 10 skipping to change at page 67, line 29
This framework defines the name "Access Information" for data This framework defines the name "Access Information" for data
concerning the RS that the AS returns to the client in an access concerning the RS that the AS returns to the client in an access
token response (see Section 5.6.2). This aims at enabling token response (see Section 5.6.2). This aims at enabling
scenarios where a powerful client, supporting multiple profiles, scenarios where a powerful client, supporting multiple profiles,
needs to interact with an RS for which it does not know the needs to interact with an RS for which it does not know the
supported profiles and the raw public key. supported profiles and the raw public key.
Proof-of-Possession: Proof-of-Possession:
This framework makes use of proof-of-possession tokens, using the This framework makes use of proof-of-possession tokens, using the
"cnf" claim [I-D.ietf-ace-cwt-proof-of-possession]. A request "cnf" claim [RFC8747]. A request parameter "cnf" and a Response
parameter "cnf" and a Response parameter "cnf", both having a parameter "cnf", both having a value space semantically and
value space semantically and syntactically identical to the "cnf" syntactically identical to the "cnf" claim, are defined for the
claim, are defined for the token endpoint, to allow requesting and token endpoint, to allow requesting and stating confirmation keys.
stating confirmation keys. This aims at making token theft This aims at making token theft harder. Token theft is
harder. Token theft is specifically relevant in constrained use specifically relevant in constrained use cases, as communication
cases, as communication often passes through middle-boxes, which often passes through middle-boxes, which could be able to steal
could be able to steal bearer tokens and use them to gain bearer tokens and use them to gain unauthorized access.
unauthorized access.
Authz-Info endpoint: Authz-Info endpoint:
This framework introduces a new way of providing access tokens to This framework introduces a new way of providing access tokens to
an RS by exposing a authz-info endpoint, to which access tokens an RS by exposing a authz-info endpoint, to which access tokens
can be POSTed. This aims at reducing the size of the request can be POSTed. This aims at reducing the size of the request
message and the code complexity at the RS. The size of the message and the code complexity at the RS. The size of the
request message is problematic, since many constrained protocols request message is problematic, since many constrained protocols
have severe message size limitations at the physical layer (e.g., have severe message size limitations at the physical layer (e.g.,
in the order of 100 bytes). This means that larger packets get in the order of 100 bytes). This means that larger packets get
skipping to change at page 84, line 22 skipping to change at page 84, line 22
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 [RFC8747]
F.16. Version -06 to -07 F.16. Version -06 to -07
o Various clarifications added. o Various clarifications added.
o Fixed erroneous author email. o Fixed erroneous author email.
F.17. Version -05 to -06 F.17. 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.
 End of changes. 48 change blocks. 
85 lines changed or deleted 103 lines changed or added

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