Consent protocol: Internet-Draft -03
XCIM records explicit consent from the person controlling a recipient email address to an identified sender for specified types of communication. An independent third party attests the consent, with immutable evidence anchored in a blockchain.
Revision -03 specifies EVP, OAuth with authenticated provider API verification, and OpenID Connect (OIDC) as alternative methods to establish control of the email address giving consent. An issuer may use any one admitted method after its required checks. Address verification alone does not grant permission: the same recipient must separately and explicitly accept the identified sender and communication types.
Corrected scope and revision status · eXplicit Consent-Identified Mail (XCIM): draft-saez-xcim-03 · Published text.
This is an individual Internet-Draft with intended status Experimental. Publication does not imply IETF endorsement, working-group adoption or an approved RFC. Amoy provisioning and live-node trials remain paused.
Explicit consent protocol
XCIM records explicit consent from the person controlling a recipient email address to an identified sender for specified types of communication. An independent third party attests the consent, with immutable evidence anchored in a blockchain.
What XCIM establishes
The attestation relates a recipient address, an identified sender, explicitly accepted communication types, the consent decision and its time. Examples of communication types include promotional and transactional email. Each accepted type requires explicit consent; a transactional label does not manufacture a grant.
The issuer verifies control of the address and observes a separate consent decision. The blockchain preserves evidence of the attestation and its history. It does not replace trust in that third party's observation. Privacy-preserving commitments can anchor evidence without placing raw addresses or identity tokens on a public blockchain.
Address control: EVP, OAuth or OIDC
Revision -03 specifies EVP, OAuth with authenticated provider API verification, and OpenID Connect (OIDC) as alternative methods to establish control of the email address giving consent. An issuer may use any one admitted method after its required checks. Address verification alone does not grant permission: the same recipient must separately and explicitly accept the identified sender and communication types.
| Alternative | Required evidence |
|---|---|
| EVP (evp-01) | Validated provider token and browser-key binding, with exact origin, nonce, freshness and authenticated handoff under the admitted EVP policy. |
| OAuth (oauth-01) | Authorization code with PKCE S256 and transaction binding; an authenticated current-account provider API must supply the verified email address bound to that account. A bearer token alone is insufficient. |
| OIDC (oidc-01) | Validated ID Token, issuer, audience, subject, nonce and freshness; email_verified must be Boolean true. Any UserInfo subject must match the ID Token subject. |
Each method requires an explicitly admitted policy and binding to the same recipient's separate consent decision. Browser/provider availability and provider-specific verification remain deployment dependencies. The official Internet-Draft specifies the complete requirements.
Immutable history and revocable consent
An issuance record remains immutable. Withdrawal and later grants are recorded as subsequent evidence; expiry remains part of the signed grant. An authentic historical grant alone does not establish that consent is currently active. A verifier evaluates current status for the exact recipient, sender and requested communication type.
Independent of any individual message
Consent can be verified without possessing an email. XCIM does not bind consent to message content, a Message-ID, an email signature, an SMTP transaction or a delivery path. It does not classify the content of messages or attest that a message's declared type is accurate.
A destination mail server may use verified consent as a positive policy signal. It can authenticate the sender using external mechanisms, such as DKIM or DKIM2, map that authenticated identity to the consented sender and query XCIM for the recipient and communication type. That integration is optional and does not make message authentication part of the XCIM core. Consent does not guarantee delivery or inbox placement.
Substantive correction from -01
- Center the protocol on recipient-to-sender consent, independently attested and blockchain anchored.
- Remove mandatory Message Presentation, Message Signer Authorization, content commitments, XCIM mail headers, DKIM processing and SMTP replay coordination from core conformance.
- Retain consent evidence, recipient and sender identification, explicit types, issuer authority, privacy, revocation and freshness.
- Keep previous publications and fixture archives identifiable as historical work. Their message-processing tests do not validate the corrected consent protocol.
Publication and implementation status
The corrected revision is published; its official text is linked above.
Independent interoperability, external review and deployment evidence are separate from publication. No new infrastructure, live Amoy node trial or production-readiness claim is part of this correction.
C01 local reference artifacts
These preserved artifacts are the revision -02 baseline. They do not test the EVP or OAuth additions in -03.
The local suite reports 101/101 passing cases. It exercises real Ed25519 signatures using public test keys, consent queries without email input, explicit types, withdrawal and rejection cases. Its blockchain adapter is a TEST ONLY equality stub; successful consent checks still return an indeterminate public result. These tests do not establish chain finality, live third-party observation, durable storage or independent interoperability.
- Artifact scope and reproduction guide · C01 development contract
- Closed JSON schema · Local verifier source · Test generator and runner
- Executed test report · Coverage and remaining work
- Synthetic grant evidence · Partial withdrawal example · Message-independent query · Test-only verifier policy
- Download the complete local suite and vectors
These development artifacts support review. The current official draft is identified above; publication of these examples does not make a test-only adapter a deployable blockchain verifier.
Historical material
P1 message-binding experiments, AS01 authority/state experiments, AN01 anchor experiments and NB01 node experiments remain available for traceability. They are not required profiles of the corrected consent core. Historical artifact hashes and current editorial status.