]> MongoDB

ietf@justin.richer.org

Okta

aaron@parecki.com

Bundesdruckerei

paul.bastian@posteo.de

Okta

panva.ip@gmail.com

SPRIND

chris.bormann@gmx.de

Security OAUTH Internet-Draft This extension to the OAuth 2.0 authorization framework defines a method for using HTTP Message Signatures to bind access tokens to keys held by OAuth 2.0 clients. Discussion Venues Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The OAuth 2.0 framework provides methods for clients to get delegated access tokens from an authorization server for accessing protected resources. OAuth access tokens can be bearer tokens, or bound to a variety of mechanisms including mutual TLS, DPoP, or other presentation mechanisms. Bearer tokens are simple to implement but also have the significant security downside of allowing anyone who sees the access token to use that token. defines a generic mechanism that is used to sign HTTP requests and responses. This specification defines means to bind access tokens to a key held by the client, a token type value, a token response for indicating that a token is meant to be used with presentation, and a method for presenting bound access tokens in HTTP requests using . This work complements and builds on experience with and , as well as implementations of , a spiritual predecessor to this specification and other forms of OAuth proof-of-possession work. [[ Editor's note: we want to give developers clear guidance on when to use HTTPSig vs. DPoP vs. mTLS vs. Bearer vs. whatever else ]]

Terminology 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. This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and other elements. Some examples use a single trailing backslash '' to indicate line wrapping for long values, as per . The \ character and leading spaces on wrapped lines are not part of the value.

Requesting an HTTP Message Signature Bound Access Token To bind an access token to a key, the AS needs to know which key to bind to which token. This specification defines two common methods depending on the needs of the client:

• A static method that depends on key material available as part of the client registration
• A runtime method that allows a client to introduce key material during the token request phase of

As part of its registration, a client MUST indicate which method it will use, using either the httpsig_key_binding_method client registration metadata parameter defined in when using Dynamic Client Registration () or Client ID Metadata Document (), or via an out of band method. [[ Editor's note: do we want to add an AS/RS metadata parameter to signal support for each type? ]] [[ Editor's note: Are there any other patterns of key introduction we should cover? I put PAR in the appendix as a note. ]]

Pre-Registration of Keys A client pre-registering its key for binding MUST include the key in its registered jwks value or make it available from its jwks_uri endpoint. The JWK MUST have a kid member and MUST indicate a signing algorithm in its alg member. The key MUST be an asymmetric key, and the registered JWK MUST be its public key. A shared secret MUST NOT be used to bind an access token, as described in . The client selects which of its registered keys the token is bound to when it makes the token request, as described in . The client's metadata names the key set rather than a key within it, allowing a client to add and retire keys without any change to its registration. Note that pre-registration can occur statically or dynamically (such as by using ), as long as the key is associated with the client's client_id before the token request is made.

Example Client Registration A client can publish its key binding metadata as part of a alongside its jwks or jwks_uri values. For example, a client with the client_id value https://client.example.com/client-metadata.json would publish the following document at that URL, indicating that it uses a pre-registered key:

Token Request Key Introduction Instead of pre-registering a key, a client can introduce its key during the token request in a similar fashion as . A client using this method presents its public key in the token request itself, as described in . The key is not registered with the AS beforehand, and the AS binds a token to the presented key subject to its own policy.

Token Request The presence of an HTTP Message Signature with the tag httpsig-oauth-token-request indicates that the client is requesting a bound token. The client MUST include a message signature of the indicated key. Additionally, the client MUST calculate and include the digest of the request body and include it as the Content-Digest header defined in . For example, a form-encoded request body consisting of: Would create the following Content-Digest header: A client using this method MUST sign the token endpoint request using with the appropriate key. The covered components MUST include:

• @method the HTTP method of the request
• @target-uri the full request URI of the request (note that this includes the scheme, authority, path, and query)
• content-digest the digest of the request body

The covered components MUST include the client's authentication, if available. If using HTTP Basic, this means including the authorization field. The signature MUST include the following signature parameters:

• created a timestamp for signature creation; this MUST be within a small number of seconds of issuance (e.g. 30 seconds to account for clock skew)
• nonce a random unique value that the AS can use to prevent signature replay within the small validity time window
• tag a string indicating that this is being used for requesting a bound token, MUST be the value "httpsig-oauth-token-request"

The remaining signature parameters identify the key, and depend on the key binding method. With a pre-registered key as in :

• keyid MUST be included. Its value MUST match the kid member of a key in the client's registered jwks value or at its jwks_uri endpoint.
• alg and pub MUST NOT be included. The algorithm comes from the identified key, as described in .

With a runtime-introduced key as in :

• alg MUST be included, with a value from the "HTTP Signature Algorithms" registry as described in .
• pub MUST be included, carrying the public key as described in .
• keyid MUST NOT be included, as the key is presented in full.

An example token request using a pre-registered key can look like the following: An example token request introducing the same key at runtime can look like the following:

Signature Algorithms The two key binding methods name signature algorithms in different registries. A key bound by one method is never used with the other, and this document neither defines nor relies on any correspondence between the two registries.

Pre-Registered Keys A pre-registered key is a JSON Web Key whose alg value names an algorithm from the "JSON Web Signature and Encryption Algorithms" registry established by . Signatures made with such a key use the JOSE signing algorithms of , which take the algorithm from the key material. The alg signature parameter is not used with those algorithms, and the client MUST NOT include it. The JWK's alg value MUST be fully specified. A polymorphic identifier such as EdDSA, which names a different signature algorithm depending on the key it is used with, MUST NOT be used. The fully specified equivalent defined in is used in its place.

Runtime-Introduced Keys A runtime-introduced key names its algorithm in the alg signature parameter, using a value from the "HTTP Signature Algorithms" registry established by , as required by . The algorithm MUST be an asymmetric signature algorithm for which this document defines a public key encoding in . [[ Editor's note: we keep the two paths apart on purpose. Bridging them would mean asserting that some JWS algorithm and some "HTTP Signature Algorithms" entry are the same algorithm, and the two registries are maintained independently with nothing requiring either to track the other. Are we happy to pay a second code path at the RS to avoid that? ]]

Embedding a Public Key Value When encoding a public key value in a runtime request as in , the client includes the public key material in the pub signature parameter attached to the signature input, encoded as a Byte Sequence as defined in . The contents of the pub signature parameter are the public key material appropriate to the signature algorithm indicated by the alg signature parameter, as defined in the following sections.

ECDSA If the alg value is ecdsa-p256-sha256 or ecdsa-p384-sha384, the pub signature parameter contains the uncompressed point representation of the public key, which is the single octet 0x04 followed by the big-endian, zero-padded, fixed-length encodings of the key's X and Y coordinates. This is the output of the Elliptic-Curve-Point-to-Octet-String Conversion in Section 2.3.3 of with point compression off. For ecdsa-p256-sha256, the X and Y values are exactly 32 octets each and the pub value is exactly 65 octets. For ecdsa-p384-sha384, the X and Y values are exactly 48 octets each and the pub value is exactly 97 octets.

Ed25519 If the alg value is ed25519, the pub signature parameter contains the Ed25519 public key A, which is the encoding of the point [s]B as specified in . The key value is exactly 32 octets in length.

ML-DSA If the alg value indicates an ML-DSA algorithm, the pub signature parameter contains the ML-DSA public key encoded as described in Section 7.2 of , which is the output of the pkEncode routine, Algorithm 22 of . The value is exactly 1312 octets for the ML-DSA-44 parameter set, 1952 octets for ML-DSA-65, and 2592 octets for ML-DSA-87. [[ Editor's note: ML-DSA algorithm identifiers for use with are being defined in separate work. We should add a reference here once that document is available. ]]

HTTP Signature Key Confirmation Method A key introduced at runtime as in is not a JSON Web Key and has no JWK representation, so the confirmation methods of cannot carry it. This document defines the HTTP Signature Key confirmation method for that purpose, using the member name htsk. The value of the htsk member is a JSON object with two members:

• alg: the algorithm identifier from the "HTTP Signature Algorithms" registry, as a string
• pub: the base64url encoding, without padding, of the pub octets defined in for that algorithm

Both members MUST be present. A recipient MUST reject the confirmation if it does not recognize the alg value or if the pub value is not a well-formed public key for that algorithm. The htsk member is used in the cnf claim of a JWT and in the cnf member of a token introspection response, as described in .

Issuing an HTTP Message Signature Bound Access Token The AS MUST validate the signature of the token request sent in against the identified key and the algorithm associated with that key. The request MUST fail with an error if any of the following occur:

• With a pre-registered key as in , the key named in keyid cannot be found or is not associated with the requesting client
• With a pre-registered key as in , the alg or pub signature parameter is present, or the JWK's alg value is not a fully specified asymmetric algorithm as required by
• With a runtime-introduced key as in , the keyid signature parameter is present, or the alg or pub signature parameter is absent
• With a runtime-introduced key as in , the alg value is not an asymmetric algorithm for which this document defines a public key encoding in , or the pub value is not a well-formed public key for it
• There is more than one signature with the tag "httpsig-oauth-token-request"
• The created value of the signature is too far in the past
• The nonce value is used more than once within the validity window of the signature

When issuing an access token bound to a key using HTTP Message Signatures, the AS associates the granted token with the key used in the requesting signature. All presentations of this token at any RS MUST contain an HTTP message signature as described in . An HTTP Message Signature bound access token MUST have a token_type value of httpsig. The client MUST associate this returned access token with the key used to make the requst. The confirmation carries the key the token is bound to, allowing an RS to validate a presented signature without reference to the client's registration. The member carrying the key depends on the key binding method and indicates which algorithm registry applies:

• A pre-registered key is carried in the jwk member of the cnf claim, as defined in , and names its algorithm in the JWK's alg value as in
• A runtime-introduced key is carried in the HTTP Signature Key (htsk) member defined in , and names its algorithm in that object's alg member as in

Encoding Confirmation in a JWT A token bound to a pre-registered key can look like the following: A token bound to a runtime-introduced key can look like the following: A confirmation MUST carry exactly one of these members.

Returning Confirmation in Token Introspection The same cnf member is returned in a token introspection response. [[ Editor's note: we need to register htsk in the "JWT Confirmation Methods" registry. Nothing further is needed for introspection, since cnf is already a registered token introspection response parameter and carries the same structure. ]]

Presenting an HTTP Message Signature Bound Access Token HTTP Message Signature bound access token MUST be presented in an HTTP Authorization field using the HTTPSig authorization scheme. Note that HTTP authorization schemes defined in are case-insensitive, and so all the following are equivalent: When presenting an HTTP Message Signature bound access token to an RS, the client MUST include a signature compliant with . The covered components MUST include:

• @method the HTTP method of the request
• @target-uri the full request URI of the request (note that this includes the scheme, authority, path, and query)
• authorization the access token value being presented

The RS MAY require additional components to be covered by the signature, and the client MUST include any additional fields or components of the HTTP request that are relevant to the security of the RS. For example, if the API being served by the RS declares that incoming content type makes a material difference, the RS SHOULD require signing of the Content-Type header in addition to the above. The request MAY include multiple signatures to serve different needs. If the request includes an entity body (such as a POST, PUT, or QUERY), the client SHOULD calculate the digest as per and also sign the digest header (such as Content-Digest). The signature MUST include the following signature parameters:

• created a timestamp for signature creation; this MUST be within a small number of seconds of issuance (e.g. 30 seconds to account for clock skew)
• nonce a random unique value that the AS can use to prevent signature replay within the small validity time window
• tag a string indicating that this is being used for requesting a bound token, MUST be the value "httpsig-oauth"

The client MUST NOT include the alg, keyid, or pub signature parameters, as the RS determines the key from the binding of the presented access token. For example, the following signed request includes a signature with the needed signature parameters:

Validating an HTTP Message Signature Bound Resource Request In order for a request protected by an HTTP Message Signature bound access token to be considered valid, the RS MUST perform the following checks:

• The presented signature validates using the key the token is bound to
• For a jwk confirmation, the signature validates under the HTTP_VERIFY application of the JWS algorithm named by the JWK's alg member, applied as described in
• For an htsk confirmation, the signature validates under the HTTP_VERIFY primitive of the named "HTTP Signature Algorithms" entry
• The created value is not too far in the past (e.g. 30 seconds to account for clock skew and network delays)
• The nonce value has not been previously used within the time validity window of this request
• The tag value is "httpsig-oauth"
• The covered components and signature parameters include all items enumerated in , including the Authorization header field
• The alg, keyid, and pub signature parameters are not present

The check on the alg, keyid, and pub signature parameters, and the corresponding checks in , are required rather than optional. allows an application to impose requirements beyond those of , but requires that it enforce them during verification and fail any signature that does not conform. If the request includes an entity body (such as a POST, PUT, or QUERY) and a digest as per , the RS MUST validate the digest. If the request includes multiple signatures tagged "httpsig-oauth", all signatures MUST be validated. For example, to validate the request: Nothing in the request identifies the key, so the RS determines the key and the algorithm from the token's confirmation method (in this example, assume the RS introspects the token to get it). The same request validates under either binding method, and only the confirmation differs. If the token was issued for a pre-registered key, the confirmation carries the JWK and the algorithm is the JWS algorithm named by its alg member: If the token was issued for a key introduced at runtime, the confirmation carries the same key as an htsk member, and the algorithm is the "HTTP Signature Algorithms" value named by its alg member: The signature base is the same in either case: The RS then calculates the signature validation against the signature base using the key using the algorithm appropriate HTTP_VERIFY function, per .

Acknowledgements

IANA Considerations [[ TBD: register the httpsig token type, the httpsig_key_binding_method client registration metadata parameter, the pub signature parameter defined in in the "HTTP Signature Metadata Parameters" registry established by , and the HTTP Signature Key (htsk) confirmation method in the "JWT Confirmation Methods" registry. The jwk confirmation method is already registered by , and cnf is already a registered token introspection response parameter. ]]

Security Considerations [[ TBD. ]]

• All requests have to be over TLS or equivalent as per .
• Leakage of a private key alongside a token allows for re-presentation of that token.
• Insufficient coverage of a message allows a signature to be attached to a different message.
• Failure to check derived attributes allows a signature to be replayed.
• Signatures could be replayed outside of their vailidty window if not checked.
• An access token cannot be bound to a shared secret. Every party that validates a presented signature needs the key that produced it, and a verifier holding symmetric key material can produce a valid signature of its own as per . Binding a token to a shared secret would allow every RS that accepts it to produce requests indistinguishable from the client's. The client's registered jwks and jwks_uri values carry public keys only ().

Privacy Considerations [[ TBD. ]]

• Re-use of a public-key for tokens at multiple RS's can allow tracking of a client/user combination based on the key identity.

References Normative References This document formally deprecates Transport Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346). Accordingly, those documents have been moved to Historic status. These versions lack support for current and recommended cryptographic algorithms and mechanisms, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLS version 1.2 became the recommended version for IETF protocols in 2008 (subsequently being obsoleted by TLS version 1.3 in 2018), providing sufficient time to transition away from older versions. Removing support for older versions from implementations reduces the attack surface, reduces opportunity for misconfiguration, and streamlines library and product maintenance. This document also deprecates Datagram TLS (DTLS) version 1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1. This document updates many RFCs that normatively refer to TLS version 1.0 or TLS version 1.1, as described herein. This document also updates the best practices for TLS usage in RFC 7525; hence, it is part of BCP 195. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. 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 document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. 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 defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. 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. This specification refers to cryptographic algorithm identifiers that fully specify the cryptographic operations to be performed, including any curve, key derivation function (KDF), and hash functions, as being "fully specified". It refers to cryptographic algorithm identifiers that require additional information beyond the algorithm identifier to determine the cryptographic operations to be performed as being "polymorphic". This specification creates fully-specified algorithm identifiers for registered JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) polymorphic algorithm identifiers, enabling applications to use only fully-specified algorithm identifiers. It deprecates those polymorphic algorithm identifiers. This specification updates RFCs 7518, 8037, and 9053. It deprecates polymorphic algorithms defined by RFCs 8037 and 9053 and provides fully-specified replacements for them. It adds to the instructions to designated experts in RFCs 7518 and 9053. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. National Institute of Standards and Technology (NIST) Certicom Research Standards for Efficient Cryptography, Version 2.0 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. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. Informative References Ping Identity ARM Limited This document a method for offering data origin authentication and integrity protection of HTTP requests. To convey the relevant data items in the request a JSON-based encapsulation is used and the JSON Web Signature (JWS) technique is re-used. JWS offers integrity protection using symmetric as well as asymmetric cryptography. Okta This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata, enabling the authorization server to fetch the metadata about the client as needed. This specification proposes an additional response secured by JSON Web Token (JWT) for OAuth 2.0 Token Introspection.

Document History

• -03
  • Added co-authors
  • Changed inline key presentation from a header field carrying a JWK to a single pub signature parameter carrying the raw public key
  • Limited the inline key representation to ECDSA, Ed25519, and ML-DSA
  • Required the alg signature parameter for runtime key introduction
  • Removed keyid from runtime key introduction and from token presentation
  • Required the bound key to be asymmetric, disallowing shared secrets
  • Kept each binding method within a single algorithm registry, with no correspondence defined between the two
  • Required pre-registered JWK algorithm identifiers to be fully specified
  • Defined the jwk confirmation method for pre-registered keys and a new HTTP Signature Key (htsk) confirmation method for runtime-introduced keys
  • Removed the httpsig_bound_access_token_kid client metadata field in favor of selecting a pre-registered key with the keyid signature parameter
• -02
  • Editorial fixes
  • Added example of client registration metadata parameter in CIMD
• -01
  • Added key binding semantics
  • Updated references
  • Updated presentation requirements
  • Added appendix for potential future work
  • Added some basic security and privacy considerations, to be expanded upon group discussion
• -00
  • Initial individual draft.

Potential Other Work provides a generic mechanism for signing arbitrary HTTP messages, both requests and responses. While this specification is focused solely on OAuth access token issuance and usage, could be used in other places in the OAuth ecosystem and this appendix exists to capture some of those ideas.

Client Authentication Similarly to , could be used as a generic client authentication mechanism for the client calling the AS for any authenticated call, including token PAR, the token endpoint. Since allows for multiple signatures with different signature parameters (including tag), this could be layered on top of even the runtime token request key binding, allowing a client to use one key for authentication and another for token use.

AS Responses Since can be used to sign responses, an AS could sign its responses from backend endpoints (including the token endpoint, revocation endpoint, discovery endpoint, introspection endpoint, etc) with an issuer-based key, providing a layer of protection in addition to the TLS transport. Signed response mechanisms like could be replaced with this method in many use cases.

Non-Repudiation of Requests Since allows a signed response to contain elements of the request that triggered the response, an AS or RS could use this mechanism to provide non-repudiation of a response to bind it to a particular request parameter set.

PAR Key Introduction Keys for this purpose could be introduced during a request phase, as part of the call to the PAR endpoint.

Accept-Signature Support The Accept-Signature mechanism in allows for runtime discovery of not only the applicability of signatures but also the expected coverage, for particular uses.

Test Vectors [[ Editor's note: we really should have end-to-end test vectors with keys and stuff all in here, not just inline. ]]