Explicit consent
for email.
A recipient authorizes an identified sender for specific types of communication. An independent attester records that decision, with verifiable evidence anchored in a blockchain.
Latest specification · draft-saez-xcim-04
Experimental individual Internet-Draft. A bounded C01/SR01 testnet pilot verified consent reuse and revocation on 26 October 2026; production readiness remains open.
Email-verification protocols can establish control of an address. XCIM adds a separate assertion: that the independently verified recipient explicitly authorized an identified sender for defined communication purposes.
XCIM is designed to complement SPF, DKIM, DMARC, ARC, EVP, OpenID Connect and existing unsubscribe mechanisms. It does not replace them, guarantee inbox placement, or establish universal legal compliance.
Introduction
Email authentication mechanisms can identify sending infrastructure and domain responsibility, but they do not independently establish that a particular recipient authorized an identified sender entity to send a defined category of communication.
XCIM introduces a portable consent receipt issued by an independent XCIM Consent Issuer after independently verifiable identity evidence is validated and an explicit communication-permission decision is presented on issuer-controlled infrastructure.
Address-control evidence may come from EVP, OAuth with authenticated provider API verification, or OpenID Connect (OIDC). Identity verification alone is never treated as communication consent.
The signed receipt records the historical decision. Verification combines that receipt with current revocation state, the identified sender entity, accepted communication types, issuer authority and immutable blockchain evidence under local trust policy. No message or sender-domain authentication result is required by the consent core.
Read the protocol introduction →Identity verification and communication permission
XCIM does not define ownership verification for email addresses. Instead, it accepts independently verifiable identity evidence and binds that evidence to a separate, explicit communication-permission decision.
| Layer | Assertion |
|---|---|
| EVP | The current user controls this email address. |
| OIDC | An identity provider authenticated this account and issued verifiable claims. |
| XCIM | This verified recipient explicitly authorized this identified sender for these communication purposes. |
Historical working-draft Identity Evidence profiles: EVP-01 (experimental Email Verification Protocol evidence) and OIDC-01 (OpenID Connect evidence). OIDC-01 has a verified managed pilot. EVP-01 has an experimental vendor-origin handoff; the Emabled-hosted EVP mode remains unavailable. Browser/provider support and an Origin Trial configuration are required for EVP. These earlier implementation results do not demonstrate C01 conformance.
Current scope and historical documents
Read the corrected consent scope and C01 artifacts. The table below preserves the earlier working-draft catalog; it does not define current C01 conformance.
| Document | Type | Status | Link |
|---|---|---|---|
| XCIM Protocol Overview | Informative | Available | View |
| Identity Evidence Profiles | Informative | WD-02 profiles published | Status |
| XCIM Trust and Threat Model | Informative | Drafting | Not yet linked |
| XCIM Core Protocol v0.1 | Historical working-draft requirements | Working Draft 02 + E1 published | Status |
| Receipt Format | Executable draft artifacts | Schemas and vectors published | Review artifacts |
| Consent Manifest | Executable draft artifacts | Schema published; pilot verified | Review artifacts |
| Historical Message Binding experiment, outside the consent core | Draft implementation material | Header adapter and ADRs published | Review tools |
| Registry and Discovery | Draft implementation material | Draft schemas published; service unavailable | Network status |
| Transparency and Current State | Draft algorithms and vectors | Historical public test-network snapshot | Proofs and testnet limits |
| Conformance Vectors | Test material | Published draft | Schemas, vectors and runners |
Relationship to the email stack
| Mechanism | Primary assertion |
|---|---|
| SPF | Which hosts are authorized to use a domain in the SMTP path. |
| DKIM | Which domain signed selected message content and headers. |
| DMARC | Alignment and handling policy for authenticated domain identities. |
| ARC | Preservation of authentication results across intermediaries. |
| EVP | Provider-backed evidence that the current user controls an email address. |
| OIDC | Identity-provider authentication and signed identity claims. |
| List-Unsubscribe | A standardized mechanism for requesting subscription removal. |
| Double opt-in | A confirmation event normally retained within sender or ESP-controlled infrastructure. |
| XCIM | Independently issued, identity-backed, purpose-specific permission evidence with separately resolved current state. |
EVP, OAuth with provider API verification and OIDC may supply address-control evidence to XCIM. None is interpreted by XCIM as communication consent on its own.
Implementation and deployment
XCIM is designed for multiple independent issuers, local receiver trust, portable receipts, and consent verification independent of individual emails.
Reference architecture
- Identified sender entity and explicit scope
- Independently verifiable Identity Evidence
- Issuer-hosted consent presentation
- Exact sender identity, communication types and consent notice
- Signed consent receipts
- Sender entity scope and epoch; fresh consent after ownership or scope change
Verification distribution
- Append-only issuance and revocation events
- Immutable blockchain anchoring of consent evidence
- Portable evidence and message-independent verification
- Receiver-local issuer trust policy
Historical working-draft Identity Evidence profiles: EVP-01 (experimental Email Verification Protocol evidence) and OIDC-01 (OpenID Connect evidence). EVP-01 is experimental and available only through the configured vendor-origin handoff. The Emabled-hosted EVP mode remains unavailable.
Emabled is the deployed managed XCIM Consent Issuer operated by We Are 14 Inc. Its earlier-profile sandbox exercises company and ESP workspaces, hosted consent, signed receipts, revocation, authorized list evaluation, lifecycle webhooks and public issuer keys. It is not part of the normative protocol and is not the only issuer XCIM is designed to support.
Historical managed pilot: consent and list evaluation
The MuMaps managed pilot exercised Google registration, issuer-hosted consent, a signed receipt, authorized ESP CSV/ZIP evaluation, authenticated revocation and list re-evaluation. Reviewed 2026-10-14.
This is an earlier operator-managed pilot, not a C01 conformance result. Its first public proof snapshot is anchored on a test network; independent sender/receiver interoperability remains pending.
Earlier pilot evidence is preserved in the historical test-network report. It does not demonstrate operational C01/SR01 conformance.
Implement XCIM
Companies and ESPs can request a managed pilot to capture permission and evaluate authorized lists. Mailbox providers, ISPs and technical teams can use the published tools in shadow mode and help shape portable email permission and verifiable list provenance.
Development and governance
XCIM was initiated by We Are 14 Inc. and remains under founder-led Experimental project governance. Draft schemas, byte-level decisions and test vectors are published; the reference implementation has a managed pilot. Working Draft 02 + E1 is published; independent review and interoperable network operation remain release gates.
XCIM is not currently an IETF standard, is not operated by an independent foundation, and does not yet claim a formal multi-stakeholder working group.
Related work
XCIM consumes independently verifiable identity evidence rather than defining email-identity verification itself. The current draft work includes an OIDC profile and an experimental EVP profile. XCIM also borrows transparency patterns from Certificate Transparency and authenticated data structures for independently checkable history and state.
Review related protocols and standards →Earlier working drafts and pilot results remain in the development archive and evidence reports. Current conformance is defined by the published Internet-Draft.