Working draft for public review. Not a stable standard, IETF adoption, certification or production recommendation. Experimental profiles require explicit opt-in.
OIDC-01 — Working Draft Profile
Contents
WD-02 · Draft profile · Existing receipt wire version 0.1
1. Scope and status
OIDC-01 supplies Identity Evidence through independently validated OpenID Connect assertions. Its issuance profile is oidc_hosted_consent; consent remains a separate issuer-controlled decision. This document defines the supported baseline's requirements for review, not a claim of provider certification or universal address authority. The core applies in addition to this profile.
An implementation MUST select exactly xcim_version: "0.1", object_type: "xcim_receipt" and issuance_profile: "oidc_hosted_consent". The receipt schema is the existing 0.1 contract and is not widened to accept experimental EVP fields. The OIDC evidence schema exposes the same historical public projection.
2. Identity validation
The issuer MUST use a versioned provider policy and validate the assertion according to OpenID Connect Core and applicable JWT security guidance. At minimum it MUST validate the permitted signing algorithm and provider key, exact issuer, audience and authorized party where applicable, expiration/issue times, the expected one-time nonce, subject and the address claims required by the provider policy.
Token discovery and JWKS updates MUST be HTTPS-only and SSRF-safe, with bounded redirects, sizes, cache lifetimes and deadlines. An untrusted token MUST NOT choose a trusted identity issuer or cause an unbounded fetch. Signature validity alone is insufficient if the assertion is for another client, session or recipient.
The application/client binding used in the flow MUST be active and tied to the intended application epoch. Where a vendor performs a token exchange, the issuer MUST independently verify the identity assertion and a session-bound application-signed exchange result. A callback echo or successful vendor HTTP response is not proof of identity validation. Vendor OAuth secrets and access/refresh credentials MUST NOT be required to be shared with the Consent Issuer.
The expected recipient, nonce, application, client binding, return URI and manifest MUST be frozen into the consent session. Replay protection, decision recording and terminal handling MUST be atomic. Authentication cannot itself grant marketing permission.
3. Public receipt mapping
The receipt includes the following closed profile-specific structures:
| Structure | OIDC-01 mapping |
|---|---|
application |
app_id, app_epoch, app_key_id, oauth_binding_id, provider_issuer, client_id_commitment |
recipient |
Opaque pairwise_id; identity_assurance is oidc_provider_authenticated |
identity_evidence |
evidence_type is oidc_id_token; provider subject/client/nonce commitments, provider policy version, authority class, authentication time and adapter version |
presentation |
Issuer-controlled top-level origin, manifest identity/hash, locale/template version and acceptance time |
The application client commitment MUST equal the evidence client commitment. Authentication time MUST NOT follow consent acceptance, which MUST NOT follow receipt issuance. Commitments MUST decode to their required byte lengths even where a legacy JSON Schema permits a broader string. Raw tokens, recipient addresses and provider subjects MUST NOT be copied into public receipt fields.
The stable application identity remains the XCIM Application ID and application key. These OAuth-specific fields are required by this profile, not by every possible XCIM profile.
The commitment scope rules distinguish issuer-local opaque attestations from publicly reproducible hashes. A receiver MUST NOT guess a subject/client/nonce preimage recipe or infer an email match from a pairwise ID. Issuers MUST publish the versioned adapter recipe used for audit without disclosing salts, keys or identity material. This requirement does not assign a new meaning to historical signed commitments.
4. Address authority and historical compatibility
A provider policy MUST distinguish authority over an address from a provider's assertion that someone previously verified it. Provider name or email_verified alone does not establish domain ownership or a suitable assurance level for every address. A policy that does not support the observed identity MUST yield no active receipt.
The historical 0.1 wire schema includes authority labels provider_authoritative, provider_verified and provider_relay. Structural acceptance of provider_relay is preserved for compatibility; it MUST NOT be treated as an unconditional verified-address class. Current provider policies can reject unsupported or relay identities. The internal policy decision unsupported is not permission to mint a receipt containing a new unsigned interpretation of an old field.
The wire object does not contain an added profile: "oidc-01" member. Its profile is determined from its signed version/type/issuance-profile tuple. Adding that member to an old signed object would change its bytes and is prohibited. A normalized private adapter view MAY contain a profile label, but is not the historical public receipt.
5. Required tests and limits
Tests MUST include wrong issuer/key/audience/client, expired token, nonce mismatch/replay, mismatched expected address, unsupported provider policy, unbound exchange result and identity success without a consent decision. Receipt tests MUST include altered canonical bytes, incorrect client commitment equality, temporal inversion and cross-profile field injection.
Published synthetic vectors exercise signatures and schema/semantic checks. A managed implementation pilot is evidence of one deployment, not an independent sender/receiver interoperability result. Provider availability and identity evidence do not replace receiver checks of current consent, application/domain bindings and local issuer trust.
See the schema catalog, core verification algorithm and change record.