]> Bespoke Engineering

ietf@justin.richer.org

Ping Identity

bcampbell@pingidentity.com

Beyond Identity

dean@thesax.es

Security Web Authorization Protocol security trust Sometimes you want to get a token that's tied to a public key but you can't prove possession of that public key. That's when you need to trust me, bruh. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The JWT confirmation claim "cnf" allows an RS to determine PoP semantics for a token. However, methods like mTLS and DPoP assume that the requester of that token can prove possession of the key that is bound to the token. Sometimes that's just too hard, and so here we define a claim to allow a requester to ask for a token that is bound to a key that the requester cannot, does not want to, or does not feel like proving possession of at the time of request.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Token Meta-key Binding Claim The token meta-key binding "tmb" claim is passed in an OAuth token request parameter of the same name. Its value is the form-encoded value that the requester wants the confirmation claim to be in the issued token. If the requester is making a DPoP or mTLS request, any keys there MUST be ignored. The same parameter can be used in a token exchange request, with the same results. If the issued token is a JWT, the value of the "tmb" claim is copied to the "cnf" claim of the resulting token. If the token is introspected, the value of "tmb" is returned in the "cnf" claim of the introspection response. The requester SHOULD give the resulting token to the holder of the key represented in the "tmb" claim. The presenter of the token MUST prove possession of the key in the resulting "cnf" claim using the appropriate key validation method for the type of token.

Security Considerations The security of this specification is entirely based on trust. If you have trust issues, it's not going to be secure.

IANA Considerations This document registers the "tmb" claim to the IANA JWT Claims registry and OAuth request parameter.

Normative References This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.