OAuth Subject Signing Key Binding for Resource Servers

OAuth Subject Signing Key Binding for Resource Servers Huawei International Pte. Ltd.

chu.cheng.kang@huawei.com

Huawei International Pte. Ltd.

li.ruochen@h-partners.com

Huawei International Pte. Ltd.

wang.haiguang.shieldlab@huawei.com

Huawei International Pte. Ltd.

Li.Tieyan@huawei.com

Security Web Authorization Protocol Resource servers in OAuth deployments sometimes receive application-layer authorization evidence that is digitally signed by the subject represented by an access token. Verification of such evidence requires the resource server to obtain a trusted public signing key that is bound to that subject. This specification defines the subject_keys parameter, by which an OAuth authorization server conveys one or more subject public signing keys to a resource server. The parameter can be carried as a claim in a JWT access token or as a member of a token introspection response. The resulting key binding is scoped to the authorization server, token subject, resource server audience, and token validity context. This specification does not define a public-key enrollment protocol or the syntax and semantics of the application-layer authorization evidence. It also does not use the OAuth cnf claim, which identifies a proof-of-possession key held by the presenter of a token.

Introduction The OAuth 2.0 Authorization Framework enables a Client to obtain limited access to a protected resource. The Authorization Server establishes the authorization context and issues an Access Token, and the Resource Server makes an authorization decision based on that token and its local policy. Some deployments require the Resource Server to process an additional authorization artifact that is signed directly by the Subject represented by the Access Token. Examples include a signed transaction instruction, a signed delegation constraint, or another application-layer statement that restricts what the Client may do on the Subject's behalf. Such an artifact can express authorization semantics that are more specific than the permissions represented by the Access Token. A Resource Server can verify such an artifact only when it has a trusted binding between the Access Token subject and the public key corresponding to the signing private key. The OAuth authorization framework does not define a general-purpose mechanism by which an Authorization Server conveys this distinct subject-to-key binding to a Resource Server. Existing proof-of-possession mechanisms, such as DPoP , bind an Access Token to a key held by the Client presenting the token; they do not convey a separate key used by the Subject to sign application-layer authorization evidence. This specification defines a subject_keys parameter. Its value is a JSON Web Key Set (JWK Set) containing public signing keys that the Authorization Server has associated with the Subject identified by the token's sub value. The parameter can be conveyed in either of the following ways:

as a top-level claim in a JWT Access Token conforming to ; or
as a top-level member of a Token Introspection response conforming to .

The Authorization Server's protection of the JWT Access Token, or the authenticated and protected introspection exchange, provides integrity and authenticity for the Subject Key Binding. A separately signed certificate containing the same key binding is therefore not required by this specification. The subject_keys parameter does not grant access. Subject-Signed Authorization Evidence verified with a conveyed key can only further constrain the authority represented by the Access Token. It cannot expand that authority. This specification defines no new authorization request parameter, token request parameter, grant type, or Rich Authorization Requests authorization-details type. How a Subject registers or provisions a public key at the Authorization Server, and the syntax and semantics of Subject-Signed Authorization Evidence, are outside the scope of this specification. The mechanism defined by this specification extends the information associated with an OAuth Access Token. It does not define or depend on a particular authorization grant, response type, Client type, or authorization endpoint interaction. It can therefore be used by an OAuth deployment in which an Authorization Server issues an Access Token for a Subject and conveys token information to a Resource Server using a JWT Access Token or Token Introspection. This document replaces draft-chu-oauth-as-attested-user-cert. The previous document defined a mechanism for requesting an Authorization Server-attested user public-key certificate using Rich Authorization Requests. This document removes that certificate request model and instead defines an Authorization Server-protected binding between an OAuth Subject and one or more public signing keys conveyed to a Resource Server.

Conventions and 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. JSON member names and string values defined by this specification are case-sensitive. This specification uses the terms "Access Token", "Authorization Server", "Client", "Resource Owner", and "Resource Server" as defined by .

Subject: The Resource Owner or other authorization subject identified by the sub value associated with an Access Token. The sub value is interpreted within the namespace of the Authorization Server and the audience of the Access Token. It is not necessarily a global identifier or a representation of a civil identity.
Subject Signing Key: An asymmetric public key that the Authorization Server has associated with the Subject and approved for verification of Subject-Signed Authorization Evidence by an intended Resource Server.
Subject Key Binding: The assertion, protected by the Authorization Server, that a Subject Signing Key is associated with the Subject identified by an Access Token for the audience and validity context of that token.
Subject-Signed Authorization Evidence: An application-layer object that is digitally signed using the private key corresponding to a Subject Signing Key and that expresses authorization constraints used by the Resource Server. Its syntax and application-specific semantics are outside the scope of this specification.
Token Authority: The maximum authority represented by a validated Access Token, including its scopes, authorization details, audience, subject, Client binding, and any other authorization-relevant claims.
Evidence Authority: The maximum authority permitted by validated Subject-Signed Authorization Evidence under the applicable evidence profile.

Applicability and Scope

Applicability This specification is applicable when all of the following conditions hold:

an Authorization Server can establish a trusted binding between a Subject and a public signing key;
an Access Token identifies that Subject to an intended Resource Server;
the Resource Server receives Subject-Signed Authorization Evidence through an application-specific mechanism; and
the Resource Server needs the Subject Signing Key in order to verify that evidence.

This specification is not needed when the only required key is held by the Client presenting the Access Token. In that case, a proof-of-possession mechanism such as DPoP or mutual-TLS certificate-bound Access Tokens is appropriate. This specification does not establish the real-world identity of the Subject. The confidence that a Resource Server can place in a Subject Key Binding is limited by the Authorization Server's Subject authentication, key enrollment, account recovery, and key-management processes.

Scope This specification standardizes only the conveyance and processing of a Subject Key Binding between an Authorization Server and a Resource Server. This specification does not define:

how a Subject generates, stores, or protects a signing key;
a wire protocol for key enrollment, update, recovery, suspension, or revocation;
the syntax of Subject-Signed Authorization Evidence;
how a Client obtains Subject-Signed Authorization Evidence;
a new source of OAuth authority;
a replacement for Access Token validation;
a mechanism for Client authentication; or
a mechanism for sender-constraining an Access Token.

A specification or deployment profile that uses this specification MUST define the syntax and validation rules for its Subject-Signed Authorization Evidence, including the requirements in .

Protocol Overview A typical deployment consists of the following steps: | | | | | | | | (2) OAuth Token Request | | |----------------->| | | | (3) Access Token | | | |<-----------------| | | | | | | (4) Subject-Signed Authorization Evidence | |----------------->| | | | | | | | | (5) Access Token + Evidence | | |------------------------------------>| | | | | | | | (6) Introspection| | | |<-----------------| | | | subject_keys | | | |----------------->| | | | | | | | | (7) Validate, | | | | verify, and | | | | authorize]]>

The Subject and the Authorization Server establish a Subject Key Binding. The wire protocol for this step is out of scope, but the requirements in apply.
The Client requests an Access Token using an OAuth grant applicable to the deployment.
The Authorization Server issues an Access Token. It either includes subject_keys in a JWT Access Token or associates subject_keys with the Access Token for later return through Token Introspection.
The Subject provides Subject-Signed Authorization Evidence to the Client through an application-specific mechanism.
The Client presents the Access Token and the Subject-Signed Authorization Evidence to the Resource Server.
When the Subject Key Binding is not carried in the Access Token, the Resource Server obtains it through Token Introspection. A Resource Server MAY also introspect a JWT Access Token when fresher token or key-binding status is required.
The Resource Server validates the Access Token, obtains and validates subject_keys, verifies the Subject-Signed Authorization Evidence, and applies the authorization-composition rules in .

Steps 1 and 4 are shown only to explain the provenance and use of the key. This specification defines no messages for either step.

The subject_keys Parameter

Parameter Definition The subject_keys parameter conveys a Subject Key Binding. Its value MUST be a JWK Set as defined in . When an Authorization Server includes subject_keys in a JWT Access Token or an active Token Introspection response, it asserts all of the following within the context of that Access Token:

Each public key in the JWK Set is associated with the Subject identified by sub.
The Authorization Server permits the Resource Server identified by aud to use the key to verify Subject-Signed Authorization Evidence.
The binding is valid only within the validity context of the Access Token.
The Authorization Server selected the key from authenticated and integrity-protected state, rather than accepting it as an untrusted value supplied in the current resource request.

The assertion is scoped by the tuple consisting of the Authorization Server issuer, the sub value, the Access Token audience, and the Access Token validity period. A Resource Server MUST NOT interpret the binding as a universal statement that the key identifies the same Subject at another issuer, for another audience, or outside that validity period. The presence of subject_keys does not assert that:

the Subject has a particular civil, legal, or organizational identity;
the Client possesses the corresponding private key;
the Subject is currently present;
a particular item of Subject-Signed Authorization Evidence is fresh or non-replayed;
the key is suitable for authentication or signing in another protocol; or
the Subject-Signed Authorization Evidence grants authority beyond the Access Token.

The iss, sub, aud, and exp claim names are defined by . The subject_keys parameter MUST NOT be present unless the token information also contains all four values. When nbf or iat is present, it also constrains the validity context of the binding. An Authorization Server MUST NOT include subject_keys in an Access Token that represents only a Client unless the sub value unambiguously identifies the same entity to which the conveyed key is bound and a deployment profile explicitly defines that use. In ordinary Client Credentials Grant deployments, subject_keys MUST be omitted.

JWK Set Requirements The subject_keys JWK Set MUST contain at least one key. The JWK Set object and each JWK MUST NOT contain duplicate JSON member names. Each JWK in the set MUST satisfy all of the following requirements:

It MUST represent an asymmetric public key.
It MUST contain all public-key parameters required for local signature verification.
It MUST NOT contain a symmetric key or any private-key parameter.
It MUST contain a kid member. The kid value MUST be unique within the JWK Set.
The Authorization Server MUST NOT reassign a kid value to different key material within the same issuer, sub, and audience context.
The kid value SHOULD be the base64url-encoded SHA-256 JWK Thumbprint of the public key computed according to . When another identifier is used, the Authorization Server MUST ensure that it is collision resistant within its key-binding namespace.
If the use member is present, its value MUST be sig.
If the key_ops member is present, its value MUST be an array containing exactly the single value verify.
If the alg member is present, it MUST identify an asymmetric digital-signature algorithm registered in . The value none and algorithms based on a shared secret MUST NOT be used.
The x5u member MUST NOT be present. A Resource Server MUST NOT dereference any URI found in a JWK in order to obtain key material.

An Authorization Server SHOULD include only the key or keys needed by the intended Resource Server. It SHOULD NOT include every key associated with the Subject. Multiple keys are permitted to support controlled rotation or multiple evidence-signature algorithms, but excessive key sets increase token size, processing cost, and linkability. An Authorization Server SHOULD NOT include an x5c certificate chain. If x5c is included, the Resource Server MUST verify that the certificate public key is identical to the public key represented directly by the JWK. The Resource Server MUST NOT infer Subject identity, key purpose, or additional authority from the certificate unless a separate profile explicitly defines those semantics and its validation rules. The trust in a key conveyed by this specification derives from the Authorization Server's protection of the Subject Key Binding, not merely from possession of the public key or from metadata contained in the JWK.

Example Parameter Value The following is a non-normative example of a subject_keys value. The kid is the SHA-256 JWK Thumbprint of the illustrated public key.

Conveying Subject Keys

JWT Access Tokens When a Subject Key Binding is conveyed in a JWT Access Token, the Authorization Server MUST include subject_keys as a top-level claim in a JWT Access Token conforming to . The Resource Server MUST validate the JWT Access Token in accordance with , , and the security requirements applicable to its deployment before trusting subject_keys. In particular, it MUST validate the token type, signature, issuer, audience, and time-based claims using keys and algorithms configured for the Authorization Server. The following is a non-normative example of a decoded JWT Access Token claims set: When a JWT Access Token has more than one audience, the Authorization Server MUST NOT include a Subject Signing Key unless every audience receiving the token is authorized to receive the same Subject Key Binding. Authorization Servers SHOULD issue audience-restricted Access Tokens and SHOULD use Resource Indicators or an equivalent mechanism to identify the intended Resource Server.

Token Introspection When a Subject Key Binding is conveyed through Token Introspection, the Authorization Server MUST include subject_keys as a top-level member of an active introspection response as defined by . An introspection response containing subject_keys MUST also contain iss, sub, aud, and exp. The iss value MUST identify the Authorization Server responsible for the Access Token. The aud value MUST identify the Resource Server or Resource Servers for which the Access Token was issued. The Authorization Server MUST authenticate and authorize the introspection caller before returning subject_keys. It MUST NOT include subject_keys in a response where active is false. It MUST NOT disclose the Subject Key Binding to an introspection caller that is not authorized to receive token information for an intended audience of the Access Token. The following is a non-normative example: An Authorization Server and Resource Server MAY use a JWT-secured introspection response as defined by . Whether a plain JSON response protected by the requirements of or a JWT-secured response is used, the Resource Server MUST establish that the response came from the Authorization Server responsible for the Access Token.

Use of Multiple Conveyance Mechanisms An Authorization Server MAY convey subject_keys in a JWT Access Token, through Token Introspection, or through both mechanisms. When a Resource Server introspects a JWT Access Token for current status, the active introspection response is authoritative for that request. The Resource Server MUST NOT combine the subject_keys JWK Set from the JWT Access Token with a JWK Set returned by introspection. If the operation requires a Subject Key Binding and the active introspection response omits subject_keys, the Resource Server MUST treat no current Subject Key Binding as available, even if the JWT Access Token contains the claim. If both sources contain a key with the same kid but different cryptographic key material, the Resource Server MUST reject the request and SHOULD record a security event. Comparison MUST be based on the cryptographic key material, such as an RFC 7638 JWK Thumbprint, and not on JSON serialization or member order.

Confidentiality A signed but unencrypted JWT Access Token can expose subject_keys to the Client and to any party that obtains the token. When that disclosure is undesirable, the Authorization Server SHOULD use an opaque Access Token with protected Token Introspection, an encrypted JWT Access Token, or another deployment-specific confidentiality mechanism. The selected conveyance mechanism MUST preserve the integrity and the issuer, subject, audience, and validity semantics defined by this specification.

Authorization Server Processing

Establishing a Subject Key Binding The wire protocol by which a Subject Signing Key is enrolled or provisioned is out of scope. Before conveying a key under this specification, however, the Authorization Server MUST establish an authenticated binding between the key and the Subject. The binding process MUST satisfy the following requirements:

The Authorization Server MUST authenticate the Subject, or rely on an equivalent trusted administrative provisioning process, at an assurance level appropriate for the protected resource.
The Authorization Server MUST verify control of the private key corresponding to the enrolled public key, unless an equivalent trusted provisioning process has already established that control. Merely receiving a public key is not proof of private-key control.
A proof-of-control ceremony SHOULD use a fresh challenge bound to the Authorization Server, the authenticated Subject account, and the intended key purpose, so that a proof generated for another account or protocol cannot be replayed to establish the binding.
The Authorization Server MUST protect key enrollment, replacement, recovery, suspension, and revocation operations against unauthorized Clients, session compromise, and account-recovery abuse.
Possession of an ordinary Access Token or Refresh Token by a Client MUST NOT, by itself, authorize creation, replacement, or reactivation of a Subject Signing Key. A key-management operation requires separate authorization appropriate to its security impact.
The Authorization Server MUST maintain the lifecycle state of the binding, including whether the key is active, replaced, expired, suspended, or revoked.
The Authorization Server MUST associate the binding with the Resource Server audiences and key purposes for which disclosure and use are permitted.
The Authorization Server MUST apply its disclosure policy before releasing the key to a Resource Server and, where required by the deployment, obtain Subject consent for that disclosure.

An Authorization Server SHOULD support audience-specific or pairwise Subject Signing Keys. A key enrolled for one Resource Server SHOULD NOT be disclosed to another Resource Server unless the Subject and Authorization Server have authorized that reuse.

Selecting Keys for an Access Token When issuing or introspecting an Access Token, the Authorization Server MUST perform the following processing before including subject_keys:

Determine the Subject represented by the grant and the sub value that will be exposed to the intended Resource Server.
Determine the intended Resource Server audience.
Retrieve only active Subject Signing Keys bound to that Subject and authorized for that audience and intended use.
Confirm that each key satisfies .
Ensure that the Access Token expiration time does not exceed any internal expiration or authorization limit on the selected Subject Key Binding.
Construct subject_keys only from trusted Authorization Server state.

The Authorization Server MUST NOT copy a public key supplied by the Client in the current authorization request, token request, or resource request into subject_keys without independently establishing that key through the binding process described in . This specification defines no Client parameter for requesting a particular subject_keys value. Inclusion of the parameter is determined by Authorization Server policy, the intended Resource Server, the grant, and any applicable Subject authorization. A deployment MAY use scopes, Resource Indicators, Rich Authorization Requests, or other policy inputs to determine that a Resource Server requires a Subject Key Binding, but those inputs do not change the syntax or semantics of subject_keys. If no valid Subject Signing Key is available, the Authorization Server MUST omit subject_keys or fail Access Token issuance according to deployment policy. It MUST NOT emit an empty JWK Set or an unverified key.

Rotation, Revocation, and Freshness The Authorization Server MUST re-evaluate the Subject Key Binding whenever it issues a new Access Token or produces an active introspection response. The Authorization Server MUST stop including a revoked, suspended, or expired key in newly issued Access Tokens and active introspection responses. Revoking a key does not modify a previously issued self-contained JWT Access Token. Deployments requiring prompt revocation SHOULD use short-lived JWT Access Tokens, Token Introspection, or both. A Resource Server MAY introspect a JWT Access Token before a high-risk operation to obtain fresher status information. During controlled rotation, the Authorization Server MAY include both an old and a new public key for a limited overlap period. Each key MUST have a distinct kid. The overlap period SHOULD be no longer than required to process in-flight Subject-Signed Authorization Evidence and complete deployment migration. Whether evidence signed before key revocation or rotation remains acceptable is an application-specific decision. An evidence profile that permits such evidence MUST define how the Resource Server establishes the signing time and the key status applicable at that time.

Resource Server Processing

Access Token and Key-Binding Validation Before using subject_keys, the Resource Server MUST validate the Access Token using the rules applicable to its token format and deployment. Validation of a JWT Access Token MUST include the processing required by and . Validation of an opaque Access Token MUST use an authorized Token Introspection exchange or another method agreed with the Authorization Server. The Resource Server MUST perform at least the following checks:

Establish the Authorization Server responsible for the Access Token.
Verify that the Access Token is active, has not expired, and, when an nbf value is present, is not used before that time.
Verify that the Resource Server is an intended audience of the Access Token.
Verify that sub is present and interpret it only within the validated issuer and audience context. When the operation targets a Subject-specific resource, verify that sub is consistent with that resource.
Obtain subject_keys from the validated JWT Access Token or from an active introspection response.
Validate the JWK Set and each candidate JWK according to .
Apply local limits on the encoded size of subject_keys, the number of keys, accepted key types, and accepted algorithms.

If Resource Server policy requires a Subject Key Binding for an operation and no valid subject_keys value is available, the Resource Server MUST NOT perform that operation. The Resource Server MUST NOT accept a Subject Signing Key received from the Client, from the Subject-Signed Authorization Evidence itself, or from another untrusted application-layer field as a substitute for subject_keys. An evidence object MAY carry a kid or thumbprint for selection, but the selected public key MUST come from the Authorization Server-protected binding.

Key Selection and Signature Verification The applicable evidence profile MUST provide an integrity-protected key identifier or an otherwise unambiguous rule for selecting a Subject Signing Key. When subject_keys contains more than one key, the Resource Server MUST select exactly one key before verifying the evidence. It MUST NOT try every key until a signature succeeds unless the evidence profile explicitly defines that behavior and bounds its resource cost. The Resource Server MUST reject the evidence if:

the evidence identifies a kid that is absent from subject_keys;
more than one key matches the selection rule;
the selected key is not permitted by the evidence profile or local policy;
the evidence algorithm is not permitted by the evidence profile or local policy;
an alg value in the JWK is inconsistent with the evidence signature algorithm; or
signature verification fails.

A valid signature proves only that the evidence was produced using the private key corresponding to a Subject Signing Key. It does not, by itself, establish that the request is fresh, that the Client is an authorized delegate, or that the requested operation is authorized.

Subject-Signed Authorization Evidence Profile Requirements A specification or deployment profile using Subject-Signed Authorization Evidence MUST define all of the following:

the evidence syntax, media type or equivalent format identifier, and digital-signature structure;
the cryptographic algorithms and key types that Resource Servers accept;
how an integrity-protected key identifier selects a key from subject_keys;
how the evidence is restricted to an intended Resource Server, resource, or operation;
how the evidence identifies or is bound to the intended Client, delegate, or presenter when such a binding is required;
how the evidence is bound to the relevant request parameters or transaction data;
its issuance time, expiration, and acceptable clock skew;
nonce, unique identifier, or other replay-prevention requirements;
canonicalization and comparison rules for authorization values;
how Evidence Authority is derived from the evidence;
how unknown, omitted, duplicate, or conflicting fields are handled; and
the application error returned when evidence validation fails.

A profile MUST use fail-closed processing. An omitted or unrecognized authorization constraint MUST NOT be interpreted as granting additional authority unless the profile explicitly and unambiguously defines that interpretation.

Authorization Composition The Resource Server MUST determine the effective authority of a request by applying all applicable authorization constraints. At a minimum: The Resource Server MUST perform the requested operation only when the complete operation, including all security-relevant parameters, is permitted by each of these three inputs. Subject-Signed Authorization Evidence MUST NOT be treated as an independent grant that can add a scope, resource, action, amount, recipient, time period, delegation right, or other permission absent from the validated Token Authority. Likewise, the Access Token does not override a narrower constraint in valid Subject-Signed Authorization Evidence. When constraints are expressed using different vocabularies or data models, the Resource Server or an explicitly trusted policy component MUST perform a deterministic, fail-closed mapping. If the mapping is ambiguous, incomplete, or unsupported, the Resource Server MUST reject the operation.

Client and Presenter Binding The Subject Signing Key is distinct from a Client proof-of-possession key. If the Access Token is sender-constrained, the Resource Server MUST validate the applicable sender-constraining mechanism independently of the Subject-Signed Authorization Evidence. When the Subject-Signed Authorization Evidence identifies an intended Client, delegate, or presenter, the Resource Server MUST compare that identifier with the validated Access Token and request context. For example, a profile can require a value in the evidence to match client_id, an actor claim, or a proof-of-possession key thumbprint associated with the Access Token. The Resource Server MUST reject a request when a required Client or presenter binding does not match. Successful verification of the Subject's signature does not repair or replace a failed Client authentication or sender-constraining check.

Caching A Resource Server MAY cache public key material obtained through this specification, but it MUST NOT treat a cached key as a current Subject Key Binding for a new Access Token unless that new token independently conveys, or its introspection response independently returns, the same binding. A cached binding MUST be scoped at least by Authorization Server issuer, sub, audience, and kid. Its use MUST be bounded by the expiration of the Access Token or introspection result from which it was obtained and by any shorter local freshness limit. A Resource Server MUST NOT use a key cached for one issuer, Subject, or audience to verify evidence in another context merely because the kid or public key material is the same.

Relationship to Existing OAuth and JWT Parameters

The cnf Claim The cnf claim defined by identifies a proof-of-possession key held by the presenter of a JWT. In OAuth deployments, it is commonly used to sender-constrain an Access Token to the Client presenting that token. The subject_keys parameter has different semantics. It identifies a public signing key associated with the Subject for verification of a separate application-layer authorization artifact. The Client is not assumed to possess the corresponding private key. An Access Token MAY contain both cnf and subject_keys. A Resource Server MUST process each according to its own semantics and MUST NOT infer one binding from the other. The use of the same key for both purposes is NOT RECOMMENDED because it weakens key separation and can create cross-protocol confusion.

Rich Authorization Requests Rich Authorization Requests allow a Client to express fine-grained authorization requirements using the authorization_details parameter. Such authorization details describe requested or granted authorization. They are not a container for Subject public-key metadata. A deployment MAY use authorization_details to express Token Authority and MAY use subject_keys in the resulting Access Token or introspection response. The Resource Server MUST process the two independently and apply . The subject_keys parameter defined by this specification MUST NOT be nested in authorization_details; it is conveyed only as the top-level JWT claim or introspection response member defined in and .

The sub_jwk Claim The sub_jwk claim is registered in for the public key used to verify the signature of a particular form of ID Token. This specification does not change those semantics and does not repurpose sub_jwk for Access Tokens or Token Introspection responses.

Error Handling This specification defines no new OAuth error code. A malformed or invalid subject_keys value in a JWT Access Token makes the token unusable for an operation that relies on this specification. When the Bearer authentication scheme is used, the Resource Server SHOULD use the invalid_token error defined by if the token cannot be accepted. When an otherwise valid Access Token lacks a Subject Key Binding required by a particular resource operation, the Resource Server MAY use insufficient_scope as defined by when that error accurately describes the failure. Otherwise, it SHOULD use an application-specific error that does not incorrectly imply that the Access Token itself is malformed. Failure to validate Subject-Signed Authorization Evidence SHOULD be reported using an application-specific error defined by the evidence profile. Error responses SHOULD avoid revealing whether a particular Subject has an enrolled key or which keys are associated with that Subject, except when such disclosure is authorized and operationally necessary.

Security Considerations OAuth deployments implementing this specification MUST follow the security guidance in in addition to the requirements below.

Key Substitution During Enrollment The primary threat to a Subject Key Binding is substitution of an attacker's public key for the Subject's key. If an attacker can create or replace the binding, the attacker can produce evidence that appears to have been signed by the Subject. Authorization Servers MUST apply the authenticated binding and proof-of-control requirements in . Account recovery and key recovery are security-critical operations and MUST receive protections comparable to, or stronger than, initial enrollment. Implementations SHOULD notify the Subject when a Subject Signing Key is added, replaced, suspended, reactivated, or revoked.

Issuer, Subject, Audience, and Key-Identifier Confusion A Subject Signing Key is not identified by kid alone. Different Authorization Servers, Subjects, or audiences can legitimately use the same kid. A Resource Server MUST namespace a Subject Key Binding by the Authorization Server issuer, sub, audience, and kid. The Resource Server MUST validate that it is an intended audience of the Access Token before using subject_keys. Failure to validate the audience can disclose a key to an unintended Resource Server or allow evidence created for one service to be accepted by another. Subject identifiers can be pairwise, sector-specific, or otherwise audience-dependent. A Resource Server MUST NOT equate Subjects across issuers or audiences solely because the same public key or kid appears in multiple tokens.

Algorithm and JWK Validation A malicious or malformed JWK can trigger algorithm confusion, parser inconsistencies, remote retrieval, or excessive resource consumption. Resource Servers MUST enforce , maintain an explicit allowlist of acceptable signature algorithms and key types, and follow the JWT and JOSE validation guidance in where applicable. The algorithm declared by Subject-Signed Authorization Evidence is attacker-controlled input until the evidence is verified. A Resource Server MUST NOT accept an algorithm merely because it appears in the evidence or the JWK. The algorithm MUST also be permitted by the evidence profile and local policy. A Resource Server MUST NOT dereference x5u or another URI obtained from an untrusted key object. This avoids server-side request forgery and key substitution through attacker-controlled locations.

Stale and Revoked Keys A self-contained JWT Access Token can continue to carry a Subject Signing Key that was revoked after token issuance. The maximum stale-key window is therefore bounded by the Access Token lifetime unless the Resource Server performs Token Introspection or another current-status check. High-risk deployments SHOULD use short-lived Access Tokens and SHOULD introspect before irreversible or high-value operations. Authorization Servers SHOULD make revocation effective immediately in active introspection responses. A Resource Server that performs introspection MUST use the current introspection result as specified in and MUST NOT restore a revoked key by merging it from the JWT Access Token.

Replay of Subject-Signed Authorization Evidence A valid signature does not prevent replay. An attacker who obtains a valid Access Token and previously signed evidence might replay both unless the evidence is bound to a specific audience, request, operation, parameter set, nonce, unique identifier, or time window. Every evidence profile using this specification MUST define replay protections appropriate to its operation. Resource Servers MUST enforce those protections. Irreversible and high-value operations SHOULD use a fresh server-provided nonce or a cryptographic binding to the exact request.

Token Theft and Client Binding The Subject Key Binding does not sender-constrain the Access Token and does not authenticate the Client presenting it. Bearer-token theft remains possible when bearer Access Tokens are used. Deployments SHOULD use DPoP , mutual-TLS certificate-bound Access Tokens , or another sender-constraining mechanism where appropriate. When Subject-Signed Authorization Evidence identifies an intended Client, delegate, or proof-of-possession key, the Resource Server MUST compare that identity or key with the validated Access Token and request context. Otherwise, a different Client that obtains both artifacts might be able to replay them.

Authorization Inflation Subject-Signed Authorization Evidence can contain permissions or parameters that are broader than those in the Access Token. Accepting that evidence as an independent grant would allow it to inflate the Client's OAuth authority. Resource Servers MUST apply . Subject-Signed Authorization Evidence can narrow, but cannot enlarge, the Token Authority or bypass Resource Server policy.

Key Separation and Cross-Protocol Use Reusing one Subject key for account authentication, Subject-Signed Authorization Evidence, Client proof of possession, and unrelated protocols increases the impact of compromise and creates cross-protocol risks. Subjects and Authorization Servers SHOULD use a dedicated key for Subject-Signed Authorization Evidence. Evidence profiles SHOULD define a distinct media type, signature context, or domain-separation value so that a signature created for one protocol cannot be interpreted as valid evidence in another. A Resource Server MUST NOT use a Subject Signing Key for another purpose unless a separate specification explicitly authorizes that use.

Authorization Server Compromise The Resource Server trusts the Authorization Server to establish the correct Subject Key Binding. Compromise of the Authorization Server or its key-binding database can cause arbitrary keys to be associated with Subjects. This specification does not reduce that trust dependency. Authorization Servers SHOULD protect key-binding records with strong access controls, integrity protection, change monitoring, and recovery procedures. Resource Servers SHOULD monitor unexpected key changes for high-value Subjects or operations when deployment policy permits.

Resource Exhaustion Large JWK Sets and expensive signature algorithms can be used to consume Resource Server resources. Authorization Servers SHOULD limit the number and encoded size of keys in subject_keys. Resource Servers MUST enforce local size and key-count limits before performing cryptographic operations and SHOULD select a key by an integrity-protected identifier rather than attempting every key.

Privacy Considerations A stable public key is a correlatable identifier even when no account name is disclosed. Reusing the same Subject Signing Key at multiple Resource Servers can allow those Resource Servers, Clients, or token observers to correlate the Subject's activity. Authorization Servers SHOULD use audience-specific or pairwise Subject Signing Keys and SHOULD align them with pairwise sub values where possible. They SHOULD disclose only the key needed by the intended Resource Server and SHOULD avoid multi-audience Access Tokens carrying Subject Key Bindings. When subject_keys is included in a signed but unencrypted JWT Access Token, the Client can inspect the key and potentially correlate it with keys seen elsewhere. Deployments that do not want the Client to observe the key SHOULD use opaque Access Tokens with protected Token Introspection or another confidentiality-preserving mechanism. A Subject Key Binding should contain only public key material and the minimum metadata needed for verification. Authorization Servers SHOULD avoid embedding certificates or other structures containing names, email addresses, device identifiers, or unrelated personal data unless required by a separate deployment profile. Resource Servers and Authorization Servers SHOULD minimize logging of full public keys and Subject-Signed Authorization Evidence. When operationally sufficient, logs SHOULD record a scoped kid or JWK Thumbprint together with the issuer and audience rather than the complete key or evidence payload.

IANA Considerations

JSON Web Token Claims Registration This specification requests registration of the following claim in the "JSON Web Token Claims" registry maintained in :

Claim Name: subject_keys
Claim Description: JWK Set containing public signing keys associated by the issuer with the token subject for the token audience
Change Controller: IETF
Reference: of this specification

OAuth Token Introspection Response Registration This specification requests registration of the following member in the "OAuth Token Introspection Response" registry maintained in :

Name: subject_keys
Description: JWK Set containing public signing keys associated by the authorization server with the token subject for the token audience
Change Controller: IETF
Reference: of this specification

Normative References JSON Web Signature and Encryption Algorithms IANA JSON Web Token Claims IANA OAuth Parameters IANA Informative References

Document History -00

Replaces draft-chu-oauth-as-attested-user-cert.
Retitled and reframed the specification as "OAuth Subject Signing Key Binding for Resource Servers".
Replaced the Authorization Server-attested user-certificate request model with an Authorization Server-protected Subject Key Binding conveyed in a JWT Access Token or Token Introspection response.
Removed the Rich Authorization Requests authorization-details type and the requirement for a separately signed public-key certificate.
Removed dependencies on a particular authorization grant, response type, Client type, and application-layer evidence format.
Defined the subject_keys parameter as a JWK Set and distinguished Subject Signing Keys from Client proof-of-possession keys represented by cnf.
Defined issuer, subject, audience, validity, key-enrollment, rotation, revocation, caching, Resource Server processing, and authorization-composition requirements.
Clarified that Subject-Signed Authorization Evidence can only narrow, and cannot expand, the authority represented by an Access Token.
Added detailed security, privacy, error-handling, and IANA considerations.