OAuth 2.0 Policy-Based Anonymous Access Tokens

Introduction OAuth 2.0 enables a client to obtain limited access to a protected resource. The authorization server (AS) makes an authorization decision and issues an access token. The client presents the access token to a resource server (RS), commonly using the bearer-token mechanism defined in . This model is widely deployed, but two common design choices create an undesirable trade-off in some environments:

The client obtains an independently redeemable token for each action or short group of actions. This provides fine-grained control. Batched issuance can reduce the number of AS round trips, but the issuance communication and issuer work remain linear in the number of tokens. A policy or public-context change requires another issuance interaction.
The client obtains a reusable token, commonly called an anonymous credential in cryptographic protocols, covering many actions. This reduces AS interaction, but increases the authority and lifetime of a single credential and can make action-level quotas difficult to enforce without an additional online authorization service.

The trade-off is especially visible for automated agents. An agent can be authorized to perform a bounded task containing many calls, potentially across administrative domains. The principal may want the agent to perform up to a specified number of actions during a policy epoch without giving the agent an unrestricted bearer token or requiring the AS to approve every individual call. Related agent-authorization requirements are discussed in . Policy-based anonymous tokens (PBATs), introduced in and extended in , provide a useful cryptographic building block for this problem. A token issuer issues one pre-token to an eligible client. The client then locally derives one token for each tag allowed by a public policy. For a fixed pre-token and tag, token derivation is deterministic, which allows the verifier to reject reuse while preventing the client from creating more independent tokens than the policy admits. Issuance and redemption are unlinkable even when the issuer and verifier collude, subject to the limitations described in this document. This document specifies the version 1 OAuth protocol profile for that primitive. It makes the following contributions:

It defines the OAuth roles and authorization semantics for policy-based anonymous access tokens.
It defines a stable ciphersuite interface and registry so that the OAuth protocol does not depend on one cryptographic construction.
It defines issuance, local derivation, presentation, and validation phases.
It defines requirements for policies, tags, public metadata, replay detection, privacy, and key management.
It defines the counter-window policy profile, the PBAT HTTP authentication scheme, conformance requirements, and required IANA registrations.

Discussion of this document takes place on the OAuth Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. The term anonymous in this document has a narrow meaning: a successfully redeemed token cannot be linked to its issuance transcript, except through information deliberately placed in the policy, public metadata, or external network and application signals. It does not mean that the client is anonymous to the AS during the OAuth authorization process, nor that the RS is unable to observe the request it serves.

Conventions and Requirements Language 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.

Terminology This document uses the OAuth terms authorization server, client, resource owner, resource server, access token, and grant as defined by .

Policy-Based Authorization Credential (PBAC):: A credential issued by the AS after an OAuth authorization decision. A PBAC is not presented directly to an RS. It enables the client to derive policy-based anonymous access tokens.
Policy-Based Anonymous Access Token (PBAT):: A token locally derived from a PBAC for one policy-admitted tag. A PBAT is presented to an RS. Within a policy epoch, the same PBAC and tag produce the same logical token.
Issuance Request:: Ciphersuite-specific data generated by the client and sent to the AS during PBAC issuance. It commonly contains a blinded or public representation of a client-generated secret and a proof of possession of that secret.
Issuance Response:: Ciphersuite-specific data generated by the AS. The client finalizes this response to obtain a PBAC.
Policy:: An authorization rule that defines the finite or otherwise bounded set of tags for which a client can derive acceptable PBATs, together with the authorization semantics applying to those tags.
Policy Epoch:: A period during which a policy, its identifier, and its tag interpretation remain stable. A new epoch results in a distinct tag namespace.
Policy Evaluation Context:: Public, independently verifiable inputs used by a policy profile when it evaluates a tag. Examples include the current time, a policy epoch derived from time, or an authenticated location assertion. The context is not a client assertion and is evaluated independently by the RS.
Tag:: A canonical byte string identifying one permitted derivation opportunity under a policy. A tag can encode a counter, time window, action class, transaction identifier, or a profile-defined combination of these values.
Public Metadata:: Canonically encoded information visible to the client, AS, and RS and cryptographically bound to a PBAC and all PBATs derived from it. Public metadata carries security-relevant information that is not intended to be hidden.
Private Metadata Bit:: An optional one-bit value selected by the AS, hidden from the client at issuance, and recoverable only by an authorized verifier. The bit is not a general-purpose claim channel.
Ciphersuite:: A registered specification of the cryptographic algorithms, groups, hash functions, encodings, and proof systems implementing the abstract PBAT operations in this document.
Spent-Token State:: State maintained by an RS, or by a service trusted by a set of RSs, to detect repeated presentation of the same PBAT.

Problem Statement OAuth provides several mechanisms for narrowing authority. Scopes, authorization details , resource indicators , token exchange , sender-constrained tokens such as DPoP , and short token lifetimes can all reduce the authority or exposure of an access token. None of these mechanisms, by itself, allows a client to obtain one policy-bound credential and then locally derive a bounded set of issuance-redemption-unlinkable access tokens. The problem addressed by this document has five elements:

Bounded local derivation: An AS authorizes a bounded set of future actions without issuing one token per action.
Least authority: Each presented token represents one tag and does not expose a reusable credential covering the entire task.
Issuance-redemption unlinkability: The AS and RS cannot cryptographically correlate a presented PBAT with a particular issuance transcript, even if they share protocol transcripts. Nor can they cryptographically correlate it with another PBAT derived from the same PBAC, except through information deliberately exposed in the tag, policy, public metadata, or the enclosing application request.
Policy enforcement: An RS can determine whether the tag and public metadata are valid under the authorization policy and can reject reuse.
OAuth compatibility: Resource-owner consent, client authentication, authorization details, audience restriction, and OAuth security best practices remain applicable.

Use Cases

Bounded Agent Task Execution A user authorizes an agent to perform up to 20 read operations against a data service during a 30-minute task. The AS issues one PBAC bound to the RS, authorization details, maximum-use policy, and expiry time. The agent derives one PBAT for each admitted counter value and presents a different PBAT for each operation. Compromise of one presented PBAT does not reveal the PBAC and does not enable additional derivations. The issuer assigns any task identifier outside the PBAT’s public metadata and policy unless that identifier is shared by a sufficiently large population. Embedding a unique task identifier, or other client-specific value, in a PBAT-bound policy or metadata partitions the anonymity set and can link the PBATs derived from that PBAC. The AS learns that it authorized the task and its policy, but it does not learn from the PBAT protocol which permitted counter value was used at which time. The RS necessarily observes the operation and tag it processes, and a colluding RS can disclose this information to the AS.

Privacy-Preserving, Rate-Limited API Access A service authorizes an eligible client to make a fixed number of anonymous API calls during a daily epoch. Eligibility can be based on subscription, device posture, proof of personhood, payment, or another mechanism outside the scope of this document. The client obtains one PBAC and derives a PBAT for each counter admitted by the daily policy. The RS rejects a repeated PBAT and therefore enforces the limit without learning the client’s OAuth identity from the PBAT.

Cross-Domain Resource Access An AS in one administrative domain authorizes a client to access an RS in another domain. A publicly verifiable PBAT ciphersuite allows the RS to validate derived tokens with an AS public key. The public metadata binds the credential to the intended audience and authorization details. The RS does not need an online introspection call for every request.

Hidden Binary Issuer Decision In a deployment with an explicitly defined risk model, an AS issues a PBAC containing a private metadata bit. The bit can represent one of two issuer decisions while preventing the client from learning the decision from the issuance transcript alone. An authorized verifier can recover the bit during redemption and apply a locally defined action. This feature is optional. It is not suitable when the verifier’s observable response immediately discloses the bit, when a transparent authorization decision is required, or when the AS needs to convey more than a binary decision.

Design Goals and Non-Goals

Goals The protocol has the following goals:

Preserve the OAuth authorization decision and audience restriction.
Permit one AS issuance interaction to authorize a bounded set of local derivations.
Prevent derivation of more independent tokens than admitted by the policy.
Bind each PBAT to immutable public metadata.
Make an issuance transcript and PBAT redemption transcript cryptographically unlinkable, and make separate PBAT redemption transcripts derived from the same PBAC cryptographically unlinkable, subject to deliberately exposed policy, metadata, tag, and application-request information.
Support public verification for cross-domain deployments.
Permit private verification where AS and RS key-sharing is acceptable.
Provide ciphersuite agility and allow independent cryptographic review.
Preserve compatibility with OAuth security guidance in .

Non-Goals This document does not:

Authenticate a human or establish proof of personhood.
Replace OAuth grants, resource-owner consent, or client authentication.
Hide the requested resource, method, timing, network address, or application behavior from the RS.
Provide general anonymous credentials or selective disclosure.
Provide unrestricted offline delegation or allow a holder to widen the authorization granted by the AS.
Eliminate all server-side state. Replay-resistant deployments maintain spent-token state.
Restate the algorithms of each concrete cryptographic ciphersuite in this document. Ciphersuites are separate Standards Track specifications and are registered under the rules in this document.

OAuth Architecture The OAuth role mapping is as follows:

PBAT function	OAuth role
Issuer	Authorization Server
Client	OAuth Client, including an automated agent
Verifier	Resource Server
Eligibility decision	OAuth authorization decision
Pre-token	Policy-Based Authorization Credential
Locally derived token	Policy-Based Anonymous Access Token

The resource owner, when present, authorizes the client through an OAuth grant. The AS authenticates the client when required by the selected grant and makes an authorization decision. PBAT changes the form and use of the resulting access credential; it does not change how the grant is obtained. The high-level protocol flow, after completion of the selected OAuth grant, is:

Client Authorization Server RS | | | |-- obtain policy and metadata ->| | |<-- policy and metadata --------| | | | | |-- token request + issuance --->| | |<-- issuance response ----------| | | | | |-- Finalize issuance | | |-- Derive(tag_1) | | |--------------------- PBAT(tag_1) -------------------------->| |<-------------------- protected resource -------------------| | | | |-- Derive(tag_2) | | |--------------------- PBAT(tag_2) -------------------------->| |<-------------------- protected resource -------------------| {: artwork-align=center artwork-name=OAuth PBAT flow} The AS can know the client and resource owner during issuance. The privacy property applies between the issuance transcript and later PBAT presentations. Deployments that require the AS not to learn the client identity need an additional anonymous or privacy-preserving eligibility mechanism, which is outside the scope of this document.

Abstract PBAT Ciphersuite Interface A conforming PBAT ciphersuite defines the following operations. The exact inputs and outputs are ciphersuite-specific byte strings, but their security semantics are common. Ciphersuite identifiers are case-sensitive ASCII strings registered in the OAuth PBAT Ciphersuites registry. An implementation MUST NOT advertise or select an unregistered identifier, except for identifiers beginning with x- in a closed test deployment.

Setup(security_parameter) -> public_parameters: Establishes public parameters and domain-separation values.
IssuerKeyGen(public_parameters, mode) -> (issuer_private_key, issuer_public_key): Generates key material for public or private verification. A public-mode ciphersuite MUST permit validation using only the issuer public key. A private-mode ciphersuite uses the issuer private key as its verifier key in version 1. An RS that receives this key is therefore trusted as an issuer for the purposes of that ciphersuite.
Request(public_parameters, public_metadata, issuer_public_key) -> (issuance_request, client_state): Creates a fresh client secret and an issuance request without revealing the secret. The public metadata is bound to the resulting client state.

Issue(public_parameters, issuance_request, public_metadata, private_bit, issuer_private_key) -> issuance_response : Creates an issuance response bound to the public metadata. If the public metadata enables a private metadata bit, private_bit is either zero or one; otherwise it is none. A malicious issuer MUST NOT be able to embed an unrestricted hidden identifier in place of the bit without detection by the client.

Finalize(public_parameters, issuance_response, client_state) -> PBAC: Verifies the issuance response and returns a PBAC or an error. Finalization MUST detect an invalid issuer proof, a public-metadata mismatch, and malformed ciphersuite data.
Derive(public_parameters, PBAC, tag) -> (token, witness): Derives the token and proof material associated with tag. For a fixed PBAC and canonical tag, the logical token MUST be deterministic. The externally visible witness SHOULD be randomized so that it cannot be linked to the issuance transcript.

Verify(public_parameters, policy, token, tag, public_metadata, witness, issuer_public_key) -> valid | invalid : Validates a publicly verifiable PBAT. VerifyPrivate(public_parameters, policy, token, tag, public_metadata, witness, verifier_key) -> valid | invalid : Validates a private-verification PBAT. ReadBit(public_parameters, policy, token, tag, public_metadata, witness, verifier_key) -> 0 | 1 | invalid : When the ciphersuite supports private metadata, validates the relevant proof and returns the private metadata bit. A ciphersuite MAY share computation between this operation and either verification operation, but the logical results remain distinct. A ciphersuite specification MUST define:

all groups, fields, hash functions, and proof systems;
canonical encoding and decoding of every ciphersuite value;
hash-to-field and hash-to-group functions, as applicable;
domain-separation tags for all protocol contexts;
validation of public keys, group elements, and proofs;
public- and private-verification capabilities;
test vectors, including invalid and boundary cases;
the security assumptions and claimed security properties; and
limits on policy, metadata, and tag sizes.

Version 1 implementations MUST implement PBAT-EQS-BLS12381-SHA256, the public-verification equivalence-class-signature ciphersuite over BLS12-381 selected in and specified by the companion ciphersuite document. An implementation MUST NOT substitute a locally defined suite under that identifier. The algebraic-MAC construction in is the designated basis for a subsequent optional private-verification ciphersuite. The zkSNARK construction is not part of version 1 because its proving cost and setup requirements do not justify a mandatory interoperable profile.

Authorization Request A client requests PBAT authorization using the authorization_details parameter defined by . The authorization-detail type is policy_based_anonymous_token. For PBAT issuance, the authorization_details array MUST contain exactly one object and that object MUST have this type. The authorization detail contains the following members:

type: REQUIRED. The value MUST be policy_based_anonymous_token.
locations: REQUIRED. An array containing one or more RS identifiers as defined by . Each identifier is also an audience restriction.
actions: OPTIONAL. An array of action identifiers understood by the AS and RS.
policy_id: REQUIRED. A stable identifier for the requested policy and policy epoch.
policy_profile: REQUIRED. An identifier for the specification that defines canonical tags and policy membership.
epoch_id: REQUIRED. A string identifying the requested policy epoch.
not_before: REQUIRED. A non-negative integer NumericDate for the beginning of the requested policy validity interval.
expires_at: REQUIRED. A non-negative integer NumericDate later than not_before for the end of the requested policy validity interval.
verification_mode: REQUIRED. The value public or private. Version 1 clients and servers MUST support public.
private_metadata: REQUIRED boolean. true requests the private metadata bit; false disables it.
maximum_uses: REQUIRED for counter-window-v1. An integer from 1 through 4294967295 limiting the number of independent tags admitted during the policy epoch.

Unknown members are invalid for this authorization-detail type. Array values MUST NOT be empty or contain duplicates. String comparison follows without additional Unicode normalization. An example authorization detail is:

{ "type": "policy_based_anonymous_token", "locations": ["https://api.example.com"], "actions": ["read"], "policy_id": "urn:example:policy:daily-read:2026-07-20", "policy_profile": "counter-window-v1", "epoch_id": "2026-07-20T00:00:00Z/P1D", "not_before": 1784505600, "expires_at": 1784592000, "verification_mode": "public", "private_metadata": false, "maximum_uses": 10 } {: artwork-name=PBAT authorization detail} The policy_based_anonymous_token type is non-enriching: the AS MUST either authorize the exact requested members and values or reject the request with invalid_authorization_details. It MUST NOT add, remove, or change a member after authorization. The client repeats the exact authorization_details array in the token request as permitted by . authorization_details_hash is the base64url-encoded SHA-256 digest of the UTF-8 JCS serialization of that complete array. The AS MUST NOT issue a policy that grants broader authority or a longer validity interval than the resource owner or grant permits. The ciphersuite issuance request is not part of the authorization request. It is created after the AS has authorized the exact authorization details and is sent in the token request as pbat_issuance_request (). This parameter carries the issuance_request output of Request and is bound to the authorized policy through the identical public-metadata bytes supplied to both operations.

Issuance at the Token Endpoint PBAC issuance is carried on the OAuth token request associated with the selected grant. The request MUST contain the exact authorization_details array authorized by the grant. This document defines three additional token-request parameters:

pbat_issuance_request: REQUIRED for a PBAT token request. A base64url-encoded, ciphersuite-specific issuance_request output generated by Request. The client MUST retain the corresponding client_state locally; it MUST NOT send that state to the AS or RS.
pbat_ciphersuite: REQUIRED. The identifier of a ciphersuite supported by both the client and AS.
pbat_public_metadata: REQUIRED. The base64url encoding of the exact public-metadata bytes used to create the issuance request.

Before invoking Request, the client uses the exact authorization detail it will send in the token request, constructs the policy object in , selects a mutually supported ciphersuite and verification mode, and obtains a matching AS key from pbat_keys_uri. The selected key MUST remain valid through the policy’s expires_at time. The client then constructs the exact public-metadata object, invokes Request, and sends the resulting issuance request. The AS and client MUST run their ciphersuite operations over identical metadata bytes. The AS MUST compare the pbat_public_metadata request parameter with the authorized policy, audience, key identifier, and validity interval. It MUST reject a mismatch. The token response MUST echo the identical byte string. After successful authorization, the token response contains:

authorization_details: REQUIRED by . The value MUST exactly equal the array in the token request.
access_token: REQUIRED. The base64url-encoded issuance_response output of Issue(public_parameters, issuance_request, public_metadata, private_bit, issuer_private_key). The client MUST process this value with Finalize and its retained client_state before storing or using the resulting PBAC. The unfinalized value MUST NOT be sent to an RS.
token_type: REQUIRED. The case-insensitive value PBAT.
expires_in: RECOMMENDED. The lifetime of the PBAC and its derived PBATs in seconds.
pbat_ciphersuite: REQUIRED. The selected ciphersuite identifier.
pbat_policy: REQUIRED. The base64url encoding of the exact UTF-8, JCS-serialized policy object defined in .
pbat_public_metadata: REQUIRED. The base64url encoding of the exact public-metadata bytes bound by the ciphersuite.

For example:

{ "access_token": "base64url(issuance-response)", "token_type": "PBAT", "expires_in": 1800, "authorization_details": [{ "type": "policy_based_anonymous_token", "locations": ["https://api.example.com"], "actions": ["read"], "policy_id": "urn:example:policy:daily-read:2026-07-20", "policy_profile": "counter-window-v1", "epoch_id": "2026-07-20T00:00:00Z/P1D", "not_before": 1784505600, "expires_at": 1784592000, "verification_mode": "public", "private_metadata": false, "maximum_uses": 10 }], "pbat_ciphersuite": "PBAT-EQS-BLS12381-SHA256", "pbat_policy": "base64url(policy-bytes)", "pbat_public_metadata": "base64url(metadata-bytes)" } {: artwork-name=PBAT token response} Malformed issuance data, a metadata mismatch, or a policy mismatch produces the token-endpoint invalid_request error. A syntactically valid but unsupported ciphersuite produces unsupported_pbat_ciphersuite. The AS MUST NOT return an issuance response after either error. An AS SHOULD NOT issue a refresh token with a PBAC unless the deployment has defined the privacy consequences. Refresh requests are linkable to the client and can allow the AS to correlate policy epochs. Short-lived PBACs and explicit reauthorization are RECOMMENDED for privacy-sensitive deployments.

Policy, Tag, and Metadata Model

Policy Requirements A policy profile defines a predicate Admitted(policy, tag, evaluation_context) and a canonical tag encoding. It MUST ensure that the set of independently usable tags in a policy epoch is bounded. A profile MUST NOT rely on a client assertion that a counter is within range unless the RS can validate that assertion from the tag, policy, and evaluation context. The evaluation context enables policy profiles to use independently available, public information such as current time, a current epoch derived from time, or an authenticated location. A profile that uses such information MUST define its canonical representation, source of truth, clock-skew or freshness rules, and the exact evaluation algorithm. The client MAY form a tag using the same public inputs, but the RS MUST derive or authenticate those inputs independently. In counter-window-v1, epoch_id is a fixed value bound into the policy and tag; a new time-based epoch requires a new policy and PBAC. Every version 1 policy object is a JSON object containing exactly the following members:

policy_id: REQUIRED string. An identifier unique within the issuer namespace.
issuer: REQUIRED string. The AS issuer identifier.
audience: REQUIRED non-empty array of strings. Each value is an RS identifier.
policy_profile: REQUIRED string containing a registered policy-profile identifier.
epoch_id: REQUIRED string identifying the policy epoch.
not_before: REQUIRED non-negative integer containing a NumericDate in seconds.
expires_at: REQUIRED non-negative integer containing a NumericDate in seconds and greater than not_before.
authorization_details: REQUIRED array exactly equal to the approved array in the token request and response.
authorization_details_hash: REQUIRED base64url string equal to SHA-256 over the UTF-8 JCS serialization of the approved authorization_details array.
parameters: REQUIRED object whose members are defined by policy_profile.

The policy is constructed deterministically from the one approved authorization detail. policy_id, policy_profile, epoch_id, not_before, and expires_at are copied without transformation; issuer is the AS issuer identifier; audience copies locations in its existing array order; authorization_details is the complete one-element array; authorization_details_hash is computed as specified above; and parameters.maximum_uses copies maximum_uses for counter-window-v1. For the authorization detail above, the decoded policy object is:

{ "policy_id": "urn:example:policy:daily-read:2026-07-20", "issuer": "https://as.example.com", "audience": ["https://api.example.com"], "policy_profile": "counter-window-v1", "epoch_id": "2026-07-20T00:00:00Z/P1D", "not_before": 1784505600, "expires_at": 1784592000, "authorization_details": [{ "type": "policy_based_anonymous_token", "locations": ["https://api.example.com"], "actions": ["read"], "policy_id": "urn:example:policy:daily-read:2026-07-20", "policy_profile": "counter-window-v1", "epoch_id": "2026-07-20T00:00:00Z/P1D", "not_before": 1784505600, "expires_at": 1784592000, "verification_mode": "public", "private_metadata": false, "maximum_uses": 10 }], "authorization_details_hash": "<base64url-hash>", "parameters": {"maximum_uses": 10} } {: artwork-name=PBAT policy object} Unknown top-level members MUST be rejected in version 1. The policy is serialized using JCS and UTF-8. policy_hash is the base64url encoding of SHA-256 over those exact bytes. The ciphersuite binds policy_hash through public metadata; a separate signature over the policy object is therefore not required. An RS MUST reject a PBAT if the received policy bytes do not produce the bound policy_hash, or if recomputing authorization_details_hash from the embedded authorization_details array does not produce the stored and bound value.

Counter-Window Policy Profile All version 1 implementations MUST implement the counter-window-v1 policy profile. For this profile, parameters contains exactly one member, maximum_uses, whose value is an integer in the range 1 through 4294967295. The profile admits one tag for every integer counter from zero through maximum_uses - 1. The canonical tag is the UTF-8 JCS serialization of this JSON object:

{ "counter": 0, "epoch_id": "2026-07-20T00:00:00Z/P1D", "policy_id": "urn:example:policy:daily-read:2026-07-20" } {: artwork-name=Counter-window tag} The object contains exactly counter, epoch_id, and policy_id; unknown members are invalid. counter MUST be within the admitted interval and the two string members MUST exactly match the policy. The counter is not a secret. A client MUST NOT reuse a counter with the same PBAC and policy epoch, and an RS MUST reject reuse of the resulting logical token. Other profiles can bind tags to transactions or action classes. Each such profile MUST be registered, define a finite tag space, specify canonical policy parameters and tags, and state its privacy consequences.

Public Metadata Public metadata prevents substitution of security-relevant context. Every version 1 public-metadata object contains exactly these members:

iss: the AS issuer identifier string;
aud: a non-empty array of intended RS identifier strings;
policy_id: the exact policy identifier string;
policy_hash: the base64url-encoded SHA-256 digest of the policy bytes;
authorization_details_hash: the value from the policy object;
nbf: the earliest acceptable redemption time as an integer NumericDate;
exp: the latest acceptable redemption time as an integer NumericDate;
key_id: the AS verification-key identifier string;
ciphersuite: the selected registered ciphersuite identifier;
verification_mode: either public or private; and
private_metadata: a boolean indicating whether ReadBit is required.

For example:

{ "iss": "https://as.example.com", "aud": ["https://api.example.com"], "policy_id": "urn:example:policy:daily-read:2026-07-20", "policy_hash": "base64url(SHA-256(policy-bytes))", "authorization_details_hash": "<base64url-hash>", "nbf": 1784505600, "exp": 1784592000, "key_id": "2026-07-key-1", "ciphersuite": "PBAT-EQS-BLS12381-SHA256", "verification_mode": "public", "private_metadata": false } {: artwork-name=PBAT public metadata} Unknown members MUST be rejected in version 1. The object is serialized using JCS and UTF-8. The resulting bytes are passed unchanged to the PBAT ciphersuite. The iss, aud, policy_id, authorization_details_hash, nbf, and exp values MUST exactly match the corresponding policy values. String comparison, URI normalization, and audience matching occur before canonicalization according to the specifications that define those fields. If private_metadata is true, the selected ciphersuite registry entry MUST indicate private-bit support, the AS supplies either zero or one to Issue, and the RS invokes ReadBit. If it is false, the AS MUST use the ciphersuite’s no-private-metadata issuance path and the RS MUST NOT invoke ReadBit. Public metadata reduces the effective anonymity set because tokens with different metadata can be distinguished. An AS SHOULD use shared policy and metadata values for sufficiently large client populations and MUST NOT place client-specific identifiers, unique timestamps, or other unnecessary fingerprinting values in public metadata.

Private Metadata Bit The private metadata bit is OPTIONAL. A ciphersuite supporting it MUST prove to the client that the hidden value is one of exactly two public alternatives. It MUST prevent the AS from embedding a larger covert identifier in the same field. Version 1 fixes the semantics: one means that normal RS authorization can continue, and zero means that the RS MUST deny the protected-resource request after otherwise validating the PBAT. The bit is intended only for a binary issuer eligibility decision whose disclosure during issuance would weaken an abuse defense. It MUST NOT encode identity, risk score, action class, or any multi-valued claim. A deployment subject to transparency, explainability, or adverse-action requirements MUST disable the feature unless its use and resulting denial behavior satisfy those requirements.

Token Derivation and Presentation Before accessing a protected resource, the client:

obtains the exact policy and verifies its integrity;
selects a canonical tag admitted by that policy;
invokes Derive with the PBAC and tag;
constructs the version 1 PBAT presentation envelope; and
sends the envelope using the PBAT HTTP authentication scheme.

The version 1 presentation envelope is a JSON object containing exactly the following members:

{ "version": 1, "ciphersuite": "PBAT-EQS-BLS12381-SHA256", "issuer": "https://as.example.com", "key_id": "2026-07-key-1", "policy": "base64url(policy-bytes)", "tag": "base64url(canonical-tag)", "public_metadata": "base64url(metadata-bytes)", "token": "base64url(token-bytes)", "witness": "base64url(witness-bytes)" } {: artwork-name=PBAT presentation envelope} version is the integer 1. ciphersuite, issuer, and key_id are strings that exactly match the bound public metadata. policy, tag, public_metadata, token, and witness are base64url strings containing the exact bytes defined by this document and the selected ciphersuite. Unknown members, duplicate names, non-integer versions, and non-canonical base64url values MUST be rejected. The envelope is serialized using JCS and UTF-8. The PBAT presentation value is the unpadded base64url encoding of those bytes. This serialization is deterministic and is the only version 1 presentation encoding. The serialized presentation is base64url encoded and sent using the HTTP authentication framework in as:

Authorization: PBAT <presentation> {: artwork-name=PBAT authorization header} The client and RS MUST use TLS for all requests carrying a PBAT. A client MUST NOT transmit a PBAT in a URI query parameter, form body, cookie, or any header field other than Authorization. The PBAC, client secret, and issuance transcript MUST NOT be included in the presentation. Unless a field specification states otherwise, base64url values in this document use the URL-safe alphabet and omit padding as specified by .

PBAT Authentication Challenge An RS that requires a PBAT and receives no usable credentials responds with HTTP status 401 and a WWW-Authenticate challenge:

WWW-Authenticate: PBAT realm="example" {: artwork-name=PBAT challenge} The PBAT challenge uses the auth-param syntax of . The realm parameter is OPTIONAL. The error, error_description, and error_uri parameters have the meanings in . A challenge MUST NOT contain a parameter more than once. Clients MUST ignore unknown challenge parameters. For an invalid, expired, malformed, or replayed PBAT, the RS responds with HTTP status 401 and error="invalid_token". When a valid PBAT does not grant the requested operation, the RS responds with HTTP status 403 and error="insufficient_scope". Error descriptions MUST NOT reveal proof validation details, spent-token state, or the value of a private metadata bit.

Resource Server Validation An RS receiving a PBAT performs the following steps in order:

Parse the presentation using strict, ciphersuite-aware decoding. Reject unknown fields, duplicate fields, invalid base64url, non-canonical encodings, and oversized values.
Verify that the issuer is trusted and obtain the exact issuer key identified by key_id.
Verify that the RS is an intended audience and that the current time is within the metadata validity interval.
Decode the policy member, recompute policy_hash, and verify that the policy identifiers, audience, validity interval, and authorization-details hash match the public metadata.
Verify that the public metadata matches the envelope and policy and that the approved authorization details permit the requested operation.
Construct the policy-profile-defined evaluation context and evaluate Admitted(policy, tag, evaluation_context). If the tag is not admitted, reject the request.
Invoke Verify for a public ciphersuite or VerifyPrivate for a private ciphersuite. Reject an invalid result.
If private metadata is enabled, invoke ReadBit, retain the returned bit, and reject invalid.
Atomically check and record spent-token state. If the token has already been accepted in the same issuer, key, policy, and ciphersuite context, reject the request.
If the retained private bit is zero, deny the request. Otherwise, authorize only the operation represented by the approved authorization details and local RS policy.

The spent-token check and record operation MUST be atomic. A distributed RS deployment MUST use a consistent replay-detection mechanism or route all presentations in the same replay domain to a common service. Eventual consistency alone can permit simultaneous double spending. Error responses use the PBAT challenge rules in and MUST NOT reveal whether failure resulted from the private metadata bit.

Verification Modes

Public Verification In public-verification mode, the RS validates a PBAT using an AS public key. This mode supports AS and RS separation and is RECOMMENDED for cross-domain OAuth deployments. A compromise of an RS verification key does not by itself permit token issuance if the key is public-only. Public verification does not mean that all PBAT fields are public, nor does it guarantee that the RS can recover an optional private metadata bit. A ciphersuite specification MUST state whether and how private-bit recovery is available. When private metadata is enabled, the AS provisions any recovery key to the authorized RS through a confidential, authenticated mechanism outside this protocol. A recovery key MUST NOT appear in pbat_keys_uri and SHOULD be scoped so that its compromise does not enable token issuance.

Private Verification In version 1 private-verification mode, an RS uses the AS issuance private key as its verification key. This mode can provide better performance, but it creates a stronger trust relationship:

every verifier holding the key can forge or issue acceptable tokens;
key distribution increases the compromise surface;
isolation between RSs becomes more difficult; and
cross-domain deployment requires explicit key-management agreements.

Private verification is therefore NOT RECOMMENDED across independent administrative domains unless the ciphersuite provides verifier-specific keys with appropriate non-forgeability and isolation properties.

Discovery and Capability Negotiation An AS supporting this protocol advertises the following metadata in its authorization-server metadata document :

pbat_versions_supported: REQUIRED array of integers. This specification defines version 1.
pbat_ciphersuites_supported: Array of supported ciphersuite identifiers.
pbat_policy_profiles_supported: Array of supported policy-profile identifiers.
pbat_verification_modes_supported: Array containing public, private, or both.
pbat_keys_uri: REQUIRED HTTPS URL of the AS PBAT ciphersuite-key document. Public-mode entries contain verification keys; private-mode entries contain the public issuance material required by the client.

The three array members after pbat_versions_supported are REQUIRED when pbat_versions_supported contains 1. An RS advertises the same four metadata members using protected-resource metadata . It also includes policy_based_anonymous_token in authorization_details_types_supported. For example:

{ "pbat_versions_supported": [1], "pbat_ciphersuites_supported": ["PBAT-EQS-BLS12381-SHA256"], "pbat_policy_profiles_supported": ["counter-window-v1"], "pbat_verification_modes_supported": ["public"], "pbat_keys_uri": "https://as.example.com/.well-known/pbat-keys" } {: artwork-name=PBAT capability metadata} The key document is a JSON object with a keys array. Each entry contains kid, ciphersuite, public_key, not_before, expires_at, and status. public_key is an unpadded base64url value whose decoded bytes are defined by the ciphersuite. status is either active or revoked. An AS MUST NOT publish two entries with the same ciphersuite and kid, and MUST NOT reuse that pair for different key material. Clients and RSs MUST validate the decoded public key using the ciphersuite rules and MUST reject a key outside its advertised validity interval or with status revoked. A revoked entry MUST remain published until every policy bound to it has expired.

{ "keys": [{ "kid": "2026-07-key-1", "ciphersuite": "PBAT-EQS-BLS12381-SHA256", "public_key": "base64url(ciphersuite-public-key)", "not_before": 1784505600, "expires_at": 1787184000, "status": "active" }] } {: artwork-name=PBAT verification-key document} The client MUST select a version, ciphersuite, policy profile, and verification mode supported by both the AS and RS. The AS MUST reject an unsupported combination with unsupported_pbat_ciphersuite when the ciphersuite is the incompatible element, or invalid_request otherwise. It MUST NOT silently substitute a different version, profile, mode, or ciphersuite. Discovery metadata is not sufficient to establish trust in a ciphersuite or issuer key. Trust establishment is deployment-specific.

Version 1 Conformance An implementation claiming version 1 conformance implements at least one of the AS, client, or RS roles and satisfies all requirements for that role. In addition:

every conforming AS supports the authorization-detail type, token-endpoint parameters, public verification, counter-window-v1, the mandatory PBAT-EQS-BLS12381-SHA256 ciphersuite, and AS discovery metadata;
every conforming client supports policy and metadata canonicalization, issuance finalization, counter-window derivation, the mandatory ciphersuite, and the PBAT HTTP authentication scheme; and
every conforming RS supports protected-resource discovery metadata, strict presentation parsing, public verification with the mandatory ciphersuite, counter-window policy validation, the PBAT challenge, and atomic replay detection.

Private verification and the private metadata bit are optional features. An implementation supporting either feature MUST advertise it and implement all corresponding ciphersuite, key-management, error, security, and privacy requirements. Implementing only the abstract ciphersuite interface without a registered ciphersuite does not constitute protocol conformance.

Relationship to Existing Work

OAuth Access Tokens Bearer tokens are directly reusable until expiry or revocation. A PBAC is not directly presented, and each PBAT is bound to one admitted tag. The PBAT protocol therefore changes token use rather than replacing OAuth’s grant and authorization model. The same separation is applicable to the OAuth 2.1 framework under development .

Rich Authorization Requests Rich Authorization Requests express fine-grained authorization requirements. This document uses authorization details to state the authority that is bound into public metadata. RAR does not define anonymous or locally derived access tokens, so the mechanisms are complementary.

Resource Indicators Resource indicators help the AS issue audience-restricted access tokens. PBAT public metadata preserves this restriction for all locally derived tokens.

Token Exchange OAuth Token Exchange allows a client to exchange one token for another at an AS. It remains an online issuance operation and is useful for cross-domain and delegation scenarios. PBAT instead permits bounded local derivation after one issuance. A deployment can use token exchange to obtain a PBAC, but the exchange and derivation operations are distinct.

DPoP DPoP sender-constrains an access token to a client key and reduces the utility of a stolen token. It does not provide issuance-redemption unlinkability or bounded local derivation. Applying DPoP directly to PBATs can introduce a stable public key that defeats unlinkability. Any combined profile MUST analyze this correlation risk and SHOULD use per-policy or per-presentation keys where compatible with the ciphersuite.

Transaction Tokens Transaction Tokens propagate identity and authorization context among workloads processing a transaction in a trusted domain. PBATs minimize identity disclosure and unlink issuance from redemption. The mechanisms address different trust and privacy goals. A PBAT MUST NOT be treated as a Transaction Token without an explicit profile.

Privacy Pass Privacy Pass defines an architecture for privacy-preserving authorization, an HTTP authentication scheme , and issuance protocols . Privacy Pass commonly issues independently redeemable tokens, including batched issuance. PBATs authorize a policy-defined family of deterministic, tag-specific derivations from one credential. The standards boundary is fixed as follows. This document owns the OAuth authorization semantics, PBAC issuance binding, PBAT presentation envelope, PBAT authentication scheme, policy profiles, and OAuth discovery. Separate PBAT ciphersuite documents own the cryptographic algorithms and receive review from the Privacy Pass and CFRG communities. The PrivateToken authentication scheme is not reused because its token challenge and redemption syntax does not carry the policy, tag, and OAuth metadata required here. A ciphersuite document can reuse Privacy Pass primitives when their security properties and wire formats match the PBAT interface.

Security Considerations

OAuth Security Requirements All deployments MUST follow the OAuth security requirements and current best practices in and the requirements of the selected grant. In particular, authorization responses need injection and mix-up defenses, redirect URIs require exact matching, public clients use PKCE where applicable, and tokens are audience restricted. PBAT does not compensate for a compromised authorization endpoint, malicious redirect URI, weak client authentication, or incorrect resource-owner consent.

Theft of a PBAC A PBAC contains or protects client state capable of deriving multiple PBATs. Its theft can therefore be more serious than theft of one derived PBAT. Clients MUST protect PBACs and derivation secrets at rest and in use. Where available, non-exportable key storage SHOULD be used. Implementations SHOULD erase intermediate issuance state after successful finalization.

Replay and Double Spending PBAT derivation makes the logical token deterministic for a tag, but does not by itself prevent repeated presentation. RS replay detection is REQUIRED. Replay keys MUST include sufficient context to prevent cross-issuer, cross-policy, and cross-ciphersuite confusion. Distributed race conditions need to be treated as security failures, not merely accounting errors.

Policy Bypass and Downgrade The policy identifier, epoch, audience, authorization details, ciphersuite, and validity interval MUST be cryptographically bound through public metadata or the ciphersuite transcript. The client and RS MUST reject substitution of a less restrictive policy or weaker ciphersuite.

Key Rotation and Revocation Version 1 deliberately uses epoch expiry for individual authorization revocation and key status for emergency bulk revocation. The AS MUST bound each policy lifetime according to deployment risk. Setting a key entry’s status to revoked invalidates every PBAT under that key; an RS MUST refresh the key document often enough to meet the deployment’s emergency-revocation objective. Immediate per-client revocation after issuance is not supported because a revocation handle would enable linkage or require an online call at redemption. Token revocation can cause a client to delete a PBAC, but cannot identify already derived PBATs to an RS. Online introspection is therefore outside the version 1 validation path; using it for each presentation defeats the stated unlinkability goal. A deployment that requires immediate per-client revocation MUST use a different access-token profile. Privacy-preserving revocation based on cryptographic accumulators is a promising future extension, but is outside version 1 until its protocol, security properties, and interoperability requirements have been specified and independently reviewed.

Malicious Issuer A malicious AS can try to place unique values in policies, metadata, keys, or proof randomness to create a subliminal identifier. Ciphersuite security alone cannot prevent unique public metadata. Clients SHOULD verify that metadata conforms to a shared profile and SHOULD reject unnecessary unique values. A private-bit ciphersuite MUST prove that the hidden choice is one of two allowed values.

Malicious Client A ciphersuite MUST prevent a client from forging a PBAC, deriving acceptable tokens for tags not admitted by the policy, or generating more independent tokens than allowed. The RS MUST independently validate policy membership; it MUST NOT rely on client-provided authorization claims without cryptographic or policy validation.

Cryptographic Agility An implementation MUST NOT deploy an unregistered or locally invented ciphersuite without a complete specification and independent review. Group elements, public keys, and proofs MUST be validated before use. Hash functions serving different roles MUST use domain separation. Decoding failures MUST terminate validation without exposing secret-dependent detail.

Privacy Considerations

Scope of Unlinkability PBAT unlinkability concerns cryptographic issuance and presentation transcripts. The AS can know the client during OAuth authorization. The RS sees the source network, timing, requested resource, application behavior, and tag. Cookies, TLS client certificates, stable DPoP keys, application identifiers, and traffic analysis can independently link requests. Applications claiming anonymity need to address these higher-layer and network-layer signals.

Anonymity Set Partitioning Public metadata and policies partition the anonymity set. A unique audience, policy identifier, expiry time, authorization-details hash, or key identifier can make a client distinguishable even if the PBAT construction is secure. ASs SHOULD issue common metadata to groups of clients and SHOULD use coarse expiry values and shared policy epochs.

Tag Linkability A tag is visible to the RS and a logical PBAT is deterministic for that tag. Repeated presentations are intentionally linkable so they can be rejected. Tags MUST NOT contain user identifiers or unnecessary application data. Policy profiles SHOULD minimize semantic information in tags while retaining verifiable boundedness.

AS-RS Collusion A secure ciphersuite aims to prevent an AS and RS from matching a valid PBAT to one issuance transcript. Colluding parties can still correlate unique metadata, authorization timing, IP addresses, policy choices, and application behavior. Privacy claims MUST distinguish cryptographic unlinkability from end-to-end anonymity.

Logging and Telemetry AS and RS logs can undo privacy protections. Implementations SHOULD avoid logging complete PBATs, witnesses, issuance requests, or client-specific policy values. Operational metrics SHOULD be aggregated. Retention periods and access controls SHOULD reflect the privacy sensitivity of the data.

Operational Considerations

Spent-Token Storage The RS can store a collision-resistant digest of the validated logical token and its issuer, key, policy, and ciphersuite context rather than the full presentation. Storage duration needs to cover the maximum redemption period plus an allowance for clock skew. The digest construction and storage model must not permit offline guessing of low-entropy tokens.

Clock and Epoch Handling AS and RS clocks need an agreed tolerance. A policy profile MUST define epoch boundaries and behavior near a boundary. A client MUST NOT derive a token for an expired epoch, and the RS MUST reject it even when the PBAC itself has not yet been deleted locally.

Failure Handling Clients need to treat issuance-finalization failure as a failed token request. They MUST NOT retry with the same client state unless the ciphersuite permits safe retry. AS and RS errors SHOULD be coarse enough not to create an oracle for private metadata or proof internals.

Audit PBAT intentionally limits correlation between issuance and resource access. Deployments requiring individual attribution for every action need a different token profile or a separate, explicitly consented audit mechanism. Audit requirements MUST be evaluated before selecting PBAT.

Standards-Track Structure and Publication Path This document is the version 1 OAuth protocol specification and is intended for publication as a Proposed Standard. It defines all OAuth-visible and HTTP-visible behavior. It is not an Informational framework and does not defer the token representation, verification mode, initial policy profile, or protocol ownership to a future document. The cryptographic construction advances as a separate IETF Standards Track companion specification. The initial companion specifies the PBAT-EQS-BLS12381-SHA256 ciphersuite, based on the publicly verifiable equivalence-class-signature construction in . It defines all group operations, hash functions, zero-knowledge proofs, encodings, validation rules, domain-separation strings, test vectors, and security limits required by . The companion receives dedicated CFRG review before the two documents complete working-group last call. The OAuth document and initial ciphersuite document are publication dependencies and advance together. The intended sequence is:

submit this document and the EQS ciphersuite companion as individual Internet-Drafts;
seek OAuth Working Group adoption of this document and Security Area coordination for the ciphersuite companion;
complete interoperable implementations and test vectors for issuance, derivation, presentation, and replay rejection;
run CFRG cryptographic review of the EQS construction and OAuth review of the authorization and HTTP bindings;
conduct coordinated working-group last calls; and
request IETF Last Call and IESG publication of both documents as Proposed Standards.

The algebraic-MAC construction in advances only as a later optional private-verification ciphersuite. It does not delay version 1 publication. The zkSNARK construction is excluded from the version 1 standards set. New ciphersuites and policy profiles are added through the registries established by without changing the OAuth wire protocol.

IANA Considerations

OAuth Access Token Type IANA is requested to register the following value in the OAuth Access Token Types registry:

Name:: PBAT
Additional Token Endpoint Response Parameters:: pbat_ciphersuite, pbat_policy, pbat_public_metadata
HTTP Authentication Scheme(s):: PBAT
Change Controller:: IETF
Reference:: This document

HTTP Authentication Scheme IANA is requested to register the following value in the HTTP Authentication Schemes registry:

Authentication Scheme Name:: PBAT
Reference:: and of this document
Notes:: Carries a policy-based anonymous access-token presentation as a token68 value.

OAuth Parameters IANA is requested to add the following values to the OAuth Parameters registry. The Change Controller for every entry is IETF and the reference is this document.

Name	Parameter Usage Location
`pbat_issuance_request`	token request
`pbat_ciphersuite`	token request, token response
`pbat_public_metadata`	token request, token response
`pbat_policy`	token response

OAuth Extensions Error IANA is requested to add the following value to the OAuth Extensions Error registry:

Name:: unsupported_pbat_ciphersuite
Usage Location:: token endpoint
Protocol Extension:: OAuth 2.0 Policy-Based Anonymous Access Tokens
Change Controller:: IETF
Reference:: of this document

Authorization Server Metadata IANA is requested to add the following values to the OAuth Authorization Server Metadata registry. The Change Controller for every entry is IETF and the reference is of this document.

Metadata Name	Metadata Description
`pbat_versions_supported`	JSON array of supported PBAT protocol version integers
`pbat_ciphersuites_supported`	JSON array of supported PBAT ciphersuite identifiers
`pbat_policy_profiles_supported`	JSON array of supported PBAT policy-profile identifiers
`pbat_verification_modes_supported`	JSON array of supported PBAT verification modes
`pbat_keys_uri`	HTTPS URL of the authorization server’s PBAT ciphersuite-key document

Protected Resource Metadata IANA is requested to add the following values to the OAuth Protected Resource Metadata registry. The Change Controller for every entry is IETF and the reference is of this document.

Metadata Name	Metadata Description
`pbat_versions_supported`	JSON array of PBAT protocol version integers accepted by the protected resource
`pbat_ciphersuites_supported`	JSON array of PBAT ciphersuite identifiers accepted by the protected resource
`pbat_policy_profiles_supported`	JSON array of PBAT policy-profile identifiers accepted by the protected resource
`pbat_verification_modes_supported`	JSON array of PBAT verification modes accepted by the protected resource

The policy_based_anonymous_token authorization-detail type is not placed in a new IANA registry. Consistent with , AS and RS implementations advertise that type through the existing authorization_details_types_supported metadata member.

OAuth PBAT Ciphersuites Registry IANA is requested to create the OAuth PBAT Ciphersuites registry under the OAuth Parameters registry group. Registry entries contain:

ciphersuite identifier;
verification mode (public or private);
private metadata bit support (yes or no); and
specification reference.

Ciphersuite identifiers are case-sensitive strings of 1 to 64 characters and match the regular expression [A-Za-z0-9][A-Za-z0-9._-]{0,63}. Identifiers beginning with x- are reserved for private testing and MUST NOT be registered. The registration policy is IETF Review . A specification requesting registration MUST satisfy every requirement in , include test vectors, and document unlinkability, unforgeability, metadata binding, replay-key construction, and implementation limits. The initial entry is:

Identifier	Mode	Private Bit	Reference
`PBAT-EQS-BLS12381-SHA256`	public	yes	Companion PBAT EQS ciphersuite specification described in

The OAuth protocol document and the companion ciphersuite document are to be published together. IANA is requested to use the RFC number assigned to the companion document as the final reference for this entry.

OAuth PBAT Policy Profiles Registry IANA is requested to create the OAuth PBAT Policy Profiles registry under the OAuth Parameters registry group. Registry entries contain a profile identifier, a short description, and a specification reference. Identifiers follow the syntax and private-use rule defined for ciphersuite identifiers. The registration policy is Specification Required . Designated experts are requested to verify that a profile defines a finite tag space, canonical policy and tag encodings, authorization semantics, and privacy considerations. The initial entry is:

Identifier	Description	Reference
`counter-window-v1`	Integer counter window within a bounded policy epoch	of this document

— back

Acknowledgments {:numbered=false} The authors thank Codrin Ogreanu for his work with David Kretzler and Yong Li on the underlying policy-based anonymous-token framework and constructions. The authors also thank the authors and contributors of the Privacy Pass and OAuth specifications whose work provides the foundation for this proposal.