eXplicit Consent-Identified Mail (XCIM)

Introduction The question addressed by XCIM is whether the party controlling recipient address R explicitly authorized identified sender S to send communications of type T, as attested by accepted third party A, and whether that consent remains current. The evidence can be created and verified before any email exists. Verifying it neither consumes the consent nor authorizes a different sender or communication type. A sender in this model is the company or other entity that receives the consent. A technical application, email service provider, OAuth client, domain, and signing key can support that entity but are not automatically equivalent identities. The third party binds the recipient's decision to the identity and scope actually presented to the recipient. Cryptographic signatures authenticate the attester and the recorded statement. Blockchain evidence preserves its committed history under the selected consensus and finality assumptions. Neither mechanism independently observes a human decision or makes a dishonest attester truthful. Explicit trust in the third party remains part of the protocol.

Scope Correction from Revisions -00 and -01 Revisions -00 and -01 made a direct-email presentation profile mandatory, including Message Presentation (MP), Message Signer Authorization (MSA), message content commitments, DKIM checks, and SMTP replay coordination. That integration exceeded the intended scope of XCIM. Revision -02 replaced it with a consent protocol that is independent of individual messages. This is a substantive scope and wire-format change, not a title-only revision. P1 and MAIL01 objects are not accepted as C01 merely by changing their labels. Historical documents and signed bytes retain their original interpretations. Their message-processing requirements and tests do not define conformance to this revision. The consent, identity, cryptographic and publication concepts that remain relevant are specified explicitly below.

Changes from Revision -02 This revision specifies EVP, OAuth-based provider verification and OIDC as alternative address-control methods. No method is universally required. It separates their issuance procedures from the common explicit-consent decision, defines the attester and delegated-origin roles, and requires method-specific admission policy. The consent relationship, communication types, lifecycle and blockchain requirements retain their -02 meanings. No individual email message becomes a core protocol input. C01 retains profile string xcim-consent-01 because the existing oidc-01 fields and their signed meaning are preserved; evp-01 and oauth-01 are explicit new method values. An implementation of -02 that does not support a method MUST reject it rather than reinterpret it as oidc-01. Local admission configuration MUST name the method explicitly when upgrading. Historical WD receipt 0.2 objects are not C01 objects and MUST NOT be relabelled or converted without a new conforming attestation.

Scope and Non-Goals The core covers address control at the time of consent, the sender identity and scope shown to the recipient, the descriptions of the accepted communication types, third-party attestation, immutable blockchain evidence, authenticated withdrawal, and current-state verification. Promotional and transactional communications are examples of types for which explicit consent can be given. A transactional relationship is not itself explicit consent. There is no XCIM requirement to sign or hash an email, carry a particular email header, create one copy per recipient, generate a per-message token, or contact the attester for every email. Email content, MIME, transport paths, forwarding, message replay, SMTP acceptance, and mailbox delivery are outside this core. An implementation MUST NOT require any of them as inputs to core consent verification. A consent result does not certify that a particular message belongs to the queried type. Classification and use of that result belong to the consuming application. XCIM does not guarantee message safety, legal compliance, continued mailbox ownership, or inbox placement.

Requirements Language and Roles The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Recipient: The party whose control of an email address is established for the consent decision; this does not require proof of a civil identity.
Sender: The identified company or other entity and bounded scope to which consent is granted.
Consent Attester: The third party that establishes address control, observes explicit consent, and signs attestations and lifecycle observations. This corresponds to the earlier Consent Issuer role.
Publisher: The party making commitments and lifecycle evidence available and anchoring historical records in an admitted blockchain.
Verifier: A party evaluating consent evidence under previously accepted trust and finality policy. It need not operate an email service.
Communication type: A stable, versioned description of the class of communications agreed to, within the sender scope. It is not a classification of an individual email.
C01: The portable consent object and verification profile defined here, with profile string xcim-consent-01.

Consent Flow and Trust Boundaries

Recipient -- address control + explicit decision --> Attester Sender ---- entity/scope enrollment ---------------> Attester Attester -- signed consent/lifecycle --------------> Publisher Publisher - commitments --------------------------> Blockchain Verifier -- recipient/sender/type query -----------> Evidence Verifier -- accepted trust + verified chain proof -> Consent result Email service (optional) --------------------------> Uses result

The attester authenticates enrollment of the sender identity and scope.
The attester establishes control of the recipient address and observes a separate affirmative decision for the frozen sender, notice and type definitions.
The attester issues the signed consent and publishes an immutable commitment, directly or in the batch defined below, on an admitted blockchain.
Authenticated withdrawal events remove accepted types without changing the historical grant. Fresh signed status reports the current projection.
A verifier checks the exact queried relationship, attestation, historical blockchain evidence and current status. Repeated verification does not consume the grant.

An identity provider and the Consent Attester are different roles even if one organization performs both. The sender's claim that a recipient consented is insufficient. Evidence transport and discovery do not establish trust. A signature by an otherwise unknown attester cannot install that attester into verifier policy.

Common Wire Rules and Cryptography C01 uses JSON , JCS , SHA-256 , Ed25519 , and JWS Flattened JSON Serialization . The fully specified JOSE algorithm identifier is Ed25519, following . All objects specified here are closed: unknown members are rejected. An unsupported profile is not interpreted as an older profile. Input MUST be valid UTF-8 without duplicate member names or invalid Unicode scalar values. JSON number tokens MUST be non-negative integers without fractional or exponent syntax, from 0 through 9007199254740991. Boolean values are not integers. Implicit Unicode normalization is forbidden. JCS ordering and encoding apply exactly; already signed protected headers and payloads MUST contain their canonical bytes. Each envelope contains exactly protected, payload, and signature, encoded with canonical unpadded base64url . Decode and re-encode equality, including unused trailing bits, is REQUIRED. The protected header contains exactly alg, kid, and typ; alg is Ed25519 and typ is application/xcim-consent+json. The type is provisional and not registered. No unprotected header, detached payload, b64=false, key URL, embedded key, or algorithm fallback is accepted. The signature is 64 octets over the ASCII protected segment, a period, and the ASCII payload segment. Every signed payload contains profile equal to xcim-consent-01, its kind, and issuer. The issuer is identical across all objects combined in an Evidence Set. Payload commitments use the following function; the signature envelope is not hashed. Signed kind and profile prevent cross-family reuse. H(P) = base64url(SHA-256( UTF8("XCIM-C01-OBJECT") || 0x00 || JCS(P))) Hashes and recipient salts decode to 32 octets. Times are non-negative integer UTC seconds since the Unix epoch; expiry is exclusive. Epochs and type versions start at one. Issuer, sender, type, policy, log and anchor-profile identifiers are absolute ASCII HTTPS URIs, at most 512 characters, without userinfo, query or fragment; they are compared exactly and MUST NOT trigger automatic discovery. consent_id and event_id are lowercase UUID version 4 URNs as specified in . Random identifiers and salts MUST be generated with a cryptographically secure random source. kid is 1 to 200 printable ASCII characters. Text fields contain 1 to 4096 Unicode scalar values unless a narrower rule is given. Type arrays contain 1 to 64 entries with unique type_id values, sorted in ASCII order of type_id. Arrays of type identifiers use the same ordering and uniqueness. An ordinary JWS envelope is at most 128 KiB; an anchor_batch JWS envelope is at most 512 KiB, with decoded payload at most 256 KiB. Complete evidence is at most 2 MiB and JSON depth at most 16. A batch has at most 4096 leaves. Limits are applied before expensive work; partial verification is not success.

Trust Policy, Keys and Sender Epochs Before evaluating evidence, the verifier administrator installs policy binding the exact issuer to an accepted third-party attester, role-authorized public keys, key identifiers, issuance windows, compromise/revocation state, sender epoch restrictions, admitted address-control policies, withdrawal procedures, supported blockchain profiles, clock bounds and policy expiry. The configuration is authenticated local input, not a member of untrusted Evidence Sets. No trust-on-first-use or self-declared accreditation is implied. kind required signing role sender sender_binding consent consent_attestation revocation consent_revocation status consent_status anchor_batch anchor_publication The signature MUST be authorized for its role and issuer at issued_at, or this_update for status, or created_at for a batch. Current policy determines whether historical signatures remain acceptable after key retirement or compromise. Routine key rotation need not erase historical evidence. The status signing key MUST also be authorized at evaluation time; its validity end limits the positive-result deadline. Compromise handling can invalidate previously accepted signatures under authenticated policy. Role delegation is not inferred. Rotation and recovery require authenticated administrator configuration; new keys cannot authorize their own admission. Losing a policy or rollback-protection store requires authenticated recovery. A missing store MUST NOT silently become an empty trusted history. The attester MUST stop issuing positive status for a sender epoch retired because the identified entity or consent scope changed. A verifier MUST honor known epoch restrictions and MUST NOT return to an older epoch. Changing a domain or technical key does not transfer a consent relationship to another company. A new entity, broader scope, or new epoch requires a new recipient decision and a new consent identifier. Each admitted address-control policy MUST identify exactly one supported method and its immutable validation rules. Admission of one method MUST NOT admit another implicitly. A changed external revision, validation rule or delivery-mode authority requires a new policy identifier and explicit admission. Unknown methods or policies MUST NOT yield a positive consent result. Merely adding a method to a schema grants no trust.

Recipient Address Representation The selected address_profile is ascii-idna15-1. Remove only outer SP and HTAB and require exactly one @. The local part is an ASCII dot-atom: letters, digits and !#$%&'*+-/=?^_`{|}~ separated by single periods. It contains 1 to 64 octets, with no leading, trailing or consecutive periods. Its case, periods and plus tags are preserved. No provider-specific alias equivalence or local-part lowercasing is inferred. Map the domain using non-transitional UTS #46 revision 31 with STD3 rules and Unicode 15.1.0 data , then apply IDNA2008 validation including hyphen, Bidi and Joiner checks . The result is lowercase A-labels of 1 to 63 octets, a domain of at most 253 octets, and a complete address of at most 254 octets. Reject a trailing domain period. Quoted local parts and SMTPUTF8 addresses are unsupported by this address profile. Changing tables or equivalence rules requires another profile. The canonical address is a private verifier input, not an email body or header. The attester derives the recipient commitment from its authenticated observation. A recomputable hash supplied by a sender does not establish address control.

Sender Binding The payload has exactly the following members, in addition to the common semantic constraints: profile, kind, issuer, sender_id, sender_epoch, name, scope, entity_evidence_commitment, issued_at, expires_at kind is sender. name and scope identify the company or other entity and exact brand/service boundaries shown to the recipient. The attester MUST authenticate the enrolling actor's authority to represent that entity and retain the observed identity and scope evidence. A display name supplied by the sender is insufficient. entity_evidence_commitment is a 32-octet commitment to randomized private evidence under the admitted attester policy; it is opaque to the verifier and does not claim a universal legal-entity certification. sender_id is an issuer-assigned stable identifier and MUST NOT be reassigned to another entity. sender_epoch is positive. The binding has finite validity with issued_at earlier than expires_at. Consent embeds H of this exact binding. The signed name and scope, rather than an unrelated website label, are presented during the consent decision. A technical application identifier can be mapped to this identity by a consuming application but cannot silently enlarge the consent scope.

Consent Attestation The payload has exactly the following members, in addition to the common semantic constraints: profile, kind, issuer, consent_id, sender_id, sender_epoch, sender_binding_commitment, address_profile, recipient_salt, recipient_commitment, types, notice, control, decision, accepted_at, issued_at, expires_at kind is consent and decision is exactly explicit_consent. Each types entry contains exactly type_id, version, title and description. The descriptions are the meanings accepted by the recipient and are covered by the signature. notice contains exactly language and text; language is 1 to 35 ASCII characters. control contains exactly method, policy_id, observed_at and evidence_commitment. method is evp-01, oauth-01 or oidc-01. policy_id identifies an immutable policy admitted by the verifier for that exact method. The opaque 32-octet evidence commitment binds the randomized private observation and decision record retained by the attester. Require control.observed_at no later than accepted_at, accepted_at no later than issued_at, and issued_at earlier than finite expires_at. The sender binding MUST already be valid at accepted_at, its commitment and sender identity/epoch MUST match exactly, and its expiry MUST be no earlier than the consent expiry. The admitted policy specifies a maximum age between control observation and acceptance; arbitrarily old authentication is not accepted as current observation. recipient_salt is a fresh random 32-octet value. With the canonical private address, compute the following exact commitment. The signed grant and its salt are access-controlled evidence; only commitments are published in the public anchor batch. recipient_commitment = base64url(SHA-256( UTF8("XCIM-C01-RECIPIENT") || 0x00 || JCS([ issuer, consent_id, sender_id, sender_epoch, address_profile, recipient_salt, canonical_recipient ]))) Every accepted type is explicit. There is no wildcard, implied affiliate permission or inference from a transactional relationship. Changing a description or adding a type requires a new affirmative decision for that meaning and a new consent identifier. Identical identifiers with broader descriptions MUST NOT preserve the old consent. The evidence does not assert that any actual email matches a type description. The tuple (issuer, sender_id, sender_epoch, type_id, version) MUST identify one immutable title and description. A changed definition requires a higher version or a new type_id, as well as a new consent decision. A verifier MUST compare a definition with any previously authenticated definition for that tuple or one supplied by its trusted consuming policy; different meanings at the same tuple are a conflict, not an expansion of consent. An unknown definition can be learned only from accepted attestation evidence, not from an unauthenticated sender label.

Address Control and Separate Consent Decision Address control and communication consent are separate operations. XCIM supports EVP (evp-01), OAuth-based provider verification (oauth-01), and OpenID Connect (oidc-01) as alternatives. An attester MAY implement one or more; a deployment selects a method supported by both the attester and the verifier's admitted policy. These are alternative evidence paths, not cumulative prerequisites or a requirement to migrate to EVP. OAuth-based verification obtains address evidence from an admitted provider API; OIDC validates an ID Token under its authentication protocol. OAuth authorization alone is not proof of address control. None of these operations grants communication consent. Unrelated API authorization and backend authentication remain outside this choice.

OIDC Address Control (oidc-01) OIDC processing uses OpenID Connect Core 1.0 incorporating errata set 2 and JWT security guidance . The attester preselects provider issuer, permitted keys/algorithms, clients, address-authority policy, consent origin and return URI. Use authorization code flow with PKCE and session-bound state and nonce. Token claims MUST NOT choose the trusted provider or cause arbitrary discovery. Validate the signature, issuer, audience, authorized party where applicable, subject, nonce, times and address claims under that policy. The admitted provider must be authoritative for the observed address; email_verified alone is insufficient. The observed canonical address MUST match the frozen recipient. Raw tokens, subjects, credentials and email addresses MUST NOT be placed in public logs or on chain. The authenticated address claims MUST include email_verified as the Boolean true for the address used. If the address is obtained from the OIDC UserInfo endpoint, validate that endpoint under the admitted provider policy and require its subject to match the validated ID Token subject. A verified claim still requires the provider's address-authority assessment; it does not establish perpetual ownership of the mailbox. Record control.method as oidc-01 only after validating the ID Token and the address-authority policy. An access token, authorization code or user-supplied email MUST NOT substitute for that validation. control.observed_at records successful validation, not the time a login page was opened. Apply to the underlying OAuth flow and use PKCE S256 . A failure MUST NOT be relabelled as success under oauth-01; changing methods requires a new, explicitly selected and independently validated flow.

OAuth-Based Provider Verification (oauth-01) This method uses the authorization-code grant of with and PKCE S256 to access a provider's authenticated account address service. OAuth does not define a universal verified-email response. Consequently, oauth-01 additionally requires an immutable provider profile admitted under control.policy_id. A provider that offers only an editable contact field, an unverified address or token-activity information cannot satisfy this method. The provider profile MUST identify the authorization server, exact HTTPS authorization, token and account-address endpoints, API revision, registered client and redirect URI, required least-privilege scopes, response schema, authenticated account identifier, and the exact semantics and provenance of the provider's address-verification evidence. It MUST explain why that provider is accepted as authoritative for the address and how current account control is established. A display name, username, domain suffix or flag named verified is insufficient without those semantics. Changes to those rules require new policy admission. For this method the attester is the OAuth client, including any backend component it operates under the same trust boundary. It MUST start a fresh authorization transaction bound to the recipient's browser and pending consent session. Freeze the provider profile, client, exact redirect URI, sender binding, notice and type definitions before redirect. Generate independent unpredictable state and PKCE verifier values and validate their transaction binding. Protect against authorization-server mix-up, code injection, replay and cross-site request forgery. Redeem the code once at the preconfigured token endpoint with the same redirect URI and PKCE verifier, and authenticate the client where required. The attester MUST obtain the token through that transaction, not accept an arbitrary bearer token from a sender or browser. Implicit, password and client-credentials grants do not satisfy this profile. A refresh token or preexisting application session alone MUST NOT create a new address observation for consent issuance. Check token response type, granted scopes and lifetime under the provider profile. Tokens need not be JWTs: decoding a token or obtaining an active introspection result is not proof of address control. Using that token, the attester MUST request the authenticated current account's address evidence directly over certificate-validated HTTPS at the admitted resource endpoint. It MUST NOT use an arbitrary address-lookup endpoint or an account identifier supplied by the sender. Reject unexpected redirects, malformed or ambiguous responses, expired credentials, insufficient scopes and failed account binding. The response MUST bind a provider-authenticated account identifier to the verified address, and the profile MUST establish that this is the account that authorized the transaction. An API accessible with an app-only credential or returning a client-selected account does not establish that binding. The address evidence MUST represent verified control under the admitted profile, not merely a deliverability check or an address the account can edit without verification. If several addresses are returned, the chosen one MUST individually satisfy that profile; selecting a primary address does not imply verification. Apply only after validating provider evidence. Preserve the local part and compare the result with any frozen expected recipient. If none was specified, freeze the validated address and present it to the recipient before the separate decision. Account or address mismatch MUST terminate the flow. The admitted policy MUST fix finite transaction and observation-to-decision age bounds, each no greater than 300 seconds for oauth-01. The transaction MUST be unexpired when the API response is validated and when the decision is accepted. A new API read MUST NOT reset the transaction deadline or turn cached historical verification into a fresh user transaction. control.observed_at is the time the attester successfully validates the current provider response. The provider profile MUST specify acceptable age or revalidation rules for the underlying address evidence; the response retrieval time alone cannot establish it. After a separate affirmative decision, record control.method as oauth-01 and the corresponding admitted policy_id. The randomized private evidence commitment MUST bind the provider profile and revision, account/address observation, transaction binding and validation outcome, sender binding, notice, type definitions and decision. Raw access tokens, refresh tokens, authorization codes and client secrets MUST NOT appear in the consent object, public logs or blockchain. Keep credentials only as needed for the verification transaction, protected from disclosure. The private evidence record need not retain reusable credentials. A later verifier evaluates the attester's admitted method and policy and the ordinary C01 consent evidence. It does not call the provider API for each email or receive an access token. OAuth scope approval remains distinct from approval of communication types. Token expiry or revocation does not by itself revoke XCIM consent; XCIM withdrawal and fresh status determine current permission.

EVP Address Control (evp-01) The external protocol for this method is revision -02 of . It remains Work in Progress. The attester MUST validate the presentation according to that revision's Sections 2.8, 3, 5.3 and 6.5, including the hash input specified in Section 6.4, and apply . A browser trial or future EVP revision is not automatically interchangeable with this revision. The browser obtains an issuer-signed Email Verification Token (EVT) and presents it with a Key Binding JWT (KB-JWT). The attester uses the authenticated address observation as one input to its consent session. The EVP issuer establishes address control; the Consent Attester observes and attests the separate recipient decision. These roles MUST NOT be conflated with the sender entity receiving consent. For XCIM, the admitted policy MUST fix the external revision, allowed algorithms, discovery and address-authority rules, validation software version, delivery mode, exact verification origin, and time bounds. It MUST NOT select these authorities from an unverified token or browser-supplied assertion. Discovery MUST use authenticated HTTPS and a trusted DNS resolution policy, with bounded retrieval, cache lifetime, redirects and key-set size. Reject destinations outside that policy, including local or private network addresses unless separately configured. DNSSEC validation or an authenticated pinned delegation MAY strengthen domain authority; ordinary DNS resolution does not imply DNSSEC proof. Generate a fresh, unpredictable session nonce with at least 128 bits of entropy before requesting address evidence. The attester MUST bind it to exactly one pending consent context. The expected recipient may initially be unset, but MUST be frozen from the validated address before the consent presentation and affirmative decision. A submitted form value alone MUST NOT select the attested recipient. Once frozen, the address, sender, types or verification origin MUST NOT be replaced within that context; a change requires a new nonce and session. All external address comparisons MUST use the external protocol's exact comparison rules before applying the C01 address representation. When the session already has an expected address, the validated address MUST match it under those rules before the session can proceed. Then canonicalize the verified address under and bind it to the consent recipient. The attester MUST NOT lowercase the local part, remove tags or dots, or substitute a sender's customer-list entry. An unsupported address is not silently converted. For a private address, consent applies only to the validated address presented to the recipient for this decision, not to its underlying mailbox or other aliases. The policy MUST set finite maximum ages for both token issue times and the pending session. For this XCIM method, each maximum MUST be no greater than 300 seconds; permitted clock uncertainty MUST be no greater than 60 seconds. With validation time t and uncertainty u, require each issue time i to satisfy i <= t-u and t+u-i <= its maximum age. The session MUST remain unexpired at validation and acceptance; an additional token expiry, when present, MUST also be enforced. The token age limit MUST NOT be reset by reloading or relaying evidence. control.observed_at is the attester's successful validation time. The admitted maximum observation-to-decision age MUST be finite and no greater than 300 seconds for evp-01.

Attester Origin and Delegated Origin In attester-origin mode, the attester is the EVP relying party and validates the presentation against its own preconfigured HTTPS origin and pending-session nonce. It then presents the frozen sender, notice and type definitions for a separate affirmative decision. In delegated-origin mode, a sender or its service operates the EVP relying-party origin and relays the complete raw presentation to the attester over an authenticated, confidential backchannel. The attester MUST preauthorize that exact origin and backend principal for evidence submission on behalf of the identified sender. This authority neither permits granting consent nor permits signing XCIM attestations. The attester MUST validate the raw evidence itself; a backend's verified=true assertion is insufficient. Before collecting evidence, the attester MUST freeze the delegated origin and nonce in its consent session. An authenticated backend MAY propose a cryptographically random nonce, but the attester MUST admit and bind it before evidence collection. At submission it MUST recheck the delegation, backend principal, session, sender, nonce, expected origin and expiry. Evidence addressed to the delegated origin MUST NOT be relabelled as evidence addressed to the attester's origin. The browser then reaches the attester's top-level consent surface through a single-use session continuation bound to the same browser context. The attester MUST authenticate that continuation and protect the decision against cross-site request forgery, session fixation and clickjacking. A leaked session identifier, sender-controlled return URL or bare redirect MUST NOT enable another browser to approve the verified recipient's consent. Only the attester observes the final affirmative action. The handoff API, credentials and browser transport are deployment choices; this document does not prescribe vendor endpoints.

Attestation Mapping and Failure Handling After validating EVP and observing the separate decision, the attester sets control.method to evp-01, control.policy_id to the admitted EVP policy, and control.observed_at to the recorded validation time. The existing private evidence commitment MUST bind the exact validated presentation, its session and origin, the policy and adapter version, sender binding, canonical recipient, notice, type definitions and affirmative decision. Its randomized opening remains private under attester policy. It is not a public EVT fingerprint or a new bearer token. No additional member is added to the closed control object. The signed consent, publication, withdrawal and fresh-status procedures are the same for all three address-control methods. A later XCIM verifier checks the attester's admitted method and policy; it does not replay the browser's EVP transaction or receive raw identity tokens. Token expiry after issuance does not revoke consent. Conversely, a valid token cannot override a withdrawal or renew a grant. Missing browser or provider support, an absent token or a cancelled verification MUST NOT be recorded as successful address control. Invalid, mismatched or replayed evidence MUST be rejected. An attester MAY offer OAuth-based provider verification or OIDC as a separately selected flow with a fresh challenge and its own validation. Such a grant MUST record oauth-01 or oidc-01 respectively. A switch MUST NOT copy an earlier decision, bypass validation, or convert an EVP failure into consent. Unsupported EVP does not by itself establish fraud.

Common Explicit Decision The server-side session freezes sender binding, recipient, notice, exact type definitions, selected control method and policy, method-specific authority and transaction challenge, verification and consent origins, return URI and expiry. The attester MUST observe a separate affirmative recipient action in that same authenticated context. Login, registration, purchase, a preselected option or a sender-supplied record does not constitute that action. The implementation retains evidence linking the address observation, presentation and decision. Consume the consent-session decision authority and persist the decision and issued grant atomically. A denial is terminal for the session. A retry retrieves the same recorded result and cannot create or broaden another grant. Refresh or login alone cannot renew consent. Multiple types can be accepted in one consent session; issuance is independent of email transmissions. Successful address-control validation consumes the method's transaction challenge exactly once and records an identity-verified state bound to the consent session. That state permits only the subsequent decision in the same unexpired context. It is not an issued consent grant. Denial, timeout or loss of continuity terminates the context without granting permission. The later atomic decision transaction consumes the remaining consent-session authority.

Withdrawal and Immutable Lifecycle The payload has exactly the following members, in addition to the common semantic constraints: profile, kind, issuer, event_id, consent_id, consent_commitment, sequence, previous_event_commitment, type_ids, actor, method, evidence_commitment, requested_at, effective_at, issued_at kind is revocation. sequence starts at one for each consent and increases by one. previous_event_commitment is H(consent) for the first event and H of the previous revocation thereafter. consent_commitment is always H of the original consent. event_id MUST be unique in that chain. type_ids is a nonempty sorted unique subset of the original types, excluding any type already removed. There are at most 64 events because every event irreversibly removes at least one of at most 64 original types. actor is recipient, sender, or attester. These mean respectively an authenticated recipient withdrawal, an authenticated sender surrender or restriction, and an authenticated protective action by the attester. All events are signed by the attester, which retains private evidence of the actual actor and authority. method matches [A-Za-z0-9._-]{1,64} and identifies a request procedure admitted in policy. A sender MUST NOT be allowed to assert that it acted as the recipient. The private evidence commitment binds authenticated actor, random request nonce, consent, affected types and outcome. Require consent.issued_at <= requested_at <= effective_at <= event.issued_at. effective_at and event.issued_at MUST NOT decrease across the chain. The minimum does not schedule future-effective revocations. Request authentication, nonce consumption, event sequencing and state update MUST be one durable transaction. The first committed valid removal of overlapping types wins. Retries return the existing result; disjoint removals serialize in the same event chain. There is no event that grants, extends or reactivates consent. Regrant requires a new explicit decision and identifier. Withdrawal is terminal for the affected type in the old grant. Publish and anchor revocations as immutable historical events. An authenticated withdrawal removes the positive signal immediately, including while its anchor is pending. An attester MUST NOT issue active status for a removed type after committing its withdrawal. Withholding a withdrawal anchor cannot restore consent. A deployment specifies its publication-delay policy and reports breaches; this core does not claim instantaneous blockchain finality.

Fresh Current Status The payload has exactly the following members, in addition to the common semantic constraints: profile, kind, issuer, consent_id, consent_commitment, sender_id, sender_epoch, sequence, event_head, active_type_ids, this_update, next_update kind is status. sequence is the number of complete revocation events supplied, from zero through 64. event_head is H(consent) at zero and H of the last event otherwise. active_type_ids is the sorted set of original type identifiers minus the cumulative removed types; it may be empty. Every identifier, issuer and commitment MUST match the exact grant and lifecycle. Missing intermediate events or a different projection are invalid. this_update is no earlier than consent.issued_at and every supplied event.issued_at. It is earlier than next_update, with an interval no greater than 300 seconds. next_update is no later than the consent and sender-binding expiries. An expired grant need not receive another positive status. Status is signed by a currently authorized consent_status key. Snapshot renewal at the same sequence may change only this_update and next_update. A different event head, active set or other semantic field at the same sequence is a conflict. A verifier MUST retain authenticated terminal removals and sequence/epoch floors. Known later restrictions override an older still-unexpired active view. Unauthenticated input MUST NOT advance those records. Conflicting authenticated history requires quarantine and authenticated recovery. Fresh status is the trusted attester's current projection, not an independent proof that a dishonest attester concealed no withdrawal. It does not require a new blockchain transaction for each query. Repeated reads and cache retrieval MUST NOT extend its signed lifetime. These controls protect lifecycle state, not email replay or SMTP queues.

Immutable Blockchain Evidence

Anchor Batch The payload has exactly the following members, in addition to the common semantic constraints: profile, kind, issuer, log_id, sequence, previous_batch_commitment, created_at, leaves kind is anchor_batch. sequence is a positive safe integer for an issuer/log. previous_batch_commitment is null only for sequence one; otherwise it is H of the immediately previous batch. leaves is an ASCII sorted array of 1 to 4096 unique object-commitment strings. It can aggregate consent and revocation commitments. The complete list accompanies an inclusion check; this bounded profile uses no additional Merkle path format. For each checked object, H of its payload MUST occur exactly in leaves and its issued_at MUST be no later than created_at. Verify the batch signature under the anchor_publication role and compute C = H(batch). The admitted blockchain adapter MUST establish that this exact C was anchored in the accepted issuer/log, network and anchor context. Further objects require another batch, not truncation or a history reset. Publishers preserve the batch sequence and predecessor and MUST NOT publish conflicting batches at one sequence. The deployment binds that history to its admitted anchoring mechanism. Known conflicts or rollback withdraw the positive signal. Grant inclusion is historical evidence; it does not replace the status algorithm. Full consent or recipient mapping payloads MUST NOT be placed on a public blockchain by this profile.

Blockchain Adapter Contract and Limits The payload has exactly the following members, in addition to the common semantic constraints: profile_id, network_id, genesis_hash, anchor_id, block_hash, transaction_hash, record_index, batch_commitment, proof This is an unsigned evidence wrapper, not another signed C01 kind. profile_id selects a previously admitted adapter. network_id, genesis_hash, anchor_id, block_hash and transaction_hash are nonempty ASCII strings of at most 512 characters whose exact encodings are defined by that adapter; record_index is a non-negative safe integer, batch_commitment a C01 hash, and proof a bounded JSON object. Schema acceptance does not authenticate any of these values. An admitted adapter MUST specify network and genesis identification, anchor authority/location and code or transaction semantics, exact committed bytes, inclusion proofs, consensus/finality verification, history continuity, halt/conflict handling and recovery. Its trusted configuration is installed independently of the wrapper. It MUST return an authenticated commitment and network/anchor context that the caller compares with the expected batch and policy. An issuer-controlled adapter cannot grant itself trust. A transaction URL, issuer-supplied finalized flag, successful HTTPS response or agreement between untrusted RPC servers is not verified consensus. A verifier MUST NOT return CONSENT_CURRENT without actual historical inclusion and finality verification through an admitted adapter. Unavailable required evidence yields INDETERMINATE; an unsupported profile is not a fallback to unanchored consent. This core specifies the adapter boundary but does not select a universal blockchain network, consensus bootstrap or chain-specific proof encoding. Peers need a common admitted adapter to interoperate end to end. Those deployment dependencies remain explicit. Operating a node is one possible implementation and is not a universal requirement on every consuming email service. No live Amoy deployment or finality result is claimed by this revision. The previous AN01 EVM contract work can be reused to publish a C01 batch commitment under a separately specified deployment/profile. Its application to an earlier AS checkpoint does not make AN01-F01 Evidence Sets compatible with C01. No historical checkpoint is relabeled. Blockchain remains part of the protocol; the separation does not create an unanchored profile with the same positive result.

Evidence Set and Acquisition The payload has exactly the following members, in addition to the common semantic constraints: profile, sender, consent, revocations, status, consent_anchor, revocation_anchors profile is xcim-consent-01. sender, consent and status are JWS envelopes of the corresponding kinds; revocations is an ordered array of revocation JWS envelopes. consent_anchor contains exactly batch (a batch JWS) and evidence (the anchor wrapper). revocation_anchors is an array of objects containing exactly event_id, batch and evidence, with unique event_id values naming supplied revocations. Missing withdrawal anchors are reported as pending and never imply active consent. All signed issuer values MUST match. Every internal sender identifier, epoch, consent identifier, commitment and lifecycle link MUST match exactly. Mixing internally inconsistent objects is INVALID_EVIDENCE, even when their individual signatures verify. A missing required member is a structural error; an unavailable required proof is not evidence of revocation or permission. Evidence can be exchanged through configured authenticated HTTPS, authorized local storage or another admitted channel. HTTP transport uses application/json. This revision does not standardize discovery, endpoint request syntax or query-credential provisioning. Peers preconfigure these deployment interfaces; transport alone does not establish consent. Evidence access MUST be authorized for the requested recipient/sender scope. Network retrieval MUST verify certificates and the configured origin, bound sizes and timeouts, avoid credential leakage, and reject unsolicited redirects, compression and destination changes. Resolved and connected addresses must comply with policy to prevent SSRF and DNS rebinding. Sender-provided URLs cannot install endpoints or trust. A network error, HTTP 404 or rate limit does not prove absence or withdrawal.

Consent Verification and Results The verifier takes an authenticated local query containing the canonical recipient, issuer, sender_id, sender_epoch, type_id, type version, evaluation time, accepted policy, and evidence. A consuming application establishes the relationship between its authenticated sender context and this sender identity. No email message, header, DKIM result, MP or MSA is a core input.

Check policy, clock and persistent-state availability; apply limits, parsing, profile and closed-object rules.
Authenticate the issuer, signatures, roles and issuance windows; require identical internal identities and commitments.
Validate the sender binding, attestation, exact queried address commitment, type/version, explicit decision, admitted address-control method and times.
Verify the complete terminal revocation chain and status projection; apply known authenticated sender-epoch and withdrawal restrictions.
Verify consent inclusion in the exact signed batch and historical blockchain inclusion/finality through the admitted adapter.
Intersect current policy, status-key, binding, consent and status validity with the clock bounds; return the corresponding result.

For local time t and uncertainty u, u MUST be at most 60 seconds. For a positive result require this_update <= t-u, t+u < min(next_update, consent expiry, binding expiry, policy expiry, status-key validity end), and t+u-this_update <= 300 seconds. Re-evaluate time before returning or reusing a result. An unbounded clock, stale status, expired policy or missing trusted recovery state cannot yield a positive result. No cache grace period extends an authenticated deadline.

CONSENT_CURRENT: All mandatory checks succeeded for the exact queried relationship and type. Actual blockchain verification is required.
CONSENT_REVOKED: An authenticated applicable withdrawal is established. Missing finality for that withdrawal cannot restore consent.
CONSENT_EXPIRED: The authenticated grant or sender binding has expired; it cannot establish current consent.
NO_MATCH: Internally consistent evidence does not cover the queried recipient, sender, epoch or type/version.
INVALID_EVIDENCE: Malformed data, invalid signatures, contradictory internal scope, broken lifecycle links or an invalid projection.
UNSUPPORTED_PROFILE: The profile or required algorithm is unsupported; no downgrade is permitted.
INDETERMINATE: Required evidence, finality, current authority or freshness is unavailable, or trusted histories conflict.

These are core result labels, not an Authentication-Results method. No result asserts that an email is safe, authenticated, correctly categorized or deliverable. A repeated query for the same valid relationship does not consume consent. Invalid data MUST NOT create persistent restrictions; authenticated restrictive events MAY be retained before their anchors arrive. Known withdrawal takes precedence over older active status. Implementations MUST NOT convert an indeterminate result into positive consent.

Optional Consumption by Email Services A receiving email service may first use its existing authentication mechanisms to establish a sender context, map that context to the identified sender named in the consent, then verify XCIM for its recipient and a requested communication type. It may use CONSENT_CURRENT as one positive policy input. This integration is optional and does not change core conformance. DKIM associates a signing domain with signed message material; DKIM2 develops message authentication, handling history and replay-related mechanisms. Neither is the recipient's decision to grant a company communication permission. They can complement XCIM without becoming dependencies of consent verification. A shared provider's authenticated domain does not automatically identify the company that benefits from a consent. The integration MUST establish that identity mapping and MUST NOT borrow another tenant's consent. Determining a particular message's type is external to XCIM. A sender merely labeling an email transactional does not prove its category or widen its grant. Positive consent does not require inbox delivery; missing XCIM does not universally require rejection. Unsubscribe mechanisms such as can supply a withdrawal request through an authenticated integration, but do not create an original consent decision.

Security Considerations Relevant attackers include a sender fabricating consent, an unauthorized actor controlling a consent UI, a dishonest accepted attester, a compromised signing key, a publisher withholding withdrawals, a verifier using stale state, and a malicious blockchain endpoint. Exact identity, type and commitment checks prevent substitution only under the admitted trust assumptions. A cryptographically valid lie remains a lie by the attester. A compromised sender or shared service MUST NOT create a grant by presenting an address hash or another company's binding. Enrollment and decision evidence require authenticated observations by the third party. Consent presentation must clearly identify the company, scope and meanings being accepted. An opaque type token is insufficient for informed selection. Address control is observed at consent time. Reassignment, account takeover and loss of control can undermine later assumptions; finite expiry, authenticated withdrawal and policy-driven reauthentication limit exposure. This revision does not claim continuous proof of mailbox ownership. Freshness bounds limit stale acceptance under an honest publishing attester; they are not a measured revocation SLA or protection against concealed withdrawals by that attester. History and cache recovery MUST preserve known terminal withdrawals and epoch restrictions. Durable local storage alone cannot detect rollback of an entire disk; a deployment requiring that protection needs an authenticated external recovery floor. An anchor proves committed history under its finality model, not data availability or correct state computation. No synthetic chain observation may be promoted to real consensus evidence.

Privacy Considerations Public batches and chain records contain commitments, not recipient addresses, raw identity tokens, credentials or private consent inputs. The signed grants, salts, sender/type descriptions and address mappings remain access-controlled evidence. A known salt permits testing candidate addresses and is not encryption. Randomized private-evidence commitments also require careful handling of their openings. Queries, timestamps and issuer/sender relationships can reveal recipient interests even without plaintext addresses. Apply access authorization, data minimization, retention controls and rate limits. Private-data deletion does not erase an immutable public commitment; it can make later evidence unavailable. Loss of access must not be misreported as proof of withdrawal or current consent.

EVP Evidence and Origin Privacy EVP evidence MUST NOT appear in public consent objects, logs, blockchain records, callback URLs or analytics. Minimize private retention and protect retained evidence with access controls and encryption. A delegated-origin flow exposes its presentation to both the relying party and attester; it MUST NOT be described as hiding the recipient from either. An attester serving multiple senders can correlate observations even when the external protocol limits issuer visibility. XCIM does not expand a private-address grant to another origin, address or sender.

IANA Considerations This revision defines no email header and no Authentication-Results method. It uses the existing HTTPS URI and UUID URN namespaces, rather than claiming a registered xcim URN namespace. The JWS typ value application/xcim-consent+json is a provisional protocol identifier; no media-type registration is established by this Internet-Draft. Evidence HTTP transport uses application/json. Before an eventual RFC, the media-type registration and any registry for interoperable address-control or blockchain profiles need concrete templates, allocation policies and change control. A future change to a signed typ or identifier requires explicit version selection and migration, not rewriting prior signed bytes. The result labels here do not imply IANA assignment.

Conformance, Validation and Remaining Work Conformance is evaluated separately for sender enrollment/attestation, consent issuance, lifecycle/status publication, blockchain adapters, and consent verification. A core verifier MUST work without an SMTP transaction, email body, message signature or per-message replay store. A complete positive result additionally requires a real admitted blockchain adapter; schema or signature success alone is not sufficient. Necessary tests include a valid query without an email, repeated verification without consuming a grant, independently selected types, partial and complete withdrawals, expired and stale evidence, altered signatures, recipient and sender substitution, shared-provider tenant confusion, wrong type/version, unauthorized actor requests, state rollback, conflicting history and incorrect blockchain context. Test reports identify the exact objects, policy, adapter, software and limits used. The core object and lifecycle rules are specified in this revision. Remaining interoperability work is explicit: chain-specific proof encodings and authenticated finality/bootstrap profiles; discovery and credential provisioning for evidence services; portable sender-enrollment assurance policies; and final registration/migration templates. Closure requires exact formats, trust inputs and adversarial vectors for each selected profile. These dependencies cannot be bypassed to obtain CONSENT_CURRENT. Independent security/privacy review, actual identity-provider flows, live chain verification, separately operated interoperability and workload measurements remain evidence tasks. They are not claimed by local fixtures and do not require adding message-processing obligations to XCIM.

EVP Profile Validation Tests MUST distinguish external-token validation, session/handoff binding, explicit decision, signed-object verification and current-state verification. Include valid evidence without consent, wrong or reused nonce, wrong origin, recipient substitution, stale tokens, substituted issuer or browser keys, invalid token linkage, unadmitted policy, expired delegation, cross-browser continuation, fallback mislabelling, denial, retry, and withdrawal after EVP-based issuance. Passing schema tests does not validate an EVP transaction. Interoperability evidence MUST identify the exact external revision, browser transport, provider, adapter, policy and delivery mode. Closure requires a successful browser-to-attester flow and adversarial cases for that same combination, followed by independent reproduction. Browser and IETF EVP specifications may differ; such differences require an explicit compatibility profile and review, not silent acceptance under evp-01. This revision fixes the IETF revision used for evp-01 but does not claim that every available browser implements it.

OAuth Provider Profile Validation Before admitting an OAuth provider profile, document its exact endpoint and response mapping and test a successful code/PKCE/API transaction plus wrong state, wrong verifier, reused code, provider mix-up, token substitution, insufficient scopes, inactive credentials, account substitution, unverified address, stale address evidence and unexpected redirect cases. Test a successful address check followed by denial or no consent action, and confirm that neither issues a grant. Test method switching, policy isolation and withdrawal after issuance separately. Closure requires repeatable provider/adapter evidence and independent reproduction; C01 object fixtures do not demonstrate those transactions.

Implementation Status This section is informative, following . The project maintains local C01 schemas and a reference verifier with positive and adversarial fixtures. These exercise consent objects, signatures, recipient/sender/type relationships, lifecycle, freshness and batch commitments independently of email messages. Test keys and simulated anchor adapters are explicitly non-operational. A simulated adapter may report successful consent checks for a test case but MUST NOT produce an operational CONSENT_CURRENT result. No real EVP, OAuth or OIDC provider/browser integration for this C01 profile, deployed C01 blockchain profile, independent interoperability or production security assurance is claimed. Previous P1/MAIL01 test counts remain historical evidence for those profiles and are not reused as proof that this corrected scope has been validated. The local examples also exercise signed evp-01 and oauth-01 consent objects and method-specific policy admission. Their address-control observations are synthetic. They are not an EVP issuer, browser, OAuth client/API adapter or token validator, and do not establish external-protocol conformance.