--- 1/draft-ietf-ace-oauth-authz-03.txt 2016-10-31 01:16:10.142857718 -0700 +++ 2/draft-ietf-ace-oauth-authz-04.txt 2016-10-31 01:16:10.246860304 -0700 @@ -1,25 +1,25 @@ ACE Working Group L. Seitz Internet-Draft SICS Intended status: Standards Track G. Selander -Expires: April 15, 2017 Ericsson +Expires: May 4, 2017 Ericsson E. Wahlstroem S. Erdtman Spotify AB H. Tschofenig ARM Ltd. - October 12, 2016 + October 31, 2016 Authentication and Authorization for Constrained Environments (ACE) - draft-ietf-ace-oauth-authz-03 + draft-ietf-ace-oauth-authz-04 Abstract This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments. 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 defined. @@ -32,21 +32,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 http://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 April 15, 2017. + This Internet-Draft will expire on May 4, 2017. Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,72 +59,72 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9 5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. The 'Token' Endpoint . . . . . . . . . . . . . . . . . . . . 14 - 6.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 14 + 6.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 15 6.2. AS-to-Client Response . . . . . . . . . . . . . . . . . . 17 - 6.3. Error Response . . . . . . . . . . . . . . . . . . . . . 18 - 6.4. New Request and Response Parameters . . . . . . . . . . . 18 - 6.4.1. Audience . . . . . . . . . . . . . . . . . . . . . . 18 + 6.3. Error Response . . . . . . . . . . . . . . . . . . . . . 19 + 6.4. New Request and Response Parameters . . . . . . . . . . . 19 + 6.4.1. Audience . . . . . . . . . . . . . . . . . . . . . . 19 6.4.2. Grant Type . . . . . . . . . . . . . . . . . . . . . 19 6.4.3. Token Type . . . . . . . . . . . . . . . . . . . . . 19 - 6.4.4. Profile . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.4.4. Profile . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.5. Confirmation . . . . . . . . . . . . . . . . . . . . 20 - 6.5. Mapping parameters to CBOR . . . . . . . . . . . . . . . 21 - 7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . . . 22 - 7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . . . 23 - 7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . . . 23 - 7.3. Error Response . . . . . . . . . . . . . . . . . . . . . 24 - 7.4. Client Token . . . . . . . . . . . . . . . . . . . . . . 25 - 7.5. Mapping Introspection parameters to CBOR . . . . . . . . 26 - 8. The Access Token . . . . . . . . . . . . . . . . . . . . . . 27 - 8.1. The 'Authorization Information' Endpoint . . . . . . . . 28 - 8.2. Token Expiration . . . . . . . . . . . . . . . . . . . . 28 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 10.1. OAuth Introspection Response Parameter Registration . . 30 - 10.2. OAuth Parameter Registration . . . . . . . . . . . . . . 31 - 10.3. OAuth Access Token Types . . . . . . . . . . . . . . . . 31 - 10.4. Token Type Mappings . . . . . . . . . . . . . . . . . . 32 - 10.4.1. Registration Template . . . . . . . . . . . . . . . 32 - 10.4.2. Initial Registry Contents . . . . . . . . . . . . . 32 - 10.5. CBOR Web Token Claims . . . . . . . . . . . . . . . . . 32 - 10.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 33 - 10.6.1. Registration Template . . . . . . . . . . . . . . . 33 - 10.7. OAuth Parameter Mappings Registry . . . . . . . . . . . 33 - 10.7.1. Registration Template . . . . . . . . . . . . . . . 33 - 10.7.2. Initial Registry Contents . . . . . . . . . . . . . 34 - 10.8. Introspection Endpoint CBOR Mappings Registry . . . . . 36 - 10.8.1. Registration Template . . . . . . . . . . . . . . . 36 - 10.8.2. Initial Registry Contents . . . . . . . . . . . . . 36 - 10.9. CoAP Option Number Registration . . . . . . . . . . . . 38 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 39 - 12.2. Informative References . . . . . . . . . . . . . . . . . 40 - Appendix A. Design Justification . . . . . . . . . . . . . . . . 42 - Appendix B. Roles and Responsibilites . . . . . . . . . . . . . 44 - Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 46 - Appendix D. Deployment Examples . . . . . . . . . . . . . . . . 46 - D.1. Local Token Validation . . . . . . . . . . . . . . . . . 47 - D.2. Introspection Aided Token Validation . . . . . . . . . . 50 - Appendix E. Document Updates . . . . . . . . . . . . . . . . . . 54 - E.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 54 - E.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 54 - E.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 55 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 + 6.5. Mapping parameters to CBOR . . . . . . . . . . . . . . . 22 + 7. The 'Introspect' Endpoint . . . . . . . . . . . . . . . . . . 23 + 7.1. RS-to-AS Request . . . . . . . . . . . . . . . . . . . . 24 + 7.2. AS-to-RS Response . . . . . . . . . . . . . . . . . . . . 24 + 7.3. Error Response . . . . . . . . . . . . . . . . . . . . . 25 + 7.4. Client Token . . . . . . . . . . . . . . . . . . . . . . 26 + 7.5. Mapping Introspection parameters to CBOR . . . . . . . . 28 + 8. The Access Token . . . . . . . . . . . . . . . . . . . . . . 28 + 8.1. The 'Authorization Information' Endpoint . . . . . . . . 29 + 8.2. Token Expiration . . . . . . . . . . . . . . . . . . . . 29 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 10.1. OAuth Introspection Response Parameter Registration . . 31 + 10.2. OAuth Parameter Registration . . . . . . . . . . . . . . 32 + 10.3. OAuth Access Token Types . . . . . . . . . . . . . . . . 32 + 10.4. Token Type Mappings . . . . . . . . . . . . . . . . . . 33 + 10.4.1. Registration Template . . . . . . . . . . . . . . . 33 + 10.4.2. Initial Registry Contents . . . . . . . . . . . . . 33 + 10.5. CBOR Web Token Claims . . . . . . . . . . . . . . . . . 33 + 10.6. ACE Profile Registry . . . . . . . . . . . . . . . . . . 34 + 10.6.1. Registration Template . . . . . . . . . . . . . . . 34 + 10.7. OAuth Parameter Mappings Registry . . . . . . . . . . . 34 + 10.7.1. Registration Template . . . . . . . . . . . . . . . 34 + 10.7.2. Initial Registry Contents . . . . . . . . . . . . . 35 + 10.8. Introspection Endpoint CBOR Mappings Registry . . . . . 37 + 10.8.1. Registration Template . . . . . . . . . . . . . . . 37 + 10.8.2. Initial Registry Contents . . . . . . . . . . . . . 37 + 10.9. CoAP Option Number Registration . . . . . . . . . . . . 39 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 40 + 12.2. Informative References . . . . . . . . . . . . . . . . . 41 + Appendix A. Design Justification . . . . . . . . . . . . . . . . 43 + Appendix B. Roles and Responsibilites . . . . . . . . . . . . . 45 + Appendix C. Requirements on Profiles . . . . . . . . . . . . . . 47 + Appendix D. Deployment Examples . . . . . . . . . . . . . . . . 47 + D.1. Local Token Validation . . . . . . . . . . . . . . . . . 48 + D.2. Introspection Aided Token Validation . . . . . . . . . . 51 + Appendix E. Document Updates . . . . . . . . . . . . . . . . . . 55 + E.1. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 55 + E.2. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 55 + E.3. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 56 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 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 is a complex task. @@ -182,20 +182,26 @@ /introspect at the AS and /authz-info at the RS. The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol" is not used in this memo. Since this specification focuses on the problem of access control to resources, we simplify the actors by assuming that the client authorization server (CAS) functionality is not stand-alone but subsumed by either the authorization server or the client (see section 2.2 in [I-D.ietf-ace-actors]). + We call the specifications of this memo the "framework" or "ACE + framework". When referring to "profiles of this framework" we mean + additional memo's that define the use of this specification with + concrete transport, and communication security protocols (e.g. CoAP + over DTLS). + 3. Overview This specification defines the ACE framework for authorization in the Internet of Things environment. It consists of a set of building blocks. The basic block is the OAuth 2.0 [RFC6749] framework, which enjoys widespread deployment. Many IoT devices can support OAuth 2.0 without any additional extensions, but for certain constrained settings additional profiling is needed. @@ -259,22 +265,22 @@ The token and introspect Endpoints: The AS hosts the /token endpoint that allows a client to request access tokens. The client makes a POST request to the /token endpoint on the AS and receives the access token in the response (if the request was successful). The token introspection endpoint, /introspect, is used by the RS when requesting additional information regarding a received access token. The RS makes a POST request to /introspect on the AS and - receives information about the access token contain in the - response. (See "Introspection" below.) + receives information about the access token in the response. (See + "Introspection" below.) Access Tokens: Access tokens are credentials needed to access protected resources. An access token is a data structure representing authorization permissions issued by the AS to the client. Access tokens are generated by the authorization server and consumed by the resource server. The access token content is opaque to the client. @@ -312,24 +318,26 @@ Asymmetric PoP key: An asymmetric key pair is generated on the client and the public key is sent to the AS (if it does not already have knowledge of the client's public key). Information about the public key, which is the PoP key in this case, is either stored to be returned on introspection calls or included inside the access token and sent back to the requesting client. The RS can identify the client's public key from the information in the token, which allows the client to use the corresponding private key for the proof of possession. - The access token is protected against modifications using a MAC or - a digital signature, which is added by the AS. The choice of PoP - key does not necessarily imply a specific credential type for the - integrity protection of the token. + The access token is either a simple reference, or a structured + information object (e.g. CWT [I-D.ietf-ace-cbor-web-token]), + protected by a cryptographic wrapper (e.g. COSE + [I-D.ietf-cose-msg]). The choice of PoP key does not necessarily + imply a specific credential type for the integrity protection of + the token. Scopes and Permissions: In OAuth 2.0, the client specifies the type of permissions it is seeking to obtain (via the scope parameter) in the access token request. In turn, the AS may use the scope response parameter to inform the client of the scope of the access token issued. As the client could be a constrained device as well, this specification uses CBOR encoded messages for CoAP, defined in Section 5, to request scopes and to be informed what scopes the access token was @@ -381,21 +389,21 @@ CoAP supports application-layer fragmentation of the CoAP payloads through blockwise transfers [RFC7959]. However, block-wise transfer does not increase the size limits of CoAP options, therefore data encoded in options has to be kept small. Transport layer security for CoAP can be provided by DTLS 1.2 [RFC6347] or TLS 1.2 [RFC5246]. CoAP defines a number of proxy operations which requires transport layer security to be terminated at the proxy. One approach for protecting CoAP communication end-to- - end through proxies, and also to support security for CoAP over + end through proxies, and also to support security for CoAP over a different transport in a uniform way, is to provide security on application layer using an object-based security mechanism such as COSE [I-D.ietf-cose-msg]. One application of COSE is OSCOAP [I-D.selander-ace-object-security], which provides end-to-end confidentiality, integrity and replay protection, and a secure binding between CoAP request and response messages. In OSCOAP, the CoAP messages are wrapped in COSE objects and sent using CoAP. @@ -410,34 +418,35 @@ access token. In other deployments the RS may process the access token locally without the need to contact an AS. 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 two preferred grant types, namely the + IoT use cases but there are two preferred grant types, namely the Authorization Code Grant (described in Section 4.1 of RFC 7521) and the Client Credentials Grant (described in Section 4.4 of RFC 7521). + 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 [I-D.ietf-oauth-native-apps] 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 constraint. In such a case the resource + the OAuth client itself is constrained. In such a case the resource owner or another person on his or her behalf have arranged with the - authorization server out-of-band, which is often accomplished using - an commissioning tool. + authorization server out-of-band, 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. We @@ -507,21 +516,21 @@ specific credential). Access Token Response (B): If the AS successfully processes the request from the client, it returns an access token. It also returns various parameters, referred as "RS Information". In addition to the response parameters defined by OAuth 2.0 and the PoP token extension, further response parameters, such as information on which profile the client should use with the resource server(s). More - information about these parameters can be found in in Section 6.4. + information about these parameters can be found in Section 6.4. Resource Request (C): The client interacts with the RS to request access to the protected resource and provides the access token. The protocol to use between the client and the RS is not restricted to CoAP. HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also viable candidates. Depending on the device limitations and the selected protocol this @@ -557,21 +566,21 @@ Token Introspection Response (E): The AS validates the token and returns the most recent parameters, such as scope, audience, validity etc. associated with it back to the RS. The RS then uses the received parameters to process the request to either accept or to deny it. The AS can additionally return information that the RS needs to pass on to the client in the form of a client token. The latter is used to establish keys for mutual authentication between client and RS, when the client - has no direct connectivity to the AS. + has no direct connectivity to the AS, see Section 7.4 for details. Protected Resource (F): If the request from the client is authorized, the RS fulfills the request and returns a response with the appropriate response code. The RS uses the dynamically established keys to protect the response, according to used communication security protocol. 5. Framework @@ -729,21 +738,21 @@ } Figure 3: Example request for an access token bound to an asymmetric key. Figure 4 shows a request for a token where a previously communicated proof-of-possession key is only referenced. Note that we assume a DTLS-based communication security profile for this example, therefore the Content-Type is "application/cbor". Also note that the client performs a password based authentication in this example by - submitting its client_secret. + submitting its client_secret (see section 2.3.1. of [RFC6749]). Header: POST (Code=0.02) Uri-Host: "server.example.com" Uri-Path: "token" Content-Type: "application/cbor" Payload: { "grant_type" : "client_credentials", "client_id" : "myclient", "client_secret" : "mysecret234", @@ -766,21 +775,21 @@ authorized, the AS returns an error response as described in Section 6.3. 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 knowledge of the capabilities of the client, and the RS. This prior knowledge may, for example, be set by the use of a dynamic client registration protocol exchange [RFC7591]. The content of the successful reply MUST be encoded as CBOR map, - containing paramters as speficied in section 5.1 of [RFC6749]. In + containing parameters as speficied in section 5.1 of [RFC6749]. In addition to these parameters, the following parameters are also part of a successful response: profile REQUIRED. This indicates the profile that the client MUST use towards the RS. See Section 6.4.4 for the formatting of this parameter. cnf REQUIRED if the token type is 'pop'. OPTIONAL otherwise. If a @@ -810,20 +819,21 @@ DTLS-based communication security profile for this example, therefore the Content-Type is "application/cbor". Header: Created (Code=2.01) Content-Type: "application/cbor" Payload: { "access_token" : b64'SlAV32hkKG ... (remainder of CWT omitted for brevity; CWT contains COSE_Key in the 'cnf' claim)', + "profile" : "coap_dtls", "expires_in" : "3600", "cnf" : { "COSE_Key" : { "kty" : "Symmetric", "kid" : b64'39Gqlw', "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' } } } @@ -902,20 +911,36 @@ 6.4.5. Confirmation The "cnf" parameter identifies or provides the key used for proof-of- possession or for authenticating the RS depending on the proof-of- possession algorithm and the context cnf is used in. This framework extends the definition of 'cnf' from [RFC7800] by adding CBOR/COSE encodings and the use of 'cnf' for transporting keys in the RS Information. + The "cnf" parameter is used in the following contexts with the + following meaning: + + o In the access token, to indicate the proof-of-possession key bound + to this token. + o In the token request C -> AS, to indicate the client's raw public + key, or the key-identifier of a previously established key between + C and RS. + o In the token response AS -> C, to indicate either the symmetric + key generated by the AS for proof-of-possession or the raw public + key used by the RS to authenticate. + o In the introspection response AS -> RS, to indicate the proof-of- + possession key bound to the introspected token. + o In the client token AS -> RS -> C, to indicate the proof-of- + possession key bound to the access token. + A CBOR encoded payload MAY contain the 'cnf' parameter with the following contents: COSE_Key In this case the 'cnf' parameter contains the proof-of- possession key to be used by the client. An example is shown in Figure 7. "cnf" : { "COSE_Key" : { "kty" : "EC", @@ -1129,30 +1154,36 @@ Note that a properly formed and authorized query for an inactive or otherwise invalid token does not warrant an error response by this specification. In these cases, the authorization server MUST instead respond with an introspection response with the "active" field set to "false". 7.4. Client Token EDITORIAL NOTE: We have tentatively introduced this concept and would - specifically like feedback if this is viewed as a useful addition to - the framework. + specifically like feedback whether this is viewed as a useful + addition to the framework. - In cases where the client has limited connectivity and is requesting - access to a previously unknown resource servers, using a long term - token, there are situations where it would be beneficial to relay the - proof-of-possession key and other relevant information from the AS to - the client through the RS. The client_token parameter is designed to - carry such information, and is intended to be used as described in - Figure 14. + In cases where the client has limited connectivity and needs to get + access to a previously unknown resource servers, this framework + suggests the following approach: The client is pre-configured with a + generic, long-term access token when it is commissioned. When the + client then tries to access a RS it transmits this access token. The + RS then performs token introspection to learn what access this token + grants. In the introspection response, the AS also relays + information for the client, such as the proof-of-possession key, + through the RS. The RS passes on this Client Token to the client in + response to the submission of the token. + + The client_token parameter is designed to carry such information, and + is intended to be used as described in Figure 14. Resource Authorization Client Server Server | | | | | | C: +--------------->| | | POST | | | Access Token | | | D: +--------------->| | | Introspection | @@ -1161,21 +1192,21 @@ | E: +<---------------+ | | Introspection | | | Response | | | + Client Token | |<---------------+ | | 2.01 Created | | | + Client Token | Figure 14: Use of the client_token parameter. - The client token is a COSE_Encrytped object, containing as payload a + The client token is a COSE_Encrypted object, containing as payload a CBOR map with the following claims: cnf REQUIRED if the token type is 'pop', OPTIONAL otherwise. Contains information about the proof-of-possession key the client is to use with its access token. See Section 6.4.5. token_type OPTIONAL. See Section 6.4.3. @@ -1233,22 +1264,21 @@ draft specifies the "cnf" and "scope" claims for CBOR web tokens. The "scope" claim explicitly encodes the scope of a given access token. This claim follows the same encoding rules as defined in section 3.3 of [RFC6749]. The meaning of a specific scope value is application specific and expected to be known to the RS running that application. The "cnf" claim follows the same rules as specified for JSON web token in RFC7800 [RFC7800], except that it is encoded in CBOR in the - same way as specified for the "cnf" parameter in section - Section 6.4.5. + same way as specified for the "cnf" parameter in Section 6.4.5. 8.1. The 'Authorization Information' Endpoint The access token, containing authorization information and information of the key used by the client, needs to be transported to the RS so that the RS can authenticate and authorize the client request. This section defines a method for transporting the access token to the RS using CoAP. Profiles of this framework MAY define other @@ -1321,21 +1351,21 @@ digest. Consequently, the token integrity protection MUST be applied to prevent the token from being modified, particularly since it contains a reference to the symmetric key or the asymmetric key. If the access token contains the symmetric key, this symmetric key MUST be encrypted by the authorization server with a long-term key shared with the resource server. It is important for the authorization server to include the identity of the intended recipient (the audience), typically a single resource server (or a list of resource servers), in the token. Using a single - shared secret with multiple authorization server to simplify key + shared secret with multiple resource servers to simplify key management is NOT RECOMMENDED since the benefit from using the proof- of-possession concept is significantly reduced. Token replay is also not possible since an eavesdropper will also have to obtain the corresponding private key or shared secret that is bound to the access token. Nevertheless, it is good practice to limit the lifetime of the access token and therefore the lifetime of associated key. The authorization server MUST offer confidentiality protection for @@ -1374,26 +1404,26 @@ This specification registers new parameters for OAuth and establishes registries for mappings to CBOR. 10.1. OAuth Introspection Response Parameter Registration This specification registers the following parameters in the OAuth introspection response parameters o Name: "cnf" - o Description: Key to use to prove the right to use an access token, - as defined in [RFC7800]. + o Description: Key to prove the right to use an access token, as + defined in [RFC7800]. o Change Controller: IESG o Specification Document(s): this document o Name: "aud" - o Description: reference to intended receiving RS, as defined in PoP + o Description: Reference to intended receiving RS, as defined in PoP token specification. o Change Controller: IESG o Specification Document(s): this document 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 Specification Document(s): this document @@ -1412,22 +1442,22 @@ This specification registers the following parameters in the OAuth Parameters Registry o Parameter name: "profile" o Parameter usage location: token request, and token response o Change Controller: IESG o Specification Document(s): this document o Name: "cnf" - o Description: Key to use to prove the right to use an access token, - as defined in [RFC7800]. + o Description: Key to prove the right to use an access token, as + defined in [RFC7800]. o Change Controller: IESG o Specification Document(s): this document 10.3. OAuth Access Token Types This specification registers the following new token type in the OAuth Access Token Types Registry o Name: "PoP" o Description: A proof-of-possession token. @@ -1799,21 +1829,21 @@ 12.1. Normative References [I-D.ietf-ace-cbor-web-token] Wahlstroem, E., Jones, M., Tschofenig, H., and S. Erdtman, "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-01 (work in progress), July 2016. [I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption (COSE)", - draft-ietf-cose-msg-19 (work in progress), September 2016. + draft-ietf-cose-msg-23 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . @@ -1839,32 +1869,32 @@ environments", draft-ietf-ace-actors-04 (work in progress), September 2016. [I-D.ietf-oauth-device-flow] Denniss, W., Myrseth, S., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Flow", draft-ietf-oauth- device-flow-03 (work in progress), July 2016. [I-D.ietf-oauth-native-apps] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", - draft-ietf-oauth-native-apps-03 (work in progress), July - 2016. + draft-ietf-oauth-native-apps-05 (work in progress), + October 2016. [I-D.seitz-ace-core-authz] Seitz, L., Selander, G., and M. Vucinic, "Authorization for Constrained RESTful Environments", draft-seitz-ace- core-authz-00 (work in progress), June 2015. [I-D.selander-ace-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)", draft-selander-ace- - object-security-05 (work in progress), July 2016. + object-security-06 (work in progress), October 2016. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . @@ -2094,22 +2124,22 @@ + Store the token so that it can be retrieved in the context of a matching request. * Process a request. + Set up communication security with the client. + Authenticate the client. + Match the client against existing tokens. + Check that tokens belonging to the client actually authorize the requested action. - + Optionally: Check that the matching tokens are still valid - (if this is possible.) + + Optionally: Check that the matching tokens are still valid, + using introspection (if this is possible.) * Send a response following the agreed upon communication security. Appendix C. Requirements on Profiles This section lists the requirements on profiles of this framework, for the convenience of a profile designer. All this information is also given in the appropriate sections of the main document, this is just meant as a checklist, to make it more easy to spot parts one might have missed.