OAuth Proof of Possession Tokens with HTTP Message Signatures
draft-richer-oauth-httpsig-02
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 | ||
| Last updated | 2026-07-02 | ||
| 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-02
OAUTH J. Richer, Ed.
Internet-Draft MongoDB
Intended status: Standards Track A. Parecki
Expires: 2 January 2027 Okta
1 July 2026
OAuth Proof of Possession Tokens with HTTP Message Signatures
draft-richer-oauth-httpsig-02
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."
This Internet-Draft will expire on 2 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Richer & Parecki Expires 2 January 2027 [Page 1]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requesting an HTTP Message Signature Bound Access Token . . . 3
2.1. Pre-Registration of Keys . . . . . . . . . . . . . . . . 4
2.1.1. Example Client Registration . . . . . . . . . . . . . 4
2.2. Token Request Key Introduction . . . . . . . . . . . . . 5
2.3. Token Request . . . . . . . . . . . . . . . . . . . . . . 6
3. Issuing an HTTP Message Signature Bound Access Token . . . . 8
3.1. Encoding Confirmation in a JWT . . . . . . . . . . . . . 9
3.2. Returning Confirmation in Token Introspection . . . . . . 9
4. Presenting an HTTP Message Signature Bound Access Token . . . 9
5. Validating an HTTP Message Signature Bound Access Token
Request . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Document History . . . . . . . . . . . . . . . . . . 15
Appendix B. Potential Other Work . . . . . . . . . . . . . . . . 16
B.1. Client Authentication . . . . . . . . . . . . . . . . . . 16
B.2. AS Responses . . . . . . . . . . . . . . . . . . . . . . 16
B.3. Non-Repudiation of Requests . . . . . . . . . . . . . . . 16
B.4. PAR Key Introduction . . . . . . . . . . . . . . . . . . 16
B.5. Accept-Signature Support . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
The OAuth 2.0 framework provides methods for clients to get delegated
access tokens from an authorization server for accessing protected
resources.
Richer & Parecki Expires 2 January 2027 [Page 2]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
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
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
Richer & Parecki Expires 2 January 2027 [Page 3]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* 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 (TBD) in Section 7 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 keys 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 field and MUST indicate a
signing algorithm in its alg field. The key ID for the public key
used for HTTP Message Signature bound access tokens MUST be
identified using the httpsig_bound_access_token_kid field in the
client's metadata.
[[ Editor's note: do we want to have a client field for the signing
alg or just leave that to the key all the time? I prefer to keep it
in the key. ]]
A pre-registered key MAY be a shared secret (such as for use in an
HMAC signature), but public key cryptography is RECOMMENDED.
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 the key binding parameters 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:
Richer & Parecki Expires 2 January 2027 [Page 4]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
{
"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": "EdDSA"
}
]
},
"httpsig_bound_access_token_kid": "j-0Ny45NWmqGq6GQ",
"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 the same fashion as [DPOP].
The client MUST present its public key in the Signature-Key header
field. The field is an HTTP Structured Field consisting of a Binary
value containing the bytes of the [JSON] serialized [JWK] form of the
key material.
The JWK MUST have a kid field. The key MUST be a public key (and
neither a private key nor a shared secret key). The JWK MUST have an
alg value that indicates a signature algorithm.
For example, the following JWK public key:
{
"kty": "OKP",
"use": "sig",
"crv": "Ed25519",
"kid": "j-0Ny45NWmqGq6GQ",
"x": "iuemcj_GhRHmY_yCsMlDNp3BQgPZDdG00VRsg_BgU3s",
"alg": "EdDSA"
}
Can be encoded to the following Signature-Key field value (this
example uses a compact JSON serialization that removes whitespace):
Richer & Parecki Expires 2 January 2027 [Page 5]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
NOTE: '\' line wrapping per RFC 8792
Signature-Key: :eyJrdHkiOiJPS1AiLCJ1c2UiOiJzaWciLCJjcnYiOiJFZDI1NTE5I\
iwia2lkIjoiai0wTnk0NU5XbXFHcTZHNFV4TGpHak51bG9rdHVndE9XNGpmR0NDZ2Vm\
USIsIngiOiJpdWVtY2pfR2hSSG1ZX3lDc01sRE5wM0JRZ1BaRGRHMDBWUnNnX0JnVTN\
zIiwiYWxnIjoiRWREU0EifQ==:
[[ Editor's note: this is a really awkward way to encode a JWK. We
could try to break apart the JSON but there's not a 1:1 map to HTTP
Structured Fields we can rely on. We could just put the minified
JSON into a string but the double quotes would need to be escaped.
This is the least bad version I could come up with right now. ]]
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.
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:
Content-Digest: sha-256=:4fEzRVTGqfZg7lqf/d3oxXu837pvb3L0GN24+F1VkZk=:
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
If a signature key is presented at runtime as described in
Section 2.2, the covered components MUST include:
Richer & Parecki Expires 2 January 2027 [Page 6]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* signature-key the encoded public key used to sign this request
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 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"
* keyid the kid value for the key to be used for binding the token;
if client uses pre-registered keys as in Section 2.1, the value
MUST match the httpsig_bound_access_token_kid value; if the key is
presented at runtime as in Section 2.2, the value MUST match the
kid of the JWK in the Signature-Key field
The signature algorithm MUST be derived from the indicated key. The
alg signature parameter MUST NOT be used.
An example request to the token endpoint (using a runtime-provided
key here) can look like the following:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
Signature-Key: :eyJrdHkiOiJPS1AiLCJ1c2UiOiJzaWciLCJjcnYiOiJFZDI1NTE5I\
iwia2lkIjoiai0wTnk0NU5XbXFHcTZHNFV4TGpHak51bG9rdHVndE9XNGpmR0NDZ2Vm\
USIsIngiOiJpdWVtY2pfR2hSSG1ZX3lDc01sRE5wM0JRZ1BaRGRHMDBWUnNnX0JnVTN\
zIiwiYWxnIjoiRWREU0EifQ==:
Content-Digest: sha-256=:4fEzRVTGqfZg7lqf/d3oxXu837pvb3L0GN24+F1VkZk=:
Signature-Input: sig1=("@method" "@target-uri" "content-digest" \
"signature-key" "authorization");created=1618884473\
;keyid="j-0Ny45NWmqGq6G4UxLjGjNuloktugtOW4jfGCCgefQ"\
;nonce="b3k2pp5k7z-50gnX1b06";tag="httpsig-oauth-token-request"
Signature: sig1=:AWyxebrJ6u8CMi0B3TyX9G1G3XT45UW5zIn8mhsyXdmjTUtGS+1M\
XiydKv5z0GLCrMhVSFe691jF98DRNNSPAg==:
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&\
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
Richer & Parecki Expires 2 January 2027 [Page 7]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
3. 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:
* The key named in kid cannot be found or is not associated with the
requesting client
* 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 4.
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.
[[ Editor's note: we should define confirmation methods for access
tokens here, including JWT values and introspection response values
to allow the RS to verify the signature w/o the client's registration
information. Leaving the following sections as placeholders. ]]
Richer & Parecki Expires 2 January 2027 [Page 8]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
3.1. Encoding Confirmation in a JWT
3.2. Returning Confirmation in Token Introspection
4. 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 parameters:
Richer & Parecki Expires 2 January 2027 [Page 9]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* 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"
* keyid the kid value for the key used to sign the request
The client MUST NOT include an alg signature parameter.
For example, the following signed request includes a signature with
the needed 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;keyid="j-0Ny45NWmqGq6G4UxLjGjNuloktugtOW4jfGCCg\
efQ";nonce="k9Jyxempel2305Nmx7Rk";tag="httpsig-oauth"
Signature: sig1=:kFJC2WoBbrQc8tsKiowIb8oeIA533qmKvzdKf8kndJ7kaLxGmm2v\
9+IPB8kLE0WUea8KryJGSV7ji1apLkeKBg==:
5. Validating an HTTP Message Signature Bound Access Token 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 associated with
the token
* The signature validates using the algorithm associated with the
key
* 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 & Parecki Expires 2 January 2027 [Page 10]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
* The covered components and parameters include all items enumerated
in Section 4
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;keyid="j-0Ny45NWmqGq6G4UxLjGjNuloktugtOW4jfGCCg\
efQ";nonce="k9Jyxempel2305Nmx7Rk";tag="httpsig-oauth"
Signature: sig1=:kFJC2WoBbrQc8tsKiowIb8oeIA533qmKvzdKf8kndJ7kaLxGmm2v\
9+IPB8kLE0WUea8KryJGSV7ji1apLkeKBg==:
The RS determines the key bound to the token and validates the kid
value against that key. The RS determines the algorithm from the key
and performs signature validation per [HTTPSIG] on the
In this example, the client has a key with the kid value of test-key-
rsa-pss which uses the JWA alg value of PS512. The signature input
string is:
"@request-target": get /foo
"host": example.org
"authorization": HTTPSig 2340897.34j123-134uh2345n
"@signature-params": ("@request-target" "host" "authorization")\
;created=1618884475;keyid="test-key-rsa-pss"
This results in the following signed HTTP message, including the
access token.
Richer & Parecki Expires 2 January 2027 [Page 11]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
NOTE: '\' line wrapping per RFC 8792
GET /foo HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Authorization: HTTPSig 2340897.34j123-134uh2345n
Signature-Input: sig1=("@request-target" "host" "authorization")\
;created=1618884475;keyid="test-key-rsa-pss"
Signature: sig1=:o+Fy/a6IIWhHwnMFhsHqfXEpheWGBMOU3pheT50zA8rL5F8Nur\
xBKAPylMGBWYCKH5Bd+TB0Co6vqANlXyOCM9Zr5c/UmR5WGex5/OgJJmfN7gOVOH5\
pB2Zxa233xsohfwo9liBlctukN5//E3F04rKjIkoeTFJiS+hMcOzn29esgFSEl4Jy\
oO5Q8snMIsC56ZAPYwU7rJis1Wvl6Y9/9tpW6gIn/SHwArhPQSAb0zZy6mCiw654n\
CaKw5NYJ9S0DZlnV4T7nJtdZsHOkddF6kH4WVka3ev0xONI5kYkEdR1Gw0VAE9thi\
p+3/aFoUVTJ/1J6JfehZpXqehwv3KNoQ==:
An RS receiving such a signed message and a bound access token MUST
verify the HTTP Message Signature as described in [HTTPSIG]. The RS
MUST verify that all required portions of the HTTP request are
covered by the signature by examining the contents of the signature
parameters.
6. Acknowledgements
7. IANA Considerations
[[ TBD: register the token type and new parameters into their
appropriate registries, as well as the JWT and introspection
parameters needed for confirmation methods. ]]
8. 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.
Richer & Parecki Expires 2 January 2027 [Page 12]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
9. 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.
10. References
10.1. Normative References
[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>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
[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>.
Richer & Parecki Expires 2 January 2027 [Page 13]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
[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>.
[JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[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>.
[OAUTH-BEARER]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/rfc/rfc6750>.
[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>.
[RAR] Olson, A., Eggert, P., and K. Murchison, "The Time Zone
Information Format (TZif)", RFC 9636,
DOI 10.17487/RFC9636, October 2024,
<https://www.rfc-editor.org/rfc/rfc9636>.
[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>.
[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>.
Richer & Parecki Expires 2 January 2027 [Page 14]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
[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>.
[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>.
10.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-01, 1 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
client-id-metadata-document-01>.
[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
* -02
- Editorial fixes
- Added example of client registration metadata parameter in CIMD
* -01
- Added key binding semantics
- Updated references
- Updated presentation requirements
Richer & Parecki Expires 2 January 2027 [Page 15]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
- Added appendix for potential future work
- Added some basic security and privacy considerations, to be
expanded upon group discussion
* -00
- Initial individual draft.
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 usage
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.
Richer & Parecki Expires 2 January 2027 [Page 16]
Internet-Draft OAuth Proof of Possession Tokens with HT July 2026
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.
Authors' Addresses
Justin Richer (editor)
MongoDB
Email: ietf@justin.richer.org
Aaron Parecki
Okta
Email: aaron@parecki.com
Richer & Parecki Expires 2 January 2027 [Page 17]