< draft-ietf-oauth-pop-key-distribution-05.txt   draft-ietf-oauth-pop-key-distribution-06.txt >
skipping to change at page 1, line 17 skipping to change at page 1, line 17
M. Jones M. Jones
Microsoft Microsoft
H. Tschofenig H. Tschofenig
Arm Ltd. Arm Ltd.
M. Meszaros M. Meszaros
GITDA GITDA
March 11, 2019 March 11, 2019
OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key
Distribution Distribution
draft-ietf-oauth-pop-key-distribution-05 draft-ietf-oauth-pop-key-distribution-06
Abstract Abstract
RFC 6750 specified the bearer token concept for securing access to RFC 6750 specified the bearer token concept for securing access to
protected resources. Bearer tokens need to be protected in transit protected resources. Bearer tokens need to be protected in transit
as well as at rest. When a client requests access to a protected as well as at rest. When a client requests access to a protected
resource it hands-over the bearer token to the resource server. resource it hands-over the bearer token to the resource server.
The OAuth 2.0 Proof-of-Possession security concept extends bearer The OAuth 2.0 Proof-of-Possession security concept extends bearer
token security and requires the client to demonstrate possession of a token security and requires the client to demonstrate possession of a
key when accessing a protected resource. key when accessing a protected resource.
This document describes how the client requests and obtains a PoP
access token from the authorization server for use with HTTPS-based
transport. Alternative transports, for example using the Constrained
Application Protocol (CoAP), have been specified in companion
specifications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 2, line 29 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Processing Instructions . . . . . . . . . . . . . . . . . . . 4 3. Processing Instructions . . . . . . . . . . . . . . . . . . . 4
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Symmetric Key Transport . . . . . . . . . . . . . . . . . 5 4.1. Symmetric Key Transport . . . . . . . . . . . . . . . . . 5
4.1.1. Client-to-AS Request . . . . . . . . . . . . . . . . 5 4.1.1. Client-to-AS Request . . . . . . . . . . . . . . . . 5
4.1.2. Client-to-AS Response . . . . . . . . . . . . . . . . 5 4.1.2. Client-to-AS Response . . . . . . . . . . . . . . . . 6
4.2. Asymmetric Key Transport . . . . . . . . . . . . . . . . 8 4.2. Asymmetric Key Transport . . . . . . . . . . . . . . . . 9
4.2.1. Client-to-AS Request . . . . . . . . . . . . . . . . 8 4.2.1. Client-to-AS Request . . . . . . . . . . . . . . . . 9
4.2.2. Client-to-AS Response . . . . . . . . . . . . . . . . 9 4.2.2. Client-to-AS Response . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6.1. OAuth Access Token Types . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. OAuth Parameters Registration . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.3. OAuth Extensions Error Registration . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The work on proof-of-possession tokens, an extended token security The work on proof-of-possession tokens, an extended token security
mechanisms for OAuth 2.0, is motivated in [21]. This document mechanisms for OAuth 2.0, is motivated in [21]. This document
defines the ability for the client request and to obtain PoP tokens defines the ability for the client request and to obtain PoP tokens
from the authorization server. After successfully completing the from the authorization server. After successfully completing the
exchange the client is in possession of a PoP token and the keying exchange the client is in possession of a PoP token and the keying
material bound to it. Clients that access protected resources then material bound to it. Clients that access protected resources then
need to demonstrate knowledge of the secret key that is bound to the need to demonstrate knowledge of the secret key that is bound to the
skipping to change at page 3, line 20 skipping to change at page 3, line 20
this document are used. this document are used.
+--------+ +---------------+ +--------+ +---------------+
| |--(A)- Authorization Request ->| Resource | | |--(A)- Authorization Request ->| Resource |
| | | Owner | | | | Owner |
| |<-(B)-- Authorization Grant ---| | | |<-(B)-- Authorization Grant ---| |
| | +---------------+ | | +---------------+
| | | |
| | +---------------+ | | +---------------+
| |--(C)-- Authorization Grant -->| | | |--(C)-- Authorization Grant -->| |
| Client | (aud, cnf) | Authorization | | Client | (resource, req_cnf) | Authorization |
| | | Server | | | | Server |
| |<-(D)-- PoP Access Token ------| | | |<-(D)-- PoP Access Token ------| |
| | (profile, cnf, rs_cnf, +---------------+ | | (rs_cnf, token_type) +---------------+
| | token_type) | |
| | +---------------+ | | +---------------+
| |--(E)-- PoP Access Token ----->| | | |--(E)-- PoP Access Token ----->| |
| | (with proof of private key) | Resource | | | (with proof of private key) | Resource |
| | | Server | | | | Server |
| |<-(F)--- Protected Resource ---| | | |<-(F)--- Protected Resource ---| |
+--------+ +---------------+ +--------+ +---------------+
Figure 1: Augmented OAuth 2.0 Protocol Flow Figure 1: Augmented OAuth 2.0 Protocol Flow
In OAuth 2.0 [2] access tokens can be obtained via authorization In OAuth 2.0 [2] access tokens can be obtained via authorization
grants and using refresh tokens. The core OAuth specification grants and using refresh tokens. The core OAuth specification
defines four authorization grants, see Section 1.3 of [2], and [18] defines four authorization grants, see Section 1.3 of [2], and [18]
adds an assertion-based authorization grant to that list. The token adds an assertion-based authorization grant to that list. The token
endpoint, which is described in Section 3.2 of [2], is used with endpoint, which is described in Section 3.2 of [2], is used with
every authorization grant except for the implicit grant type. In the every authorization grant except for the implicit grant type. In the
implicit grant type the access token is issued directly. implicit grant type the access token is issued directly.
This document extends the functionality of the token endpoint, i.e., This specification extends the functionality of the token endpoint,
the protocol exchange between the client and the authorization i.e., the protocol exchange between the client and the authorization
server, to allow keying material to be bound to an access token. Two server, to allow keying material to be bound to an access token. Two
types of keying material can be bound to an access token, namely types of keying material can be bound to an access token, namely
symmetric keys and asymmetric keys. Conveying symmetric keys from symmetric keys and asymmetric keys. Conveying symmetric keys from
the authorization server to the client is described in Section 4.1 the authorization server to the client is described in Section 4.1
and the procedure for dealing with asymmetric keys is described in and the procedure for dealing with asymmetric keys is described in
Section 4.2. Section 4.2.
This document describes how the client requests and obtains a PoP
access token from the authorization server for use with HTTPS-based
transport. The use of alternative transports, such as Constrained
Application Protocol (CoAP), is described in [23].
2. Terminology 2. Terminology
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
specification are to be interpreted as described in [1]. specification are to be interpreted as described in [1].
Session Key: Session Key:
In the context of this specification 'session key' refers to fresh In the context of this specification 'session key' refers to fresh
and unique keying material established between the client and the and unique keying material established between the client and the
skipping to change at page 4, line 31 skipping to change at page 4, line 33
JWA: JSON Web Algorithms[7] JWA: JSON Web Algorithms[7]
JWT: JSON Web Token[9] JWT: JSON Web Token[9]
JWS: JSON Web Signature[6] JWS: JSON Web Signature[6]
JWK: JSON Web Key[5] JWK: JSON Web Key[5]
JWE: JSON Web Encryption[8] JWE: JSON Web Encryption[8]
CWT: CBOR Web Token[14] CWT: CBOR Web Token[13]
COSE: CBOR Object Signing and Encryption[15] COSE: CBOR Object Signing and Encryption[14]
3. Processing Instructions 3. Processing Instructions
Step (0): As an initial step the client typically determines the Step (0): As an initial step the client typically determines the
resource server it wants to interact with. This may, for example, resource server it wants to interact with. This may, for example,
happen as part of a discovery procedure or via manual happen as part of a discovery procedure or via manual
configuration. configuration.
Step (1): The client starts the OAuth 2.0 protocol interaction Step (1): The client starts the OAuth 2.0 protocol interaction
based on the selected grant type. based on the selected grant type.
Step (2): When the client interacts with the token endpoint to Step (2): When the client interacts with the token endpoint to
obtain an access token it MUST follow the processing steps for the obtain an access token it MUST use the resource identicator
HTTPS-based transport described in Section 5.6.1 of [12]. This defined in [15] when symmetric PoP tokens are used. For
includes determining whether to use the 'aud' and the 'cnf' asymmetric PoP tokens the use of resource indicators is optional
parameters. but recommended.
Step (3): The authorization server parses the request from the Step (3): The authorization server parses the request from the
server and determines the suitable response based on the server and determines the suitable response based on OAuth 2.0 and
description in Section 5.6.2 of [12]. In case of an error the the PoP token credential procedures.
procedure in Section 5.6.3 of [12] is applicable.
Note that PoP access tokens may be encoded in a variety of ways. In Note that PoP access tokens may be encoded in a variety of ways:
case the access token is encoded using the JSON Web Token (JWT)
format [9] it MUST be protected against modification by either using
a digital signature or a keyed message digest, as described in [6].
The JWT may also be encrypted using [8]. [14] defines an alternative
token format based on CBOR. The proof-of-possession token
functionality is defined in [13]. Finally, access tokens can also be
passed by reference, which then requires the token introspection
endpoint (or a similiar, proprietary protocol mechanism) to be used.
This specification does not mandate a specific PoP token format.
Subsequent steps for the interaction between the client and the JWT The access token may be encoded using the JSON Web Token (JWT)
resource server are beyond the scope of this document. format [9]. The proof-of-possession token functionality is
described in [10]. A JWT encoded PoP token MUST be protected
against modification by either using a digital signature or a
keyed message digest, as described in [6]. The JWT may also be
encrypted using [8].
CWT [13] defines an alternative token format based on CBOR. The
proof-of-possession token functionality is defined in [12]. A CWT
encoded PoP token MUST be protected against modification by either
using a digital signature or a keyed message digest, as described
in [12].
If the access token is only a reference then a look-up by the
resource server is needed, as described in the token introspection
specification [22].
Note that the OAuth 2.0 framework nor this specification does not
mandate a specific PoP token format but using a standardized format
will improve interoperability and will lead to better code re-use.
Application layer interactions between the client and the resource
server are beyond the scope of this document.
4. Examples 4. Examples
This section provides a number of examples. This section provides a number of examples.
4.1. Symmetric Key Transport 4.1. Symmetric Key Transport
4.1.1. Client-to-AS Request 4.1.1. Client-to-AS Request
The client starts with a request to the authorization server The client starts with a request to the authorization server
indicating that it is interested to obtain a token for example- indicating that it is interested to obtain a token for
server. https://www.example.com
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=authorization_code grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA &code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&aud=example-server &resource=https://www.example.com
Example Request to the Authorization Server Example Request to the Authorization Server
4.1.2. Client-to-AS Response 4.1.2. Client-to-AS Response
If the access token request has been successfully verified by the If the access token request has been successfully verified by the
authorization server and the client is authorized to obtain a PoP authorization server and the client is authorized to obtain a PoP
token for the indicated resource server, the authorization server token for the indicated resource server, the authorization server
issues an access token and optionally a refresh token. issues an access token and optionally a refresh token.
Figure 2 shows a response containing a token and a "cnf" parameter Figure 2 shows a response containing a token and a "cnf" parameter
with a symmetric proof-of-possession key. with a symmetric proof-of-possession key both encoded in a JSON-based
serialization format. The "cnf" parameter contains the RFC 7517 [5]
encoded key element.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Cache-Control: no-store Cache-Control: no-store
{ {
"access_token":"SlAV32hkKG ... "access_token":"SlAV32hkKG ...
(remainder of JWT omitted for brevity; (remainder of JWT omitted for brevity;
JWT contains JWK in the cnf claim)", JWT contains JWK in the cnf claim)",
"token_type":"pop", "token_type":"pop",
"expires_in":3600, "expires_in":3600,
"refresh_token":"8xLOxBtZp8", "refresh_token":"8xLOxBtZp8",
"cnf":{ "cnf":{
"keys" : { {"keys":
"kty" : "Symmetric", [
"kid" : b64'39Gqlw', {"kty":"oct",
"k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' "alg":"A128KW",
} "k":"GawgguFyGrWKav7AX4VKUg"
} }
]
}
}
} }
Figure 2: Example: Response from the Authorization Server (Symmetric Figure 2: Example: Response from the Authorization Server (Symmetric
Variant) Variant)
Note that the cnf payload in Figure 2 is not encrypted at the Note that the cnf payload in Figure 2 is not encrypted at the
application layer since Transport Layer Security is used between the application layer since Transport Layer Security is used between the
AS and the client and the content of the cnf payload is consumed by AS and the client and the content of the cnf payload is consumed by
the client itself. Alternatively, a JWE could be used to encrypt the the client itself. Alternatively, a JWE could be used to encrypt the
key distribution, as shown in Figure 3. key distribution, as shown in Figure 3.
skipping to change at page 7, line 17 skipping to change at page 8, line 17
(remainder of JWT omitted for brevity; (remainder of JWT omitted for brevity;
JWT contains JWK in the cnf claim)", JWT contains JWK in the cnf claim)",
"token_type":"pop", "token_type":"pop",
"expires_in":3600, "expires_in":3600,
"refresh_token":"8xLOxBtZp8", "refresh_token":"8xLOxBtZp8",
"cnf":{ "cnf":{
"jwe": "jwe":
"eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ. "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
(remainder of JWE omitted for brevity)" (remainder of JWE omitted for brevity)"
} }
} }
} }
Figure 3: Example: Encrypted Symmmetric Key Figure 3: Example: Encrypted Symmmetric Key
The content of the key parameter, which is a JWK in our example, is
shown in Figure 4.
{
"kty":"oct",
"kid":"id123",
"alg":"HS256",
"k":"ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE"
}
Figure 4: Example: Key Transport to Client via a JWK
The content of the 'access_token' in JWT format contains the 'cnf' The content of the 'access_token' in JWT format contains the 'cnf'
(confirmation) claim, as shown in Figure 5. The confirmation claim (confirmation) claim. The confirmation claim is defined in [10].
is defined in [10]. The digital signature or the keyed message The digital signature or the keyed message digest offering integrity
digest offering integrity protection is not shown in this example but protection is not shown in this example but has to be present in a
has to be present in a real deployment to mitigate a number of real deployment to mitigate a number of security threats.
security threats.
The JWK in the key element of the response from the authorization The JWK in the key element of the response from the authorization
server, as shown in Figure 2, contains the same session key as the server, as shown in Figure 2, contains the same session key as the
JWK inside the access token, as shown in Figure 5. It is, in this JWK inside the access token, as shown in Figure 4. It is, in this
example, protected by TLS and transmitted from the authorization example, protected by TLS and transmitted from the authorization
server to the client (for processing by the client). server to the client (for processing by the client).
{ {
"iss": "https://server.example.com", "iss": "https://server.example.com",
"sub": "24400320", "sub": "24400320",
"aud": "s6BhdRkqt3", "aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj", "nonce": "n-0S6_WzA2Mj",
"exp": 1311281970, "exp": 1311281970,
"iat": 1311280970, "iat": 1311280970,
"cnf":{ "cnf":{
"jwk": "jwe":
"JDLUhTMjU2IiwiY3R5Ijoi ... "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSFMyNTYifQ.
(remainder of JWK protected by JWE omitted for brevity)" (remainder of JWE omitted for brevity)"
} }
} }
Figure 5: Example: Access Token in JWT Format Figure 4: Example: Access Token in JWT Format
Note: When the JWK inside the access token contains a symmetric key Note: When the JWK inside the access token contains a symmetric key
it must be confidentiality protected using a JWE to maintain the it must be confidentiality protected using a JWE to maintain the
security goals of the PoP architecture, as described in [21] since security goals of the PoP architecture since content is meant for
content is meant for consumption by the selected resource server consumption by the selected resource server only. The details are
only. described in [21].
Note: This document does not impose requirements on the encoding of
the access token. The examples used in this document make use of the
JWT structure but the CWT format is an equally appropriate format to
use.
If the access token is only a reference then a look-up by the
resource server is needed, as described in the token introspection
specification [22].
4.2. Asymmetric Key Transport 4.2. Asymmetric Key Transport
4.2.1. Client-to-AS Request 4.2.1. Client-to-AS Request
This example illustrates the case where an asymmetric key shall be This example illustrates the case where an asymmetric key shall be
bound to an access token. The client makes the following HTTPS bound to an access token. The client makes the following HTTPS
request shown in Figure 6. Extra line breaks are for display request shown in Figure 5. Extra line breaks are for display
purposes only. purposes only.
POST /token HTTP/1.1 POST /token HTTP/1.1
Host: server.example.com Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded;charset=UTF-8 Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=authorization_code grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA &code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&token_type=pop &token_type=pop
&cnf=eyJhbGciOiJSU0ExXzUi ... &req_cnf=eyJhbGciOiJSU0ExXzUi ...
(remainder of JWK omitted for brevity) (remainder of JWK omitted for brevity)
Figure 6: Example Request to the Authorization Server (Asymmetric Key Figure 5: Example Request to the Authorization Server (Asymmetric Key
Variant) Variant)
As shown in Figure 7 the content of the 'cnf' parameter contains the As shown in Figure 6 the content of the 'req_cnf' parameter contains
ECC public key the client would like to associate with the access the ECC public key the client would like to associate with the access
token. token (in JSON format).
"jwk":{ "jwk":{
"kty": "EC", "kty": "EC",
"use": "sig", "use": "sig",
"crv": "P-256", "crv": "P-256",
"x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM", "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
"y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
} }
Figure 7: Client Providing Public Key to Authorization Server Figure 6: Client Providing Public Key to Authorization Server
4.2.2. Client-to-AS Response 4.2.2. Client-to-AS Response
If the access token request is valid and authorized, the If the access token request is valid and authorized, the
authorization server issues an access token and optionally a refresh authorization server issues an access token and optionally a refresh
token. The authorization server also places information about the token. The authorization server also places information about the
public key used by the client into the access token to create the public key used by the client into the access token to create the
binding between the two. The new token type "public_key" is placed binding between the two. The new token type "pop" is placed into the
into the 'token_type' parameter. 'token_type' parameter.
An example of a successful response is shown in Figure 8. An example of a successful response is shown in Figure 7.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8 Content-Type: application/json;charset=UTF-8
Cache-Control: no-store Cache-Control: no-store
Pragma: no-cache Pragma: no-cache
{ {
"access_token":"2YotnFZFE....jr1zCsicMWpAA", "access_token":"2YotnFZFE....jr1zCsicMWpAA",
"token_type":"pop", "token_type":"pop",
"expires_in":3600, "expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA" "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
} }
Figure 8: Example: Response from the Authorization Server (Asymmetric Figure 7: Example: Response from the Authorization Server (Asymmetric
Variant) Variant)
The content of the 'access_token' field contains an encoded JWT, as The content of the 'access_token' field contains an encoded JWT, as
shown in Figure 9. The digital signature covering the access token shown in Figure 8. The digital signature covering the access token
offering authenticity and integrity protection is not shown below offering authenticity and integrity protection is not shown below
(but must be present). (but must be present).
{ {
"iss":"xas.example.com", "iss":"xas.example.com",
"aud":"http://auth.example.com", "aud":"http://auth.example.com",
"exp":"1361398824", "exp":"1361398824",
"nbf":"1360189224", "nbf":"1360189224",
"cnf":{ "cnf":{
"jwk" : { "jwk" : {
"kty" : "EC", "kty" : "EC",
"kid" : h'11', "kid" : h'11',
"crv" : "P-256", "crv" : "P-256",
"x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8', "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
"y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4' "y" : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
} }
} }
} }
Figure 9: Example: Access Token Structure (Asymmetric Variant) Figure 8: Example: Access Token Structure (Asymmetric Variant)
Note: In this example there is no need for the authorization server Note: In this example there is no need for the authorization server
to convey further keying material to the client since the client is to convey further keying material to the client since the client is
already in possession of the private key. already in possession of the private key (as well as the public key).
5. Security Considerations 5. Security Considerations
[21] describes the architecture for the OAuth 2.0 proof-of-possession [21] describes the architecture for the OAuth 2.0 proof-of-possession
security architecture, including use cases, threats, and security architecture, including use cases, threats, and
requirements. This requirements describes one solution component of requirements. This requirements describes one solution component of
that architecture, namely the mechanism for the client to interact that architecture, namely the mechanism for the client to interact
with the authorization server to either obtain a symmetric key from with the authorization server to either obtain a symmetric key from
the authorization server, to obtain an asymmetric key pair, or to the authorization server, to obtain an asymmetric key pair, or to
offer a public key to the authorization. In any case, these keys are offer a public key to the authorization. In any case, these keys are
skipping to change at page 12, line 29 skipping to change at page 13, line 10
server to use shorter key sizes, which translate to a performance server to use shorter key sizes, which translate to a performance
benefit for the client and for the resource server. Shorter keys benefit for the client and for the resource server. Shorter keys
also lead to shorter messages (particularly with asymmetric keying also lead to shorter messages (particularly with asymmetric keying
material). material).
When authorization servers bind symmetric keys to access tokens then When authorization servers bind symmetric keys to access tokens then
they SHOULD scope these access tokens to a specific permissions. they SHOULD scope these access tokens to a specific permissions.
6. IANA Considerations 6. IANA Considerations
This document does not require any actions by IANA. 6.1. OAuth Access Token Types
This specification registers the following error in the IANA "OAuth
Access Token Types" [24] established by [16].
o Name: pop
o Change controller: IESG
o Specification document(s): [[ this specification ]]
6.2. OAuth Parameters Registration
This specification registers the following value in the IANA "OAuth
Parameters" registry [24] established by [2].
o Parameter name: cnf_req
o Parameter usage location: authorization request, token request
o Change controller: IESG
o Specification document(s): [[ this specification ]]
o Parameter name: cnf
o Parameter usage location: authorization response, token response
o Change controller: IESG
o Specification document(s): [[ this specification ]]
o Parameter name: rs_cnf
o Parameter usage location: token response
o Change controller: IESG
o Specification document(s): [[ this specification ]]
6.3. OAuth Extensions Error Registration
This specification registers the following error in the IANA "OAuth
Extensions Error Registry" [24] established by [2].
o Error name: invalid_token_type
o Error usage location: implicit grant error response, token error
response
o Related protocol extension: token_type parameter
o Change controller: IESG
o Specification document(s): [[ this specification ]]
7. Acknowledgements 7. Acknowledgements
We would like to thank Chuck Mortimore for his review comments. We would like to thank Chuck Mortimore for his review comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate [1] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 13, line 39 skipping to change at page 15, line 14
[10] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [10] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)", Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016, RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>. <https://www.rfc-editor.org/info/rfc7800>.
[11] Jones, M. and N. Sakimura, "JSON Web Key (JWK) [11] Jones, M. and N. Sakimura, "JSON Web Key (JWK)
Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
2015, <https://www.rfc-editor.org/info/rfc7638>. 2015, <https://www.rfc-editor.org/info/rfc7638>.
[12] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and [12] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22
(work in progress), March 2019.
[13] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-06 (work in progress), February 2019. possession-06 (work in progress), February 2019.
[14] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [13] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[15] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [14] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[15] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", draft-ietf-oauth-resource-
indicators-02 (work in progress), January 2019.
8.2. Informative References 8.2. Informative References
[16] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [16] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>. <https://www.rfc-editor.org/info/rfc6750>.
[17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [17] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
skipping to change at page 14, line 45 skipping to change at page 16, line 19
[21] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. [21] Hunt, P., Richer, J., Mills, W., Mishra, P., and H.
Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security
Architecture", draft-ietf-oauth-pop-architecture-08 (work Architecture", draft-ietf-oauth-pop-architecture-08 (work
in progress), July 2016. in progress), July 2016.
[22] Richer, J., Ed., "OAuth 2.0 Token Introspection", [22] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>. <https://www.rfc-editor.org/info/rfc7662>.
[23] IANA, "JSON Web Token Claims", March 2019. [23] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22
(work in progress), March 2019.
[24] IANA, "OAuth Parameters", October 2018.
[25] IANA, "JSON Web Token Claims", June 2018.
Authors' Addresses Authors' Addresses
John Bradley John Bradley
Ping Identity Ping Identity
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/ URI: http://www.thread-safe.com/
Phil Hunt Phil Hunt
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com Email: phil.hunt@yahoo.com
 End of changes. 42 change blocks. 
115 lines changed or deleted 156 lines changed or added

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