< draft-ietf-ace-oauth-authz-35.txt   draft-ietf-ace-oauth-authz-36.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: December 26, 2020 Ericsson Expires: May 21, 2021 Ericsson
E. Wahlstroem E. Wahlstroem
S. Erdtman S. Erdtman
Spotify AB Spotify AB
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
June 24, 2020 November 17, 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-35 draft-ietf-ace-oauth-authz-36
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 December 26, 2020. This Internet-Draft will expire on May 21, 2021.
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 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16
5.1.1. Unauthorized Resource Request Message . . . . . . . . 16 5.2. Unauthorized Resource Request Message . . . . . . . . . . 17
5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 17 5.3. AS Request Creation Hints . . . . . . . . . . . . . . . . 17
5.1.2.1. The Client-Nonce Parameter . . . . . . . . . . . 19 5.3.1. The Client-Nonce Parameter . . . . . . . . . . . . . 19
5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 20 5.4. Authorization Grants . . . . . . . . . . . . . . . . . . 20
5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20 5.5. Client Credentials . . . . . . . . . . . . . . . . . . . 21
5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 21 5.6. AS Authentication . . . . . . . . . . . . . . . . . . . . 21
5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 21 5.7. The Authorization Endpoint . . . . . . . . . . . . . . . 21
5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21 5.8. The Token Endpoint . . . . . . . . . . . . . . . . . . . 21
5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22 5.8.1. Client-to-AS Request . . . . . . . . . . . . . . . . 22
5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25 5.8.2. AS-to-Client Response . . . . . . . . . . . . . . . . 25
5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 27 5.8.3. Error Response . . . . . . . . . . . . . . . . . . . 27
5.6.4. Request and Response Parameters . . . . . . . . . . . 28 5.8.4. Request and Response Parameters . . . . . . . . . . . 28
5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28 5.8.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 28
5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29 5.8.4.2. Token Type . . . . . . . . . . . . . . . . . . . 29
5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29 5.8.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 29
5.6.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30 5.8.4.4. Client-Nonce . . . . . . . . . . . . . . . . . . 30
5.6.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30 5.8.5. Mapping Parameters to CBOR . . . . . . . . . . . . . 30
5.7. The Introspection Endpoint . . . . . . . . . . . . . . . 31 5.9. The Introspection Endpoint . . . . . . . . . . . . . . . 31
5.7.1. Introspection Request . . . . . . . . . . . . . . . . 32 5.9.1. Introspection Request . . . . . . . . . . . . . . . . 32
5.7.2. Introspection Response . . . . . . . . . . . . . . . 33 5.9.2. Introspection Response . . . . . . . . . . . . . . . 33
5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 34 5.9.3. Error Response . . . . . . . . . . . . . . . . . . . 34
5.7.4. Mapping Introspection parameters to CBOR . . . . . . 35 5.9.4. Mapping Introspection parameters to CBOR . . . . . . 35
5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 35 5.10. The Access Token . . . . . . . . . . . . . . . . . . . . 35
5.8.1. The Authorization Information Endpoint . . . . . . . 36 5.10.1. The Authorization Information Endpoint . . . . . . . 36
5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 37 5.10.1.1. Verifying an Access Token . . . . . . . . . . . 37
5.8.1.2. Protecting the Authorization Information 5.10.1.2. Protecting the Authorization Information
Endpoint . . . . . . . . . . . . . . . . . . . . 39 Endpoint . . . . . . . . . . . . . . . . . . . . 39
5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 39 5.10.2. Client Requests to the RS . . . . . . . . . . . . . 39
5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 40 5.10.3. Token Expiration . . . . . . . . . . . . . . . . . . 40
5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41 5.10.4. Key Expiration . . . . . . . . . . . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42 6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42 6.1. Protecting Tokens . . . . . . . . . . . . . . . . . . . . 42
6.2. Communication Security . . . . . . . . . . . . . . . . . 43 6.2. Communication Security . . . . . . . . . . . . . . . . . 43
6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44 6.3. Long-Term Credentials . . . . . . . . . . . . . . . . . . 44
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 . . . . . . . . . . . . . . . . . . . 46
6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47 6.8. Unprotected Information . . . . . . . . . . . . . . . . . 47
6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 48 6.9. Identifying audiences . . . . . . . . . . . . . . . . . . 47
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. CoRE Resource Type registry . . . . . . . . . . . . . . . 51 8.2. CoRE Resource Type registry . . . . . . . . . . . . . . . 50
8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51 8.3. OAuth Extensions Error Registration . . . . . . . . . . . 51
8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51 8.4. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 51
8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 52 8.5. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 51
8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52 8.6. OAuth Access Token Types . . . . . . . . . . . . . . . . 52
8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52 8.7. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 52
8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53 8.7.1. Initial Registry Contents . . . . . . . . . . . . . . 53
8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53 8.8. ACE Profile Registry . . . . . . . . . . . . . . . . . . 53
8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 54 8.9. OAuth Parameter Registration . . . . . . . . . . . . . . 53
8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54 8.10. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 54
8.11. OAuth Introspection Response Parameter Registration . . . 54 8.11. OAuth Introspection Response Parameter Registration . . . 54
8.12. OAuth Token Introspection Response CBOR Mappings Registry 55 8.12. OAuth Token Introspection Response CBOR Mappings Registry 55
8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55 8.13. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 55
8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56 8.14. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 56
8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57 8.15. Media Type Registrations . . . . . . . . . . . . . . . . 57
8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 58 8.16. CoAP Content-Format Registry . . . . . . . . . . . . . . 57
8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58 8.17. Expert Review Instructions . . . . . . . . . . . . . . . 58
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 59 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 . . . . . . . . . . . . . . . . 65 Appendix A. Design Justification . . . . . . . . . . . . . . . . 64
Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 68
Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 71 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 70
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 . . . . . . . . . . . . . . . . 72 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
skipping to change at page 5, line 51 skipping to change at page 5, line 51
Since exchanges in this specification are described as RESTful Since exchanges in this specification are described as RESTful
protocol interactions, HTTP [RFC7231] offers useful terminology. protocol interactions, HTTP [RFC7231] offers useful terminology.
Terminology for entities in the architecture is defined in OAuth 2.0 Terminology for entities in the architecture is defined in OAuth 2.0
[RFC6749] such as client (C), resource server (RS), and authorization [RFC6749] such as client (C), resource server (RS), and authorization
server (AS). server (AS).
Note that the term "endpoint" is used here following its OAuth Note that the term "endpoint" is used here following its OAuth
definition, which is to denote resources such as token and definition, which is to denote resources such as token and
introspection at the AS and authz-info at the RS (see Section 5.8.1 introspection at the AS and authz-info at the RS (see Section 5.10.1
for a definition of the authz-info endpoint). The CoAP [RFC7252] for a definition of the authz-info endpoint). The CoAP [RFC7252]
definition, which is "An entity participating in the CoAP protocol" definition, which is "An entity participating in the CoAP protocol"
is not used in this specification. is not used in this specification.
The specifications in this document is called the "framework" or "ACE The specifications in this document is called the "framework" or "ACE
framework". When referring to "profiles of this framework" it refers framework". When referring to "profiles of this framework" it refers
to additional specifications that define the use of this to additional specifications that define the use of this
specification with concrete transport and communication security specification with concrete transport and communication security
protocols (e.g., CoAP over DTLS). protocols (e.g., CoAP over DTLS).
skipping to change at page 13, line 47 skipping to change at page 13, line 47
Access Token Response (B): Access Token Response (B):
If the AS successfully processes the request from the client, it If the AS successfully processes the request from the client, it
returns an access token and optionally a refresh token (note that returns an access token and optionally a refresh token (note that
only certain grant types support refresh tokens). It can also only certain grant types support refresh tokens). It can also
return additional parameters, referred to as "Access Information". return additional parameters, referred to as "Access Information".
In addition to the response parameters defined by OAuth 2.0 and In addition to the response parameters defined by OAuth 2.0 and
the PoP access token extension, this framework defines parameters the PoP access token extension, this framework defines parameters
that can be used to inform the client about capabilities of the that can be used to inform the client about capabilities of the
RS, e.g. the profiles the RS supports. More information about RS, e.g. the profiles the RS supports. More information about
these parameters can be found in Section 5.6.4. these parameters can be found in Section 5.8.4.
Resource Request (C): Resource Request (C):
The client interacts with the RS to request access to the The client interacts with the RS to request access to the
protected resource and provides the access token. The protocol to protected resource and provides the access token. The protocol to
use between the client and the RS is not restricted to CoAP. use between the client and the RS is not restricted to CoAP.
HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also
viable candidates. viable candidates.
Depending on the device limitations and the selected protocol, Depending on the device limitations and the selected protocol,
this exchange may be split up into two parts: this exchange may be split up into two parts:
skipping to change at page 14, line 35 skipping to change at page 14, line 35
obtained in the access token or the Access Information. The RS obtained in the access token or the Access Information. The RS
verifies that the token is integrity protected and originated by verifies that the token is integrity protected and originated by
the AS. It then compares the claims contained in the access token the AS. It then compares the claims contained in the access token
with the resource request. If the RS is online, validation can be with the resource request. If the RS is online, validation can be
handed over to the AS using token introspection (see messages D handed over to the AS using token introspection (see messages D
and E) over HTTP or CoAP. and E) over HTTP or CoAP.
Token Introspection Request (D): Token Introspection Request (D):
A resource server may be configured to introspect the access token A resource server may be configured to introspect the access token
by including it in a request to the introspection endpoint at that by including it in a request to the introspection endpoint at that
AS. Token introspection over CoAP is defined in Section 5.7 and AS. Token introspection over CoAP is defined in Section 5.9 and
for HTTP in [RFC7662]. for HTTP in [RFC7662].
Note that token introspection is an optional step and can be Note that token introspection is an optional step and can be
omitted if the token is self-contained and the resource server is omitted if the token is self-contained and the resource server is
prepared to perform the token validation on its own. prepared to perform the token validation on its own.
Token Introspection Response (E): Token Introspection Response (E):
The AS validates the token and returns the most recent parameters, The AS validates the token and returns the most recent parameters,
such as scope, audience, validity etc. associated with it back to such as scope, audience, validity etc. associated with it back to
the RS. The RS then uses the received parameters to process the the RS. The RS then uses the received parameters to process the
skipping to change at page 16, line 36 skipping to change at page 16, line 36
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.16). 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 C must discover the AS in charge of RS to determine where to request
RS, C MAY send an initial Unauthorized Resource Request message to the access token. To do so, C must 1. find out the AS URI to which
RS. RS then denies the request and sends the address of its AS back the token request message must be sent and 2. MUST validate that the
to C. AS with this URI is authorized to provide access tokens for this RS.
Instead of the initial Unauthorized Resource Request message, other In order to determine the AS URI, C MAY send an initial Unauthorized
discovery methods may be used, or the client may be pre-provisioned Resource Request message to RS. RS then denies the request and sends
with an RS-to-AS mapping. the address of its AS back to C (see Section 5.2). How C validates
the AS authorization is not in scope for this document. C may, e.g.,
ask it's owner if this AS is authorized for this RS. C may also use
a mechanism that addresses both problems at once.
5.1.1. Unauthorized Resource Request Message 5.2. Unauthorized Resource Request Message
An Unauthorized Resource Request message is a request for any An Unauthorized Resource Request message is a request for any
resource hosted by RS for which the client does not have resource hosted by RS for which the client does not have
authorization granted. RSes MUST treat any request for a protected authorization granted. RSes MUST treat any request for a protected
resource as an Unauthorized Resource Request message when any of the resource as an Unauthorized Resource Request message when any of the
following hold: following hold:
o The request has been received on an unprotected channel. o The request has been received on an unprotected channel.
o The RS has no valid access token for the sender of the request o The RS has no valid access token for the sender of the request
skipping to change at page 17, line 19 skipping to change at page 17, line 27
o The RS has a valid access token for the sender of the request, but o The RS has a valid access token for the sender of the request, but
that token does not authorize the requested action on the that token does not authorize the requested action on the
requested resource. requested resource.
Note: These conditions ensure that the RS can handle requests Note: These conditions ensure that the RS can handle requests
autonomously once access was granted and a secure channel has been autonomously once access was granted and a secure channel has been
established between C and RS. The authz-info endpoint, as part of established between C and RS. The authz-info endpoint, as part of
the process for authorizing to protected resources, is not itself a the process for authorizing to protected resources, is not itself a
protected resource and MUST NOT be protected as specified above (cf. protected resource and MUST NOT be protected as specified above (cf.
Section 5.8.1). Section 5.10.1).
Unauthorized Resource Request messages MUST be denied with an Unauthorized Resource Request messages MUST be denied with an
"unauthorized_client" error response. In this response, the Resource "unauthorized_client" error response. In this response, the Resource
Server SHOULD provide proper AS Request Creation Hints to enable the Server SHOULD provide proper AS Request Creation Hints to enable the
Client to request an access token from RS's AS as described in Client to request an access token from RS's AS as described in
Section 5.1.2. Section 5.3.
The handling of all client requests (including unauthorized ones) by The handling of all client requests (including unauthorized ones) by
the RS is described in Section 5.8.2. the RS is described in Section 5.10.2.
5.1.2. AS Request Creation Hints 5.3. AS Request Creation Hints
The AS Request Creation Hints message is sent by an RS as a response The AS Request Creation Hints message is sent by an RS as a response
to an Unauthorized Resource Request message (see Section 5.1.1) to to an Unauthorized Resource Request message (see Section 5.2) to help
help the sender of the Unauthorized Resource Request message acquire the sender of the Unauthorized Resource Request message acquire a
a valid access token. The AS Request Creation Hints message is a valid access token. The AS Request Creation Hints message is a CBOR
CBOR map, with a MANDATORY element "AS" specifying an absolute URI map, with an OPTIONAL element "AS" specifying an absolute URI (see
(see Section 4.3 of [RFC3986]) that identifies the appropriate AS for Section 4.3 of [RFC3986]) that identifies the appropriate AS for the
the RS. RS.
The message can also contain the following OPTIONAL parameters: The message can also contain the following OPTIONAL parameters:
o A "audience" element containing a suggested audience that the o A "audience" element containing a suggested audience that the
client should request at the AS. client should request at the AS.
o A "kid" element containing the key identifier of a key used in an o A "kid" element containing the key identifier of a key used in an
existing security association between the client and the RS. The existing security association between the client and the RS. The
RS expects the client to request an access token bound to this RS expects the client to request an access token bound to this
key, in order to avoid having to re-establish the security key, in order to avoid having to re-establish the security
association. association.
o A "cnonce" element containing a client-nonce. See o A "cnonce" element containing a client-nonce. See Section 5.3.1.
Section 5.1.2.1.
o A "scope" element containing the suggested scope that the client o A "scope" element containing the suggested scope that the client
should request towards the AS. should request towards the AS.
Figure 2 summarizes the parameters that may be part of the AS Request Figure 2 summarizes the parameters that may be part of the AS Request
Creation Hints. Creation Hints.
/-----------+----------+---------------------\ /-----------+----------+---------------------\
| Name | CBOR Key | Value Type | | Name | CBOR Key | Value Type |
|-----------+----------+---------------------| |-----------+----------+---------------------|
skipping to change at page 19, line 5 skipping to change at page 19, line 12
Figure 3: AS Request Creation Hints payload example Figure 3: AS Request Creation Hints payload example
In the example above, the response parameter "AS" points the receiver In the example above, the response parameter "AS" points the receiver
of this message to the URI "coaps://as.example.com/token" to request of this message to the URI "coaps://as.example.com/token" to request
access tokens. The RS sending this response (i.e., RS) uses an access tokens. The RS sending this response (i.e., RS) uses an
internal clock that is only loosely synchronized with the clock of internal clock that is only loosely synchronized with the clock of
the AS. Therefore it can not reliably verify the expiration time of the AS. Therefore it can not reliably verify the expiration time of
access tokens it receives. To ensure a certain level of access token access tokens it receives. To ensure a certain level of access token
freshness nevetheless, the RS has included a "cnonce" parameter (see freshness nevetheless, the RS has included a "cnonce" parameter (see
Section 5.1.2.1) in the response. Section 5.3.1) in the response.
Figure 4 illustrates the mandatory to use binary encoding of the Figure 4 illustrates the mandatory to use binary encoding of the
message payload shown in Figure 3. message payload shown in Figure 3.
a4 # map(4) a4 # map(4)
01 # unsigned(1) (=AS) 01 # unsigned(1) (=AS)
78 1c # text(28) 78 1c # text(28)
636f6170733a2f2f61732e657861 636f6170733a2f2f61732e657861
6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
05 # unsigned(5) (=audience) 05 # unsigned(5) (=audience)
skipping to change at page 19, line 28 skipping to change at page 19, line 35
6d706c652e636f6d # "coaps://rs.example.com" 6d706c652e636f6d # "coaps://rs.example.com"
09 # unsigned(9) (=scope) 09 # unsigned(9) (=scope)
66 # text(6) 66 # text(6)
7254656d7043 # "rTempC" 7254656d7043 # "rTempC"
18 27 # unsigned(39) (=cnonce) 18 27 # unsigned(39) (=cnonce)
45 # bytes(5) 45 # bytes(5)
e0a156bb3f # e0a156bb3f #
Figure 4: AS Request Creation Hints example encoded in CBOR Figure 4: AS Request Creation Hints example encoded in CBOR
5.1.2.1. The Client-Nonce Parameter 5.3.1. The Client-Nonce Parameter
If the RS does not synchronize its clock with the AS, it could be If the RS does not synchronize its clock with the AS, it could be
tricked into accepting old access tokens, that are either expired or tricked into accepting old access tokens, that are either expired or
have been compromised. In order to ensure some level of token have been compromised. In order to ensure some level of token
freshness in that case, the RS can use the "cnonce" (client-nonce) freshness in that case, the RS can use the "cnonce" (client-nonce)
parameter. The processing requirements for this parameter are as parameter. The processing requirements for this parameter are as
follows: follows:
o An RS sending a "cnonce" parameter in an AS Request Creation Hints o An RS sending a "cnonce" parameter in an AS Request Creation Hints
message MUST store information to validate that a given cnonce is message MUST store information to validate that a given cnonce is
fresh. How this is implemented internally is out of scope for fresh. How this is implemented internally is out of scope for
this specification. Expiration of client-nonces should be based this specification. Expiration of client-nonces should be based
roughly on the time it would take a client to obtain an access roughly on the time it would take a client to obtain an access
token after receiving the AS Request Creation Hints message, with token after receiving the AS Request Creation Hints message, with
some allowance for unexpected delays. some allowance for unexpected delays.
o A client receiving a "cnonce" parameter in an AS Request Creation o A client receiving a "cnonce" parameter in an AS Request Creation
Hints message MUST include this in the parameters when requesting Hints message MUST include this in the parameters when requesting
an access token at the AS, using the "cnonce" parameter from an access token at the AS, using the "cnonce" parameter from
Section 5.6.4.4. Section 5.8.4.4.
o If an AS grants an access token request containing a "cnonce" o If an AS grants an access token request containing a "cnonce"
parameter, it MUST include this value in the access token, using parameter, it MUST include this value in the access token, using
the "cnonce" claim specified in Section 5.8. the "cnonce" claim specified in Section 5.10.
o An RS that is using the client-nonce mechanism and that receives o An RS that is using the client-nonce mechanism and that receives
an access token MUST verify that this token contains a cnonce an access token MUST verify that this token contains a cnonce
claim, with a client-nonce value that is fresh according to the claim, with a client-nonce value that is fresh according to the
information stored at the first step above. If the cnonce claim information stored at the first step above. If the cnonce claim
is not present or if the cnonce claim value is not fresh, the RS is not present or if the cnonce claim value is not fresh, the RS
MUST discard the access token. If this was an interaction with MUST discard the access token. If this was an interaction with
the authz-info endpoint the RS MUST also respond with an error the authz-info endpoint the RS MUST also respond with an error
message using a response code equivalent to the CoAP code 4.01 message using a response code equivalent to the CoAP code 4.01
(Unauthorized). (Unauthorized).
5.2. Authorization Grants 5.4. Authorization Grants
To request an access token, the client obtains authorization from the To request an access token, the client obtains authorization from the
resource owner or uses its client credentials as a grant. The resource owner or uses its client credentials as a grant. The
authorization is expressed in the form of an authorization grant. authorization is expressed in the form of an authorization grant.
The OAuth framework [RFC6749] defines four grant types. The grant The OAuth framework [RFC6749] defines four grant types. The grant
types can be split up into two groups, those granted on behalf of the types can be split up into two groups, those granted on behalf of the
resource owner (password, authorization code, implicit) and those for resource owner (password, authorization code, implicit) and those for
the client (client credentials). Further grant types have been added the client (client credentials). Further grant types have been added
later, such as [RFC7521] defining an assertion-based authorization later, such as [RFC7521] defining an assertion-based authorization
skipping to change at page 20, line 45 skipping to change at page 21, line 5
resource owner, but does not have any display or has very limited resource owner, but does not have any display or has very limited
interaction possibilities, it is recommended to use the device code interaction possibilities, it is recommended to use the device code
grant defined in [RFC8628]. In cases where the client acts grant defined in [RFC8628]. In cases where the client acts
autonomously the client credentials grant is recommended. autonomously the client credentials grant is recommended.
For details on the different grant types, see section 1.3 of For details on the different grant types, see section 1.3 of
[RFC6749]. The OAuth 2.0 framework provides an extension mechanism [RFC6749]. The OAuth 2.0 framework provides an extension mechanism
for defining additional grant types, so profiles of this framework for defining additional grant types, so profiles of this framework
MAY define additional grant types, if needed. MAY define additional grant types, if needed.
5.3. Client Credentials 5.5. Client Credentials
Authentication of the client is mandatory independent of the grant Authentication of the client is mandatory independent of the grant
type when requesting an access token from the token endpoint. In the type when requesting an access token from the token endpoint. In the
case of the client credentials grant type, the authentication and case of the client credentials grant type, the authentication and
grant coincide. grant coincide.
Client registration and provisioning of client credentials to the Client registration and provisioning of client credentials to the
client is out of scope for this specification. client is out of scope for this specification.
The OAuth framework defines one client credential type in section The OAuth framework defines one client credential type in section
2.3.1 of [RFC6749]: client id and client secret. 2.3.1 of [RFC6749]: client id and client secret.
[I-D.erdtman-ace-rpcc] adds raw-public-key and pre-shared-key to the [I-D.erdtman-ace-rpcc] adds raw-public-key and pre-shared-key to the
client credentials types. Profiles of this framework MAY extend with client credentials types. Profiles of this framework MAY extend with
an additional client credentials type using client certificates. an additional client credentials type using client certificates.
5.4. AS Authentication 5.6. AS Authentication
The client credential grant does not, by default, authenticate the AS The client credential grant does not, by default, authenticate the AS
that the client connects to. In classic OAuth, the AS is that the client connects to. In classic OAuth, the AS is
authenticated with a TLS server certificate. authenticated with a TLS server certificate.
Profiles of this framework MUST specify how clients authenticate the Profiles of this framework MUST specify how clients authenticate the
AS and how communication security is implemented. By default, server AS and how communication security is implemented. By default, server
side TLS certificates, as defined by OAuth 2.0, are required. side TLS certificates, as defined by OAuth 2.0, are required.
5.5. The Authorization Endpoint 5.7. The Authorization Endpoint
The OAuth 2.0 authorization endpoint is used to interact with the The OAuth 2.0 authorization endpoint is used to interact with the
resource owner and obtain an authorization grant, in certain grant resource owner and obtain an authorization grant, in certain grant
flows. The primary use case for the ACE-OAuth framework is for flows. The primary use case for the ACE-OAuth framework is for
machine-to-machine interactions that do not involve the resource machine-to-machine interactions that do not involve the resource
owner in the authorization flow; therefore, this endpoint is out of owner in the authorization flow; therefore, this endpoint is out of
scope here. Future profiles may define constrained adaptation scope here. Future profiles may define constrained adaptation
mechanisms for this endpoint as well. Non-constrained clients mechanisms for this endpoint as well. Non-constrained clients
interacting with constrained resource servers can use the interacting with constrained resource servers can use the
specification in section 3.1 of [RFC6749] and the attack specification in section 3.1 of [RFC6749] and the attack
countermeasures suggested in section 4.2 of [RFC6819]. countermeasures suggested in section 4.2 of [RFC6819].
5.6. The Token Endpoint 5.8. The Token Endpoint
In standard OAuth 2.0, the AS provides the token endpoint for In standard OAuth 2.0, the AS provides the token endpoint for
submitting access token requests. This framework extends the submitting access token requests. This framework extends the
functionality of the token endpoint, giving the AS the possibility to functionality of the token endpoint, giving the AS the possibility to
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
skipping to change at page 22, line 4 skipping to change at page 22, line 11
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,
fulfilling the requirements specified in Section 5. fulfilling the requirements specified in Section 5.
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.8.1. Client-to-AS Request
The client sends a POST request to the token endpoint at the AS. The The client sends a POST request to the token endpoint at the AS. The
profile MUST specify how the communication is protected. The content profile MUST specify how the communication is protected. The content
of the request consists of the parameters specified in the relevant of the request consists of the parameters specified in the relevant
subsection of section 4 of the OAuth 2.0 specification [RFC6749], subsection of section 4 of the OAuth 2.0 specification [RFC6749],
depending on the grant type, with the following exceptions and depending on the grant type, with the following exceptions and
additions: additions:
o The parameter "grant_type" is OPTIONAL in the context of this o The parameter "grant_type" is OPTIONAL in the context of this
framework (as opposed to REQUIRED in RFC6749). If that parameter framework (as opposed to REQUIRED in RFC6749). If that parameter
is missing, the default value "client_credentials" is implied. is missing, the default value "client_credentials" is implied.
o The "audience" parameter from [RFC8693] is OPTIONAL to request an o The "audience" parameter from [RFC8693] is OPTIONAL to request an
access token bound to a specific audience. access token bound to a specific audience.
o The "cnonce" parameter defined in Section 5.6.4.4 is REQUIRED if o The "cnonce" parameter defined in Section 5.8.4.4 is REQUIRED if
the RS provided a client-nonce in the "AS Request Creation Hints" the RS provided a client-nonce in the "AS Request Creation Hints"
message Section 5.1.2 message Section 5.3
o The "scope" parameter MAY be encoded as a byte string instead of o The "scope" parameter MAY be encoded as a byte string instead of
the string encoding specified in section 3.3 of [RFC6749], in the string encoding specified in section 3.3 of [RFC6749], in
order allow compact encoding of complex scopes. The syntax of order allow compact encoding of complex scopes. The syntax of
such a binary encoding is explicitly not specified here and left such a binary encoding is explicitly not specified here and left
to profiles or applications, specifically note that a binary to profiles or applications, specifically note that a binary
encoded scope does not necessarily use the space character '0x20' encoded scope does not necessarily use the space character '0x20'
to delimit scope-tokens. to delimit scope-tokens.
o The client can send an empty (null value) "ace_profile" parameter o The client can send an empty (null value) "ace_profile" parameter
to indicate that it wants the AS to include the "ace_profile" to indicate that it wants the AS to include the "ace_profile"
parameter in the response. See Section 5.6.4.3. parameter in the response. See Section 5.8.4.3.
o A client MUST be able to use the parameters from o A client MUST be able to use the parameters from
[I-D.ietf-ace-oauth-params] in an access token request to the [I-D.ietf-ace-oauth-params] in an access token request to the
token endpoint and the AS MUST be able to process these additional token endpoint and the AS MUST be able to process these additional
parameters. parameters.
The default behavior, is that the AS generates a symmetric proof-of- The default behavior, is that the AS generates a symmetric proof-of-
possession key for the client. In order to use an asymmetric key possession key for the client. In order to use an asymmetric key
pair or to re-use a key previously established with the RS, the pair or to re-use a key previously established with the RS, the
client is supposed to use the "req_cnf" parameter from client is supposed to use the "req_cnf" parameter from
[I-D.ietf-ace-oauth-params]. [I-D.ietf-ace-oauth-params].
If CBOR is used then these parameters MUST be encoded as a CBOR map. If CBOR is used then these parameters MUST be provided as a CBOR map.
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 section 3.2 of [RFC6749]. the HTTP request entity-body, as defined in section 3.2 of [RFC6749].
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-
skipping to change at page 25, line 30 skipping to change at page 25, line 30
reference. reference.
Refresh tokens are typically not stored as securely as proof-of- Refresh tokens are typically not stored as securely as proof-of-
possession keys in requesting clients. Proof-of-possession based possession keys in requesting clients. Proof-of-possession based
refresh token requests MUST NOT request different proof-of-possession refresh token requests MUST NOT request different proof-of-possession
keys or different audiences in token requests. Refresh token keys or different audiences in token requests. Refresh token
requests can only use to request access tokens bound to the same requests can only use to request access tokens bound to the same
proof-of-possession key and the same audience as access tokens issued proof-of-possession key and the same audience as access tokens issued
in the initial token request. in the initial token request.
5.6.2. AS-to-Client Response 5.8.2. AS-to-Client Response
If the access token request has been successfully verified by the AS If the access token request has been successfully verified by the AS
and the client is authorized to obtain an access token corresponding and the client is authorized to obtain an access token corresponding
to its access token request, the AS sends a response with the to its access token request, the AS sends a response with the
response code equivalent to the CoAP response code 2.01 (Created). response code equivalent to the CoAP response code 2.01 (Created).
If client request was invalid, or not authorized, the AS returns an If client request was invalid, or not authorized, the AS returns an
error response as described in Section 5.6.3. error response as described in Section 5.8.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 Appendix D). This prior knowledge may, for example, be set by the
use of a dynamic client registration protocol exchange [RFC7591]. If use of a dynamic client registration protocol exchange [RFC7591]. If
the client has requested a specific proof-of-possession key using the the client has requested a specific proof-of-possession key using the
"req_cnf" parameter from [I-D.ietf-ace-oauth-params], this may also "req_cnf" parameter from [I-D.ietf-ace-oauth-params], this may also
influence which profile the AS selects, as it needs to support the influence which profile the AS selects, as it needs to support the
use of the key type requested the client. use of the key type requested the client.
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 a CBOR map, using CBOR payloads, the content MUST be encoded as a CBOR map,
containing parameters as specified in Section 5.1 of [RFC6749], with containing parameters as specified in Section 5.1 of [RFC6749], with
the following additions and changes: the following additions and changes:
ace_profile: ace_profile:
OPTIONAL unless the request included an empty ace_profile OPTIONAL unless the request included an empty ace_profile
parameter in which case it is MANDATORY. This indicates the parameter in which case it is MANDATORY. This indicates the
profile that the client MUST use towards the RS. See profile that the client MUST use towards the RS. See
Section 5.6.4.3 for the formatting of this parameter. If this Section 5.8.4.3 for the formatting of this parameter. If this
parameter is absent, the AS assumes that the client implicitly parameter is absent, the AS assumes that the client implicitly
knows which profile to use towards the RS. knows which profile to use towards the RS.
token_type: token_type:
This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]. This parameter is OPTIONAL, as opposed to 'required' in [RFC6749].
By default implementations of this framework SHOULD assume that By default implementations of this framework SHOULD assume that
the token_type is "PoP". If a specific use case requires another the token_type is "PoP". If a specific use case requires another
token_type (e.g., "Bearer") to be used then this parameter is token_type (e.g., "Bearer") to be used then this parameter is
REQUIRED. REQUIRED.
skipping to change at page 27, line 26 skipping to change at page 27, line 26
"kty" : "Symmetric", "kty" : "Symmetric",
"kid" : b64'39Gqlw', "kid" : b64'39Gqlw',
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
} }
} }
} }
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.8.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
generally equivalent to the ones for HTTP-based interactions as generally equivalent to the ones for HTTP-based interactions as
defined in Section 5.2 of [RFC6749], with the following exceptions: defined in Section 5.2 of [RFC6749], with the following exceptions:
o When using CBOR the raw payload before being processed by the o When using CBOR the raw payload before being processed by the
communication security protocol MUST be encoded as a CBOR map. 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
skipping to change at page 28, line 35 skipping to change at page 28, line 35
response code equivalent to the CoAP code 4.00 (Bad Request) response code equivalent to the CoAP code 4.00 (Bad Request)
including the error code "unsupported_pop_key" defined in including the error code "unsupported_pop_key" defined in
Figure 10. Figure 10.
o If the client and the RS it has requested an access token for do o If the client and the RS it has requested an access token for do
not share a common profile, the AS MUST reject that request with a not share a common profile, the AS MUST reject that request with a
response code equivalent to the CoAP code 4.00 (Bad Request) response code equivalent to the CoAP code 4.00 (Bad Request)
including the error code "incompatible_ace_profiles" defined in including the error code "incompatible_ace_profiles" defined in
Figure 10. Figure 10.
5.6.4. Request and Response Parameters 5.8.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.8.4.1. Grant Type
The abbreviations specified in the registry defined in Section 8.5 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] |
\--------------------+------------+------------------------/ \--------------------+------------+------------------------/
Figure 11: CBOR abbreviations for common grant types Figure 11: CBOR abbreviations for common grant types
5.6.4.2. Token Type 5.8.4.2. Token Type
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.7, 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.8.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
skipping to change at page 30, line 11 skipping to change at page 30, line 11
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.
5.6.4.4. Client-Nonce 5.8.4.4. Client-Nonce
This parameter MUST be sent from the client to the AS, if it This parameter MUST be sent from the client to the AS, if it
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.3. 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.8.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.10, 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
skipping to change at page 31, line 18 skipping to change at page 31, line 18
| access_token | 1 | byte string | | access_token | 1 | byte string |
| expires_in | 2 | unsigned integer | | expires_in | 2 | unsigned integer |
| audience | 5 | text string | | audience | 5 | text string |
| scope | 9 | text or byte string | | scope | 9 | text or byte string |
| client_id | 24 | text string | | client_id | 24 | text string |
| client_secret | 25 | byte string | | client_secret | 25 | byte string |
| response_type | 26 | text string | | response_type | 26 | text string |
| redirect_uri | 27 | text string | | redirect_uri | 27 | text string |
| state | 28 | text string | | state | 28 | text string |
| code | 29 | byte string | | code | 29 | byte string |
| error | 30 | unsigned integer | | error | 30 | integer |
| error_description | 31 | text string | | error_description | 31 | text string |
| error_uri | 32 | text string | | error_uri | 32 | text string |
| grant_type | 33 | unsigned integer | | grant_type | 33 | unsigned integer |
| token_type | 34 | unsigned integer | | token_type | 34 | integer |
| username | 35 | text string | | username | 35 | text string |
| password | 36 | text string | | password | 36 | text string |
| refresh_token | 37 | byte string | | refresh_token | 37 | byte string |
| ace_profile | 38 | unsigned integer | | ace_profile | 38 | integer |
| cnonce | 39 | byte string | | cnonce | 39 | byte string |
\-------------------+----------+---------------------/ \-------------------+----------+---------------------/
Figure 12: CBOR mappings used in token requests and responses Figure 12: CBOR mappings used in token requests and responses
5.7. The Introspection Endpoint 5.9. The Introspection 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 [RFC7662] for HTTP and JSON, this section to the protocol defined in [RFC7662] for HTTP and JSON, this section
defines adaptations to more constrained environments using CBOR and defines adaptations to more constrained environments using CBOR and
leaving the choice of the application protocol to the profile. leaving the choice of the application protocol to the profile.
Communication between the requesting entity and the introspection Communication between the requesting entity and the introspection
endpoint at the AS MUST be integrity protected and encrypted. The endpoint at the AS MUST be integrity protected and encrypted. The
skipping to change at page 32, line 16 skipping to change at page 32, line 16
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. Introspection Request 5.9.1. Introspection Request
The requesting entity sends a POST request to the introspection The requesting entity sends a POST request to the introspection
endpoint at the AS. The profile MUST specify how the communication endpoint at the AS. The profile MUST specify how the communication
is protected. If CBOR is used, the payload MUST be encoded as a CBOR is protected. If CBOR is used, the payload MUST be encoded as a CBOR
map with a "token" entry containing the access token. Further map with a "token" entry containing the access token. Further
optional parameters representing additional context that is known by optional parameters representing additional context that is known by
the requesting entity to aid the AS in its response MAY be included. the requesting entity to aid the AS in its response MAY be included.
For CoAP-based interaction, all messages MUST use the content type For CoAP-based interaction, all messages MUST use the content type
"application/ace+cbor", while for HTTP-based interactions the "application/ace+cbor", while for HTTP-based interactions the
skipping to change at page 33, line 12 skipping to change at page 33, line 12
Figure 13: Example introspection request. Figure 13: Example introspection request.
{ {
"token" : b64'7gj0dXJQ43U', "token" : b64'7gj0dXJQ43U',
"token_type_hint" : "PoP" "token_type_hint" : "PoP"
} }
Figure 14: Decoded payload. Figure 14: Decoded payload.
5.7.2. Introspection Response 5.9.2. Introspection 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.9.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 [RFC7662] with the following addition: Section 2.2 of [RFC7662] with the following addition:
ace_profile OPTIONAL. This indicates the profile that the RS MUST ace_profile OPTIONAL. This indicates the profile that the RS MUST
use with the client. See Section 5.6.4.3 for more details on the use with the client. See Section 5.8.4.3 for more details on the
formatting of this parameter. formatting of this parameter.
cnonce OPTIONAL. A client-nonce provided to the AS by the client. cnonce OPTIONAL. A client-nonce provided to the AS by the client.
The RS MUST verify that this corresponds to the client-nonce The RS MUST verify that this corresponds to the client-nonce
previously provided to the client in the AS Request Creation previously provided to the client in the AS Request Creation
Hints. See Section 5.1.2 and Section 5.6.4.4. Hints. See Section 5.3 and Section 5.8.4.4.
exi OPTIONAL. The "expires-in" claim associated to this access exi OPTIONAL. The "expires-in" claim associated to this access
token. See Section 5.8.3. token. See Section 5.10.3.
Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that Furthermore [I-D.ietf-ace-oauth-params] defines more parameters that
the AS MUST be able to use when responding to a request to the the AS MUST be able to use when responding to a request to the
introspection endpoint. introspection endpoint.
For example, Figure 15 shows an AS response to the introspection For example, Figure 15 shows an AS response to the introspection
request in Figure 13. Note that this example contains the "cnf" request in Figure 13. Note that this example contains the "cnf"
parameter defined in [I-D.ietf-ace-oauth-params]. parameter defined in [I-D.ietf-ace-oauth-params].
Header: Created (Code=2.01) Header: Created (Code=2.01)
skipping to change at page 34, line 23 skipping to change at page 34, line 23
"COSE_Key" : { "COSE_Key" : {
"kty" : "Symmetric", "kty" : "Symmetric",
"kid" : b64'39Gqlw', "kid" : b64'39Gqlw',
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh'
} }
} }
} }
Figure 15: Example introspection response. Figure 15: Example introspection response.
5.7.3. Error Response 5.9.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 and CBOR is used the payload MUST be encoded as o If content is sent and CBOR is used the payload MUST be encoded as
a CBOR map and the Content-Format "application/ace+cbor" MUST be a CBOR map and the Content-Format "application/ace+cbor" MUST be
used. used.
o If the credentials used by the requesting entity (usually the RS) o If the credentials used by the requesting entity (usually the RS)
skipping to change at page 35, line 7 skipping to change at page 35, line 7
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.4. 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.9.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.12, 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.8.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 |
| aud | 3 | text string | | aud | 3 | text string |
| exp | 4 | integer or | | exp | 4 | integer or |
| | | floating-point number | | | | floating-point number |
| nbf | 5 | integer or | | nbf | 5 | integer or |
| | | floating-point number | | | | floating-point number |
| iat | 6 | integer or | | iat | 6 | integer or |
| | | floating-point number | | | | floating-point number |
| cti | 7 | byte string | | cti | 7 | byte string |
| scope | 9 | text or byte string | | scope | 9 | text or byte string |
| active | 10 | True or False | | active | 10 | True or False |
| token | 11 | byte string | | token | 11 | byte string |
| client_id | 24 | text string | | client_id | 24 | text string |
| error | 30 | unsigned integer | | error | 30 | integer |
| error_description | 31 | text string | | error_description | 31 | text string |
| error_uri | 32 | text string | | error_uri | 32 | text string |
| token_type_hint | 33 | text string | | token_type_hint | 33 | text string |
| token_type | 34 | text string | | token_type | 34 | integer |
| username | 35 | text string | | username | 35 | text string |
| ace_profile | 38 | unsigned integer | | ace_profile | 38 | integer |
| cnonce | 39 | byte string | | cnonce | 39 | byte string |
| exi | 40 | unsigned integer | | exi | 40 | unsigned integer |
\-------------------+----------+-------------------------/ \-------------------+----------+-------------------------/
Figure 16: CBOR Mappings to Token Introspection Parameters. Figure 16: CBOR Mappings to Token Introspection Parameters.
5.8. The Access Token 5.10. 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 [RFC8747] and the "scope" claim document uses the "cnf" claim from [RFC8747] and the "scope" claim
from [RFC8693] for JWT- and CWT-encoded tokens. In addition to from [RFC8693] for JWT- and CWT-encoded tokens. In addition to
string encoding specified for the "scope" claim, a binary encoding string encoding specified for the "scope" claim, a binary encoding
MAY be used. The syntax of such an encoding is explicitly not MAY be used. The syntax of such an encoding is explicitly not
specified here and left to profiles or applications, specifically specified here and left to profiles or applications, specifically
note that a binary encoded scope does not necessarily use the space note that a binary encoded scope does not necessarily use the space
character '0x20' to delimit scope-tokens. character '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.8.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.8.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.
5.8.1. The Authorization Information Endpoint 5.10.1. The Authorization Information Endpoint
The access token, containing authorization information and The access token, containing authorization information and
information about the proof-of-possession method used by the client, information about the proof-of-possession method used by the client,
needs to be transported to the RS so that the RS can authenticate and needs to be transported to the RS so that the RS can authenticate and
authorize the client request. authorize the client 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
framework MAY define other methods for token transport. framework MAY define other methods for token transport.
The method consists of an authz-info endpoint, implemented by the RS. The method consists of an authz-info endpoint, implemented by the RS.
A client using this method MUST make a POST request to the authz-info A client using this method MUST make a POST request to the authz-info
endpoint at the RS with the access token in the payload. The RS endpoint at the RS with the access token in the payload. The RS
receiving the token MUST verify the validity of the token. If the receiving the token MUST verify the validity of the token. If the
token is valid, the RS MUST respond to the POST request with 2.01 token is valid, the RS MUST respond to the POST request with 2.01
(Created). Section Section 5.8.1.1 outlines how an RS MUST proceed (Created). Section Section 5.10.1.1 outlines how an RS MUST proceed
to verify the validity of an access token. to verify the validity of an access token.
The RS MUST be prepared to store at least one access token for future The RS MUST be prepared to store at least one access token for future
use. This is a difference to how access tokens are handled in OAuth use. This is a difference to how access tokens are handled in OAuth
2.0, where the access token is typically sent along with each 2.0, where the access token is typically sent along with each
request, and therefore not stored at the RS. request, and therefore not stored at the RS.
This specification RECOMMENDS that an RS stores only one token per This specification RECOMMENDS that an RS stores only one token per
proof-of-possession key, meaning that an additional token linked to proof-of-possession key, meaning that an additional token linked to
the same key will overwrite any existing token at the RS. The reason the same key will overwrite any existing token at the RS. The reason
skipping to change at page 37, line 28 skipping to change at page 37, line 28
Profiles MUST specify whether the authz-info endpoint is protected, Profiles MUST specify whether the authz-info endpoint is protected,
including whether error responses from this endpoint are protected. including whether error responses from this endpoint are protected.
Note that since the token contains information that allow the client Note that since the token contains information that allow the client
and the RS to establish a security context in the first place, mutual and the RS to establish a security context in the first place, mutual
authentication may not be possible at this point. authentication may not be possible at this point.
The default name of this endpoint in an url-path is '/authz-info', The default name of this endpoint in an url-path is '/authz-info',
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.1.1. Verifying an Access Token 5.10.1.1. Verifying an Access Token
When an RS receives an access token, it MUST verify it before storing When an RS receives an access token, it MUST verify it before storing
it. The details of token verification depends on various aspects, it. The details of token verification depends on various aspects,
including the token encoding, the type of token, the security including the token encoding, the type of token, the security
protection applied to the token, and the claims. The token encoding protection applied to the token, and the claims. The token encoding
matters since the security wrapper differs between the token matters since the security wrapper differs between the token
encodings. For example, a CWT token uses COSE while a JWT token uses encodings. For example, a CWT token uses COSE while a JWT token uses
JOSE. The type of token also has an influence on the verification JOSE. The type of token also has an influence on the verification
procedure since tokens may be self-contained whereby token procedure since tokens may be self-contained whereby token
verification may happen locally at the RS while a token-by-reference verification may happen locally at the RS while a token-by-reference
skipping to change at page 38, line 8 skipping to change at page 38, line 8
of the token first, as specified by the respective token format. For of the token first, as specified by the respective token format. For
CWT the description can be found in [RFC8392] and for JWT the CWT the description can be found in [RFC8392] and for JWT the
relevant specification is [RFC7519]. This MUST include a relevant specification is [RFC7519]. This MUST include a
verification that security protection (and thus the token) was verification that security protection (and thus the token) was
generated by an AS that has the right to issue access tokens for this generated by an AS that has the right to issue access tokens for this
RS. RS.
In case the token is communicated by reference the RS needs to obtain In case the token is communicated by reference the RS needs to obtain
the claims first. When the RS uses token introspection the relevant the claims first. When the RS uses token introspection the relevant
specification is [RFC7662] with CoAP transport specified in specification is [RFC7662] with CoAP transport specified in
Section 5.7. Section 5.9.
Errors may happen during this initial processing stage: Errors may happen during this initial processing stage:
o If token or claim verification fails, the RS MUST discard the o If token or claim verification fails, the RS MUST discard the
token and, if this was an interaction with authz-info, return an token and, if this was an interaction with authz-info, return an
error message with a response code equivalent to the CoAP code error message with a response code equivalent to the CoAP code
4.01 (Unauthorized). 4.01 (Unauthorized).
o If the claims cannot be obtained the RS MUST discard the token o If the claims cannot be obtained the RS MUST discard the token
and, in case of an interaction via the authz-info endpoint, return and, in case of an interaction via the authz-info endpoint, return
skipping to change at page 39, line 22 skipping to change at page 39, line 22
Also note that profiles of this framework may define access token Also note that profiles of this framework may define access token
transport mechanisms that do not allow for error responses. transport mechanisms that do not allow for error responses.
Therefore the error messages specified here only apply if the token Therefore the error messages specified here only apply if the token
was sent to the authz-info endpoint. was sent to the authz-info endpoint.
When sending error responses, the RS MAY use the error codes from When sending error responses, the RS MAY use the error codes from
Section 3.1 of [RFC6750], to provide additional details to the Section 3.1 of [RFC6750], to provide additional details to the
client. client.
5.8.1.2. Protecting the Authorization Information Endpoint 5.10.1.2. Protecting the Authorization Information Endpoint
As this framework can be used in RESTful environments, it is As this framework can be used in RESTful environments, it is
important to make sure that attackers cannot perform unauthorized important to make sure that attackers cannot perform unauthorized
requests on the authz-info endpoints, other than submitting access requests on the authz-info endpoints, other than submitting access
tokens. tokens.
Specifically it SHOULD NOT be possible to perform GET, DELETE or PUT Specifically it SHOULD NOT be possible to perform GET, DELETE or PUT
on the authz-info endpoint and on it's children (if any). on the authz-info endpoint and on it's children (if any).
The POST method SHOULD NOT be allowed on children of the authz-info The POST method SHOULD NOT be allowed on children of the authz-info
endpoint. endpoint.
The RS SHOULD implement rate limiting measures to mitigate attacks The RS SHOULD implement rate limiting measures to mitigate attacks
aiming to overload the processing capacity of the RS by repeatedly aiming to overload the processing capacity of the RS by repeatedly
submitting tokens. For CoAP-based communication the RS could use the submitting tokens. For CoAP-based communication the RS could use the
mechanisms from [RFC8516] to indicate that it is overloaded. mechanisms from [RFC8516] to indicate that it is overloaded.
5.8.2. Client Requests to the RS 5.10.2. Client Requests to the RS
Before sending a request to an RS, the client MUST verify that the Before sending a request to an RS, the client MUST verify that the
keys used to protect this communication are still valid. See keys used to protect this communication are still valid. See
Section 5.8.4 for details on how the client determines the validity Section 5.10.4 for details on how the client determines the validity
of the keys used. of the keys used.
If an RS receives a request from a client, and the target resource If an RS receives a request from a client, and the target resource
requires authorization, the RS MUST first verify that it has an 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 binding that token to the request. performed the proof-of-possession binding that token to the request.
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
skipping to change at page 40, line 32 skipping to change at page 40, line 32
Note: The RS MAY use introspection for timely validation of an access Note: The RS MAY use introspection for timely validation of an access
token, at the time when a request is presented. token, at the time when a request is presented.
Note: Matching the claims of the access token (e.g., scope) to a Note: Matching the claims of the access token (e.g., scope) to a
specific request is application specific. specific request is application specific.
If the request matches a valid token and the client has performed the If the request matches a valid token and the client has performed the
proof-of-possession for that token, the RS continues to process the proof-of-possession for that token, the RS continues to process the
request as specified by the underlying application. request as specified by the underlying application.
5.8.3. Token Expiration 5.10.3. Token Expiration
Depending on the capabilities of the RS, there are various ways in Depending on the capabilities of the RS, there are various ways in
which it can verify the expiration of a received access token. Here which it can verify the expiration of a received access token. Here
follows a list of the possibilities including what functionality they follows a list of the possibilities including what functionality they
require of the RS. require of the RS.
o The token is a CWT and includes an "exp" claim and possibly the o The token is a CWT and includes an "exp" claim and possibly the
"nbf" claim. The RS verifies these by comparing them to values "nbf" claim. The RS verifies these by comparing them to values
from its internal clock as defined in [RFC7519]. In this case the from its internal clock as defined in [RFC7519]. In this case the
RS's internal clock must reflect the current date and time, or at RS's internal clock must reflect the current date and time, or at
least be synchronized with the AS's clock. How this clock least be synchronized with the AS's clock. How this clock
synchronization would be performed is out of scope for this synchronization would be performed is out of scope for this
specification. specification.
o The RS verifies the validity of the token by performing an o The RS verifies the validity of the token by performing an
introspection request as specified in Section 5.7. This requires introspection request as specified in Section 5.9. This requires
the RS to have a reliable network connection to the AS and to be the RS to have a reliable network connection to the AS and to be
able to handle two secure sessions in parallel (C to RS and RS to able to handle two secure sessions in parallel (C to RS and RS to
AS). AS).
o In order to support token expiration for devices that have no o In order to support token expiration for devices that have no
reliable way of synchronizing their internal clocks, this reliable way of synchronizing their internal clocks, this
specification defines the following approach: The claim "exi" specification defines the following approach: The claim "exi"
("expires in") can be used, to provide the RS with the lifetime of ("expires in") can be used, to provide the RS with the lifetime of
the token in seconds from the time the RS first receives the the token in seconds from the time the RS first receives the
token. For CBOR-based interaction this parameter is encoded as token. For CBOR-based interaction this parameter is encoded as
skipping to change at page 41, line 42 skipping to change at page 41, line 42
+ The RS MUST store the highest sequence number of an expired + The RS MUST store the highest sequence number of an expired
token containing the "exi" claim that it has seen, and treat token containing the "exi" claim that it has seen, and treat
tokens with lower sequence numbers as expired. tokens with lower sequence numbers as expired.
If a token that authorizes a long running request such as a CoAP If a token that authorizes a long running request such as a CoAP
Observe [RFC7641] expires, the RS MUST send an error response with Observe [RFC7641] expires, the RS MUST send an error response with
the response code equivalent to the CoAP code 4.01 (Unauthorized) to the response code equivalent to the CoAP code 4.01 (Unauthorized) to
the client and then terminate processing the long running request. the client and then terminate processing the long running request.
5.8.4. Key Expiration 5.10.4. Key Expiration
The AS provides the client with key material that the RS uses. This The AS provides the client with key material that the RS uses. This
can either be a common symmetric PoP-key, or an asymmetric key used can either be a common symmetric PoP-key, or an asymmetric key used
by the RS to authenticate towards the client. Since there is by the RS to authenticate towards the client. Since there is
currently no expiration metadata associated to those keys, the client currently no expiration metadata associated to those keys, the client
has no way of knowing if these keys are still valid. This may lead has no way of knowing if these keys are still valid. This may lead
to situations where the client sends requests containing sensitive to situations where the client sends requests containing sensitive
information to the RS using a key that is expired and possibly in the information to the RS using a key that is expired and possibly in the
hands of an attacker, or accepts responses from the RS that are not hands of an attacker, or accepts responses from the RS that are not
properly protected and could possibly have been forged by an properly protected and could possibly have been forged by an
skipping to change at page 44, line 44 skipping to change at page 44, line 44
Operators also SHOULD have procedures for decommissioning devices, Operators also SHOULD have procedures for decommissioning devices,
that include securely erasing credentials and other security critical that include securely erasing credentials and other security critical
material in the devices being decommissioned. material in the devices being decommissioned.
6.4. Unprotected AS Request Creation Hints 6.4. Unprotected AS Request Creation Hints
Initially, no secure channel exists to protect the communication Initially, no secure channel exists to protect the communication
between C and RS. Thus, C cannot determine if the AS Request between C and RS. Thus, C cannot determine if the AS Request
Creation Hints contained in an unprotected response from RS to an Creation Hints contained in an unprotected response from RS to an
unauthorized request (see Section 5.1.2) are authentic. It is unauthorized request (see Section 5.3) are authentic. C therefore
therefore advisable to provide C with a (possibly hard-coded) list of MUST determine if an AS is authorized to provide access tokens for a
trustworthy authorization servers, possibly including information certain RS.
used to authenticate the AS, such as a public key or certificate
fingerprint. AS Request Creation Hints referring to a URI not listed
there would be ignored.
A compromised RS may use the hints to trick a client into contacting
an AS that is not supposed to be in charge of that RS. Since this AS
must be in the hard-coded list of trusted AS no violation of
privileges and or exposure of credentials should happen, since a
trusted AS is expected to refuse requestes for which it is not
applicable and render a corresponding error response. However a
compromised RS may use this to perform a denial of service against a
specific AS, by redirecting a large number of client requests to that
AS.
A compromised client can be made to contact any AS, including A compromised RS may use the hints for attempting to trick a client
compromised ones. This should not affect the RS, since it is into contacting an AS that is not supposed to be in charge of that
supposed to keep track of which AS are trusted and have corresponding RS. Therefore, C must not communicate with an AS if it cannot
credentials to verify the source of access tokens it receives. determine that this AS has the authority to issue access tokens for
this RS. Otherwise, a compromised RS may use this to perform a
denial of service attack against a specific AS, by redirecting a
large number of client requests to that AS.
6.5. Minimal security requirements for communication 6.5. Minimal security requirements for communication
This section summarizes the minimal requirements for the This section summarizes the minimal requirements for the
communication security of the different protocol interactions. communication security of the different protocol interactions.
C-AS All communication between the client and the Authorization C-AS All communication between the client and the Authorization
Server MUST be encrypted, integrity and replay protected. Server MUST be encrypted, integrity and replay protected.
Furthermore responses from the AS to the client MUST be bound to Furthermore responses from the AS to the client MUST be bound to
the client's request to avoid attacks where the attacker swaps the the client's request to avoid attacks where the attacker swaps the
skipping to change at page 46, line 25 skipping to change at page 46, line 15
negotiation between C and RS, the client MUST have learned what negotiation between C and RS, the client MUST have learned what
profile the RS supports (e.g. from the AS or pre-configured) and profile the RS supports (e.g. from the AS or pre-configured) and
initiate the communication accordingly. initiate the communication accordingly.
6.6. Token Freshness and Expiration 6.6. Token Freshness and Expiration
An RS that is offline faces the problem of clock drift. Since it An RS that is offline faces the problem of clock drift. Since it
cannot synchronize its clock with the AS, it may be tricked into cannot synchronize its clock with the AS, it may be tricked into
accepting old access tokens that are no longer valid or have been accepting old access tokens that are no longer valid or have been
compromised. In order to prevent this, an RS may use the nonce-based compromised. In order to prevent this, an RS may use the nonce-based
mechanism defined in Section 5.1.2 to ensure freshness of an Access mechanism defined in Section 5.3 to ensure freshness of an Access
Token subsequently presented to this RS. Token subsequently presented to this RS.
Another problem with clock drift is that evaluating the standard Another problem with clock drift is that evaluating the standard
token expiration claim "exp" can give unpredictable results. token expiration claim "exp" can give unpredictable results.
Acceptable ranges of clock drift are highly dependent on the concrete Acceptable ranges of clock drift are highly dependent on the concrete
application. Important factors are how long access tokens are valid, application. Important factors are how long access tokens are valid,
and how critical timely expiration of access token is. and how critical timely expiration of access token is.
The expiration mechanism implemented by the "exi" claim, based on the The expiration mechanism implemented by the "exi" claim, based on the
skipping to change at page 47, line 38 skipping to change at page 47, line 29
particular use cases, where this assessment does not apply, detailed particular use cases, where this assessment does not apply, detailed
error messages can be replaced by more generic ones. error messages can be replaced by more generic ones.
In some scenarios it may be possible to protect the communication In some scenarios it may be possible to protect the communication
with the authz-info endpoint (e.g. through DTLS with only server-side with the authz-info endpoint (e.g. through DTLS with only server-side
authentication). In cases where this is not possible this framework authentication). In cases where this is not possible this framework
RECOMMENDS to use encrypted CWTs or tokens that are opaque references RECOMMENDS to use encrypted CWTs or tokens that are opaque references
and need to be subjected to introspection by the RS. and need to be subjected to introspection by the RS.
If the initial unauthorized resource request message (see If the initial unauthorized resource request message (see
Section 5.1.1) is used, the client MUST make sure that it is not Section 5.2) is used, the client MUST make sure that it is not
sending sensitive content in this request. While GET and DELETE sending sensitive content in this request. While GET and DELETE
requests only reveal the target URI of the resource, POST and PUT requests only reveal the target URI of the resource, POST and PUT
requests would reveal the whole payload of the intended operation. requests would reveal the whole payload of the intended operation.
Since the client is not authenticated at the point when it is Since the client is not authenticated at the point when it is
submitting an access token to the authz-info endpoint, attackers may submitting an access token to the authz-info endpoint, attackers may
be pretending to be a client and trying to trick an RS to use an be pretending to be a client and trying to trick an RS to use an
obsolete profile that in turn specifies a vulnerable security obsolete profile that in turn specifies a vulnerable security
mechanism via the authz-info endpoint. Such an attack would require mechanism via the authz-info endpoint. Such an attack would require
a valid access token containing an "ace_profile" claim requesting the a valid access token containing an "ace_profile" claim requesting the
skipping to change at page 48, line 41 skipping to change at page 48, line 32
Even the client must be able to determine the correct values to put Even the client must be able to determine the correct values to put
into the "audience" parameter, in order to obtain a token for the into the "audience" parameter, in order to obtain a token for the
intended RS. Errors in this process can lead to the client intended RS. Errors in this process can lead to the client
inadvertently obtaining a token for the wrong RS. The correct values inadvertently obtaining a token for the wrong RS. The correct values
for "audience" can either be provisioned to the client as part of its for "audience" can either be provisioned to the client as part of its
configuration, or dynamically looked up by the client in some configuration, or dynamically looked up by the client in some
directory. In the latter case the integrity and correctness of the directory. In the latter case the integrity and correctness of the
directory data must be assured. Note that the "audience" hint directory data must be assured. Note that the "audience" hint
provided by the RS as part of the "AS Request Creation Hints" provided by the RS as part of the "AS Request Creation Hints"
Section 5.1.2 is not typically source authenticated and integrity Section 5.3 is not typically source authenticated and integrity
protected, and should therefore not be treated a trusted value. protected, and should therefore not be treated a trusted value.
6.10. Denial of service against or with Introspection 6.10. Denial of service against or with Introspection
The optional introspection mechanism provided by OAuth and supported The optional introspection mechanism provided by OAuth and supported
in the ACE framework allows for two types of attacks that need to be in the ACE framework allows for two types of attacks that need to be
considered by implementers. considered by implementers.
First, an attacker could perform a denial of service attack against First, an attacker could perform a denial of service attack against
the introspection endpoint at the AS in order to prevent validation the introspection endpoint at the AS in order to prevent validation
skipping to change at page 50, line 5 skipping to change at page 49, line 44
device or application running the client. This may be linkable to device or application running the client. This may be linkable to
the identity of the person using the client (if there is a person and the identity of the person using the client (if there is a person and
not a machine-to-machine interaction). not a machine-to-machine interaction).
Clients using asymmetric keys for proof-of-possession should be aware Clients using asymmetric keys for proof-of-possession should be aware
of the consequences of using the same key pair for proof-of- of the consequences of using the same key pair for proof-of-
possession towards different RSs. A set of colluding RSs or an possession towards different RSs. A set of colluding RSs or an
attacker able to obtain the access tokens will be able to link the attacker able to obtain the access tokens will be able to link the
requests, or even to determine the client's identity. requests, or even to determine the client's identity.
An unprotected response to an unauthorized request (see An unprotected response to an unauthorized request (see Section 5.3)
Section 5.1.2) may disclose information about RS and/or its existing may disclose information about RS and/or its existing relationship
relationship with C. It is advisable to include as little with C. It is advisable to include as little information as possible
information as possible in an unencrypted response. If means of in an unencrypted response. Even the absolute URI of the AS may
encrypting communication between C and RS already exist, more reveal sensitive information about the service that RS provides.
detailed information may be included with an error response to Developers must ensure that the RS does not disclose information that
provide C with sufficient information to react on that particular has an impact on the privacy of the stakeholders in the AS Request
error. Creation Hints. They may choose to use a different mechanism for the
discovery of the AS if necessary. If means of encrypting
communication between C and RS already exist, more detailed
information may be included with an error response to provide C with
sufficient information to react on that particular 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.17. 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
skipping to change at page 51, line 27 skipping to change at page 51, line 20
8.3. OAuth Extensions Error Registration 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.8.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.8.3 of [this document]
8.4. 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:
skipping to change at page 54, line 13 skipping to change at page 53, line 52
registrations from the ACE framework profiles. registrations from the ACE framework profiles.
8.9. 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.8.2 and Section 5.8.4.3 of [this document]
8.10. 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:
skipping to change at page 54, line 46 skipping to change at page 54, line 36
8.11. 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.9.2 of [this document]
o Name: "cnonce" o Name: "cnonce"
o Description: "client-nonce". A nonce previously provided to the o Description: "client-nonce". A nonce previously provided to the
AS by the RS via the client. Used to verify token freshness when AS by the RS via the client. Used to verify token freshness when
the RS cannot synchronize its clock with the AS. the RS cannot synchronize its clock with the AS.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.7.2 of [this document] o Reference: Section 5.9.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.9.2 of [this document]
8.12. 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:
skipping to change at page 55, line 50 skipping to change at page 55, line 41
8.13. 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.10 of [this document]
o Claim Name: "cnonce" o Claim Name: "cnonce"
o Claim Description: "client-nonce". A nonce previously provided to o Claim Description: "client-nonce". A nonce previously provided to
the AS by the RS via the client. Used to verify token freshness the AS by the RS via the client. Used to verify token freshness
when the RS cannot synchronize its clock with the AS. when the RS cannot synchronize its clock with the AS.
o Change Controller: IESG o Change Controller: IESG
o Reference: Section 5.8 of [this document] o Reference: Section 5.10 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.10.3 of [this document]
8.14. 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
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.10 of [this document]
o Claim Name: "cnonce" o Claim Name: "cnonce"
o Claim Description: The client-nonce sent to the AS by the RS via o Claim Description: The client-nonce sent to the AS by the RS via
the client. the client.
o JWT Claim Name: cnonce o JWT Claim Name: cnonce
o Claim Key: TBD (suggested: 39) o Claim Key: TBD (suggested: 39)
o Claim Value Type(s): byte string o Claim Value Type(s): byte string
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.8 of [this document] o Specification Document(s): Section 5.10 of [this document]
o Claim Name: "exi" o Claim Name: "exi"
o Claim Description: The expiration time of a token measured from o Claim Description: The expiration time of a token measured from
when it was received at the RS in seconds. when it was received at the RS in seconds.
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.10.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: 9)
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]
skipping to change at page 62, line 33 skipping to change at page 62, line 29
<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-29 (work and Secure Transport", draft-ietf-quic-transport-32 (work
in progress), June 2020. in progress), October 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-38 (work in progress), May 1.3", draft-ietf-tls-dtls13-39 (work in progress),
2020. November 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 21 skipping to change at page 67, line 11
specifically aimed at constrained devices, like, e.g., Bluetooth specifically aimed at constrained devices, like, e.g., Bluetooth
Low Energy (see Section 3.2). This aims again at reducing the Low Energy (see Section 3.2). This aims again at reducing the
size of messages sent over the wire, the RAM size of data objects size of messages sent over the wire, the RAM size of data objects
that need to be kept in memory and the size of libraries that that need to be kept in memory and the size of libraries that
devices need to support. devices need to support.
Access Information: Access Information:
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.8.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 [RFC8747]. A request parameter "cnf" and a Response "cnf" claim [RFC8747]. A request parameter "cnf" and a Response
parameter "cnf", both having a value space semantically and parameter "cnf", both having a value space semantically and
syntactically identical to the "cnf" claim, are defined for the syntactically identical to the "cnf" claim, are defined for the
skipping to change at page 71, line 13 skipping to change at page 70, line 49
tokens. tokens.
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 Optionally define new methods for the client to discover the o Optionally define new methods for the client to discover the
necessary permissions and AS for accessing a resource, different necessary permissions and AS for accessing a resource, different
from the one proposed in Section 5.1. Section 4 from the one proposed in Section 5.1. Section 4
o Optionally specify new grant types. Section 5.2 o Optionally specify new grant types. Section 5.4
o Optionally define the use of client certificates as client o Optionally define the use of client certificates as client
credential type. Section 5.3 credential type. Section 5.5
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.3 (e.g., CoAP). Section 5 and Section 5.8.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). This must protect their communication (e.g., OSCORE or DTLS). This must
provide encryption, integrity and replay protection. provide encryption, integrity and replay protection.
Section 5.6.4.3 Section 5.8.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 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.2 possession protocol. Section 5.8.4.2
o Specify a unique ace_profile identifier. Section 5.6.4.3 o Specify a unique ace_profile identifier. Section 5.8.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.9
o Specify the communication and security protocol for interactions o Specify the communication and security protocol for interactions
between client and AS. This must provide encryption, integrity between client and AS. This must provide encryption, integrity
protection, replay protection and a binding between requests and protection, replay protection and a binding between requests and
responses. Section 5 and Section 5.6 responses. Section 5 and Section 5.8
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.10.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.10.1
Appendix D. Assumptions on AS knowledge about C and RS Appendix D. Assumptions on AS knowledge about C and RS
This section lists the assumptions on what an AS should know about a This section lists the assumptions on what an AS should know about a
client and an RS in order to be able to respond to requests to the client and an RS in order to be able to respond to requests to the
token and introspection endpoints. How this information is token and introspection endpoints. How this information is
established is out of scope for this document. established is out of scope for this document.
o The identifier of the client or RS. o The identifier of the client or RS.
o The profiles that the client or RS supports. o The profiles that the client or RS supports.
skipping to change at page 82, line 43 skipping to change at page 82, line 43
o Added text about protection of credentials. o Added text about protection of credentials.
o Rephrased introspection so that other entities than RS can do it. o Rephrased introspection so that other entities than RS can do it.
o Editorial improvements. o Editorial improvements.
F.9. Version -13 to -14 F.9. Version -13 to -14
o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to
[I-D.ietf-ace-oauth-params] [I-D.ietf-ace-oauth-params]
o Introduced the "application/ace+cbor" Content-Type. o Introduced the "application/ace+cbor" Content-Type.
o Added claim registrations from 'profile' and 'rs_cnf'. o Added claim registrations from 'profile' and 'rs_cnf'.
o Added note on schema part of AS Information Section 5.1.2 o Added note on schema part of AS Information Section 5.3
o Realigned the parameter abbreviations to push rarely used ones to o Realigned the parameter abbreviations to push rarely used ones to
the 2-byte encoding size of CBOR integers. the 2-byte encoding size of CBOR integers.
F.10. Version -12 to -13 F.10. 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
skipping to change at page 84, line 34 skipping to change at page 84, line 34
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.
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.4, and Section 5.5.
o Added Section 5.4 on AS authentication. o Added Section 5.6 on AS authentication.
o Added Section 5.5 on the Authorization endpoint. o Added Section 5.7 on the Authorization endpoint.
F.18. Version -04 to -05 F.18. 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.5 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.10.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.19. Version -03 to -04 F.19. Version -03 to -04
 End of changes. 114 change blocks. 
184 lines changed or deleted 181 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/