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. This revision replaces 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.

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.

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. In this minimum method is oidc-01 and policy_id identifies a policy admitted by the verifier. 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 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 server-side session freezes sender binding, recipient, notice, exact type definitions, provider/client, nonce, origin, 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 session and nonce 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.

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.

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.

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 OIDC provider/browser integration, 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.