OAuth Proof of Possession Tokens with HTTP Message Signatures
draft-richer-oauth-httpsig-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Justin Richer , Aaron Parecki , Paul Bastian , Filip Skokan , Christian Bormann | ||
| Last updated | 2026-07-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-richer-oauth-httpsig-03
OAUTH J. Richer, Ed.
Internet-Draft MongoDB
Intended status: Standards Track A. Parecki
Expires: 29 January 2027 Okta
P. Bastian
Bundesdruckerei
F. Skokan
Okta
C. Bormann
SPRIND
28 July 2026
OAuth Proof of Possession Tokens with HTTP Message Signatures
draft-richer-oauth-httpsig-03
Abstract
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
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Web Authorization
Protocol Working Group mailing list (oauth@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/oauth/.
Source for this draft and an issue tracker can be found at
https://github.com/jricher/draft-richer-oauth-httpsig.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Richer, et al. Expires 29 January 2027 [Page 1]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
This Internet-Draft will expire on 29 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requesting an HTTP Message Signature Bound Access Token . . . 4
2.1. Pre-Registration of Keys . . . . . . . . . . . . . . . . 4
2.1.1. Example Client Registration . . . . . . . . . . . . . 5
2.2. Token Request Key Introduction . . . . . . . . . . . . . 5
2.3. Token Request . . . . . . . . . . . . . . . . . . . . . . 5
3. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 8
3.1. Pre-Registered Keys . . . . . . . . . . . . . . . . . . . 8
3.2. Runtime-Introduced Keys . . . . . . . . . . . . . . . . . 8
4. Embedding a Public Key Value . . . . . . . . . . . . . . . . 9
4.1. ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ed25519 . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. ML-DSA . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. HTTP Signature Key Confirmation Method . . . . . . . . . . . 10
6. Issuing an HTTP Message Signature Bound Access Token . . . . 10
6.1. Encoding Confirmation in a JWT . . . . . . . . . . . . . 12
6.2. Returning Confirmation in Token Introspection . . . . . . 12
7. Presenting an HTTP Message Signature Bound Access Token . . . 13
8. Validating an HTTP Message Signature Bound Resource
Request . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Document History . . . . . . . . . . . . . . . . . . 20
Appendix B. Potential Other Work . . . . . . . . . . . . . . . . 22
Richer, et al. Expires 29 January 2027 [Page 2]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
B.1. Client Authentication . . . . . . . . . . . . . . . . . . 22
B.2. AS Responses . . . . . . . . . . . . . . . . . . . . . . 22
B.3. Non-Repudiation of Requests . . . . . . . . . . . . . . . 22
B.4. PAR Key Introduction . . . . . . . . . . . . . . . . . . 22
B.5. Accept-Signature Support . . . . . . . . . . . . . . . . 22
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. 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.
[HTTPSIG] 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 [HTTPSIG] presentation, and a
method for presenting bound access tokens in HTTP requests using
[HTTPSIG].
This work complements and builds on experience with [DPOP] and
[MTLS], as well as implementations of
[I-D.ietf-oauth-signed-http-request], 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 ]]
1.1. 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 [RFC2119] [RFC8174] 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
Richer, et al. Expires 29 January 2027 [Page 3]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
indicate line wrapping for long values, as per [RFC8792]. The \
character and leading spaces on wrapped lines are not part of the
value.
2. 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 [OAUTH]
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 Section 10 when using
Dynamic Client Registration ([DYNREG]) or Client ID Metadata Document
([I-D.ietf-oauth-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. ]]
2.1. Pre-Registration of Keys
A client pre-registering its key for [HTTPSIG] 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 Section 11.
The client selects which of its registered keys the token is bound to
when it makes the token request, as described in Section 2.3. 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.
Richer, et al. Expires 29 January 2027 [Page 4]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
Note that pre-registration can occur statically or dynamically (such
as by using [DYNREG]), as long as the key is associated with the
client's client_id before the token request is made.
2.1.1. Example Client Registration
A client can publish its key binding metadata as part of a
[I-D.ietf-oauth-client-id-metadata-document] 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:
{
"client_id": "https://client.example.com/client-metadata.json",
"client_name": "Example Client",
"jwks": {
"keys": [
{
"kty": "OKP",
"use": "sig",
"crv": "Ed25519",
"kid": "j-0Ny45NWmqGq6GQ",
"x": "iuemcj_GhRHmY_yCsMlDNp3BQgPZDdG00VRsg_BgU3s",
"alg": "Ed25519"
}
]
},
"httpsig_key_binding_method": "preregistered"
}
2.2. 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 [DPOP].
A client using this method presents its public key in the token
request itself, as described in Section 2.3. The key is not
registered with the AS beforehand, and the AS binds a token to the
presented key subject to its own policy.
2.3. 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.
Richer, et al. Expires 29 January 2027 [Page 5]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
Additionally, the client MUST calculate and include the digest of the
request body and include it as the Content-Digest header defined in
[DIGEST].
For example, a form-encoded request body consisting of:
NOTE: '\' line wrapping per RFC 8792
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA\
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Would create the following Content-Digest header:
NOTE: '\' line wrapping per RFC 8792
Content-Digest: sha-256=:4fEzRVTGqfZg7lqf/d3oxXu837pvb3L0GN24+F\
1VkZk=:
A client using this method MUST sign the token endpoint request using
[HTTPSIG] 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.
Richer, et al. Expires 29 January 2027 [Page 6]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
With a pre-registered key as in Section 2.1:
* 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 Section 3.1.
With a runtime-introduced key as in Section 2.2:
* alg MUST be included, with a value from the "HTTP Signature
Algorithms" registry as described in Section 3.2.
* pub MUST be included, carrying the public key as described in
Section 4.
* 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:
NOTE: '\' line wrapping per RFC 8792
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
Content-Digest: sha-256=:4fEzRVTGqfZg7lqf/d3oxXu837pvb3L0GN24+F\
1VkZk=:
Signature-Input: sig1=("@method" "@target-uri" "content-digest" \
"authorization");created=1618884473;keyid="j-0Ny45NWmqGq6GQ"\
;nonce="b3k2pp5k7z-50gnX1b06";tag="httpsig-oauth-token-request"
Signature: sig1=:blPeRn3D3nkYqc1RNzCzge9E0n/Guf9yA1BBOeMFOOeSwuDdrVN\
cc5KSUKSOabdVHXVExQT0v6J+e3QDc3zzBA==:
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_u\
ri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
An example token request introducing the same key at runtime can look
like the following:
Richer, et al. Expires 29 January 2027 [Page 7]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
NOTE: '\' line wrapping per RFC 8792
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
Content-Digest: sha-256=:4fEzRVTGqfZg7lqf/d3oxXu837pvb3L0GN24+F\
1VkZk=:
Signature-Input: sig1=("@method" "@target-uri" "content-digest" \
"authorization");created=1618884473;alg="ed25519"\
;nonce="b3k2pp5k7z-50gnX1b06";tag="httpsig-oauth-token-request"\
;pub=:iuemcj/GhRHmY/yCsMlDNp3BQgPZDdG00VRsg/BgU3s=:
Signature: sig1=:W1jjnCpI59MI13gajmWP9DViwQHXhQdQ8r8q+h+Drp2JbJyu/md\
QrMMkGuiMvkWWY/noYbi9L4cW/lTOZigsCQ==:
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_u\
ri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
3. 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.
3.1. Pre-Registered Keys
A pre-registered key is a JSON Web Key [JWK] whose alg value names an
algorithm from the "JSON Web Signature and Encryption Algorithms"
registry established by [JWA]. Signatures made with such a key use
the JOSE signing algorithms of Section 3.3.7 of [HTTPSIG], 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 [RFC9864] is used in its place.
3.2. 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 Section 6.2 of [HTTPSIG], as required by
Section 3.3 of [HTTPSIG]. The algorithm MUST be an asymmetric
signature algorithm for which this document defines a public key
encoding in Section 4.
Richer, et al. Expires 29 January 2027 [Page 8]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
[[ 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? ]]
4. Embedding a Public Key Value
When encoding a public key value in a runtime request as in
Section 2.2, 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 [STRUCTURED].
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.
4.1. 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 [SEC1] 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.
4.2. 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 Section 5.1.5 of [RFC8032].
The key value is exactly 32 octets in length.
4.3. 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 [FIPS204], which is the output of the pkEncode
routine, Algorithm 22 of [FIPS204].
Richer, et al. Expires 29 January 2027 [Page 9]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
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 [HTTPSIG]
are being defined in separate work. We should add a reference here
once that document is available. ]]
5. HTTP Signature Key Confirmation Method
A key introduced at runtime as in Section 2.2 is not a JSON Web Key
and has no JWK representation, so the confirmation methods of
[POPKEY] 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 Section 4 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.
{
"alg": "ed25519",
"pub": "iuemcj_GhRHmY_yCsMlDNp3BQgPZDdG00VRsg_BgU3s"
}
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 Section 6.
6. Issuing an HTTP Message Signature Bound Access Token
The AS MUST validate the signature of the token request sent in
Section 2.3 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 Section 2.1, the key named in
keyid cannot be found or is not associated with the requesting
client
Richer, et al. Expires 29 January 2027 [Page 10]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* With a pre-registered key as in Section 2.1, the alg or pub
signature parameter is present, or the JWK's alg value is not a
fully specified asymmetric algorithm as required by Section 3.1
* With a runtime-introduced key as in Section 2.2, the keyid
signature parameter is present, or the alg or pub signature
parameter is absent
* With a runtime-introduced key as in Section 2.2, the alg value is
not an asymmetric algorithm for which this document defines a
public key encoding in Section 4, 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 Section 7.
An HTTP Message Signature bound access token MUST have a token_type
value of httpsig.
HTTP 200 OK
Content-Type: application/json
{
"access_token": "2340897.34j123-134uh2345n",
"token_type": "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 Section 3.2 of [POPKEY], and names its
algorithm in the JWK's alg value as in Section 3.1
Richer, et al. Expires 29 January 2027 [Page 11]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* A runtime-introduced key is carried in the HTTP Signature Key
(htsk) member defined in Section 5, and names its algorithm in
that object's alg member as in Section 3.2
6.1. Encoding Confirmation in a JWT
A token bound to a pre-registered key can look like the following:
{
"iss": "https://server.example.com",
"aud": "https://resource.example.com",
"cnf": {
"jwk": {
"kty": "OKP",
"crv": "Ed25519",
"alg": "Ed25519",
"x": "iuemcj_GhRHmY_yCsMlDNp3BQgPZDdG00VRsg_BgU3s"
}
}
}
A token bound to a runtime-introduced key can look like the
following:
{
"iss": "https://server.example.com",
"aud": "https://resource.example.com",
"cnf": {
"htsk": {
"alg": "ed25519",
"pub": "iuemcj_GhRHmY_yCsMlDNp3BQgPZDdG00VRsg_BgU3s"
}
}
}
A confirmation MUST carry exactly one of these members.
6.2. 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. ]]
Richer, et al. Expires 29 January 2027 [Page 12]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
7. 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.
Authorization: HTTPSig 2340897.34j123-134uh2345n
Note that HTTP authorization schemes defined in [HTTPAUTH] are case-
insensitive, and so all the following are equivalent:
Authorization: HTTPSig 2340897.34j123-134uh2345n
Authorization: httpsig 2340897.34j123-134uh2345n
Authorization: HTTPSIG 2340897.34j123-134uh2345n
Authorization: Httpsig 2340897.34j123-134uh2345n
Authorization: hTtPsIg 2340897.34j123-134uh2345n
When presenting an HTTP Message Signature bound access token to an
RS, the client MUST include a signature compliant with [HTTPSIG].
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 [DIGEST] 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
Richer, et al. Expires 29 January 2027 [Page 13]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* 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:
NOTE: '\' line wrapping per RFC 8792
GET /foo HTTP/1.1
Host: example.com
Date: Mon, 20 Apr 2026 02:07:55 GMT
Authorization: HTTPSig 2340897.34j123-134uh2345n
Signature-Input: sig1=("@method" "@target-uri" "authorization")\
;created=1776650875;nonce="k9Jyxempel2305Nmx7Rk"\
;tag="httpsig-oauth"
Signature: sig1=:uvIxaaJED8BxpYUL6cBd1v5uy24SptQnVQ35oKxWflg8GumiH77\
60va6P2qWxadrLodjGmIFna3bS70KxYv7CQ==:
8. 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 Section 3.3.7 of [HTTPSIG]
* 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"
Richer, et al. Expires 29 January 2027 [Page 14]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* The covered components and signature parameters include all items
enumerated in Section 7, 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 Section 6, are required rather than optional.
Section 3.2.1 of [HTTPSIG] allows an application to impose
requirements beyond those of [HTTPSIG], 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 [DIGEST], 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:
NOTE: '\' line wrapping per RFC 8792
GET /foo HTTP/1.1
Host: example.com
Date: Mon, 20 Apr 2026 02:07:55 GMT
Authorization: HTTPSig 2340897.34j123-134uh2345n
Signature-Input: sig1=("@method" "@target-uri" "authorization")\
;created=1776650875;nonce="k9Jyxempel2305Nmx7Rk"\
;tag="httpsig-oauth"
Signature: sig1=:iIwwgqVdmaneSVYJaLAMCf9yz8SnvNfUPZgeyWdkEjsO3+29XB0\
OLVBsR0w9Q+uw04yOVV1JeogdVvpyBhw3ZA==:
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:
Richer, et al. Expires 29 January 2027 [Page 15]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
{
"cnf": {
"jwk": {
"kty": "EC",
"crv": "P-256",
"alg": "ES256",
"x": "R4YT13Ra4frLCH75BdM53OEHYi_YY2eQgR43BWWQpVw",
"y": "UFVFPBGODokYW06OXCqDskhZSU3RpUI6fR8_OCz2doo"
}
}
}
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:
{
"cnf": {
"htsk": {
"alg": "ecdsa-p256-sha256",
"pub": "BEeGE9d0WuH6ywh--QXTOdzhB2Iv2GNnkIEeNwVlkKVcUF\
VFPBGODokYW06OXCqDskhZSU3RpUI6fR8_OCz2doo"
}
}
}
The signature base is the same in either case:
NOTE: '\' line wrapping per RFC 8792
"@method": GET
"@target-uri": https://example.com/foo
"authorization": HTTPSig 2340897.34j123-134uh2345n
"@signature-params": ("@method" "@target-uri" "authorization")\
;created=1776650875;nonce="k9Jyxempel2305Nmx7Rk"\
;tag="httpsig-oauth"
The RS then calculates the signature validation against the signature
base using the key using the algorithm appropriate HTTP_VERIFY
function, per [HTTPSIG].
9. Acknowledgements
Richer, et al. Expires 29 January 2027 [Page 16]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
10. IANA Considerations
[[ TBD: register the httpsig token type, the
httpsig_key_binding_method client registration metadata parameter,
the pub signature parameter defined in Section 4 in the "HTTP
Signature Metadata Parameters" registry established by [HTTPSIG], and
the HTTP Signature Key (htsk) confirmation method in the "JWT
Confirmation Methods" registry. The jwk confirmation method is
already registered by [POPKEY], and cnf is already a registered token
introspection response parameter. ]]
11. Security Considerations
[[ TBD. ]]
* All requests have to be over TLS or equivalent as per [BCP195].
* 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 Section 7.3.3 of [HTTPSIG].
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 ([DYNREG]).
12. 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.
13. References
13.1. Normative References
Richer, et al. Expires 29 January 2027 [Page 17]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[DIGEST] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/rfc/rfc9530>.
[DPOP] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.
[DYNREG] 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,
<https://www.rfc-editor.org/rfc/rfc7591>.
[FIPS204] National Institute of Standards and Technology (NIST),
"Module-Lattice-Based Digital Signature Standard",
NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.204.pdf>.
[HTTPAUTH] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/rfc/rfc7235>.
[HTTPSIG] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/rfc/rfc7518>.
Richer, et al. Expires 29 January 2027 [Page 18]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/rfc/rfc7517>.
[MTLS] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/rfc/rfc8705>.
[OAUTH] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[PAR] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
RFC 9126, DOI 10.17487/RFC9126, September 2021,
<https://www.rfc-editor.org/rfc/rfc9126>.
[POPKEY] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/rfc/rfc7800>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/rfc/rfc8792>.
[RFC9864] Jones, M.B. and O. Steele, "Fully-Specified Algorithms for
JSON Object Signing and Encryption (JOSE) and CBOR Object
Signing and Encryption (COSE)", RFC 9864,
DOI 10.17487/RFC9864, October 2025,
<https://www.rfc-editor.org/rfc/rfc9864>.
Richer, et al. Expires 29 January 2027 [Page 19]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Standards for Efficient Cryptography, Version 2.0, May
2009, <https://www.secg.org/sec1-v2.pdf>.
[STRUCTURED]
Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/rfc/rfc9651>.
13.2. Informative References
[I-D.ietf-oauth-client-id-metadata-document]
Parecki, A. and E. Smith, "OAuth Client ID Metadata
Document", Work in Progress, Internet-Draft, draft-ietf-
oauth-client-id-metadata-document-02, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
client-id-metadata-document-02>.
[I-D.ietf-oauth-signed-http-request]
Richer, J., Bradley, J., and H. Tschofenig, "A Method for
Signing HTTP Requests for OAuth", Work in Progress,
Internet-Draft, draft-ietf-oauth-signed-http-request-03, 8
August 2016, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-signed-http-request-03>.
[SIGNED-INTROSPECTION]
Lodderstedt, T., Ed. and V. Dzhuvinov, "JSON Web Token
(JWT) Response for OAuth Token Introspection", RFC 9701,
DOI 10.17487/RFC9701, January 2025,
<https://www.rfc-editor.org/rfc/rfc9701>.
Appendix A. 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
Richer, et al. Expires 29 January 2027 [Page 20]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
- 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.
Richer, et al. Expires 29 January 2027 [Page 21]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
Appendix B. Potential Other Work
[HTTPSIG] 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, [HTTPSIG]
could be used in other places in the OAuth ecosystem and this
appendix exists to capture some of those ideas.
B.1. Client Authentication
Similarly to [MTLS], [HTTPSIG] 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
[HTTPSIG] 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.
B.2. AS Responses
Since [HTTPSIG] 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
[SIGNED-INTROSPECTION] could be replaced with this method in many use
cases.
B.3. Non-Repudiation of Requests
Since [HTTPSIG] 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.
B.4. PAR Key Introduction
Keys for this purpose could be introduced during a [PAR] request
phase, as part of the call to the PAR endpoint.
B.5. Accept-Signature Support
The Accept-Signature mechanism in [HTTPSIG] allows for runtime
discovery of not only the applicability of signatures but also the
expected coverage, for particular uses.
Richer, et al. Expires 29 January 2027 [Page 22]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
Appendix C. Test Vectors
[[ Editor's note: we really should have end-to-end test vectors with
keys and stuff all in here, not just inline. ]]
Authors' Addresses
Justin Richer (editor)
MongoDB
Email: ietf@justin.richer.org
Aaron Parecki
Okta
Email: aaron@parecki.com
Paul Bastian
Bundesdruckerei
Email: paul.bastian@posteo.de
Filip Skokan
Okta
Email: panva.ip@gmail.com
Christian Bormann
SPRIND
Email: chris.bormann@gmx.de
Richer, et al. Expires 29 January 2027 [Page 23]