Skip to main content

12. IANA Considerations

12.1. OAuth Access Token Types Registration​

IANA has registered the following access token type in the "OAuth Access Token Types" registry [IANA.OAuth.Params] established by [RFC6749].

  • Name: DPoP
  • Additional Token Endpoint Response Parameters: (none)
  • HTTP Authentication Scheme(s): DPoP
  • Change Controller: IETF
  • Reference: RFC 9449

12.2. OAuth Extensions Error Registration​

IANA has registered the following error values in the "OAuth Extensions Error" registry [IANA.OAuth.Params] established by [RFC6749].

Invalid DPoP proof:

  • Name: invalid_dpop_proof
  • Usage Location: token error response, resource access error response
  • Protocol Extension: Demonstrating Proof of Possession (DPoP)
  • Change Controller: IETF
  • Reference: RFC 9449

Use DPoP nonce:

  • Name: use_dpop_nonce
  • Usage Location: token error response, resource access error response
  • Protocol Extension: Demonstrating Proof of Possession (DPoP)
  • Change Controller: IETF
  • Reference: RFC 9449

12.3. OAuth Parameters Registration​

IANA has registered the following authorization request parameter in the "OAuth Parameters" registry [IANA.OAuth.Params] established by [RFC6749].

  • Name: dpop_jkt
  • Parameter Usage Location: authorization request
  • Change Controller: IETF
  • Reference: Section 10 of RFC 9449

12.4. HTTP Authentication Schemes Registration​

IANA has registered the following scheme in the "HTTP Authentication Schemes" registry [IANA.HTTP.AuthSchemes] established by [RFC9110], Section 16.4.1.

  • Authentication Scheme Name: DPoP
  • Reference: Section 7.1 of RFC 9449

12.5. Media Type Registration​

IANA has registered the application/dpop+jwt media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in [RFC6838], which is used to indicate that the content is a DPoP JWT.

  • Type name: application
  • Subtype name: dpop+jwt
  • Required parameters: n/a
  • Optional parameters: n/a
  • Encoding considerations: binary. A DPoP JWT is a JWT; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters.
  • Security considerations: See Section 11 of RFC 9449
  • Interoperability considerations: n/a
  • Published specification: RFC 9449
  • Applications that use this media type: Applications using RFC 9449 for application-level proof of possession
  • Fragment identifier considerations: n/a
  • Additional information:
    • File extension(s): n/a
    • Macintosh file type code(s): n/a
  • Person & email address to contact for further information: Michael B. Jones, [email protected]
  • Intended usage: COMMON
  • Restrictions on usage: none
  • Author: Michael B. Jones, [email protected]
  • Change controller: IETF

12.6. JWT Confirmation Methods Registration​

IANA has registered the following JWT cnf member value in the "JWT Confirmation Methods" registry [IANA.JWT] established by [RFC7800].

  • Confirmation Method Value: jkt
  • Confirmation Method Description: JWK SHA-256 Thumbprint
  • Change Controller: IETF
  • Reference: Section 6 of RFC 9449

12.7. JSON Web Token Claims Registration​

IANA has registered the following Claims in the "JSON Web Token Claims" registry [IANA.JWT] established by [RFC7519].

HTTP method:

  • Claim Name: htm
  • Claim Description: The HTTP method of the request
  • Change Controller: IETF
  • Reference: Section 4.2 of RFC 9449

HTTP URI:

  • Claim Name: htu
  • Claim Description: The HTTP URI of the request (without query and fragment parts)
  • Change Controller: IETF
  • Reference: Section 4.2 of RFC 9449

Access token hash:

  • Claim Name: ath
  • Claim Description: The base64url-encoded SHA-256 hash of the ASCII encoding of the associated access token's value
  • Change Controller: IETF
  • Reference: Section 4.2 of RFC 9449

12.7.1. "nonce" Registration Update​

The Internet Security Glossary [RFC4949] provides a useful definition of nonce as a random or non-repeating value that is included in data exchanged by a protocol, usually for the purpose of guaranteeing liveness and thus detecting and protecting against replay attacks.

However, the initial registration of the nonce claim by [OpenID.Core] used language that was contextually specific to that application, which was potentially limiting to its general applicability.

Therefore, IANA has updated the entry for nonce in the "JSON Web Token Claims" registry [IANA.JWT] with an expanded definition to reflect that the claim can be used appropriately in other contexts and with the addition of this document as a reference, as follows.

  • Claim Name: nonce
  • Claim Description: Value used to associate a Client session with an ID Token (MAY also be used for nonce values in other applications of JWTs)
  • Change Controller: OpenID Foundation Artifact Binding Working Group, [email protected]
  • Specification Document(s): Section 2 of [OpenID.Core] and RFC 9449

12.8. Hypertext Transfer Protocol (HTTP) Field Name Registration​

IANA has registered the following HTTP header fields, as specified by this document, in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" [IANA.HTTP.Fields] established by [RFC9110]:

DPoP:

  • Field Name: DPoP
  • Status: permanent
  • Reference: RFC 9449

DPoP-Nonce:

  • Field Name: DPoP-Nonce
  • Status: permanent
  • Reference: RFC 9449

12.9. OAuth Authorization Server Metadata Registration​

IANA has registered the following value in the "OAuth Authorization Server Metadata" registry [IANA.OAuth.Params] established by [RFC8414].

  • Metadata Name: dpop_signing_alg_values_supported
  • Metadata Description: JSON array containing a list of the JWS algorithms supported for DPoP proof JWTs
  • Change Controller: IETF
  • Reference: Section 5.1 of RFC 9449

12.10. OAuth Dynamic Client Registration Metadata​

IANA has registered the following value in the IANA "OAuth Dynamic Client Registration Metadata" registry [IANA.OAuth.Params] established by [RFC7591].

  • Client Metadata Name: dpop_bound_access_tokens
  • Client Metadata Description: Boolean value specifying whether the client always uses DPoP for token requests
  • Change Controller: IETF
  • Reference: Section 5.2 of RFC 9449
Last updated on