--- 1/draft-ietf-ace-oauth-authz-21.txt 2019-03-05 02:13:09.827553832 -0800 +++ 2/draft-ietf-ace-oauth-authz-22.txt 2019-03-05 02:13:09.975557423 -0800 @@ -1,26 +1,26 @@ ACE Working Group L. Seitz Internet-Draft RISE Intended status: Standards Track G. Selander -Expires: August 18, 2019 Ericsson +Expires: September 6, 2019 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig Arm Ltd. - February 14, 2019 + March 5, 2019 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) - draft-ietf-ace-oauth-authz-21 + draft-ietf-ace-oauth-authz-22 Abstract This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 18, 2019. + This Internet-Draft will expire on September 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,21 +64,21 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 11 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Discovering Authorization Servers . . . . . . . . . . . . 16 5.1.1. Unauthorized Resource Request Message . . . . . . . . 16 5.1.2. AS Request Creation Hints . . . . . . . . . . . . . . 17 5.2. Authorization Grants . . . . . . . . . . . . . . . . . . 19 - 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 19 + 5.3. Client Credentials . . . . . . . . . . . . . . . . . . . 20 5.4. AS Authentication . . . . . . . . . . . . . . . . . . . . 20 5.5. The Authorization Endpoint . . . . . . . . . . . . . . . 20 5.6. The Token Endpoint . . . . . . . . . . . . . . . . . . . 20 5.6.1. Client-to-AS Request . . . . . . . . . . . . . . . . 21 5.6.2. AS-to-Client Response . . . . . . . . . . . . . . . . 24 5.6.3. Error Response . . . . . . . . . . . . . . . . . . . 26 5.6.4. Request and Response Parameters . . . . . . . . . . . 27 5.6.4.1. Grant Type . . . . . . . . . . . . . . . . . . . 27 5.6.4.2. Token Type . . . . . . . . . . . . . . . . . . . 28 5.6.4.3. Profile . . . . . . . . . . . . . . . . . . . . . 28 @@ -88,81 +88,82 @@ 5.7.2. Introspection Response . . . . . . . . . . . . . . . 31 5.7.3. Error Response . . . . . . . . . . . . . . . . . . . 32 5.7.4. Mapping Introspection parameters to CBOR . . . . . . 33 5.8. The Access Token . . . . . . . . . . . . . . . . . . . . 33 5.8.1. The Authorization Information Endpoint . . . . . . . 34 5.8.1.1. Verifying an Access Token . . . . . . . . . . . . 35 5.8.1.2. Protecting the Authorization Information Endpoint . . . . . . . . . . . . . . . . . . . . 37 5.8.2. Client Requests to the RS . . . . . . . . . . . . . . 37 5.8.3. Token Expiration . . . . . . . . . . . . . . . . . . 38 - 5.8.4. Key Expriation . . . . . . . . . . . . . . . . . . . 39 + 5.8.4. Key Expiration . . . . . . . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 6.1. Unprotected AS Request Creation Hints . . . . . . . . . . 41 6.2. Minimal security requirements for communication . 41 6.3. Use of Nonces for Replay Protection . . . . . . . . . . . 42 6.4. Combining profiles . . . . . . . . . . . . . . . . . . . 42 6.5. Unprotected Information . . . . . . . . . . . . . . . . . 42 6.6. Identifying audiences . . . . . . . . . . . . . . . . . . 43 6.7. Denial of service against or with Introspection . . 44 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 44 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 8.1. ACE Authorization Server Request Creation Hints . . . . . 45 8.2. OAuth Extensions Error Registration . . . . . . . . . . . 46 8.3. OAuth Error Code CBOR Mappings Registry . . . . . . . . . 46 - 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 46 + 8.4. OAuth Grant Type CBOR Mappings . . . . . . . . . . . . . 47 8.5. OAuth Access Token Types . . . . . . . . . . . . . . . . 47 8.6. OAuth Access Token Type CBOR Mappings . . . . . . . . . . 47 8.6.1. Initial Registry Contents . . . . . . . . . . . . . . 48 8.7. ACE Profile Registry . . . . . . . . . . . . . . . . . . 48 8.8. OAuth Parameter Registration . . . . . . . . . . . . . . 49 8.9. OAuth Parameters CBOR Mappings Registry . . . . . . . . . 49 8.10. OAuth Introspection Response Parameter Registration . . . 49 8.11. OAuth Token Introspection Response CBOR Mappings Registry 50 8.12. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 50 8.13. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 51 - 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 52 - 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 53 + 8.14. Media Type Registrations . . . . . . . . . . . . . . . . 51 + 8.15. CoAP Content-Format Registry . . . . . . . . . . . . . . 52 8.16. Expert Review Instructions . . . . . . . . . . . . . . . 53 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 10.1. Normative References . . . . . . . . . . . . . . . . . . 54 10.2. Informative References . . . . . . . . . . . . . . . . . 56 Appendix A. Design Justification . . . . . . . . . . . . . . . . 59 Appendix B. Roles and Responsibilities . . . . . . . . . . . . . 62 Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 64 Appendix D. Assumptions on AS knowledge about C and RS . . . . . 65 - Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 66 + Appendix E. Deployment Examples . . . . . . . . . . . . . . . . 65 E.1. Local Token Validation . . . . . . . . . . . . . . . . . 66 E.2. Introspection Aided Token Validation . . . . . . . . . . 70 Appendix F. Document Updates . . . . . . . . . . . . . . . . . . 74 - F.1. Verion -20 to 21 . . . . . . . . . . . . . . . . . . . . 74 - F.2. Verion -19 to 20 . . . . . . . . . . . . . . . . . . . . 74 - F.3. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 74 - F.4. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 75 - F.5. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 75 - F.6. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 75 - F.7. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 75 - F.8. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 76 - F.9. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 76 - F.10. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 76 - F.11. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 76 - F.12. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 76 - F.13. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 77 - F.14. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 77 - F.15. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 77 - F.16. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 78 - F.17. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 78 - F.18. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 78 - F.19. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 78 - F.20. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 79 - F.21. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 79 + F.1. Version -21 to 22 . . . . . . . . . . . . . . . . . . . . 74 + F.2. Version -20 to 21 . . . . . . . . . . . . . . . . . . . . 74 + F.3. Version -19 to 20 . . . . . . . . . . . . . . . . . . . . 74 + F.4. Version -18 to -19 . . . . . . . . . . . . . . . . . . . 75 + F.5. Version -17 to -18 . . . . . . . . . . . . . . . . . . . 75 + F.6. Version -16 to -17 . . . . . . . . . . . . . . . . . . . 75 + F.7. Version -15 to -16 . . . . . . . . . . . . . . . . . . . 76 + F.8. Version -14 to -15 . . . . . . . . . . . . . . . . . . . 76 + F.9. Version -13 to -14 . . . . . . . . . . . . . . . . . . . 76 + F.10. Version -12 to -13 . . . . . . . . . . . . . . . . . . . 76 + F.11. Version -11 to -12 . . . . . . . . . . . . . . . . . . . 76 + F.12. Version -10 to -11 . . . . . . . . . . . . . . . . . . . 77 + F.13. Version -09 to -10 . . . . . . . . . . . . . . . . . . . 77 + F.14. Version -08 to -09 . . . . . . . . . . . . . . . . . . . 77 + F.15. Version -07 to -08 . . . . . . . . . . . . . . . . . . . 77 + F.16. Version -06 to -07 . . . . . . . . . . . . . . . . . . . 78 + F.17. Version -05 to -06 . . . . . . . . . . . . . . . . . . . 78 + F.18. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 78 + F.19. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 78 + F.20. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 78 + F.21. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 79 + F.22. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 1. Introduction Authorization is the process for granting approval to an entity to access a resource [RFC4949]. The authorization task itself can best be described as granting access to a requesting client, for a resource hosted on a device, the resource server (RS). This exchange is mediated by one or multiple authorization servers (AS). Managing authorization for a large number of devices and users can be a @@ -271,23 +272,23 @@ format COSE [RFC8152], which enables application layer security as an alternative or complement to transport layer security (DTLS [RFC6347] or TLS [RFC8446]). COSE is used to secure self-contained tokens such as proof-of-possession (PoP) tokens, which is an extension to the OAuth tokens. The default token format is defined in CBOR web token (CWT) [RFC8392]. Application layer security for CoAP using COSE can be provided with OSCORE [I-D.ietf-core-object-security]. With the building blocks listed above, solutions satisfying various IoT device and network constraints are possible. A list of - constraints is described in detail in RFC 7228 [RFC7228] and a - description of how the building blocks mentioned above relate to the - various constraints can be found in Appendix A. + constraints is described in detail in [RFC7228] and a description of + how the building blocks mentioned above relate to the various + constraints can be found in Appendix A. Luckily, not every IoT device suffers from all constraints. The ACE framework nevertheless takes all these aspects into account and allows several different deployment variants to co-exist, rather than mandating a one-size-fits-all solution. It is important to cover the wide range of possible interworking use cases and the different requirements from a security point of view. Once IoT deployments mature, popular deployment variants will be documented in the form of ACE profiles. @@ -475,36 +476,36 @@ from an AS using the token endpoint and subsequently presents the access token to a RS to gain access to a protected resource. In most deployments the RS can process the access token locally, however in some cases the RS may present it to the AS via the introspection endpoint to get fresh information. These interactions are shown in Figure 1. An overview of various OAuth concepts is provided in Section 3.1. The OAuth 2.0 framework defines a number of "protocol flows" via grant types, which have been extended further with extensions to - OAuth 2.0 (such as RFC 7521 [RFC7521] and - [I-D.ietf-oauth-device-flow]). What grant types works best depends - on the usage scenario and RFC 7744 [RFC7744] describes many different - IoT use cases but there are two preferred grant types, namely the - Authorization Code Grant (described in Section 4.1 of [RFC7521]) and - the Client Credentials Grant (described in Section 4.4 of [RFC7521]). - The Authorization Code Grant is a good fit for use with apps running - on smart phones and tablets that request access to IoT devices, a - common scenario in the smart home environment, where users need to go - through an authentication and authorization phase (at least during - the initial setup phase). The native apps guidelines described in - [RFC8252] are applicable to this use case. The Client Credential - Grant is a good fit for use with IoT devices where the OAuth client - itself is constrained. In such a case, the resource owner has pre- - arranged access rights for the client with the authorization server, - which is often accomplished using a commissioning tool. + OAuth 2.0 (such as [RFC7521] and [I-D.ietf-oauth-device-flow]). What + grant types works best depends on the usage scenario and [RFC7744] + describes many different IoT use cases but there are two preferred + grant types, namely the Authorization Code Grant (described in + Section 4.1 of [RFC7521]) and the Client Credentials Grant (described + in Section 4.4 of [RFC7521]). The Authorization Code Grant is a good + fit for use with apps running on smart phones and tablets that + request access to IoT devices, a common scenario in the smart home + environment, where users need to go through an authentication and + authorization phase (at least during the initial setup phase). The + native apps guidelines described in [RFC8252] are applicable to this + use case. The Client Credential Grant is a good fit for use with IoT + devices where the OAuth client itself is constrained. In such a + case, the resource owner has pre-arranged access rights for the + client with the authorization server, which is often accomplished + using a commissioning tool. The consent of the resource owner, for giving a client access to a protected resource, can be provided dynamically as in the traditional OAuth flows, or it could be pre-configured by the resource owner as authorization policies at the AS, which the AS evaluates when a token request arrives. The resource owner and the requesting party (i.e., client owner) are not shown in Figure 1. This framework supports a wide variety of communication security mechanisms between the ACE entities, such as client, AS, and RS. It @@ -790,47 +791,54 @@ be transformed to "coaps://as.example.com/token". It is assumed that the client can determine the correct schema part on its own depending on the way it communicates with the AS. Figure 3 shows an example for an AS Request Creation Hints message payload using CBOR [RFC7049] diagnostic notation, using the parameter names instead of the CBOR keys for better human readability. 4.01 Unauthorized Content-Format: application/ace+cbor - {AS: "coaps://as.example.com/token", - audience: "coaps://rs.example.com", - nonce: h'e0a156bb3f', - scope: "rTempC" + {"AS" : "coaps://as.example.com/token", + "nonce" : h'e0a156bb3f', + "scope" : "rTempC", + "audience" : "coaps://rs.example.com" } Figure 3: AS Request Creation Hints payload example In this example, the attribute AS points the receiver of this message to the URI "coaps://as.example.com/token" to request access permissions. The originator of the AS Request Creation Hints payload (i.e., RS) uses a local clock that is loosely synchronized with a time scale common between RS and AS (e.g., wall clock time). Therefore, it has included a parameter "nonce" for replay attack prevention. Figure 4 illustrates the mandatory to use binary encoding of the message payload shown in Figure 3. - a2 # map(2) + a4 # map(4) 00 # unsigned(0) (=AS) 78 1c # text(28) 636f6170733a2f2f61732e657861 6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token" 05 # unsigned(5) (=nonce) 45 # bytes(5) - e0a156bb3f + e0a156bb3f # "\xE0\xA1V\xBB?" + 09 # unsigned(9) (=scope) + 66 # text(6) + 7254656d7043 # "rTempC" + 12 # unsigned(18) (=audience) + 76 # text(22) + 636f6170733a2f2f72732e657861 + 6d706c652e636f6d # "coaps://rs.example.com" Figure 4: AS Request Creation Hints example encoded in CBOR 5.2. Authorization Grants To request an access token, the client obtains authorization from the resource owner or uses its client credentials as grant. The authorization is expressed in the form of an authorization grant. The OAuth framework [RFC6749] defines four grant types. The grant @@ -842,60 +850,61 @@ The grant type is selected depending on the use case. In cases where the client acts on behalf of the resource owner, authorization code grant is recommended. If the client acts on behalf of the resource owner, but does not have any display or very limited interaction possibilities it is recommended to use the device code grant defined in [I-D.ietf-oauth-device-flow]. In cases where the client does not act on behalf of the resource owner, client credentials grant is recommended. - For details on the different grant types, see the OAuth 2.0 framework + For details on the different grant types, see section 1.3 of [RFC6749]. The OAuth 2.0 framework provides an extension mechanism for defining additional grant types so profiles of this framework MAY define additional grant types, if needed. 5.3. Client Credentials Authentication of the client is mandatory independent of the grant type when requesting the access token from the token endpoint. In the case of client credentials grant type, the authentication and grant coincide. Client registration and provisioning of client credentials to the client is out of scope for this specification. - The OAuth framework [RFC6749] defines one client credential type, - client id and client secret. [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 additional client credentials client - certificates. + The OAuth framework defines one client credential type in section + 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 + client credentials types. Profiles of this framework MAY extend with + additional client credentials client certificates. 5.4. AS Authentication Client credential does not, by default, authenticate the AS that the client connects to. In classic OAuth, the AS is authenticated with a TLS server certificate. Profiles of this framework MUST specify how clients authenticate the AS and how communication security is implemented, otherwise server side TLS certificates, as defined by OAuth 2.0, are required. 5.5. The Authorization Endpoint The authorization endpoint is used to interact with the resource owner and obtain an authorization grant in certain grant flows. Since it requires the use of a user agent (i.e., browser), it is not expected that these types of grant flow will be used by constrained clients. This endpoint is therefore out of scope for this specification. Implementations should use the definition and - recommendations of [RFC6749] and [RFC6819]. + recommendations of section 3.1 of [RFC6749] and of section 4.2 of + [RFC6819]. If clients involved cannot support HTTP and TLS, profiles MAY define mappings for the authorization endpoint. 5.6. The Token Endpoint In standard OAuth 2.0, the AS provides the token endpoint for submitting access token requests. This framework extends the functionality of the token endpoint, giving the AS the possibility to help the client and RS to establish shared keys or to exchange their @@ -923,44 +932,45 @@ The figures of this section use CBOR diagnostic notation without the integer abbreviations for the parameters or their values for illustrative purposes. Note that implementations MUST use the integer abbreviations and the binary CBOR encoding, if the CBOR encoding is used. 5.6.1. Client-to-AS Request The client sends a POST request to the token endpoint at the AS. The profile MUST specify how the communication is protected. The content - of the request consists of the parameters specified in Section 4 of - the OAuth 2.0 specification [RFC6749] with the exception of the - "grant_type" parameter, which is OPTIONAL in the context of this - framework (as opposed to REQUIRED in RFC6749). If that parameter is - missing, the default value "client_credentials" is implied. + of the request consists of the parameters specified in the relevant + subsection of section 4 of the OAuth 2.0 specification [RFC6749], + depending on the grant type. The parameter "grant_type" is an + exception, as it is OPTIONAL in the context of this framework (as + opposed to REQUIRED in RFC6749). If that parameter is missing, the + default value "client_credentials" is implied. Furthermore the "audience" parameter from [I-D.ietf-oauth-token-exchange] can be used to request an access token bound to a specific audience. In addition to these parameters, a client MUST be able to use the parameters from [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 parameters. If CBOR is used then this parameter MUST be encoded as a CBOR map. - The "scope" parameter can be formatted as specified in [RFC6749] and - additionally as a byte string, in order to allow compact encoding of - complex scopes. + The "scope" parameter can be formatted as specified in section 3.3 of + [RFC6749] and additionally as a byte string, in order to allow + compact encoding of complex scopes. When HTTP is used as a transport then the client makes a request to the token endpoint by sending the parameters using the "application/ x-www-form-urlencoded" format with a character encoding of UTF-8 in - the HTTP request entity-body, as defined in RFC 6749. + the HTTP request entity-body, as defined in section 3.2 of [RFC6749]. The following examples illustrate different types of requests for proof-of-possession tokens. Figure 5 shows a request for a token with a symmetric proof-of- possession key. The content is displayed in CBOR diagnostic notation, without abbreviations for better readability. Header: POST (Code=0.02) Uri-Host: "as.example.com" @@ -1201,23 +1211,23 @@ | password | 0 | RFC6749 | | authorization_code | 1 | RFC6749 | | client_credentials | 2 | RFC6749 | | refresh_token | 3 | RFC6749 | \--------------------+------------+------------------------/ Figure 11: CBOR abbreviations for common grant types 5.6.4.2. Token Type - The "token_type" parameter, defined in [RFC6749], allows the AS to - indicate to the client which type of access token it is receiving - (e.g., a bearer token). + 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 + is receiving (e.g., a bearer token). This document registers the new value "pop" for the OAuth Access Token Types registry, specifying a proof-of-possession token. How the proof-of-possession by the client to the RS is performed MUST be specified by the profiles. The values in the "token_type" parameter MUST be CBOR text strings, if a CBOR encoding is used. In this framework the "pop" value for the "token_type" parameter is @@ -1279,24 +1289,23 @@ | profile | 39 | unsigned integer | \-------------------+----------+---------------------/ Figure 12: CBOR mappings used in token requests 5.7. The Introspection Endpoint 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 for metadata about a given token, e.g., validity or scope. Analogous - to the protocol defined in RFC 7662 [RFC7662] for HTTP and JSON, this - section defines adaptations to more constrained environments using - CBOR and leaving the choice of the application protocol to the - profile. + to the protocol defined in [RFC7662] for HTTP and JSON, this section + defines adaptations to more constrained environments using CBOR and + leaving the choice of the application protocol to the profile. Communication between the requesting entity and the introspection endpoint at the AS MUST be integrity protected and encrypted. The communication security protocol MUST also provide a binding between requests and responses. Furthermore the two interacting parties MUST perform mutual authentication. Finally the AS SHOULD verify that the requesting entity has the right to access introspection information about the provided token. Profiles of this framework that support introspection MUST specify how authentication and communication security between the requesting entity and the AS is implemented. @@ -1320,21 +1329,21 @@ map with a "token" entry containing either the access token or a reference to the token (e.g., the cti). Further optional parameters representing additional context that is known by the requesting entity to aid the AS in its response MAY be included. For CoAP-based interaction, all messages MUST use the content type "application/ace+cbor", while for HTTP-based interactions the equivalent media type "application/ace+cbor" MUST be used. The same parameters are required and optional as in Section 2.1 of - RFC 7662 [RFC7662]. + [RFC7662]. For example, Figure 13 shows a RS calling the token introspection endpoint at the AS to query about an OAuth 2.0 proof-of-possession token. Note that object security based on OSCORE [I-D.ietf-core-object-security] is assumed in this example, therefore the Content-Format is "application/oscore". Figure 14 shows the decoded payload. Header: POST (Code=0.02) Uri-Host: "as.example.com" @@ -1356,21 +1365,21 @@ 5.7.2. Introspection Response If the introspection request is authorized and successfully processed, the AS sends a response with the response code equivalent to the CoAP code 2.01 (Created). If the introspection request was invalid, not authorized or couldn't be processed the AS returns an error response as described in Section 5.7.3. In a successful response, the AS encodes the response parameters in a map including with the same required and optional parameters as in - Section 2.2 of RFC 7662 [RFC7662] with the following addition: + Section 2.2 of [RFC7662] with the following addition: 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 formatting of this parameter. 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 introspection endpoint. For example, Figure 15 shows an AS response to the introspection @@ -1401,21 +1410,21 @@ equivalent to the ones for HTTP-based interactions as defined in Section 2.3 of [RFC7662], with the following differences: 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 used. o If the credentials used by the requesting entity (usually the RS) are invalid the AS MUST respond with the response code equivalent to the CoAP code 4.01 (Unauthorized) and use the required and - optional parameters from Section 5.2 in RFC 6749 [RFC6749]. + optional parameters from Section 5.2 in [RFC6749]. o If the requesting entity does not have the right to perform this introspection request, the AS MUST respond with a response code equivalent to the CoAP code 4.03 (Forbidden). In this case no payload is returned. o The parameters "error", "error_description" and "error_uri" MUST be abbreviated using the codes specified in Figure 12. o The error codes MUST be abbreviated using the codes specified in @@ -1580,49 +1589,61 @@ and, in case of an interaction via the authz-info endpoint, return an error message with a response code equivalent to the CoAP code 4.00 (Bad Request). Next, the RS MUST verify claims, if present, contained in the access token. Errors are returned when claim checks fail, in the order of priority of this list: iss The issuer claim must identify an AS that has the authority to issue access tokens for the receiving RS. If that is not the case - the RS MUST respond with a response code equivalent to the CoAP - code 4.01 (Unauthorized). + the RS MUST discard the token. If this was an interaction with + authz-info, the RS MUST also respond with a response code + equivalent to the CoAP code 4.01 (Unauthorized). exp The expiration date must be in the future. If that is not the - case the RS MUST respond with a response code equivalent to the - CoAP code 4.01 (Unauthorized). Note that the RS has to terminate - access rights to the protected resources at the time when the - tokens expire. + case the RS MUST discard the token. If this was an interaction + with authz-info the RS MUST also respond with a response code + equivalent to the CoAP code 4.01 (Unauthorized). Note that the RS + has to terminate access rights to the protected resources at the + time when the tokens expire. aud The audience claim must refer to an audience that the RS - identifies with. If that is not the case the RS MUST respond with - a response code equivalent to the CoAP code 4.03 (Forbidden). + identifies with. If that is not the case the RS MUST discard the + token. If this was an interaction with authz-info, the RS MUST + also respond with a response code equivalent to the CoAP code 4.03 + (Forbidden). scope The RS must recognize value of the scope claim. If that is - not the case the RS MUST respond with a response code equivalent - to the CoAP code 4.00 (Bad Request). The RS MAY provide - additional information in the error response, to clarify what went - wrong. + not the case the RS MUST discard the token. If this was an + interaction with authz-info, the RS MUST also respond with a + response code equivalent to the CoAP code 4.00 (Bad Request). The + RS MAY provide additional information in the error response, to + clarify what went wrong. If the access token contains any other claims that the RS cannot - process the RS MUST respond with a response code equivalent to the - CoAP code 4.00 (Bad Request). The RS MAY provide additional detail - in the error response to clarify which claim couldn't be processed. + process the RS MUST discard the token. If this was an interaction + with authz-info, the RS MUST also respond with a response code + equivalent to the CoAP code 4.00 (Bad Request). The RS MAY provide + additional detail in the error response to clarify which claim + couldn't be processed. Note that the Subject (sub) claim cannot always be verified when the token is submitted to the RS since the client may not have authenticated yet. Also note that a counter for the expires_in (exi) claim MUST be initialized when the RS first verifies this token. + Also note that profiles of this framework may define access token + transport mechanisms that do not allow for error responses. + Therefore the error messages specified here only apply if the token + was POSTed to the authz-info endpoint. + When sending error responses, the RS MAY use the error codes from Section 3.1 of [RFC6750], to provide additional details to the client. 5.8.1.2. Protecting the Authorization Information Endpoint As this framework can be used in RESTful environments, it is important to make sure that attackers cannot perform unauthorized requests on the auth-info endpoints, other than submitting access tokens. @@ -1703,21 +1724,21 @@ in some regular intervals, so that the can AS provide the RS with a list of expired tokens. The drawback of this mitigation is that the RS might as well use the communication with the AS to synchronize its internal clock. If a token that authorizes a long running request such as a CoAP Observe [RFC7641] expires, the RS MUST send an error response with the response code equivalent to the CoAP code 4.01 (Unauthorized) to the client and then terminate processing the long running request. -5.8.4. Key Expriation +5.8.4. Key Expiration 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 by the RS to authenticate towards the client. Since there is no metadata associated to those keys, the client has no way of knowing if these keys are still valid. This may lead to situations where the client sends requests containing sensitive 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 properly protected and could possibly have been forged by an attacker. @@ -2009,24 +2030,24 @@ 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.1. ACE Authorization Server Request Creation Hints This specification establishes the IANA "ACE Authorization Server Request Creation Hints" registry. The registry has been created to - use the "Expert Review Required" registration procedure [RFC8126]. - It should be noted that, in addition to the expert review, some - portions of the registry require a specification, potentially a - Standards Track RFC, be supplied as well. + use the "Expert Review" registration procedure [RFC8126]. It should + be noted that, in addition to the expert review, some portions of the + registry require a specification, potentially a Standards Track RFC, + be supplied as well. The columns of the registry are: Name The name of the parameter CBOR Key CBOR map key for the parameter. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are @@ -2041,153 +2062,137 @@ This registry will be initially populated by the values in Figure 2. The Reference column for all of these entries will be this document. 8.2. OAuth Extensions Error Registration This specification registers the following error values in the OAuth Extensions Error registry defined in [RFC6749]. o Error name: "unsupported_pop_key" - o Error usage location: AS token endpoint error response + o Error usage location: token error response o Related protocol extension: The ACE framework [this document] o Change Controller: IESG o Specification document(s): Section 5.6.3 of [this document] o Error name: "incompatible_profiles" - o Error usage location: AS token endpoint error response + o Error usage location: token error response o Related protocol extension: The ACE framework [this document] o Change Controller: IESG o Specification document(s): Section 5.6.3 of [this document] 8.3. OAuth Error Code CBOR Mappings Registry This specification establishes the IANA "OAuth Error Code CBOR Mappings" registry. The registry has been created to use the "Expert - Review Required" registration procedure [RFC8126]. It should be - noted that, in addition to the expert review, some portions of the - registry require a specification, potentially a Standards Track RFC, - be supplied as well. + Review" registration procedure [RFC8126], except for the value range + designated for private use. The columns of the registry are: Name The OAuth Error Code name, refers to the name in Section 5.2. of [RFC6749], e.g., "invalid_request". - CBOR Value CBOR abbreviation for this error code. Different ranges - of values use different registration policies [RFC8126]. Integer - values from -256 to 255 are designated as Standards Action. - Integer values from -65536 to -257 and from 256 to 65535 are - designated as Specification Required. Integer values greater than - 65535 are designated as Expert Review. Integer values less than - -65536 are marked as Private Use. + CBOR Value CBOR abbreviation for this error code. Integer values + less than -65536 are marked as "Private Use", all other values use + the registration policy "Expert Review" [RFC8126]. Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 10. The Reference column for all of these entries will be this document. 8.4. OAuth Grant Type CBOR Mappings This specification establishes the IANA "OAuth Grant Type CBOR Mappings" registry. The registry has been created to use the "Expert - Review Required" registration procedure [RFC8126]. It should be - noted that, in addition to the expert review, some portions of the - registry require a specification, potentially a Standards Track RFC, - be supplied as well. + Review" registration procedure [RFC8126], except for the value range + designated for private use. The columns of this registry are: Name The name of the grant type as specified in Section 1.3 of [RFC6749]. - CBOR Value CBOR abbreviation for this grant type. Different ranges - of values use different registration policies [RFC8126]. Integer - values from -256 to 255 are designated as Standards Action. - Integer values from -65536 to -257 and from 256 to 65535 are - designated as Specification Required. Integer values greater than - 65535 are designated as Expert Review. Integer values less than - -65536 are marked as Private Use. + CBOR Value CBOR abbreviation for this grant type. Integer values + less than -65536 are marked as "Private Use", all other values use + the registration policy "Expert Review" [RFC8126]. Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. Original Specification This contains a pointer to the public specification of the grant type, if one exists. This registry will be initially populated by the values in Figure 11. The Reference column for all of these entries will be this document. 8.5. OAuth Access Token Types This section registers the following new token type in the "OAuth Access Token Types" registry [IANA.OAuthAccessTokenTypes]. - o Name: "PoP" + o Type name: "PoP" + o Additional Token Endpoint Response Parameters: "cnf", "rs_cnf" see + section 3.3 of [I-D.ietf-ace-oauth-params]. + o HTTP Authentication Scheme(s): N/A o Change Controller: IETF - o Reference: [this document] + o Specification document(s): [this document] 8.6. OAuth Access Token Type CBOR Mappings This specification established the IANA "OAuth Access Token Type CBOR Mappings" registry. The registry has been created to use the "Expert - Review Required" registration procedure [RFC8126]. It should be - noted that, in addition to the expert review, some portions of the - registry require a specification, potentially a Standards Track RFC, - be supplied as well. + Review" registration procedure [RFC8126], except for the value range + designated for private use. The columns of this registry are: Name The name of token type as registered in the OAuth Access Token Types registry, e.g., "Bearer". - CBOR Value CBOR abbreviation for this token type. Different ranges - of values use different registration policies [RFC8126]. Integer - values from -256 to 255 are designated as Standards Action. + CBOR Value CBOR abbreviation for this token type. Integer values + less than -65536 are marked as "Private Use", all other values use + the registration policy "Expert Review" [RFC8126]. - Integer values from -65536 to -257 and from 256 to 65535 are - designated as Specification Required. Integer values greater than - 65535 are designated as Expert Review. Integer values less than - -65536 are marked as Private Use. Reference This contains a pointer to the public specification of the OAuth token type abbreviation, if one exists. Original Specification This contains a pointer to the public specification of the grant type, if one exists. 8.6.1. Initial Registry Contents o Name: "Bearer" o Value: 1 o Reference: [this document] o Original Specification: [RFC6749] o Name: "pop" o Value: 2 o Reference: [this document] o Original Specification: [this document] 8.7. ACE Profile Registry This specification establishes the IANA "ACE Profile" registry. The - registry has been created to use the "Expert Review Required" - registration procedure [RFC8126]. It should be noted that, in - addition to the expert review, some portions of the registry require - a specification, potentially a Standards Track RFC, be supplied as - well. + registry has been created to use the "Expert Review" registration + procedure [RFC8126]. It should be noted that, in addition to the + expert review, some portions of the registry require a specification, + potentially a Standards Track RFC, be supplied as well. The columns of this registry are: Name The name of the profile, to be used as value of the profile attribute. Description Text giving an overview of the profile and the context it is developed for. CBOR Value CBOR abbreviation for this profile name. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater - than 65535 are designated as Expert Review. Integer values less + than 65535 are designated as "Expert Review". Integer values less than -65536 are marked as Private Use. Reference This contains a pointer to the public specification of the profile abbreviation, if one exists. This registry will be initially empty and will be populated by the registrations from the ACE framework profiles. 8.8. OAuth Parameter Registration This specification registers the following parameter in the "OAuth @@ -2195,36 +2200,30 @@ o Name: "profile" o Parameter Usage Location: token response o Change Controller: IESG o Reference: Section 5.6.4.3 of [this document] 8.9. OAuth Parameters CBOR Mappings Registry This specification establishes the IANA "OAuth Parameters CBOR Mappings" registry. The registry has been created to use the "Expert - Review Required" registration procedure [RFC8126]. It should be - noted that, in addition to the expert review, some portions of the - registry require a specification, potentially a Standards Track RFC, - be supplied as well. + Review" registration procedure [RFC8126], except for the value range + designated for private use. The columns of this registry are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., "client_id". - CBOR Key CBOR map key for this parameter. Different ranges of - values use different registration policies [RFC8126]. Integer - values from -256 to 255 are designated as Standards Action. - Integer values from -65536 to -257 and from 256 to 65535 are - designated as Specification Required. Integer values greater than - 65535 are designated as Expert Review. Integer values less than - -65536 are marked as Private Use. + CBOR Key CBOR map key for this parameter. Integer values less than + -65536 are marked as "Private Use", all other values use the + registration policy "Expert Review" [RFC8126]. Value Type The allowable CBOR data types for values of this parameter. Reference This contains a pointer to the public specification of the parameter abbreviation, if one exists. This registry will be initially populated by the values in Figure 12. The Reference column for all of these entries will be this document. Note that the mappings of parameters corresponding to claim names intentionally coincide with the CWT claim name mappings from @@ -2239,36 +2238,30 @@ o Name: "profile" o Description: The communication and communication security profile used between client and RS, as defined in ACE profiles. o Change Controller: IESG o Reference: Section 5.7.2 of [this document] 8.11. OAuth Token Introspection Response CBOR Mappings Registry This specification establishes the IANA "OAuth Token Introspection Response CBOR Mappings" registry. The registry has been created to - use the "Expert Review Required" registration procedure [RFC8126]. - It should be noted that, in addition to the expert review, some - portions of the registry require a specification, potentially a - Standards Track RFC, be supplied as well. + use the "Expert Review" registration procedure [RFC8126], except for + the value range designated for private use. The columns of this registry are: Name The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., "client_id". - CBOR Key CBOR map key for this parameter. Different ranges of - values use different registration policies [RFC8126]. Integer - values from -256 to 255 are designated as Standards Action. - Integer values from -65536 to -257 and from 256 to 65535 are - designated as Specification Required. Integer values greater than - 65535 are designated as Expert Review. Integer values less than - -65536 are marked as Private Use. + CBOR Key CBOR map key for this parameter. Integer values less than + -65536 are marked as "Private Use", all other values use the + registration policy "Expert Review" [RFC8126]. Value Type The allowable CBOR data types for values of this parameter. Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. This registry will be initially populated by the values in Figure 16. The Reference column for all of these entries will be this document. Note that the mappings of parameters corresponding to claim names intentionally coincide with the CWT claim name mappings from @@ -2419,26 +2411,28 @@ needs to have sufficient information to identify what the point is being used for. o Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for standards track documents does not mean that a standards track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. - o Since a high degree of overlap is expected between these registries and the contents of the OAuth parameters [IANA.OAuthParameters] registries, experts should require new - registrations to maintain a reasonable level of alignment with - parameters from OAuth that have comparable functionality. + registrations to maintain alignment with parameters from OAuth + that have comparable functionality. Deviation from this alignment + should only be allowed if there are functional differences, that + are motivated by the use case and that cannot be easily or + efficiently addressed by comparable OAuth parameters. 9. Acknowledgments This document is a product of the ACE working group of the IETF. Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and UMA in IoT scenarios, Robert Taylor for his discussion input, and Malisa Vucinic for his input on the predecessors of this proposal. Thanks to the authors of draft-ietf-oauth-pop-key-distribution, from @@ -2457,21 +2451,21 @@ the CelticPlus project CyberWI, with funding from Vinnova. 10. References 10.1. Normative References [I-D.ietf-ace-cwt-proof-of-possession] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- - possession-05 (work in progress), November 2018. + possession-06 (work in progress), February 2019. [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", draft-ietf-ace-oauth- params-04 (work in progress), February 2019. [I-D.ietf-oauth-token-exchange] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", draft-ietf-oauth- token-exchange-16 (work in progress), October 2018. @@ -2660,21 +2654,21 @@ [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . - [RFC8516] Keraenen, A., ""Too Many Requests" Response Code for the + [RFC8516] Keranen, A., ""Too Many Requests" Response Code for the Constrained Application Protocol", RFC 8516, DOI 10.17487/RFC8516, January 2019, . Appendix A. Design Justification This section provides further insight into the design decisions of the solution documented in this document. Section 3 lists several building blocks and briefly summarizes their importance. The justification for offering some of those building blocks, as opposed @@ -3363,56 +3360,64 @@ F: |<--------+ Header: 2.04 Changed | 2.04 | Payload: | | Figure 26: Resource request and response protected by OSCORE Appendix F. Document Updates RFC EDITOR: PLEASE REMOVE THIS SECTION. -F.1. Verion -20 to 21 +F.1. Version -21 to 22 + + o Provided section numbers in references to OAuth RFC. + o Updated IANA mapping registries to only use "Private Use" and + "Expert Review". + o Made error messages optional for RS at token submission since it + may not be able to send them depending on the profile. + o Corrected errors in examples. + +F.2. Version -20 to 21 o Added text about expiration of RS keys. -F.2. Verion -19 to 20 +F.3. Version -19 to 20 o Replaced "req_aud" with "audience" from the OAuth token exchange draft. o Updated examples to remove unnecessary elements. -F.3. Version -18 to -19 +F.4. Version -18 to -19 o Added definition of "Authorization Information". o Explicitly state that ACE allows encoding refresh tokens in binary format in addition to strings. o Renamed "AS Information" to "AS Request Creation Hints" and added the possibility to specify req_aud and scope as hints. o Added the "kid" parameter to AS Request Creation Hints. o Added security considerations about the integrity protection of tokens with multi-RS audiences. - o Renamed IANA registries mapping OAuth parameters to reflect the mapped registry. o Added JWT claim names to CWT claim registrations. o Added expert review instructions. o Updated references to TLS from 1.2 to 1.3. -F.4. Version -17 to -18 +F.5. Version -17 to -18 o Added OSCORE options in examples involving OSCORE. o Removed requirement for the client to send application/cwt, since the client has no way to know. o Clarified verification of tokens by the RS. o Added exi claim CWT registration. -F.5. Version -16 to -17 +F.6. Version -16 to -17 o Added references to (D)TLS 1.3. o Added requirement that responses are bound to requests. o Specify that grant_type is OPTIONAL in C2AS requests (as opposed to REQUIRED in OAuth). o Replaced examples with hypothetical COSE profile with OSCORE. o Added requirement for content type application/ace+cbor in error responses for token and introspection requests and responses. o Reworked abbreviation space for claims, request and response parameters. @@ -3420,91 +3425,90 @@ info resource. o Added section that specifies how the RS verifies an access token. o Added section on the protection of the authz-info endpoint. o Removed the expiration mechanism based on sequence numbers. o Added reference to RFC7662 security considerations. o Added considerations on minimal security requirements for communication. o Added security considerations on unprotected information sent to authz-info and in the error responses. -F.6. Version -15 to -16 +F.7. Version -15 to -16 o Added text the RS using RFC6750 error codes. o Defined an error code for incompatible token request parameters. o Removed references to the actors draft. o Fixed errors in examples. -F.7. Version -14 to -15 +F.8. Version -14 to -15 o Added text about refresh tokens. o Added text about protection of credentials. o Rephrased introspection so that other entities than RS can do it. - o Editorial improvements. -F.8. Version -13 to -14 +F.9. Version -13 to -14 o Split out the 'aud', 'cnf' and 'rs_cnf' parameters to [I-D.ietf-ace-oauth-params] o Introduced the "application/ace+cbor" Content-Type. o Added claim registrations from 'profile' and 'rs_cnf'. o Added note on schema part of AS Information Section 5.1.2 o Realigned the parameter abbreviations to push rarely used ones to the 2-byte encoding size of CBOR integers. -F.9. Version -12 to -13 +F.10. Version -12 to -13 o Changed "Resource Information" to "Access Information" to avoid confusion. o Clarified section about AS discovery. o Editorial changes -F.10. Version -11 to -12 +F.11. Version -11 to -12 o Moved the Request error handling to a section of its own. o Require the use of the abbreviation for profile identifiers. o Added rs_cnf parameter in the introspection response, to inform RS' with several RPKs on which key to use. o Allowed use of rs_cnf as claim in the access token in order to inform an RS with several RPKs on which key to use. o Clarified that profiles must specify if/how error responses are protected. o Fixed label number range to align with COSE/CWT. o Clarified the requirements language in order to allow profiles to specify other payload formats than CBOR if they do not use CoAP. -F.11. Version -10 to -11 +F.12. Version -10 to -11 o Fixed some CBOR data type errors. o Updated boilerplate text -F.12. Version -09 to -10 +F.13. Version -09 to -10 o Removed CBOR major type numbers. o Removed the client token design. o Rephrased to clarify that other protocols than CoAP can be used. o Clarifications regarding the use of HTTP -F.13. Version -08 to -09 +F.14. Version -08 to -09 o Allowed scope to be byte strings. o Defined default names for endpoints. o Refactored the IANA section for briefness and consistency. o Refactored tables that define IANA registry contents for consistency. o Created IANA registry for CBOR mappings of error codes, grant types and Authorization Server Information. o Added references to other document sections defining IANA entries in the IANA section. -F.14. Version -07 to -08 +F.15. Version -07 to -08 o Moved AS discovery from the DTLS profile to the framework, see Section 5.1. o Made the use of CBOR mandatory. If you use JSON you can use vanilla OAuth. o Made it mandatory for profiles to specify C-AS security and RS-AS security (the latter only if introspection is supported). o Made the use of CBOR abbreviations mandatory. o Added text to clarify the use of token references as an alternative to CWTs. @@ -3514,67 +3518,69 @@ discovery information, combining profiles and leakage through error responses. o Added privacy considerations about leakage through unprotected AS discovery. o Added text that clarifies that introspection is optional. o Made profile parameter optional since it can be implicit. o Clarified that CoAP is not mandatory and other protocols can be used. o Clarified the design justification for specific features of the framework in appendix A. + o Clarified appendix E.2. o Removed specification of the "cnf" claim for CBOR/COSE, and replaced with references to [I-D.ietf-ace-cwt-proof-of-possession] -F.15. Version -06 to -07 +F.16. Version -06 to -07 o Various clarifications added. o Fixed erroneous author email. -F.16. Version -05 to -06 +F.17. Version -05 to -06 o Moved sections that define the ACE framework into a subsection of the framework Section 5. o Split section on client credentials and grant into two separate sections, Section 5.2, and Section 5.3. o Added Section 5.4 on AS authentication. o Added Section 5.5 on the Authorization endpoint. -F.17. Version -04 to -05 +F.18. Version -04 to -05 o Added RFC 2119 language to the specification of the required behavior of profile specifications. o Added Section 5.3 on the relation to the OAuth2 grant types. o Added CBOR abbreviations for error and the error codes defined in OAuth2. o Added clarification about token expiration and long-running requests in Section 5.8.3 o Added security considerations about tokens with symmetric pop keys valid for more than one RS. o Added privacy considerations section. o Added IANA registry mapping the confirmation types from RFC 7800 to equivalent COSE types. o Added appendix D, describing assumptions about what the AS knows about the client and the RS. -F.18. Version -03 to -04 +F.19. Version -03 to -04 o Added a description of the terms "framework" and "profiles" as used in this document. o Clarified protection of access tokens in section 3.1. o Clarified uses of the "cnf" parameter in section 6.4.5. o Clarified intended use of Client Token in section 7.4. -F.19. Version -02 to -03 +F.20. Version -02 to -03 o Removed references to draft-ietf-oauth-pop-key-distribution since the status of this draft is unclear. + o Copied and adapted security considerations from draft-ietf-oauth- pop-key-distribution. o Renamed "client information" to "RS information" since it is information about the RS. o Clarified the requirements on profiles of this framework. o Clarified the token endpoint protocol and removed negotiation of "profile" and "alg" (section 6). o Renumbered the abbreviations for claims and parameters to get a consistent numbering across different endpoints. o Clarified the introspection endpoint. @@ -3571,42 +3577,41 @@ o Copied and adapted security considerations from draft-ietf-oauth- pop-key-distribution. o Renamed "client information" to "RS information" since it is information about the RS. o Clarified the requirements on profiles of this framework. o Clarified the token endpoint protocol and removed negotiation of "profile" and "alg" (section 6). o Renumbered the abbreviations for claims and parameters to get a consistent numbering across different endpoints. o Clarified the introspection endpoint. - o Renamed token, introspection and authz-info to "endpoint" instead of "resource" to mirror the OAuth 2.0 terminology. o Updated the examples in the appendices. -F.20. Version -01 to -02 +F.21. Version -01 to -02 o Restructured to remove communication security parts. These shall now be defined in profiles. o Restructured section 5 to create new sections on the OAuth endpoints token, introspection and authz-info. o Pulled in material from draft-ietf-oauth-pop-key-distribution in order to define proof-of-possession key distribution. o Introduced the "cnf" parameter as defined in RFC7800 to reference or transport keys used for proof of possession. o Introduced the "client-token" to transport client information from the AS to the client via the RS in conjunction with introspection. o Expanded the IANA section to define parameters for token request, introspection and CWT claims. o Moved deployment scenarios to the appendix as examples. -F.21. Version -00 to -01 +F.22. Version -00 to -01 o Changed 5.1. from "Communication Security Protocol" to "Client Information". o Major rewrite of 5.1 to clarify the information exchanged between C and AS in the PoP access token request profile for IoT. * Allow the client to indicate preferences for the communication security protocol. * Defined the term "Client Information" for the additional information returned to the client in addition to the access