Individual Submission G. Valverde Internet-Draft Zentity Intended status: Informational 18 April 2026 Expires: 20 October 2026 VEIL: Verified Ephemeral Identity Layer for OAuth 2.1 draft-valverde-oauth-veil-00 Abstract VEIL (Verified Ephemeral Identity Layer) is a security profile of OAuth 2.1 for privacy-preserving identity verification. It separates claims into two tracks: proof claims (boolean verification results, compliance flags, assurance levels) travel through standard token claims, while identity claims (name, date of birth, address, nationality) travel only through an ephemeral, single-consume channel that keeps personally identifiable information off long-lived tokens. Subject identifiers are pairwise by default. Consent records are HMAC-protected. Step-up authentication scales with operation sensitivity. VEIL is the base profile for domain-specific extensions. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 20 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Valverde Expires 20 October 2026 [Page 1] Internet-Draft VEIL April 2026 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 2.2. Versioning . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Transport Constraints . . . . . . . . . . . . . . . . . . . . 6 3.1. Authorization Server Requirements . . . . . . . . . . . . 6 3.2. Client Requirements . . . . . . . . . . . . . . . . . . . 6 4. Subject Unlinkability . . . . . . . . . . . . . . . . . . . . 7 4.1. Default Posture . . . . . . . . . . . . . . . . . . . . . 7 4.2. Derivation . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Token Exchange . . . . . . . . . . . . . . . . . . . . . 8 4.4. Extension Point . . . . . . . . . . . . . . . . . . . . . 8 5. Claim Separation . . . . . . . . . . . . . . . . . . . . . . 8 5.1. The Two Tracks . . . . . . . . . . . . . . . . . . . . . 8 5.2. Scope Families . . . . . . . . . . . . . . . . . . . . . 8 5.3. Delivery Channels . . . . . . . . . . . . . . . . . . . . 9 5.4. Sybil Nullifiers . . . . . . . . . . . . . . . . . . . . 10 6. Transient Disclosure . . . . . . . . . . . . . . . . . . . . 10 6.1. Single-Consume Properties . . . . . . . . . . . . . . . . 10 6.2. Intent Flow . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Exclusions . . . . . . . . . . . . . . . . . . . . . . . 12 7. Tiered Verification . . . . . . . . . . . . . . . . . . . . . 12 7.1. Abstract Interface . . . . . . . . . . . . . . . . . . . 12 7.2. Derivation Requirements . . . . . . . . . . . . . . . . . 13 7.3. Step-Up Enforcement . . . . . . . . . . . . . . . . . . . 13 8. Signing Agility . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Algorithm Selection . . . . . . . . . . . . . . . . . . . 14 8.2. Key Management . . . . . . . . . . . . . . . . . . . . . 14 9. Tamper-Evident Consent . . . . . . . . . . . . . . . . . . . 15 9.1. Scope Verification . . . . . . . . . . . . . . . . . . . 15 9.2. Tamper Response . . . . . . . . . . . . . . . . . . . . . 15 9.3. Identity Scope Stripping . . . . . . . . . . . . . . . . 15 10. Federated Session Termination . . . . . . . . . . . . . . . . 16 10.1. Back-Channel Logout . . . . . . . . . . . . . . . . . . 16 10.2. Extension Coordination . . . . . . . . . . . . . . . . . 16 11. Machine-Readable Surfaces . . . . . . . . . . . . . . . . . . 16 11.1. OIDC Discovery Extensions . . . . . . . . . . . . . . . 16 11.2. Extension Discovery . . . . . . . . . . . . . . . . . . 17 12. Compositional Extension . . . . . . . . . . . . . . . . . . . 17 Valverde Expires 20 October 2026 [Page 2] Internet-Draft VEIL April 2026 12.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 17 12.2. Extension Boundaries . . . . . . . . . . . . . . . . . . 17 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13.1. PII Exposure Window . . . . . . . . . . . . . . . . . . 18 13.2. Correlation Resistance . . . . . . . . . . . . . . . . . 18 13.3. Sender Constraining . . . . . . . . . . . . . . . . . . 18 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 14.1. Double Anonymity . . . . . . . . . . . . . . . . . . . . 19 14.2. Sybil Nullifier Privacy . . . . . . . . . . . . . . . . 19 14.3. Session Metadata Nullification . . . . . . . . . . . . . 19 14.4. Provider Fingerprint Removal . . . . . . . . . . . . . . 19 14.5. Claim Specificity . . . . . . . . . . . . . . . . . . . 20 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 15.1. OAuth Parameter Registries . . . . . . . . . . . . . . . 20 15.2. Well-Known URI Registrations . . . . . . . . . . . . . . 20 15.3. Assurance Certification Values (acr) . . . . . . . . . . 20 15.4. Verifiable Credential Type Identifiers . . . . . . . . . 20 16. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 21 16.1. Authorization Server Requirements . . . . . . . . . . . 21 16.2. Client Requirements . . . . . . . . . . . . . . . . . . 21 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 17.1. Normative References . . . . . . . . . . . . . . . . . . 22 17.2. Informative References . . . . . . . . . . . . . . . . . 23 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 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 [OIDC-Core] 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: Valverde Expires 20 October 2026 [Page 3] Internet-Draft VEIL April 2026 +=========================+=======================================+ | Concern | Specifications | +=========================+=======================================+ | Authorization Framework | OAuth 2.1 [I-D.ietf-oauth-v2-1] | +-------------------------+---------------------------------------+ | Proof Key | PKCE [RFC7636], mandatory | +-------------------------+---------------------------------------+ | Pushed Authorization | PAR [RFC9126], mandatory | +-------------------------+---------------------------------------+ | Sender Constraining | DPoP [RFC9449] | +-------------------------+---------------------------------------+ | Identity Layer | OpenID Connect Core 1.0 [OIDC-Core] | +-------------------------+---------------------------------------+ | Structured Intent | Rich Authorization Requests [RFC9396] | +-------------------------+---------------------------------------+ | Token Exchange | [RFC8693] | +-------------------------+---------------------------------------+ | Token Introspection | [RFC7662] | +-------------------------+---------------------------------------+ | Back-Channel Logout | [OIDC-BCL] | +-------------------------+---------------------------------------+ Table 1 This document specifies: a two-track claim model (Section 5), an ephemeral identity delivery channel (Section 6), pairwise subject identifiers as the default (Section 4), an abstract interface for assurance level derivation (Section 7), HMAC-verified consent integrity (Section 9), and an extension profile architecture for domain-specific profiles (Section 12). 2. Conventions and Terminology 2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Valverde Expires 20 October 2026 [Page 4] Internet-Draft VEIL April 2026 2.2. 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. 2.3. 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. Valverde Expires 20 October 2026 [Page 5] Internet-Draft VEIL April 2026 3. 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. 3.1. Authorization Server Requirements The authorization server MUST: * Support OAuth 2.1 [I-D.ietf-oauth-v2-1] authorization code flow with PKCE. * Require Pushed Authorization Requests (PAR, [RFC9126]) for all authorization requests. * Support DPoP [RFC9449] 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 [RFC9396] for structured intent. * Support Token Exchange [RFC8693] for audience rebinding and scope attenuation. * Support Back-Channel Logout [OIDC-BCL] for federated session termination. 3.2. Client Requirements Clients MUST: * Use PKCE with S256 challenge method. * Submit authorization parameters via PAR before initiating the authorization flow. * Include the resource parameter [RFC8707] on PAR requests. Valverde Expires 20 October 2026 [Page 6] Internet-Draft VEIL April 2026 * Support DPoP for sender-constrained token usage. Clients MUST NOT: * Use the implicit grant. * Use the resource owner password credentials grant. 4. 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. 4.1. 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. 4.2. Derivation Pairwise subject identifiers are derived as: sub = HMAC-SHA-256(PAIRWISE_SECRET, sector + "." + userId) 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. Valverde Expires 20 October 2026 [Page 7] Internet-Draft VEIL April 2026 4.3. Token Exchange When performing Token Exchange [RFC8693] 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. 4.4. Extension Point Extension profiles MAY apply pairwise derivation to additional token claims. PACT [I-D.valverde-oauth-pact] extends pairwise derivation to the act.sub claim for agent session identifiers. 5. 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 (Section 5.2), consent decisions (Section 5.3), and delivery mechanisms (Section 6). 5.1. 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 (Section 6). 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. 5.2. 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. Valverde Expires 20 October 2026 [Page 8] Internet-Draft VEIL April 2026 * 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 (Section 6). * 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. 5.3. 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 Section 6. 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 Section 5.4: 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). Valverde Expires 20 October 2026 [Page 9] Internet-Draft VEIL April 2026 5.4. Sybil Nullifiers The profile defines an optional proof:sybil scope that produces a per-RP unlinkable nullifier: sybil_nullifier = HMAC-SHA-256( DEDUP_HMAC_SECRET, dedupKey + ":" + clientId ) 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. 6. 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. 6.1. Single-Consume Properties When identity scopes are approved, the authorization server stages PII in an in-memory store with the following properties: Valverde Expires 20 October 2026 [Page 10] Internet-Draft VEIL April 2026 +=============+=================================================+ | 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 | Intent JTIs MUST be persisted in durable | | protection | 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 | Intent and stage endpoints MUST be rate-limited | | limiting | per user identity to prevent brute-force unlock | | | attempts and ephemeral store flooding. | +-------------+-------------------------------------------------+ | Ambiguity | If multiple entries exist for the same userId | | safety | when the consuming endpoint lacks clientId | | | context, the server MUST return no claims | | | rather than risk cross-client PII misdelivery. | +-------------+-------------------------------------------------+ Table 2 6.2. 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: 1. *User action.* The user performs a credential-specific unlock action (the mechanism is implementation-specific). Valverde Expires 20 October 2026 [Page 11] Internet-Draft VEIL April 2026 2. *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. 3. *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. 4. *Consume.* The relying party calls the userinfo endpoint. The server retrieves and deletes the staged entry in a single atomic operation. 6.3. 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. 7. 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. 7.1. 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: Valverde Expires 20 October 2026 [Page 12] Internet-Draft VEIL April 2026 +==============+=========+==================================+ | 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). | +--------------+---------+----------------------------------+ Table 3 7.2. 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. 7.3. 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 Valverde Expires 20 October 2026 [Page 13] Internet-Draft VEIL April 2026 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. 8. Signing Agility 8.1. 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. 8.2. Key Management Signing keys MUST be encrypted at rest (SHOULD use AES-256-GCM with a dedicated key encryption key). Valverde Expires 20 October 2026 [Page 14] Internet-Draft VEIL April 2026 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. 9. 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 (Section 9.1), and identity scopes are excluded from durable consent storage (Section 9.3). 9.1. 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: scope_hmac = HMAC-SHA-256(SECRET, length_prefix(context) || length_prefix(userId) || length_prefix(clientId) || length_prefix(referenceId) || length_prefix(sorted_scopes)) Length-prefixed encoding prevents concatenation collisions. The HMAC key MUST be derived from the server's base secret via a KDF (e.g., HKDF [RFC5869]) 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. 9.2. 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. 9.3. 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. Valverde Expires 20 October 2026 [Page 15] Internet-Draft VEIL April 2026 10. Federated Session Termination 10.1. Back-Channel Logout The authorization server MUST support OIDC Back-Channel Logout [OIDC-BCL] for federated session termination. On user sign-out: 1. Query all registered clients with a backchannel_logout_uri. 2. For each: build a logout token JWT with the client's pairwise sub and sid (if backchannel_logout_session_required). 3. POST the logout token to the client's endpoint. 4. Retry with exponential backoff on transient failures. 10.2. Extension Coordination Extension profiles MAY define additional cleanup actions triggered by logout. 11. Machine-Readable Surfaces 11.1. 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"]). Valverde Expires 20 October 2026 [Page 16] Internet-Draft VEIL April 2026 11.2. 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. 12. Compositional Extension Domain-specific profiles (agent delegation, verifiable credentials, regulatory compliance) extend VEIL through the mechanism defined below. Extensions MUST NOT modify VEIL itself. 12.1. 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. 12.2. 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 [RFC8693]. * Define additional consent routing logic. Valverde Expires 20 October 2026 [Page 17] Internet-Draft VEIL April 2026 * Extend the ephemeral store TTL for their specific flow patterns. 13. Security Considerations Implementations MUST satisfy the security considerations of each composed specification: OAuth 2.1 [I-D.ietf-oauth-v2-1], PKCE [RFC7636], PAR [RFC9126], DPoP [RFC9449], RAR [RFC9396], Token Exchange [RFC8693], OIDC Core 1.0 [OIDC-Core], and OIDC Back-Channel Logout 1.0 [OIDC-BCL]. 13.1. 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. 13.2. 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. 13.3. 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). 14. 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 (Section 5), pairwise subjects (Section 4), sybil nullifiers (Section 5.4), and identity claims (PII), which flow only through the ephemeral channel (Section 6). Cross-RP correlation through subject identifiers requires explicit opt-in at registration (subject_type: "public"); identity disclosure requires explicit opt- Valverde Expires 20 October 2026 [Page 18] Internet-Draft VEIL April 2026 in at authorization (identity scopes, per-scope user consent). 14.1. 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). 14.2. Sybil Nullifier Privacy The sybil_nullifier (Section 5.4) 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. 14.3. 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. 14.4. Provider Fingerprint Removal Four concrete signals can fingerprint the authorization server and enable cross-RP provider correlation: 1. 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. 2. Trust framework naming. The trust framework identifier in identity assurance claims SHOULD identify the regulatory framework (e.g., eidas), not the provider name. 3. 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. 4. Structural fingerprinting. SD-JWT credentials SHOULD include decoy disclosures to prevent fingerprinting via disclosed claim set analysis. Valverde Expires 20 October 2026 [Page 19] Internet-Draft VEIL April 2026 14.5. 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. 15. 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. 15.1. 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 Section 3). Extension profiles that build on VEIL are responsible for registering any new OAuth identifiers they introduce. 15.2. Well-Known URI Registrations VEIL relies on the existing well-known URI registrations openid- configuration (OIDC Discovery 1.0) and oauth-authorization-server [RFC8414]. It does not register a new well-known URI. Extension profiles MAY register their own well-known URI suffixes per [RFC8615]. 15.3. 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 Section 7.3). 15.4. Verifiable Credential Type Identifiers Where a deployment emits verifiable credentials, credential type identifiers (VCT) MUST be provider-neutral URNs (see Section 14.4). VEIL does not define or reserve specific VCT URNs; deployments choose values consistent with the credential ecosystem they participate in. Valverde Expires 20 October 2026 [Page 20] Internet-Draft VEIL April 2026 16. Conformance 16.1. Authorization Server Requirements A conforming authorization server MUST: * Implement the OAuth 2.1 baseline (Section 3). * Default to pairwise subject identifiers (Section 4). * Implement the two-track claim model (Section 5). * Implement ephemeral identity delivery with single-consume semantics (Section 6). * Implement an assurance level derivation function that satisfies the abstract interface (Section 7). * Enforce step-up authentication for acr_values and max_age (Section 7.3). * Protect consent records with HMAC integrity verification (Section 9). * Strip identity scopes from persisted consent (Section 9.3). * Support back-channel logout ([OIDC-BCL]). * Publish OIDC Discovery metadata. 16.2. 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). 17. References Valverde Expires 20 October 2026 [Page 21] Internet-Draft VEIL April 2026 17.1. Normative References [I-D.ietf-oauth-v2-1] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Authorization Framework", Work in Progress, Internet- Draft, draft-ietf-oauth-v2-1-15, 2 March 2026, . [OIDC-BCL] OpenID Foundation, "OpenID Connect Back-Channel Logout 1.0 incorporating errata set 1", 14 September 2022, . [OIDC-Core] OpenID Foundation, "OpenID Connect Core 1.0 incorporating errata set 2", 15 December 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . Valverde Expires 20 October 2026 [Page 22] Internet-Draft VEIL April 2026 [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . 17.2. Informative References [FAPI-2] OpenID Foundation, "FAPI 2.0 Security Profile", n.d., . [HAIP] OpenID Foundation, "OpenID4VC High Assurance Interoperability Profile 1.0", n.d., . [I-D.valverde-oauth-pact] Valverde, G., "PACT: Private Agent Consent and Trust Profile", 2026. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, . Acknowledgments The author thanks the OAuth working group and the OpenID Foundation for the foundational specifications on which this profile composes, and the FAPI 2.0 [FAPI-2] and HAIP [HAIP] working groups whose security-profile patterns informed this document's structure. Valverde Expires 20 October 2026 [Page 23] Internet-Draft VEIL April 2026 Author's Address Gustavo Valverde Zentity Portugal Email: g.valverde02@gmail.com Valverde Expires 20 October 2026 [Page 24]