draft-ietf-oauth-token-binding-00.txt   draft-ietf-oauth-token-binding-01.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: March 11, 2017 B. Campbell Expires: March 24, 2017 B. Campbell
Ping Identity Ping Identity
September 7, 2016 September 20, 2016
OAuth 2.0 Token Binding OAuth 2.0 Token Binding
draft-ietf-oauth-token-binding-00 draft-ietf-oauth-token-binding-01
Abstract Abstract
This specification enables OAuth 2.0 implementations to apply Token This specification enables OAuth 2.0 implementations to apply Token
Binding to Access Tokens and Refresh Tokens. This cryptographically Binding to Access Tokens and Refresh Tokens. This cryptographically
binds these tokens to the TLS connections over which they are binds these tokens to the TLS connections over which they are
intended to be used. This use of Token Binding protects these tokens intended to be used. This use of Token Binding protects these tokens
from man-in-the-middle and token export and replay attacks. from man-in-the-middle and token export and replay attacks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2017. This Internet-Draft will expire on March 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation and Conventions . . . . . . . . . . 3 1.1. Requirements Notation and Conventions . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Token Binding for Refresh Tokens . . . . . . . . . . . . . . 3 2. Token Binding for Refresh Tokens . . . . . . . . . . . . . . 3
3. Token Binding for Access Tokens . . . . . . . . . . . . . . . 4 3. Token Binding for Access Tokens . . . . . . . . . . . . . . . 4
3.1. Initial Access Tokens . . . . . . . . . . . . . . . . . . 5 3.1. Access Tokens Issued from the Authorization Endpoint . . 5
3.2. Refreshed Access Tokens . . . . . . . . . . . . . . . . . 5 3.2. Access Tokens Issued from the Token Endpoint . . . . . . 5
3.3. Resource Server Token Binding Validation . . . . . . . . 5 3.3. Protected Resource Token Binding Validation . . . . . . . 5
3.4. Representing Token Binding in JWT Access Tokens . . . . . 5 3.4. Representing Token Binding in JWT Access Tokens . . . . . 5
4. Phasing in Token Binding and Preventing Downgrade Attacks . . 6 4. Phasing in Token Binding and Preventing Downgrade Attacks . . 6
5. Token Binding Metadata . . . . . . . . . . . . . . . . . . . 7 5. Token Binding Metadata . . . . . . . . . . . . . . . . . . . 7
5.1. Token Binding Client Metadata . . . . . . . . . . . . . . 7 5.1. Token Binding Client Metadata . . . . . . . . . . . . . . 7
5.2. Token Binding Authorization Server Metadata . . . . . . . 7 5.2. Token Binding Authorization Server Metadata . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.3. Token Binding Protected Resource Metadata . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. OAuth Parameters Registration . . . . . . . . . . . . . . 8 7.1. OAuth Dynamic Client Registration Metadata Registration . 8
7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8 7.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 8
7.2. OAuth Dynamic Client Registration Metadata Registration . 8 7.2. OAuth Authorization Server Metadata Registration . . . . 8
7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 8 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 9
7.3. OAuth Authorization Server Discovery Metadata 7.3. OAuth Protected Resource Metadata Registration . . . . . 9
Registration . . . . . . . . . . . . . . . . . . . . . . 8
7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 9 7.3.1. Registry Contents . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 11 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 11
Appendix C. Document History . . . . . . . . . . . . . . . . . . 11 Appendix C. Document History . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This specification enables OAuth 2.0 [RFC6749] implementations to This specification enables OAuth 2.0 [RFC6749] implementations to
apply Token Binding The Token Binding Protocol Version 1.0 apply Token Binding The Token Binding Protocol Version 1.0
[I-D.ietf-tokbind-protocol] Token Binding over HTTP [I-D.ietf-tokbind-protocol] Token Binding over HTTP
[I-D.ietf-tokbind-https] to Access Tokens and Refresh Tokens. This [I-D.ietf-tokbind-https] to Access Tokens and Refresh Tokens. This
cryptographically binds these tokens to the TLS connections over cryptographically binds these tokens to the TLS connections over
which they are intended to be used. This use of Token Binding which they are intended to be used. This use of Token Binding
protects these tokens from man-in-the-middle and token export and protects these tokens from man-in-the-middle and token export and
skipping to change at page 3, line 15 skipping to change at page 3, line 15
1.1. Requirements Notation and Conventions 1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
This specification uses the terms "Access Token", "Authorization This specification uses the terms "Access Token", "Authorization
Code", "Authorization Endpoint", "Authorization Grant", Endpoint", "Authorization Server", "Client", "Protected Resource",
"Authorization Server", "Client", "Client Authentication", "Client "Refresh Token", and "Token Endpoint" defined by OAuth 2.0 [RFC6749],
Identifier", "Client Secret", "Grant Type", "Protected Resource", the terms "Claim" and "JSON Web Token (JWT)" defined by JSON Web
"Redirection URI", "Refresh Token", "Resource Owner", "Resource Token (JWT) [JWT], the term "User Agent" defined by RFC 7230
Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC7230], and the terms "Provided", "Referred", "Token Binding" and
[RFC6749], the terms "Claim", "Claim Name", "Claim Value", and "JSON "Token Binding ID" defined by Token Binding over HTTP
Web Token (JWT)" defined by JSON Web Token (JWT) [JWT], the term [I-D.ietf-tokbind-https].
"User Agent" defined by RFC 7230 [RFC7230], and the terms "Provided",
"Referred", "Token Binding" and "Token Binding ID" defined by Token
Binding over HTTP [I-D.ietf-tokbind-https].
2. Token Binding for Refresh Tokens 2. Token Binding for Refresh Tokens
Token Binding of refresh tokens is a straightforward first-party Token Binding of refresh tokens is a straightforward first-party
scenario, applying term "first-party" as used in Token Binding over scenario, applying term "first-party" as used in Token Binding over
HTTP [I-D.ietf-tokbind-https]. It cryptographically binds the HTTP [I-D.ietf-tokbind-https]. It cryptographically binds the
refresh token to the TLS connection between the client and the token refresh token to the TLS connection between the client and the token
endpoint. This case is straightforward because the refresh token is endpoint. This case is straightforward because the refresh token is
both retrieved by the client from the token endpoint and sent by the both retrieved by the client from the token endpoint and sent by the
client to the token endpoint. Unlike the federated scenarios client to the token endpoint. Unlike the federated scenarios
described in Section 3 (Federation Use Cases) of Token Binding over described in Section 4 (Federation Use Cases) of Token Binding over
HTTP [I-D.ietf-tokbind-https] and the access token case described in HTTP [I-D.ietf-tokbind-https] and the access token case described in
the next section, only a single TLS connection is involved in the the next section, only a single TLS connection is involved in the
refresh token case. refresh token case.
Token Binding a refresh token requires that the authorization server Token Binding a refresh token requires that the authorization server
do two things. First, when refresh token is sent to the client, the do two things. First, when refresh token is sent to the client, the
authorization server needs to remember the Provided Token Binding ID authorization server needs to remember the Provided Token Binding ID
and remember its association with the issued refresh token. Second, and remember its association with the issued refresh token. Second,
when a token request containing a refresh token is received at the when a token request containing a refresh token is received at the
token endpoint, the authorization server needs to verify that the token endpoint, the authorization server needs to verify that the
Provided Token Binding ID for the request matches the remembered Provided Token Binding ID for the request matches the remembered
Token Binding ID associated with the refresh token. If the Token Token Binding ID associated with the refresh token. If the Token
Binding IDs do not match, the authorization server should return an Binding IDs do not match, the authorization server should return an
error in response to the request. error in response to the request.
The means by which the authorization server remembers the association How the authorization server remembers the association between the
between the refresh token and the Token Binding ID is an refresh token and the Token Binding ID is an implementation detail
implementation detail that beyond the scope of this specification. that beyond the scope of this specification. Some authorization
Some authorization servers will choose to store the Token Binding ID servers will choose to store the Token Binding ID (or a cryptographic
(or a cryptographic hash of it, such a SHA-256 hash [SHS]) in the hash of it, such a SHA-256 hash [SHS]) in the refresh token itself,
refresh token itself, thus reducing the amount of state to be kept by thus reducing the amount of state to be kept by the server. Other
the server. Other authorization servers will add the Token Binding authorization servers will add the Token Binding ID value (or a hash
ID value (or a hash of it) to an internal data structure also of it) to an internal data structure also containing other
containing other information about the refresh token, such as grant information about the refresh token, such as grant type information.
type information. These choices make no difference to the client, These choices make no difference to the client, since the refresh
since the refresh token is opaque to it. token is opaque to it.
3. Token Binding for Access Tokens 3. Token Binding for Access Tokens
Token Binding for access tokens cryptographically binds the access Token Binding for access tokens cryptographically binds the access
token to the TLS connection between the client and the resource token to the TLS connection between the client and the protected
server. Token Binding is applied to access tokens in a similar resource. Token Binding is applied to access tokens in a similar
manner to that described in Section 3 (Federation Use Cases) of Token manner to that described in Section 4 (Federation Use Cases) of Token
Binding over HTTP [I-D.ietf-tokbind-https]. It is also builds upon Binding over HTTP [I-D.ietf-tokbind-https]. It also builds upon the
the mechanisms for Token Binding of ID Tokens defined in OpenID mechanisms for Token Binding of ID Tokens defined in OpenID Connect
Connect Token Bound Authentication 1.0 [OpenID.TokenBinding]. Token Bound Authentication 1.0 [OpenID.TokenBinding].
In the OpenID Connect [OpenID.Core] use case, HTTP redirects are used In the OpenID Connect [OpenID.Core] use case, HTTP redirects are used
to pass information between the identity provider and the relying to pass information between the identity provider and the relying
party; this HTTP redirect makes the Token Binding ID of the relying party; this HTTP redirect makes the Token Binding ID of the relying
party available to the identity provider as the Referred Token party available to the identity provider as the Referred Token
Binding ID, information about which is then added to the ID Token. Binding ID, information about which is then added to the ID Token.
No such redirect occurs between the authorization server and the No such redirect occurs between the authorization server and the
resource server in the access token case; therefore, information protected resource in the access token case; therefore, information
about the Token Binding ID for the TLS connection between the client about the Token Binding ID for the TLS connection between the client
and the resource server needs to be explicitly communicated by the and the protected resource needs to be explicitly communicated by the
client to the authorization server to achieve Token Binding of the client to the authorization server to achieve Token Binding of the
access token. This information is passed to the authorization server access token.
using this request parameter:
resource_tbh This information is passed to the authorization server using the
Base64url encoding of the SHA-256 hash [SHS] of the Token Binding Referred Token Binding ID, just as in the ID Token case. The only
ID for the TLS connection between the client and the resource difference is that the client needs to explicitly communicate the
server. Token Binding ID of the TLS connection between the client and the
protected resource to the Token Binding implementation so that it is
sent as the Referred Token Binding ID in the request to the
authorization server. This functionality provided by Token Binding
implementations is described in Section 5 (Implementation
Considerations) of Token Binding over HTTP [I-D.ietf-tokbind-https].
Note that to obtain this Token Binding ID, the client needs to Note that to obtain this Token Binding ID, the client may need to
establish a TLS connection between itself and the resource server establish a TLS connection between itself and the protected resource
prior to making the authorization request so that the Provided Token prior to making the request to the authorization server so that the
Binding ID for the TLS connection to the resource server can be Provided Token Binding ID for the TLS connection to the protected
obtained. The means by which the client retrieves this Token Binding resource can be obtained. How the client retrieves this Token
ID from the underlying Token Binding API is implementation and Binding ID from the underlying Token Binding API is implementation
operating system specific. An alternative, if supported, is for the and operating system specific. An alternative, if supported, is for
client to generate a Token Binding key to use for the resource the client to generate a Token Binding key to use for the protected
server, use the Token Binding ID for that key, and then later use resource, use the Token Binding ID for that key, and then later use
that key when the TLS connection to the resource server is that key when the TLS connection to the protected resource is
established. established.
The authorization server MUST ignore the "resource_tbh" parameter if 3.1. Access Tokens Issued from the Authorization Endpoint
it does not support Token Binding for the access token.
3.1. Initial Access Tokens
Upon receiving the hash of the Token Binding ID in an authorization For access tokens returned directly from the authorization endpoint,
request containing the "resource_tbh" (resource token binding hash) such as with the implicit grant defined in Section 4.2 of OAuth 2.0
authorization request parameter, the authorization server then [RFC6749], the Referred Token Binding ID used to bind the access
records it in the issued access token. Alternatively, in some token is sent with the authorization request. Upon receiving the
implementations, the resource's Token Binding ID hash might be Referred Token Binding ID in an authorization request, the
communicated to the resource server by other means, such as by authorization server then records it (or a cryptographic hash of it)
introspecting [RFC7662] the access token. in the issued access token. Alternatively, in some implementations,
the resource's Token Binding ID information might be communicated to
the protected resource by other means, such as by introspecting
[RFC7662] the access token.
3.2. Refreshed Access Tokens 3.2. Access Tokens Issued from the Token Endpoint
Access tokens obtained from refresh requests can also be token bound. For access tokens returned from the token endpoint, the Referred
In this case, the hash of the Token Binding ID of the TLS connection Token Binding ID used to bind the access token is sent with the token
between the client and the resource server is sent to the request. This applies to all the conventional grant types from OAuth
authorization server at the token endpoint using the "resource_tbh" 2.0 [RFC6749], including but not limited to refresh and authorization
(resource token binding hash) token request parameter; its syntax is code token requests, as well as extension grants, such as JWT
exactly the same as the corresponding authorization request assertion authorization grants [RFC7523]. In this case, the Token
parameter. The authorization server then records it in the issued Binding ID of the TLS connection between the client and the protected
access token or communicates it to the resource server by other resource is sent to the authorization server at the token endpoint as
means, just as in the previous case. the Referred Token Binding ID. The authorization server then records
it (or a cryptographic hash of it) in the issued access token or
communicates it to the protected resource by other means, just as in
the previous case.
3.3. Resource Server Token Binding Validation 3.3. Protected Resource Token Binding Validation
Upon receiving a token bound access token, the resource server Upon receiving a token bound access token, the protected resource
validates the binding by computing a SHA-256 hash of the Provided validates the binding by comparing the Provided Token Binding ID to
Token Binding ID and comparing it to the token binding hash value for the Token Binding ID for the access token. Alternatively,
the access token. If these values do not match, the resource access cryptographic hashes of these Token Binding ID values can be
attempt MUST be rejected with an error. compared. If the values do not match, the resource access attempt
MUST be rejected with an error.
3.4. Representing Token Binding in JWT Access Tokens 3.4. Representing Token Binding in JWT Access Tokens
If the access token is represented as a JWT, the token binding If the access token is represented as a JWT, the token binding
information SHOULD be represented in the same way that it is in token information SHOULD be represented in the same way that it is in token
bound OpenID Connect ID Tokens [OpenID.TokenBinding]. That bound OpenID Connect ID Tokens [OpenID.TokenBinding]. That
specification defines the new JWT Confirmation Method RFC 7800 specification defines the new JWT Confirmation Method RFC 7800
[RFC7800] member "tbh" (token binding hash) to represent the SHA-256 [RFC7800] member "tbh" (token binding hash) to represent the SHA-256
hash of a Token Binding ID in an ID Token. The value of the "tbh" hash of a Token Binding ID in an ID Token. The value of the "tbh"
member is the base64url encoding of the SHA-256 hash of the Token member is the base64url encoding of the SHA-256 hash of the Token
skipping to change at page 6, line 24 skipping to change at page 6, line 26
"exp": 1467324920, "exp": 1467324920,
"cnf":{ "cnf":{
"tbh": "n0jI3trBK6_Gp2qiLOf48ZEZTjpBnhm-QOyzJxhBeAk" "tbh": "n0jI3trBK6_Gp2qiLOf48ZEZTjpBnhm-QOyzJxhBeAk"
} }
} }
4. Phasing in Token Binding and Preventing Downgrade Attacks 4. Phasing in Token Binding and Preventing Downgrade Attacks
Many OAuth implementations will be deployed in situations in which Many OAuth implementations will be deployed in situations in which
not all participants support Token Binding. Any of combination of not all participants support Token Binding. Any of combination of
the client, the authorization server, the resource server, and the the client, the authorization server, the protected resource, and the
User Agent may not yet support Token Binding, in which case it will user agent may not yet support Token Binding, in which case it will
not work end-to-end. not work end-to-end.
It is a context-dependent deployment choice whether to allow It is a context-dependent deployment choice whether to allow
interactions to proceed in which Token Binding is not supported or interactions to proceed in which Token Binding is not supported or
whether to treat Token Binding failures at any step as fatal errors. whether to treat Token Binding failures at any step as fatal errors.
Particularly in dynamic deployment environments in which End Users Particularly in dynamic deployment environments in which End Users
have choices of clients, authorization servers, resource servers, have choices of clients, authorization servers, protected resources,
and/or User Agents, it is RECOMMENDED that authorizations using one and/or user agents, it is RECOMMENDED that authorizations using one
or more components that do not implement Token Binding be allowed to or more components that do not implement Token Binding be allowed to
successfully proceed. This enables different components to be successfully proceed. This enables different components to be
upgraded to supporting Token Binding at different times, providing a upgraded to supporting Token Binding at different times, providing a
smooth transition path for phasing in Token Binding. However, when smooth transition path for phasing in Token Binding. However, when
Token Binding has been performed, any Token Binding key mismatches Token Binding has been performed, any Token Binding key mismatches
MUST be treated as fatal errors. MUST be treated as fatal errors.
If all the participants in an authorization interaction support Token If all the participants in an authorization interaction support Token
Binding and yet one or more of them does not use it, this is likely Binding and yet one or more of them does not use it, this is likely
evidence of a downgrade attack. In this case, the authorization evidence of a downgrade attack. In this case, the authorization
SHOULD be aborted with an error. For instance, if the resource SHOULD be aborted with an error. For instance, if the protected
server knows that the authorization server and the User Agent both resource knows that the authorization server and the user agent both
support Token Binding and yet the access token received does not support Token Binding and yet the access token received does not
contain Token Binding information, this is almost certainly a sign of contain Token Binding information, this is almost certainly a sign of
an attack. an attack.
The authorization server and client can determine whether the other The authorization server, client, and protected resource can
supports Token Binding using the metadata values defined in the next determine whether the others support Token Binding using the metadata
section. They can determine whether the User Agent supports Token values defined in the next section. They can determine whether the
Binding by whether it negotiated Token Binding for the TLS user agent supports Token Binding by whether it negotiated Token
connection. At present, there is no defined mechanism for Binding for the TLS connection.
determining whether the resource server supports Token Binding or
not. However, it always safe to proceed as if it does; at worst, the
resource server simply won't verify the Token Binding.
5. Token Binding Metadata 5. Token Binding Metadata
5.1. Token Binding Client Metadata 5.1. Token Binding Client Metadata
Clients supporting Token Binding that also support the OAuth 2.0 Clients supporting Token Binding that also support the OAuth 2.0
Dynamic Client Registration Protocol [RFC7591] use these metadata Dynamic Client Registration Protocol [RFC7591] use these metadata
values to register their support for Token Binding of Access Tokens values to declare their support for Token Binding of access tokens
and Refresh Tokens: and refresh tokens:
client_access_token_token_binding_supported client_access_token_token_binding_supported
OPTIONAL. Boolean value specifying whether the Client supports OPTIONAL. Boolean value specifying whether the client supports
Token Binding of Access Tokens. If omitted, the default value is Token Binding of access tokens. If omitted, the default value is
"false". "false".
client_refresh_token_token_binding_supported client_refresh_token_token_binding_supported
OPTIONAL. Boolean value specifying whether the Client supports OPTIONAL. Boolean value specifying whether the client supports
Token Binding of Refresh Tokens. If omitted, the default value is Token Binding of refresh tokens. If omitted, the default value is
"false". "false".
5.2. Token Binding Authorization Server Metadata 5.2. Token Binding Authorization Server Metadata
Authorization Servers supporting Token Binding that also support Authorization servers supporting Token Binding that also support
OAuth 2.0 Authorization Server Metadata [OAuth.AuthorizationMetadata] OAuth 2.0 Authorization Server Metadata [OAuth.AuthorizationMetadata]
use these metadata values to register their support for Token Binding use these metadata values to declare their support for Token Binding
of Access Tokens and Refresh Tokens: of access tokens and refresh tokens:
as_access_token_token_binding_supported as_access_token_token_binding_supported
OPTIONAL. Boolean value specifying whether the Authorization OPTIONAL. Boolean value specifying whether the authorization
Server supports Token Binding of Access Tokens. If omitted, the server supports Token Binding of access tokens. If omitted, the
default value is "false". default value is "false".
as_refresh_token_token_binding_supported as_refresh_token_token_binding_supported
OPTIONAL. Boolean value specifying whether the Authorization OPTIONAL. Boolean value specifying whether the authorization
Server supports Token Binding of Refresh Tokens. If omitted, the server supports Token Binding of refresh tokens. If omitted, the
default value is "false". default value is "false".
5.3. Token Binding Protected Resource Metadata
Protected resources supporting Token Binding that also support the
OAuth 2.0 Protected Resource Metadata [OAuth.ResourceMetadata] use
this metadata value to declare their support for Token Binding of
access tokens:
resource_access_token_token_binding_supported
OPTIONAL. Boolean value specifying whether the protected resource
supports Token Binding of access tokens. If omitted, the default
value is "false".
6. Security Considerations 6. Security Considerations
If a refresh request is received by the authorization server If a refresh request is received by the authorization server
containing a "resource_tbh" (resource token binding hash) value containing a Referred Token Binding ID and the refresh token in the
requesting a token bound access token and the refresh token in the
request is not itself token bound, then it is not clear that token request is not itself token bound, then it is not clear that token
binding the access token adds significant value. This situation binding the access token adds significant value. This situation
should be considered an open issue for discussion by the working should be considered an open issue for discussion by the working
group. group.
7. IANA Considerations 7. IANA Considerations
7.1. OAuth Parameters Registration 7.1. OAuth Dynamic Client Registration Metadata Registration
This specification registers the following parameter in the IANA
"OAuth Parameters" registry [IANA.OAuth.Parameters] established by
RFC 6749 [RFC6749]:
7.1.1. Registry Contents
o Parameter name: "resource_tbh"
o Parameter usage location: Authorization Request, Token Request
o Change controller: IESG
o Specification document(s): Section 3 of this document
o Related information: None
7.2. OAuth Dynamic Client Registration Metadata Registration
This specification registers the following client metadata This specification registers the following client metadata
definitions in the IANA "OAuth Dynamic Client Registration Metadata" definitions in the IANA "OAuth Dynamic Client Registration Metadata"
registry [IANA.OAuth.Parameters] established by [RFC7591]: registry [IANA.OAuth.Parameters] established by [RFC7591]:
7.2.1. Registry Contents 7.1.1. Registry Contents
o Client Metadata Name: o Client Metadata Name:
"client_access_token_token_binding_supported" "client_access_token_token_binding_supported"
o Client Metadata Description: Boolean value specifying whether the o Client Metadata Description: Boolean value specifying whether the
Client supports Token Binding of Access Tokens client supports Token Binding of access tokens
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.1 of [[ this specification ]] o Specification Document(s): Section 5.1 of [[ this specification ]]
o Client Metadata Name: o Client Metadata Name:
"client_refresh_token_token_binding_supported" "client_refresh_token_token_binding_supported"
o Client Metadata Description: Boolean value specifying whether the o Client Metadata Description: Boolean value specifying whether the
Client supports Token Binding of Refresh Tokens client supports Token Binding of refresh tokens
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.1 of [[ this specification ]] o Specification Document(s): Section 5.1 of [[ this specification ]]
7.3. OAuth Authorization Server Discovery Metadata Registration 7.2. OAuth Authorization Server Metadata Registration
This specification registers the following discovery metadata This specification registers the following metadata definitions in
definitions in the IANA "OAuth Authorization Server Discovery the IANA "OAuth Authorization Server Metadata" registry established
Metadata" registry established by [OAuth.AuthorizationMetadata]: by [OAuth.AuthorizationMetadata]:
7.3.1. Registry Contents 7.2.1. Registry Contents
o Discovery Metadata Name: "as_access_token_token_binding_supported" o Metadata Name: "as_access_token_token_binding_supported"
o Discovery Metadata Description: Boolean value specifying whether o Metadata Description: Boolean value specifying whether the
the Authorization Server supports Token Binding of Access Tokens authorization server supports Token Binding of access tokens
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2 of [[ this specification ]] o Specification Document(s): Section 5.2 of [[ this specification ]]
o Discovery Metadata Name: o Metadata Name: "as_refresh_token_token_binding_supported"
"as_refresh_token_token_binding_supported" o Metadata Description: Boolean value specifying whether the
o Discovery Metadata Description: Boolean value specifying whether authorization server supports Token Binding of refresh tokens
the Authorization Server supports Token Binding of Refresh Tokens
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 5.2 of [[ this specification ]] o Specification Document(s): Section 5.2 of [[ this specification ]]
7.3. OAuth Protected Resource Metadata Registration
This specification registers the following client metadata definition
in the IANA "OAuth Protected Resource Metadata" registry
[IANA.OAuth.Parameters] established by [OAuth.ResourceMetadata]:
7.3.1. Registry Contents
o Resource Metadata Name:
"resource_access_token_token_binding_supported"
o Resource Metadata Description: Boolean value specifying whether
the protected resource supports Token Binding of access tokens
o Change Controller: IESG
o Specification Document(s): Section 5.3 of [[ this specification ]]
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-tokbind-https] [I-D.ietf-tokbind-https]
Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J. Popov, A., Nystrom, M., Balfanz, D., Langley, A., and J.
Hodges, "Token Binding over HTTP", draft-ietf-tokbind- Hodges, "Token Binding over HTTP", draft-ietf-tokbind-
https-06 (work in progress), August 2016. https-06 (work in progress), August 2016.
[I-D.ietf-tokbind-protocol] [I-D.ietf-tokbind-protocol]
skipping to change at page 9, line 43 skipping to change at page 10, line 9
2016. 2016.
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://tools.ietf.org/html/rfc7519>. <http://tools.ietf.org/html/rfc7519>.
[OAuth.AuthorizationMetadata]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", draft-ietf-oauth-
discovery-04 (work in progress), August 2016,
<http://tools.ietf.org/html/
draft-ietf-oauth-discovery-04>.
[OAuth.ResourceMetadata]
Jones, M. and P. Hunt, "OAuth 2.0 Protected Resource
Metadata", draft-jones-oauth-resource-metadata-00 (work in
progress), August 2016, <http://tools.ietf.org/html/
draft-jones-oauth-resource-metadata-00>.
[OpenID.TokenBinding] [OpenID.TokenBinding]
Jones, M., Bradley, J., and B. Campbell, "OpenID Connect Jones, M., Bradley, J., and B. Campbell, "OpenID Connect
Token Bound Authentication 1.0", July 2016, Token Bound Authentication 1.0", July 2016,
<http://openid.net/specs/ <http://openid.net/specs/
openid-connect-token-bound-authentication-1_0.html>. openid-connect-token-bound-authentication-1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <http://www.rfc-editor.org/info/rfc6749>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<http://www.rfc-editor.org/info/rfc7591>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<http://www.rfc-editor.org/info/rfc7662>. <http://www.rfc-editor.org/info/rfc7662>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- [RFC7800] 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,
<http://www.rfc-editor.org/info/rfc7800>. <http://www.rfc-editor.org/info/rfc7800>.
[SHS] National Institute of Standards and Technology, "Secure [SHS] National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4, March 2012, Hash Standard (SHS)", FIPS PUB 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
8.2. Informative References 8.2. Informative References
[OAuth.AuthorizationMetadata]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", draft-ietf-oauth-
discovery-02 (work in progress), August 2016,
<http://tools.ietf.org/html/
draft-ietf-oauth-discovery-04>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014, C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", (JWT) Profile for OAuth 2.0 Client Authentication and
RFC 7591, DOI 10.17487/RFC7591, July 2015, Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
<http://www.rfc-editor.org/info/rfc7591>. 2015, <http://www.rfc-editor.org/info/rfc7523>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to thank the following people for their The authors would like to thank the following people for their
contributions to the specification: Dirk Balfanz, William Denniss, contributions to the specification: Dirk Balfanz, William Denniss,
Andrei Popov, and Nat Sakimura. Andrei Popov, and Nat Sakimura.
Appendix B. Open Issues Appendix B. Open Issues
o Some token binding implementations apparently provide APIs that o What should we do in the case that a refresh request for a token
enable native applications to provide Referred Token Bindings, bound access token is received when the refresh token used in the
just as the federation support in the HTTPS Token Binding spec request is not token bound?
does. Can we count on these APIs being supported on all
platforms, and if so, does this enable us to somehow do without
the "resource_tbh" parameter by mandating that the client send
both a Provided and a Referred Token Binding to the authorization
server? If this isn't the case, is "resource_tbh" actually secure
or does this open a cross-channel validation hole? This area
probably needs more attention from both the Token Binding and
OAuth working groups.
o How should we support crypto agility for the hash function?
Appendix C. Document History Appendix C. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-01
o Changed Token Binding for access tokens to use the Referred Token
Binding ID, now that the Implementation Considerations in the
Token Binding HTTPS specification make it clear that
implementations will enable using the Referred Token Binding ID.
o Defined Protected Resource Metadata value.
o Changed to use the more specific term "protected resource" instead
of "resource server".
-00 -00
o Created the initial working group version from draft-jones-oauth- o Created the initial working group version from draft-jones-oauth-
token-binding-00. token-binding-00.
Authors' Addresses Authors' Addresses
Michael B. Jones Michael B. Jones
Microsoft Microsoft
 End of changes. 54 change blocks. 
171 lines changed or deleted 196 lines changed or added

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