Working draft for public review. Not a stable standard, IETF adoption, certification or production recommendation. Experimental profiles require explicit opt-in.

EVP-01 — Experimental Profile

WD-02 · Experimental and explicit opt-in · Receipt wire version 0.2

1. Scope and external dependency

EVP-01 maps validated Email Verification Protocol evidence into an issuer-controlled XCIM consent decision. The external Email Verification Protocol proposal is a separate evolving specification. This XCIM document does not make it a final standard, guarantee browser/provider availability or claim endorsement by its authors.

The mapping in this profile documents the experimental receipt structure used by an implementation adapter. It is published for review, not declared interoperable or production-ready. A schema fixture is not an actual browser/provider verification. No public EVP end-to-end interoperability result is asserted by WD-02 or the OIDC-based Amoy evidence.

Adapters MUST pin and record the exact external protocol revision, browser API/transport behavior and adapter version they validate. This publication intentionally does not invent a universal wire format for the external EVT or freeze an unspecified browser revision. Until a concrete combination is reviewed and tested, a claimed EVP deployment MUST remain experimental and opt-in.

2. Selection and versioning

This profile selects exactly xcim_version: "0.2", object_type: "xcim_receipt" and issuance_profile: "evp_hosted_consent". It does not change every core object to version 0.2. Supporting receipt 0.1, a proof envelope 0.1 or the schema selector does not enable this profile automatically.

Implementations MUST reject cross-version/profile combinations and MUST require explicit experimental support and policy. They MUST NOT cast an OIDC ID token into EVP evidence, append new fields to an old signed receipt, or silently accept an unknown future receipt version. A receiver that does not support this profile MUST withhold a positive XCIM result for it.

The experimental receipt schema and EVP evidence schema describe the public projection. Their versioned bytes and this draft's tests distinguish structural support from external cryptographic validation.

Issuers advertising this profile MUST use metadata 0.2 with evp_hosted_consent and receipt version 0.2. Legacy metadata 0.1 cannot advertise EVP and MUST NOT be extended in place. Receivers require both advertised capabilities and explicit experimental local policy; metadata alone is insufficient.

3. Validation before consent

Before accepting evidence, the Consent Issuer MUST validate the expected email binding, required verified-address claim, intended audience/origin, one-time session nonce, issue/expiry limits, identity-issuer signature and authorized key, browser key binding and any required selective-disclosure digest/binding for the pinned external revision. DNS delegation, HTTPS issuer metadata and key discovery MUST be authenticated and SSRF-safe.

The issuer MUST bind the validated evidence to the stored session's recipient, application/epoch, verification origin, return URI and manifest. Browser-supplied changes to these authorities or the nonce MUST NOT be accepted. A vendor backend may relay raw evidence over a scoped authenticated backchannel; it MUST NOT replace it with an assertion that validation succeeded.

Raw EVT material MUST NOT be published in the receipt, log or chain. Private retention, if necessary for diagnostics, SHOULD be encrypted, access-controlled and short-lived. A token fingerprint is not independently validated evidence by itself. Validation must be fail-closed for unsupported revisions, missing browser/provider support, absent required trial configuration, invalid signature/binding, replay or indeterminate discovery.

4. Delivery-mode boundary

The design permits an issuer-origin identity form or an origin-bound vendor form followed by a scoped handoff. These are integration modes, not two different meanings of consent. An actual implementation MUST declare which mode and pinned external revision it has exercised; publishing a profile is not a claim that both modes are available.

A vendor-origin handoff requires active exact-domain authority for consent_presentation_delegate, an authenticated application backend and a nonce frozen before token processing. A vendor-controlled form may request identity evidence, but the final purpose-specific consent MUST remain on the Consent Issuer's top-level surface. Neither mode permits the vendor to grant communication permission or issue Consent Issuer receipts.

If EVP is unavailable, an issuer MAY offer OIDC as a separate explicitly chosen flow. It MUST NOT treat EVP failure as OIDC success or imply that a fallback receipt contains EVP evidence.

5. Public mapping

The receipt's application object contains exactly app_id, app_epoch, app_key_id and identity_profiles. The profiles list MUST be unique and include evp-01; it MAY also declare oidc-01. OAuth client fields are not required in this object. The recipient's assurance is evp_email_control_verified, with an opaque pairwise recipient ID.

The closed Identity Evidence object contains profile: "evp-01", evidence_type: "email_verification_token", the HTTPS identity_issuer, identity_issuer_commitment, verification_origin, evidence_fingerprint, external_protocol_revision, adapter_version, authenticated_at, nonce_commitment and the claims object.

The issuer commitment is:

SHA-256("XCIM-IDENTITY-ISSUER-0.1\0" || UTF8(identity_issuer))

The source URI MUST be the normalized HTTPS identity-issuer string whose exact bytes were committed. The fingerprint commits to the adapter's canonical validated evidence representation under its pinned external revision; different adapters MUST NOT assert interoperable fingerprint derivation without a shared exact recipe and vectors. This is an explicit remaining review gate, not authority to choose an undocumented digest.

The WD-02 encoding rules define that normalization exactly. The published identity_issuer MUST already equal the normalized form, and verification_origin MUST equal the serialized HTTPS origin without a path. These rules do not normalize or rewrite OIDC issuer identifiers or previously signed evidence.

The seven public claim flags are email_verified, audience_verified, nonce_verified, freshness_verified, identity_signature_verified, browser_key_binding_verified and issuer_dns_binding_verified. Each MUST be true for an issued verified receipt. They are assertions signed by the Consent Issuer, not substitutes for performing those validations. Selective-disclosure validation, when required by the external revision, remains mandatory even though this projection has no separate flag for it.

The shared presentation/permission structures retain their established 0.1 shapes. Receipt signatures retain application/xcim-receipt+jcs, and receipt commitments retain the XCIM-RECEIPT-0.1\0 domain tag. Schema selection uses the signed receipt version/profile, not the media type alone.

WD-02 further constrains every timestamp in receipt 0.2 to an uppercase Z, including presentation.accepted_at, every non-null permission granted_at and expires_at, and the top-level and evidence timestamps. Reusing a 0.1 structure does not waive that constraint. The revision-specific schema enforces it without modifying the historical schemas.

6. Negative tests, maturity and outstanding work

Tests MUST reject false/missing claim flags, extra raw token/email fields, unsupported profile/version, arbitrary OAuth fields in the EVP application object, missing EVP support, wrong issuer commitment, wrong nonce/origin/audience, expired token, broken key/disclosure binding, replay and consent that was never explicitly granted.

The published WD-02 structural fixtures cover shape, profile dispatch, forbidden fields and commitment relationships using synthetic objects. They do not perform external EVP token validation, browser key-binding validation or DNS-backed identity discovery. Public browser/provider end-to-end evidence, exact cross-adapter fingerprint vectors, external protocol revision interoperability and independent security/privacy review remain open before a non-experimental claim.

The core applies in addition to this profile. General receipt acceptance MUST NOT be broadened to experimental support merely to make a test fixture pass.