Introduction

XCIM records explicit consent from the person controlling a recipient email address to an identified sender for specified communication types. A third party attests the consent, and immutable evidence is anchored in a blockchain. No individual email is needed to verify that relationship.

Problem statement

Email authentication can establish facts about domains and messages, but it does not by itself prove that a recipient authorized an identified sender entity for a particular type of communication. XCIM explores a portable proof layer for that missing relationship.

Protocol model

1. A sender entity requests consent for precisely described communication types. Its company identity and scope are shown to the recipient.
2. An XCIM Consent Issuer obtains and validates acceptable Identity Evidence for the recipient.
3. The XCIM Consent Issuer presents a frozen Consent Manifest on issuer-controlled infrastructure.
4. The recipient explicitly grants or declines each applicable permission.
5. The XCIM Consent Issuer signs an attestation binding the recipient, identified sender entity, exact communication types and explicit decision.
6. The signed attestation is included in immutable blockchain-anchored evidence.
7. A verifier checks signed evidence, current permission state, current recipient-to-sender scope, accepted communication type and local trust policy. No message or mail header is required.

Identity Evidence

XCIM separates identity verification from communication permission. The draft defines an extensible Identity Evidence layer. Current work includes:

• EVP-01 - experimental evidence from the Email Verification Protocol.
• OAuth-01 - authorization code with PKCE and an authenticated provider API proving the verified email of the account authorizing the transaction.
• OIDC-01 - validated OpenID Connect evidence with email_verified true and the required issuer, audience, subject and transaction checks.

Any one admitted method can establish address control after its required checks. Other independently verifiable profiles may be defined later. Identity verification by itself never creates an XCIM communication permission.

Glossary

Identity Evidence

Cryptographically verifiable evidence that establishes control of, or authentication for, the recipient identity used in the XCIM decision.

Identity Issuer

The external authority that produces identity evidence, such as an EVP account authority or OIDC provider.

XCIM Consent Issuer

The independent XCIM actor that verifies accepted identity evidence, presents the frozen Consent Manifest, records the explicit decision, and signs the XCIM receipt.

Consent Manifest

The versioned description of the identified sender entity, communication types, and decision presented to the recipient.

Email Verification Protocol

EVP is an emerging protocol that lets a browser obtain cryptographic proof from an email-account authority that the current user controls an email address, without requiring a verification email. XCIM can consume successful EVP evidence as the identity input to a separate issuer-hosted consent decision.

EVP verifies the address. XCIM attests the permission. EVP remains an active Internet-Draft and browser experiment, not an IETF standard. Its provider and browser behavior may change.

Primary references: IETF Datatracker draft, Chrome August 2026 update, and the WICG proposal.

Trust boundaries

XCIM does not replace SPF, DKIM, DMARC, ARC, mailbox policy, or abuse controls. A successful identity verification MUST NOT be interpreted as marketing, newsletter, promotional, or transactional permission. A valid XCIM proof is one input to a verifier; it is not a guarantee of delivery, safety, or endorsement. Issuers and verifiers remain independently governed.

Current scope

Earlier working-draft implementation evidence includes an Emabled sandbox exercising an OIDC-backed company and ESP pilot with consent, receipts, authorized list evaluation and revocation. The profile-neutral Identity Evidence layer is implemented, and the experimental EVP-01 vendor-origin adapter is deployed. Working Draft 02 + E1 and profile schemas remain available as historical material. They do not establish C01 conformance; current scope and revision status are linked above. The first public Amoy testnet batch now provides historical transparency proofs, not continuously fresh permission status or mainnet operation. See protocol status and implementation status.