Draft email protocol · Phase 0 · Experimental

eXplicit Consent-Identified Mail (XCIM)

XCIM is a draft email protocol for associating independently issued, identity-backed permission evidence with an application, a recipient, defined communication purposes, and currently authorized sending infrastructure.

Email-verification protocols can establish control of an address. XCIM adds a separate assertion: that the independently verified recipient explicitly authorized a specific application 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.

STATUSDraft v0.1
MATURITYPhase 0 · Experimental
PRODUCTIONNot recommended
INITIATED BYWe Are 14 Inc.
REFERENCE XCIM CONSENT ISSUEREmabled sandbox active

Introduction

Email authentication mechanisms can identify sending infrastructure and domain responsibility, but they do not independently establish that a particular recipient authorized a particular application 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.

Identity evidence may come from profiles such as OpenID Connect or, experimentally, the Email Verification Protocol (EVP). Identity verification alone is never treated as communication consent.

The signed receipt records the historical decision. Verification combines that receipt with current revocation state, application identity, sender-domain bindings, issuer policy, and receiver-local trust.

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.

Identity evidence is not consent
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 application for these communication purposes.

Identity Evidence profiles currently under development: EVP-01 (experimental Email Verification Protocol evidence) and OIDC-01 (OpenID Connect evidence). EVP-01 is not universally available.

Current documents

XCIM document publication status
Document Type Status Link
XCIM Protocol Overview Informative Available View
Identity Evidence Profiles Informative Drafting Status
XCIM Trust and Threat Model Informative Drafting Not yet linked
XCIM Core Protocol v0.1 Normative Publication pending Status
Receipt Format Normative Drafting Not yet linked
Consent Manifest Normative Drafting Not yet linked
Message Binding Normative Drafting Not yet linked
Registry and Discovery Normative Drafting Not yet linked
Transparency and Current State Normative Drafting Not yet linked
Conformance Vectors Test material Published draft Schemas, vectors and runners

Open the document index →

Relationship to the email stack

Mechanisms and their primary assertions
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 and OIDC may supply Identity Evidence to XCIM. Neither 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 verification that does not require a per-message call to a commercial issuer.

Reference architecture

  • XCIM application identity and application signing key
  • Independently verifiable Identity Evidence
  • Issuer-hosted consent presentation
  • Versioned Consent Manifest
  • Signed consent receipts
  • Application and sender-domain epochs

Verification distribution

  • Append-only issuance and revocation events
  • Public root anchoring profile
  • Resolver-based local verification
  • Receiver-local issuer trust policy

Identity Evidence profiles currently under development: EVP-01 (experimental Email Verification Protocol evidence) and OIDC-01 (OpenID Connect evidence). EVP-01 is not universally available.

Emabled is the deployed managed XCIM Consent Issuer operated by We Are 14 Inc. Its sandbox exercises hosted consent, signed receipts, revocation processing, 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.

Implement XCIM

ESPs, mailbox providers, ISPs and technical teams can test the draft in shadow mode and help shape the first interoperable profile for portable email permission and verifiable list provenance.

Development and governance

XCIM was initiated by We Are 14 Inc. and remains under founder-led Phase 0 governance while the v0.1 byte-level formats, test vectors, security model, and reference implementation are completed.

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 →