VEIL: Verified Ephemeral Identity Layer for OAuth 2.1

Introduction Identity verification produces two kinds of outputs: attestation (boolean results, compliance scores, assurance tiers) and identity data (name, date of birth, address, document details). OpenID Connect Core 1.0 delivers both through the same channel, with the same lifetime and the same correlation properties. VEIL separates them: attestation is carried in standard token claims, while identity data is delivered through an ephemeral, single-consume channel bound to a user-initiated disclosure intent. The profile composes and constrains the following specifications: Concern Specifications Authorization Framework OAuth 2.1 Proof Key PKCE , mandatory Pushed Authorization PAR , mandatory Sender Constraining DPoP Identity Layer OpenID Connect Core 1.0 Structured Intent Rich Authorization Requests Token Exchange Token Introspection Back-Channel Logout This document specifies: a two-track claim model (), an ephemeral identity delivery channel (), pairwise subject identifiers as the default (), an abstract interface for assurance level derivation (), HMAC-verified consent integrity (), and an extension profile architecture for domain-specific profiles ().

Conventions and Terminology

Notational Conventions 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.

Versioning VEIL uses MAJOR.MINOR versioning, with -draft appended for pre-release revisions. Implementations MUST reject configurations or discovery documents with an unrecognized major version. Implementations SHOULD accept documents with a higher minor version than expected and ignore unrecognized fields, preserving forward compatibility.

Definitions

Assurance Level:: A tiered classification of how thoroughly a user's identity has been verified. The profile defines the interface (inputs and outputs) but not the specific checks or tier definitions.
Ephemeral Store:: An in-memory, TTL-bounded storage mechanism for identity claims with single-consume semantics. PII staged in the ephemeral store is consumed on first retrieval and automatically expires if unclaimed.
Identity Claim:: A claim that contains personally identifiable information (name, date of birth, address, nationality, document details). Identity claims require explicit user action to release and flow only through the ephemeral store.
Proof Claim:: A claim that conveys a boolean verification result, assurance level, or compliance flag without revealing the underlying PII. Proof claims flow through standard token claims and the userinfo endpoint.
Proof Scope:: An OAuth scope that authorizes the release of proof claims. Proof scopes MUST NOT trigger identity claim delivery.
Identity Scope:: An OAuth scope that authorizes the release of identity claims. Identity scopes require user action to unlock PII and flow through the ephemeral delivery channel.
Sector Identifier:: A stable client-bound identifier used as input to pairwise subject derivation. In OIDC this is the registered sector identifier for the client; absent an explicit sector identifier, the chosen value SHOULD remain stable across redirect URI reordering.
Step-Up Authentication:: A flow where the authorization server enforces a higher assurance requirement (acr_values) or session freshness (max_age) than the user's current session provides, triggering re-verification or re-authentication.

Transport Constraints The following OAuth 2.1 options are mandatory under this profile. Requirements that OAuth 2.1 states as SHOULD or RECOMMENDED are restated here as MUST.

Authorization Server Requirements The authorization server MUST: Support OAuth 2.1 authorization code flow with PKCE. Require Pushed Authorization Requests (PAR, ) for all authorization requests. Support DPoP for sender-constrained tokens. Issue access tokens signed with EdDSA (Ed25519) for compact signatures. Support id_token_signed_response_alg client metadata for per-client signing algorithm selection. The authorization server SHOULD: Support multiple signing algorithms for id_tokens (RS256, ES256, EdDSA, ML-DSA-65). Support Rich Authorization Requests for structured intent. Support Token Exchange for audience rebinding and scope attenuation. Support Back-Channel Logout for federated session termination.

Client Requirements Clients MUST: Use PKCE with S256 challenge method. Submit authorization parameters via PAR before initiating the authorization flow. Include the resource parameter on PAR requests. Support DPoP for sender-constrained token usage. Clients MUST NOT: Use the implicit grant. Use the resource owner password credentials grant.

Subject Unlinkability Under this profile, pairwise subject identifiers are the default. Unless a client explicitly registers subject_type: "public", each relying party receives a distinct pseudonym for the same user, preventing cross-RP correlation through the subject identifier.

Default Posture All client registrations MUST default to subject_type: "pairwise". Clients that require globally stable subject identifiers explicitly opt in via subject_type: "public" at registration.

Derivation Pairwise subject identifiers are derived as:

Where: PAIRWISE_SECRET is a server-side secret of at least 32 bytes. sector is the client's stable sector identifier. If the authorization server supports OIDC sector_identifier_uri, it MUST use that registered sector identifier. Otherwise it MUST derive a stable client-bound value that does not change when redirect URI order changes. userId is the internal user identifier. Two clients with different sector identifiers receiving tokens for the same user see different sub values. Neither client can derive the other's sub or determine that both values refer to the same user.

Token Exchange When performing Token Exchange with an audience parameter, the authorization server MUST re-derive the pairwise sub for the target audience's sector identifier. The exchanged token's sub MUST differ from the subject token's sub unless both clients share the same sector.

Extension Point Extension profiles MAY apply pairwise derivation to additional token claims. PACT extends pairwise derivation to the act.sub claim for agent session identifiers.

Claim Separation VEIL divides claims into two tracks based on whether they contain personally identifiable information. The separation is enforced at three independent layers: scope definitions (), consent decisions (), and delivery mechanisms ().

The Two Tracks Proof claims convey verification results without PII. Examples: age_verification: true, nationality_verified: true, verification_level: "full", sybil_resistant: true. Proof claims are derived from cryptographic artifacts (ZK proofs, signed claims, encrypted attributes) rather than raw identity data. Identity claims contain PII. Examples: name: "Jane Doe", date_of_birth: "1990-05-15", address: {...}, nationality: "FR". Identity claims require explicit user action to unlock and flow through the ephemeral delivery channel (). The distinction between tracks is not what the claim describes but what it reveals. An age verification proof and a date of birth both describe the user's age, but the proof reveals only a boolean while the date reveals the value itself.

Scope Families The authorization server MUST define two disjoint scope families: Proof scopes (e.g., proof:age, proof:nationality, proof:verification, proof:compliance): Authorize the release of proof claims only. MUST NOT trigger identity claim delivery. Do not require vault unlock or any user action beyond initial consent. May be auto-approved on subsequent requests if consent already exists. Identity scopes (e.g., identity.name, identity.address, identity.nationality, identity.dob): Authorize the release of identity claims. MUST trigger the ephemeral delivery channel (). Require explicit user action to unlock PII for each authorization. MUST NOT be persisted in durable consent records (ensuring the unlock prompt reappears on each request). An umbrella proof scope (e.g., proof:identity) MAY expand to all proof sub-scopes at consent time, allowing the user to opt in per sub-scope.

Delivery Channels The two tracks produce different delivery behavior at each OAuth endpoint:

In id_tokens:: Proof claims MAY be embedded directly. Identity claims MUST NOT be embedded in id_tokens. Identity scopes unlock PII only through the ephemeral delivery channel and userinfo consumption path described in .
In access tokens:: Access tokens ordinarily carry only structural claims (sub, scope, aud, cnf, and extension-defined claims like act). Proof claims are not embedded there except where a profile explicitly defines an access-token-only proof artifact. VEIL defines one such exception in : proof:sybil yields a per-RP sybil_nullifier in access tokens only. Identity claims MUST NOT be embedded in access tokens.
Via userinfo:: Both proof claims and identity claims are delivered. Proof claims are resolved from the user's verification state. Identity claims are consumed from the ephemeral store (single-consume; the entry is deleted after retrieval).

Sybil Nullifiers The profile defines an optional proof:sybil scope that produces a per-RP unlinkable nullifier:

The same person receives the same nullifier at one RP but different nullifiers at different RPs. This enables per-human rate limiting and duplicate detection without cross-RP identity linkage.

Transient Disclosure Identity claims (PII) reach the relying party through an in-memory store with single-consume semantics, bound to a user-initiated intent flow. The profile mandates the delivery semantics; the unlock mechanism (passkey PRF, password-derived key, wallet signature) is implementation-specific.

Single-Consume Properties When identity scopes are approved, the authorization server stages PII in an in-memory store with the following properties: Property Requirement Storage In-memory only; MUST NOT be written to disk or database. Key Implementation-defined. It MUST either include a request-specific handle or otherwise guarantee that only one live staged entry exists per userId:clientId. TTL Configurable; SHOULD default to 5 minutes for interactive flows. Consumption Single-consume; the entry MUST be deleted on first retrieval. Concurrency If the key does not include a request-specific handle, concurrent staging for the same userId:clientId MUST be rejected until the earlier entry is consumed, cleared, or expires. Replay protection Intent JTIs MUST be persisted in durable storage (not memory-only) and checked to prevent replay of unlock events. Persistence MUST use insert-or-ignore semantics to handle concurrent first-use races. Rate limiting Intent and stage endpoints MUST be rate-limited per user identity to prevent brute-force unlock attempts and ephemeral store flooding. Ambiguity safety If multiple entries exist for the same userId when the consuming endpoint lacks clientId context, the server MUST return no claims rather than risk cross-client PII misdelivery.

Intent Flow The staging process follows an intent-then-stage pattern to ensure that PII staging is bound to a specific user action and cannot be replayed or triggered by the relying party alone: User action. The user performs a credential-specific unlock action (the mechanism is implementation-specific). Intent token. The authorization server issues a signed intent token (HMAC-SHA-256, short TTL) carrying a scope hash and, for backchannel flows, the authorization request identifier that binds the unlock to a specific consent request. Stage. The client presents the intent token. The server validates it, filters the user's identity data by the approved scopes, and stages the filtered claims in the ephemeral store. Consume. The relying party calls the userinfo endpoint. The server retrieves and deletes the staged entry in a single atomic operation.

Exclusions The ephemeral store MUST NOT contain: Raw biometric data (images, embeddings, liveness scores). Document images. Cryptographic key material. Internal identifiers that could be used to correlate across RPs. Only the identity claims authorized by the approved identity scopes are staged.

Tiered Verification VEIL defines the interface for assurance level derivation (inputs, outputs, properties) but leaves the verification pipeline, check definitions, and tier labels to each implementation.

Abstract Interface Input: A set of verification artifacts. The profile does not mandate the artifact types, but common examples include zero-knowledge proof verification results, signed claims from verification processes, encrypted attribute presence flags, biometric match results, and sybil resistance indicators. Output: An assurance result containing: Field Type Description verified boolean Whether the user meets the minimum verification threshold. level string Tiered assurance level (implementation-defined labels). numericLevel integer Numeric ordering of tiers for comparison. checks object Individual boolean check results (implementation-defined).

Derivation Requirements The derivation function MUST be: Pure. No database access, no side effects. All inputs are passed explicitly. Deterministic. The same inputs always produce the same output. Monotonic in tier ordering. A higher numeric level MUST satisfy any requirement for a lower level. The authorization server MUST expose the assurance level through: The acr claim in id_tokens (mapping implementation tiers to URN identifiers). Proof claims filtered by granted proof scopes.

Step-Up Enforcement Step-up authentication is spatial (trust depends on which operation is attempted) rather than temporal (trust deepening over time). Two enforcement points apply: When a client includes acr_values in an authorization request, the authorization server MUST verify that the user's current assurance level satisfies the requested tier. If it does not, the server MUST return an explicit step-up error rather than silently downgrading. In browser-based authorization flows, the error SHOULD be surfaced as interaction_required; extension profiles MAY define an equivalent continuation-oriented error if they also provide a resumable step-up path. When a client includes max_age, the authorization server MUST verify that the user's session is not older than the specified value. If it is, the server MUST require re-authentication. In PAR-based flows, the PAR record SHOULD be preserved with an extended TTL to cover the re-authentication round-trip, so the authorization flow can resume after login. When acr_values cannot be satisfied in a browser-based PAR flow, the PAR record MUST be deleted and the server MUST redirect with the same step-up error contract used for other authorization flows (for example, interaction_required). ACR identifiers are deployment-local. Consistent with OIDC Core 1.0 Section 2 and established IETF practice (e.g., urn:mace:incommon:iap:silver), a conforming authorization server MUST document the ACR URNs it issues and their tier semantics in its discovery metadata (acr_values_supported). VEIL does not register specific ACR values and does not reserve a VEIL-specific ACR namespace; interoperability is achieved by publishing the local URNs rather than by centralized registration. Extension profiles MAY define additional step-up enforcement points.

Signing Agility

Algorithm Selection The authorization server MUST support at least RS256 for id_tokens (OIDC Discovery 1.0 Section 3 mandatory). The authorization server SHOULD support ES256, EdDSA, and ML-DSA-65. Access tokens MUST be signed with EdDSA (compact 64-byte signatures for Bearer headers). Clients MAY declare a preferred id_token signing algorithm via id_token_signed_response_alg in their registration metadata. The authorization server MUST honor the declared preference if it supports the algorithm.

Key Management Signing keys MUST be encrypted at rest (SHOULD use AES-256-GCM with a dedicated key encryption key). Key rotation MUST support an overlap window during which both the retiring and replacement keys are served by the JWKS endpoint. The retiring key carries an expiresAt timestamp; after the overlap window, it is removed.

Tamper-Evident Consent An attacker who can modify stored consent scopes can bypass both the two-track model and ephemeral delivery. Consent records are protected by an HMAC (), and identity scopes are excluded from durable consent storage ().

Scope Verification The authorization server MUST verify the integrity of stored consent records on every authorization request. Consent records MUST be protected by an HMAC computed over the consent context:

Length-prefixed encoding prevents concatenation collisions. The HMAC key MUST be derived from the server's base secret via a KDF (e.g., HKDF ) with a domain-separating info parameter, not used as a raw key. This separation ensures that the consent integrity key and the session authentication key are cryptographically independent even when derived from the same root secret.

Tamper Response Before processing an authorization request against stored consent, the server MUST recompute the HMAC and compare it to the stored value. If they differ, the server MUST delete the consent record and require re-consent. This prevents three attack vectors: direct database scope escalation, consent replay across clients, and consent replay across users.

Identity Scope Stripping Identity scopes MUST NOT be persisted in durable consent records. The full scope set (including identity scopes) is written for authorization code derivation, then identity scopes are stripped immediately so that the consent page reappears on subsequent requests. This ensures that PII delivery requires a fresh user decision each time.

Machine-Readable Surfaces

OIDC Discovery Extensions The authorization server's OpenID Provider Configuration (/.well-known/openid-configuration) MUST include: subject_types_supported: ["pairwise", "public"] with pairwise listed first. acr_values_supported listing all supported assurance tier URNs. scopes_supported listing all proof and identity scopes. backchannel_logout_supported: true. backchannel_logout_session_supported: true. require_pushed_authorization_requests: true. dpop_signing_alg_values_supported. id_token_signing_alg_values_supported (at minimum ["RS256"]).

Extension Discovery Extension profiles define their own discovery documents at dedicated well-known paths. The OIDC Discovery document SHOULD NOT be overloaded with extension-specific metadata.

Compositional Extension Domain-specific profiles (agent delegation, verifiable credentials, regulatory compliance) extend VEIL through the mechanism defined below. Extensions MUST NOT modify VEIL itself.

Architecture Each extension profile: References VEIL as its base and inherits all VEIL requirements. Adds domain-specific capabilities without modifying VEIL's core requirements. Defines its own discovery document at a dedicated well-known path. Specifies additional conformance requirements for its domain.

Extension Boundaries Extension profiles MUST NOT: Weaken pairwise subject requirements (e.g., defaulting to public subjects). Bypass the ephemeral delivery channel for identity claims. Embed identity claims in access tokens or extension-specific token types. Modify the consent integrity mechanism. Extension profiles MAY: Define additional pairwise derivations. Define additional step-up enforcement points. Define additional token types via Token Exchange . Define additional consent routing logic. Extend the ephemeral store TTL for their specific flow patterns.

Security Considerations Implementations MUST satisfy the security considerations of each composed specification: OAuth 2.1 , PKCE , PAR , DPoP , RAR , Token Exchange , OIDC Core 1.0 , and OIDC Back-Channel Logout 1.0 .

PII Exposure Window Identity claims exist in cleartext only during the ephemeral delivery window (between staging and consumption). Outside that window, identity data is either encrypted (credential-wrapped secrets, FHE ciphertexts) or absent. Authorization servers MUST NOT log identity claim values. Authorization servers MUST NOT cache identity claims beyond the ephemeral store TTL.

Correlation Resistance Pairwise subject identifiers prevent cross-RP user correlation under the standard OIDC threat model. However, timing correlation (two RPs comparing token issuance timestamps) and metadata correlation (user agent, IP address) remain possible. The authorization server SHOULD minimize metadata leakage in token responses and SHOULD NOT include client-identifying information in error responses visible to other clients.

Sender Constraining DPoP sender-constraining prevents token theft and replay. When combined with pairwise subjects, a stolen token is useless to a different RP (wrong aud) and useless to a different client (wrong cnf.jkt).

Privacy Considerations Implementations MUST satisfy the privacy considerations of each composed specification. Participants are the authorization server (AS), the relying party (RP), and the end user. Data categories are proof claims (), pairwise subjects (), sybil nullifiers (), and identity claims (PII), which flow only through the ephemeral channel (). Cross-RP correlation through subject identifiers requires explicit opt-in at registration (subject_type: "public"); identity disclosure requires explicit opt-in at authorization (identity scopes, per-scope user consent).

Double Anonymity The profile supports a double-anonymity mode where both sides of the identity verification relationship are protected. The relying party cannot identify the user or recognize returning users (pairwise subjects, no email scope), and the authorization server cannot reconstruct which services the user visits (consent records do not accumulate when identity scopes are stripped).

Sybil Nullifier Privacy The sybil_nullifier () is derived per-RP. Two RPs receiving nullifiers for the same user cannot determine that fact. The nullifier enables per-human uniqueness enforcement without cross-RP identity linkage.

Session Metadata Nullification The authorization server MUST NOT persist the user's IP address or user agent in session records. If the session layer collects these values (as most frameworks do by default), they MUST be nullified before storage. Without this, two RPs that obtain session metadata (via breach, legal compulsion, or insider access) can correlate users by matching IP + user agent + timestamp patterns.

Provider Fingerprint Removal Four concrete signals can fingerprint the authorization server and enable cross-RP provider correlation: Provider identifiers in proof claims. Proof claim payloads MUST NOT include provider-identifying fields (e.g., issuer_id). Provider identity is an internal audit concern. Trust framework naming. The trust framework identifier in identity assurance claims SHOULD identify the regulatory framework (e.g., eidas), not the provider name. Credential type identifiers. Verifiable credential type identifiers (VCT) MUST use provider-neutral URNs (e.g., urn:credential:identity-verification:v1) rather than provider-domain URLs. Structural fingerprinting. SD-JWT credentials SHOULD include decoy disclosures to prevent fingerprinting via disclosed claim set analysis.

Claim Specificity Proof claims are derived from cryptographic artifacts, not from raw PII. The authorization server SHOULD minimize the specificity of proof claims. For example, nationality_group: "EU" is preferable to nationality: "FR" when the relying party's requirement is jurisdiction membership rather than specific nationality.

IANA Considerations This document has no immediate IANA actions that require new registry creation. It relies on identifiers and registries that are either already allocated or that are delegated to extension profiles.

OAuth Parameter Registries VEIL does not register new OAuth parameters, grant types, token type URIs, client metadata fields, or authorization server metadata fields. It narrows existing OAuth 2.1 and OIDC Core 1.0 parameters to a mandatory subset (see ). Extension profiles that build on VEIL are responsible for registering any new OAuth identifiers they introduce.

Well-Known URI Registrations VEIL relies on the existing well-known URI registrations openid-configuration (OIDC Discovery 1.0) and oauth-authorization-server . It does not register a new well-known URI. Extension profiles MAY register their own well-known URI suffixes per .

Assurance Certification Values (acr) ACR URNs listed in acr_values_supported are deployment-local, consistent with OIDC Core 1.0 Section 2 and established IETF practice. VEIL does not register a VEIL-specific ACR namespace and does not request a registry; each authorization server documents its own ACR URNs and their tier mapping in its discovery metadata (see ).

Verifiable Credential Type Identifiers Where a deployment emits verifiable credentials, credential type identifiers (VCT) MUST be provider-neutral URNs (see ). VEIL does not define or reserve specific VCT URNs; deployments choose values consistent with the credential ecosystem they participate in.

Conformance

Authorization Server Requirements A conforming authorization server MUST: Implement the OAuth 2.1 baseline (). Default to pairwise subject identifiers (). Implement the two-track claim model (). Implement ephemeral identity delivery with single-consume semantics (). Implement an assurance level derivation function that satisfies the abstract interface (). Enforce step-up authentication for acr_values and max_age (). Protect consent records with HMAC integrity verification (). Strip identity scopes from persisted consent (). Support back-channel logout (). Publish OIDC Discovery metadata.

Client Requirements A conforming client MUST: Use PKCE with S256 and PAR for all authorization requests. Include the resource parameter on PAR requests. Support DPoP for token binding. Consume identity claims from the userinfo endpoint, not from id_token claims alone. Treat userinfo identity claim delivery as single-consume (do not retry expecting the same data).