eXplicit Consent-Identified Mail (XCIM)

2.1. Minimum Direct-Email Flow and Exclusions

1. The Consent Issuer validates identity under OIDC-01 and a separate explicit-consent decision for the application and purpose.¶
2. The issuer issues the receipt, permission evidence, and RBA binding the authenticated recipient context to that permission.¶
3. The application's control key authorizes a scoped message signer through MSA; the signer cannot create consent or redelegate.¶
4. The sender freezes one recipient's message copy, signs MP over scope, RBA, MSA, and content, adds Reference, then applies DKIM.¶
5. The receiver uses its trusted original RCPT TO and preaccepted trust policy to verify bindings, signatures, currently authorized keys/domains, permission, publication, freshness, and DKIM.¶
6. The receiver coordinates replay state with SMTP acceptance and applies its own delivery policy. Missing or stale evidence cannot be converted to a fresh positive result.¶

Product APIs, infrastructure provisioning, forwarding/list authorization, SMTPUTF8 and other authorization classes are outside the minimum. XCIM-Reference is required. XCIM-Proof is outside MAIL01: its presence prevents a positive MAIL01 result. A future profile would need to define its complete verification behavior.¶

2.2. Initial Related-Work Comparison

SPF [RFC7208] authorizes hosts for SMTP domain identities, while DKIM [RFC6376] binds selected message content to a signing domain. DMARC [RFC9989] addresses Author Domain validation, alignment, policy, and reporting; RFC 9989 obsoletes RFCs 7489 and 9091. These mechanisms do not attest to an application's purpose-specific permission for an individual recipient.¶

ARC [RFC8617] authenticates a chain of intermediary authentication assessments; it does not create permission for a new destination. One-click unsubscribe [RFC8058] provides list-header signaling for removal and complements, rather than establishes, the current permission presented by a message.¶

NO-SOLICITING [RFC3865] is relevant prior work on solicitation-class signaling. Its scope excludes authentication and consent. XCIM's proposed distinction is an authenticated relationship among application, recipient, purpose, message, and current permission. This comparison does not claim an exhaustive novelty survey.¶

8.1. Authority and State Objects

AS01-F01 [XCIMAS] defines the selected C1-C8 authority and state contracts. Its objects have distinct versions and do not extend closed WD-02-E1 objects implicitly. Section 18.6 specifies how the receiver derives P1 authority from authenticated AS evidence.¶

C1 is receiver-local trust policy: issuer/log identifiers, root and recovery key sets and thresholds, genesis, anchor policy, origin allowlist, expiry and durable epoch floors. Initial trust is provisioned outside the message; HTTPS discovery cannot create it. MAIL01 selects local pins; a registry path would need a separate authenticated lifecycle contract.¶

C2 is an AuthorityManifest authorized by the pinned root quorum. It binds role-specific keys and validity intervals to a manifest epoch and predecessor. C3 is a fresh ControlHead and C4 a StateCheckpoint; their keys must differ. A ControlHead commits to one exact checkpoint under that manifest. Neither online publication role can establish its own current authority through a state leaf it authenticates itself.¶

C5 defines typed application, key, domain and MSA state; C6 provides sparse membership or absence proofs against C4. Application state is looked up by stable application identity so an old epoch cannot remain active merely by selecting an obsolete lookup key. MSA material binds the exact P1 envelope, authorization identifier, key and app epochs. Domain state requires observed challenge evidence for the exact role.¶

C7 transports the component evidence; the unsigned wrapper grants no authority. C8 records attested lifecycle changes and their actor authorization commitments in a separate append-only authority log. Sparse state commits to the latest event; the event commits to the new state core without that event commitment, avoiding a circular hash.¶

Revocation of an MSA or MP key is terminal for its identifier. New authorization requires a new identifier and proof of possession; an MP timestamp cannot bypass current revocation. Control-key changes conservatively advance application epochs under the baseline rule; unrelated owners cannot inherit grants. Root recovery needs previously accepted recovery authority or external reprovisioning.¶

The nested AS evidence schema retains a null anchor_evidence slot; MAIL01 requires the separate AN01 wrapper and its verified anchor. AS-only fixtures do not establish an anchored positive result. Administrative actor/possession procedures and operational recovery remain subject to Section 25.¶

12.1. Content Commitment

Use RFC 6376 relaxed header/body canonicalization [RFC6376] on the network message. Include all header occurrences in their original order except the following exact names, compared case-insensitively: Received, Return-Path, Authentication-Results, ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal, DKIM-Signature, XCIM-Reference, and XCIM-Proof. There is no wildcard exclusion for unknown or X- fields.¶

Represent the included relaxed header fields, retaining each final CRLF, as an ordered array of ASCII strings. Hash the complete relaxed body, including MIME parts, without a body-length limit or MIME decoding. An empty relaxed body is the empty sequence. This equality follows the selected canonicalization, not raw-byte or rendered-content identity.¶

message_input = {
  "headers": ordered_relaxed_headers,
  "body_sha256": base64url(SHA-256(relaxed_full_body))
}
message_commitment = base64url(SHA-256(
  UTF8("XCIM-DIRECT-MESSAGE-P1\0") || JCS(message_input)))

Require unambiguous parsing, a single mailbox in From, one Date and Message-ID, and at most one occurrence of each critical singleton field, including Reference/Proof. A changed Subject, From, Reply-To, MIME structure, unknown non-excluded field, or body changes this commitment; added hop fields above do not. Other in-transit metadata modifications can lose the P1 signal, which requires MTA evaluation.¶

12.2. Signing Order, Transport, and Replay

Obtain RBA/MSA, freeze message content, compute its commitment, sign MP, add XCIM-Reference, then DKIM-sign. The message commitment excludes XCIM/DKIM fields to avoid circularity. RBA/MSA envelope commitments use separate domain tags; duplicated scope fields must match the receipt and permission exactly. Do not add Proof to MAIL01.¶

The Reference wrapper contains proposal_version p1, recipient_binding, signer_authorization, and presentation. Transport is v=p1; data= followed by base64url of its JCS, with FWS-separated fragments of at most 76 characters. The P1 grammar also recognizes Proof framing, but MAIL01 does not accept Proof. There is no sender-selected fetch URL or fallback to the legacy URL adapter.¶

Require a valid DKIM signature for the exact domain declared by MP, current application/domain authority, full-body coverage without l=, and actual coverage of Reference and critical fields. Singleton oversigning excludes Bcc as described in Section 13. Content hashes, DKIM, RBA signatures, and current state are complementary checks.¶

DKIM processing uses [RFC6376] with its applicable updates [RFC8301] [RFC8463] [RFC8553] [RFC8616]. These updates do not enable SMTPUTF8 or expand this profile's message syntax. An exact domain match and current application/domain authority are additional XCIM checks, not consequences of any passing DKIM signature.¶

MAIL01 bounds RBA/MP lifetimes to 24 hours, MP expiry by RBA/MSA expiry, MSA to seven days with separately verified current state, and future iat tolerance to 60 seconds. Expiry is exclusive with no grace extension. Current-state windows can be shorter. Reference is limited to 16 KiB and JSON depth to 32; these selected limits have not been validated as production performance budgets.¶

Use a 32-byte random presentation_id per recipient copy. After all validation, deduplicate by issuer/app/epoch/permission/original recipient and that ID, coordinated across the receiver's MX/workers. Persist acceptance and replay state atomically before final SMTP acceptance; retries before acceptance must remain idempotent. Already accepted duplicates produce no fresh positive authorization. An identical intercepted copy can arrive first; no global replay guarantee is claimed.¶

18.1. Scope, Inputs and Trust Boundaries

A conforming minimum copy has one application and epoch, one original SMTP recipient, one purpose, and explicit_consent. The identity profile is OIDC-01 with receipt version 0.1. RBA, MSA and MP use P1; current authority and permission use AS01 within the AN01 anchored evidence envelope. Mailing lists, forwarding, SMTPUTF8, quoted local parts, EVP, wildcard scopes and subdelegation are outside this minimum profile.¶

The receiver MUST obtain the original RCPT TO from its trusted SMTP boundary, not from To, a sender-supplied mapping or a forwarded header. Exactly one XCIM-Reference is required. XCIM-Proof is outside this minimum revision: its presence MUST prevent a positive MAIL01 result, even when its framing is valid. A future profile may specify Proof independently. A malformed or unsupported Reference MUST NOT fall back to a legacy URL representation.¶

Receiver policy is installed administratively before evaluating mail. It binds the exact consent issuer URI to issuer_id and log_id, accepted genesis, root and recovery keys and thresholds, legacy pins, allowed algorithms, origins, provider policies, and AN intent, binding, contract, network genesis and finality bootstrap. Email, DNS discovery or a fetched self-signed manifest MUST NOT install or enlarge this policy. A valid issuer signature attests its observation; it does not prove that an untrusted issuer observed a truthful consent decision.¶

18.2. Exact Wire Selection and Closed Structures

Receipts MUST match the tuple (0.1, xcim_receipt, oidc_hosted_consent), with alg EdDSA restricted to Ed25519, the separately pinned legacy_receipt role and typ application/xcim-receipt+jcs. Batch manifests MUST match (0.1, batch_manifest), the legacy_batch role, EdDSA restricted to Ed25519, and application/xcim-batch-manifest+jcs. These legacy exceptions do not authorize EdDSA in the new families; see the fully specified algorithm guidance in [RFC9864].¶

RBA, MSA and MP MUST use proposal_version p1, alg Ed25519, and the respective exact types application/xcim-recipient-binding-p1+json, application/xcim-message-signer-authorization-p1+json and application/xcim-message-presentation-p1+json. Their signer roles are recipient_binding, current application control and message_presentation. AS proposal_version is as-01; typ is application/xcim-as- followed by the exact object_type and +jcs. The AN deployment binding uses Ed25519, root quorum and application/xcim-as-anchor-binding+jcs. Each object MUST satisfy its closed schema as well as its semantic checks.¶

RBA has exactly proposal_version, object_type, binding_id, issuer, app_id, app_epoch, receipt_id, receipt_commitment, permission_id, purpose_id, authorization_kind, pairwise_id, address_profile, recipient_domain, salt, address_commitment, iat and exp. MSA has exactly proposal_version, object_type, authorization_id, app_id, app_epoch, authority_epoch, message_key, roles, purpose_ids, authorization_kinds, from_domains, dkim_domains, iat and exp. message_key has kid, alg, public_jwk and public_key_thumbprint. roles contains only message_presentation; authorization_kinds contains only explicit_consent. Scope arrays contain 1 to 64 distinct entries and no wildcard.¶

MP has exactly proposal_version, object_type, issuer, app_id, app_epoch, receipt_id, permission_id, purpose_id, authorization_kind, binding_commitment, signer_authorization_commitment, message_profile, message_commitment, presentation_id, from_domain, dkim_domain, iat and exp. The reference wrapper and JWS envelopes have exactly the properties defined in the P1 closed schemas. Schema acceptance alone establishes neither trust, freshness nor equality of scopes.¶

JWS protected headers have exactly alg, kid and typ. No unprotected header, private JWK member, unknown critical extension, detached payload, b64=false or algorithm fallback is accepted. JWK members are exactly kty, crv and x, with OKP and Ed25519. A kid MUST NOT be reused for another key or role. New objects signed by application keys MUST postdate their authenticated admission. The key must be valid at issuance and evaluation. Changes to algorithms, types or namespace semantics require new versioned issuance, never rewriting signed historical objects.¶

18.3. Parsing, Address Rules and Commitments

Apply E1 before conversion: valid UTF-8, no duplicate JSON names or isolated surrogates, no fractional or exponent number tokens, and safe integers within plus or minus 9007199254740991. Booleans are not epochs. Signed protected headers, payloads and the Reference wrapper MUST already be JCS bytes; lexical -0 is therefore rejected in those canonical representations. Base64url is unpadded and MUST reproduce itself after decoding and re-encoding. Signatures decode to 64 octets; hashes, salts, pairwise IDs and presentation IDs decode to 32 octets.¶

The address procedure removes only outer SP and HTAB, requires exactly one @, and preserves the ASCII dot-atom local part and its case. Reject consecutive, leading or trailing local-part dots, a local part over 64 octets, and a trailing domain dot. Map the domain with UTS #46 revision 31, Unicode 15.1.0, nontransitional processing and STD3 rules, followed by IDNA2008 A-label validation including hyphen, Bidi and Joiner checks. Labels are 1 to 63 octets, the domain at most 253 and the entire address at most 254. No provider-specific equivalence, alias expansion or local part lowercasing is inferred. A new Unicode table requires a new address_profile; installed library updates MUST NOT silently change it.¶

Use the P1 ABNF for raw Reference, including final CRLF. Parameter values and order are case-sensitive. Concatenate only the permitted FWS separated base64url fragments. Reference is at most 16384 raw octets; physical header lines are at most 998 octets without CRLF. JSON depth is at most 32. IDs are at most 256 characters, kid 200 and purpose tokens 128 ASCII characters. This bounded revision accepts messages up to 16 MiB, headers up to 256 KiB, AS evidence up to 1 MiB and the complete anchored envelope up to 2 MiB. Exceeding a bound cannot yield partial verification.¶

With H = SHA-256, J = JCS, U = UTF-8 and NUL a zero octet, the following functions fix the domain separation. The JWS envelope hashes include all protected, payload and signature members.¶

rc = b64u(H(U("XCIM-RECEIPT-0.1") || NUL || J(receipt_payload)))
bc = b64u(H(U("XCIM-BINDING-ENVELOPE-P1") || NUL || J(rba_jws)))
sc = b64u(H(U("XCIM-SIGNER-AUTHORIZATION-P1") || NUL || J(msa_jws)))
ac = b64u(H(U("XCIM-RECIPIENT-BINDING-P1") || NUL
           || J(address_input)))
mc = b64u(H(U("XCIM-DIRECT-MESSAGE-P1") || NUL || J(message_input)))

rc is receipt_commitment, bc binding_commitment, sc signer_authorization_commitment, ac address_commitment and mc message_commitment. address_input contains exactly the RBA fields issuer, app_id, app_epoch, receipt_id, receipt_commitment, permission_id, purpose_id, authorization_kind, pairwise_id, address_profile, recipient_domain and salt, plus canonical_recipient computed from trusted RCPT TO. The canonical recipient is not added to the transported RBA.¶

RBA and MP lifetimes MUST be positive and at most 86400 seconds; MSA lifetime at most 604800. iat MUST NOT exceed evaluation time plus 60 seconds. Expiration is exclusive. MP.iat is at least both RBA.iat and MSA.iat, and MP.exp is no later than either parent expiration. Authority, state and clock-uncertainty deadlines further restrict these windows; a long-lived signature is not a current send permit.¶

18.4. OIDC Issuance and Consent Transaction

The issuer MUST preselect a versioned provider policy containing exact issuer, permitted keys and algorithms, clients, address authority classes, consent origins and return URIs. Use the authorization-code flow with session-bound state, PKCE and a one-time nonce. The server session fixes application and epoch, active OAuth binding, provider, client, original recipient, nonce, manifest and hash, purpose, origin, return URI and expiry. A token MUST NOT choose the trusted issuer or cause arbitrary discovery.¶

Validate the ID Token signature, exact issuer, audience, azp where applicable, subject, nonce, times and required address claims according to [OIDCCore] and the admitted provider policy. MAIL01 excludes provider_relay. email_verified alone is insufficient authority. The observed canonical address MUST equal the frozen recipient. Authentication is distinct from consent: require a separate decision for the same session, manifest and purpose, with authenticated_at no later than accepted_at, and accepted_at no later than issued_at.¶

The issuer MUST durably consume session and nonce and store the decision and issued receipt atomically. A denial is terminal for that session. Refresh and login alone do not renew a grant. A failure before commit does not emit a receipt. A retry after commit cannot create a second grant; the issuer may retrieve the recorded result through its authenticated session interface. Nonce reuse across sessions of the same provider and client MUST be rejected.¶

The public mapping retains the closed OIDC 0.1 receipt structure. The application and identity-evidence client commitments MUST be equal and all commitment values decode to their prescribed lengths. The receiver admits adapter version, provider policy, comparison rule, address authority class and consent origin explicitly. It does not receive raw tokens, subjects, addresses or the issuer's commitment key.¶

MAIL01 requires finite, non-null receipt and permission expirations, even where historical schemas permit null. Issuer replay storage loss requires authenticated recovery; a token or session retry MUST NOT recreate an empty issuance store. The local adapter checks nbf when present and restricts sub to a nonempty ASCII string of at most 255 characters.¶

The new experimental adapter mail01-local-oidc-01 uses HMAC-SHA256(secret, UTF8(tag) || NUL || JCS(array)), encoded as unpadded base64url. Scope is [consent_issuer, app_id, app_epoch, provider_issuer]. The tags XCIM-MAIL01-CLIENT, XCIM-MAIL01-SUBJECT, XCIM-MAIL01-NONCE and XCIM-MAIL01-PAIRWISE append respectively client_id, sub, nonce and sub to that scope. XCIM-MAIL01-RECEIPT-ID appends session_id; XCIM-MAIL01-PERMISSION-ID appends session_id and purpose_id. IDs add their existing receipt or permission URN prefix. The private key has at least 256 bits of entropy and is separated by issuer; its version belongs to the issuance policy. Rotation affects new issuance only. These commitments are opaque attestations, not receiver-recomputable identity proofs, and assign no new recipe to historical commitments.¶

The local issuer harness accepts only synthetic, pinned EdDSA/Ed25519 JWTs, one string audience, a maximum 600-second token interval and no clock leeway. It tests claim validation and durable issuance, not a browser, authorization endpoint, PKCE exchange or real provider integration. This harness restriction does not replace the OIDC requirements above.¶

18.5. Message Construction and Domain Authentication

The sender freezes the content, signs MP, adds Reference, and then signs DKIM. It generates a fresh 32-octet random presentation_id per copy. A retry preserves the presentation and signed objects. A different content commitment requires a new presentation. Deterministic IDs and keys in the published test data MUST NOT be used for operational issuance.¶

message_input contains exactly headers, an ordered array of ASCII relaxed-canonicalized header strings including their terminal CRLF, and body_sha256, the base64url SHA-256 of the complete relaxed body. Use [RFC6376] Sections 3.4.2 and 3.4.4. Do not decode MIME, render the body, truncate it or sort header occurrences. The empty relaxed body is zero octets. Exclude only Received, Return-Path, Authentication-Results, ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal, DKIM-Signature, XCIM-Reference and XCIM-Proof, comparing names case-insensitively. Do not exclude arbitrary x-* fields.¶

Reject bare CR/LF, controls and non-ASCII headers. From has one mailbox, Date a timezone and Message-ID one local@domain enclosed by angle brackets with no whitespace or extra @. From, Date, Message-ID, To, Cc, Bcc, Subject, Sender, Reply-To, MIME-Version, Content-Type, Content-Transfer-Encoding, Reference and Proof are singletons. Nonempty Bcc is unsupported. All occurrences of other fields are included in their original order.¶

At least one cryptographically valid DKIM signature MUST have the exact MP dkim_domain, current domain authority, no l= truncation and coverage of the present Reference and critical singleton fields. Require one more h= occurrence than present instances of each critical singleton except Bcc. Bcc remains covered by the MP projection and cardinality checks. Inspect actual DKIM occurrence selection. A separate invalid DKIM signature does not invalidate a qualifying signature. AS domain authority does not replace DNS/DKIM verification.¶

18.6. Authenticated State Composition

Derive the AS request from the bounded, still-untrusted Reference: app_id, app_epoch, authority_epoch, control_kid, mp_kid, authorization_id, the recomputed MSA envelope commitment, from_domain, dkim_domain, purpose_id, pairwise_id, permission_id and receipt_commitment. A sender-supplied auxiliary request MUST NOT substitute for this derivation. These hints have no authority before verification.¶

Verify the AS root quorum, manifest chain, exact roles, epochs and predecessor commitments from the admitted genesis. Require distinct signers by thumbprint; root/recovery sets are disjoint. Check that kid is not reused and revoked keys are not reactivated. Checkpoint and control-head signers are distinct and authorized by the root manifest, never by their own state leaves. The checkpoint and control-head MUST bind the same manifest, genesis, cut and sequence.¶

Reproduce the authenticated event-history prefixes and AS sparse projection; verify membership or absence witnesses, material commitments and current lifecycle events. Verify the WD receipt and batch, event inclusion and current sparse permission proof under the same committed cut. Consult application state by stable app_id so an old epoch cannot remain authoritative. Application, control key, delegated MP key, MSA, From domain, DKIM domain and consent-presentation delegation MUST all be active, current and in the exact scope. The transported MSA envelope MUST equal the one authenticated by AS state.¶

Derive the P1 key and state context only from these authenticated records; never accept active/revoked flags supplied beside the message. Match receipt, RBA and MP issuer, receipt ID, application and epoch, permission, purpose and authorization kind. Match pairwise ID, receipt commitment, key thumbprints, MSA authority epoch, domains, RBA/MSA commitments, recipient commitment and message commitment. Verify all signatures and their issuance and current key windows.¶

Revoked, expired and erased states are terminal. A suspended MSA cannot reactivate; new authorization is required. Key rotation uses a new kid, authenticated lifecycle events and an updated MSA. A new key cannot authorize its own admission. Signed absence is not permission. Preserve known terminal states and monotonic epochs across restarts. Root recovery requires authenticated resynchronization before use, not merely a recovery signature or resetting local floors.¶

Issuer authority_attestation records attest administrative actor and domain-possession observations. The issuer MUST retain private evidence binding authenticated actor, a random one-time challenge, app/epoch, domain, role, observation time, outcome and expiry. Challenge consumption and state change are atomic. Recheck possession on control/epoch changes and before recheck_by; loss of possession withdraws the domain roles. The public observation commitment does not independently prove DNS ownership or the truth of an issuer's human-action report.¶

18.7. Publication Hashes and Proof Reconstruction

Let TH(tag, bytes...) mean SHA-256 of UTF8(tag), NUL and the concatenated raw byte arguments. AS object commitment of kind K and value V is base64url(TH("XCIM-AS-01-" || K, JCS(V))). K is exactly GENESIS, MANIFEST, EVENT, STATE-VALUE, MATERIAL, CHECKPOINT or CONTROL-HEAD for the corresponding object. Commit the decoded payload rather than its signature envelope unless the P1 envelope formula explicitly applies.¶

The AS sparse key is TH("XCIM-AS-01-STATE-KEY", JCS of the object with issuer_id, log_id and locator). A present leaf is TH("XCIM-AS-01-STATE-LEAF", key, decoded STATE-VALUE commitment). Define E[0] = TH("XCIM-AS-01-STATE-EMPTY") and E[h+1] = TH("XCIM-AS-01-STATE-NODE", E[h], E[h]). Begin at the present leaf or E[0] for authenticated absence. Interpret key as an unsigned big-endian 256-bit integer. Consume exactly 256 siblings from leaf to root, each 32 decoded octets. At height h, use TH("XCIM-AS-01-STATE-NODE", sibling, current) if bit h is one, otherwise TH("XCIM-AS-01-STATE-NODE", current, sibling). The reconstructed root MUST equal the checkpoint's authority_state_root. Check issuer/log, locator and checkpoint commitment before accepting either presence or absence. Absence material/event fields must be null.¶

For AS event history, the empty root is TH("XCIM-AS-01-EVENT-EMPTY"), a one-event tree is TH("XCIM-AS-01-EVENT-LEAF", JCS(event)), and an internal node is TH("XCIM-AS-01-EVENT-NODE", left, right). For n greater than one, split at the largest power of two strictly less than n, preserving event order. Inclusion paths contain siblings from leaf to root, with side determined recursively by leaf_index and tree_size. Consume the entire path and reject missing or excess nodes. For the WD permission event tree, use respectively XCIM-EVENT-EMPTY-0.1, XCIM-EVENT-LEAF-0.1 and XCIM-MERKLE-NODE-0.1 with the same splitting procedure.¶

The WD permission sparse key is TH("XCIM-STATE-KEY-0.1", UTF8("permission"), NUL, UTF8(permission_id)). Its present leaf is TH("XCIM-STATE-LEAF-0.1", key, TH("XCIM-STATE-VALUE-0.1", JCS(state_value))). Empty leaf and node tags are XCIM-STATE-EMPTY-LEAF-0.1 and XCIM-STATE-NODE-0.1. The 32-octet sibling bitmap is indexed by root depth, most-significant bit first; non_empty_siblings follow that root-to-leaf order. During leaf-to-root reconstruction at height h, consult depth 255-h, consuming supplied nonempty siblings in reverse order; a zero bitmap bit uses the recursively constructed empty node at height h. Direction is again bit h of the big-endian key. Require exactly the bitmap population count of siblings, correct state_key and the batch's exact state_root. MAIL01 requires a present active permission.¶

Replay AS lifecycle events in sequence from one. The first state epoch is one; each successor increments by one and binds both previous event and state commitments. State time cannot decrease; terminal states cannot become active. Every event binds issuer, log, locator, state epoch and effective time to its new state core. Recompute the projected sparse root at each checkpoint cut. Full prefixes MUST match their declared sizes, roots and last sequence. A zero-event permission batch MUST NOT change the previous state root. An accepted newer checkpoint cannot hide a previously known terminal state.¶

AN anchors decoded 32-octet commitments. Checkpoint commitment C uses the CHECKPOINT formula above. G is the GENESIS commitment. AN identity I uses TH("XCIM-AS-EVM-01-IDENTITY", JCS of adapter_profile, issuer_id, log_id and as_genesis_commitment). Intent T uses TH("XCIM-AS-EVM-01-INTENT", JCS(intent)); binding B uses TH("XCIM-AS-EVM-01-DEPLOYMENT-BINDING", JCS(binding payload)). ABI digest is SHA-256 of the JCS ABI array; contract/event identifiers use Keccak-256 and ABI encoding as specified in [XCIMAN]. Do not interchange SHA-256 and Keccak-256 or hash the textual hex/base64 encoding in place of bytes32. Intent and genesis precede deployment; neither includes its future binding or receipt. This avoids circular commitments. The fixed AN contract/ABI and build recipe remain normative dependencies of this bounded adapter, not certification of Amoy operation.¶

18.8. Anchoring and Evidence Acquisition

Require the AN01 external evidence wrapper. Its intent, root-signed binding, network and genesis, ABI, constructor, runtime, contract, event, checkpoint and current contract state MUST satisfy [XCIMAN]. AS01's inner null anchor slot only locates the anchor in that outer wrapper; an AS-only response MUST NOT produce a positive MAIL01 result.¶

Network observations originate from the receiver's admitted node: finalized block and ancestry, receipt/event, code and getters at the same canonical block hash, current head, halt state and monotonic chain floors. A finalized flag in an issuer object, matching responses from two RPC servers or latest are insufficient. No fallback bypasses consensus bootstrap, finality or state verification. The current laboratory checks relationships against a synthetic view and therefore never reports consensus_verified or can_assert_xcim_pass as true.¶

Evidence endpoints and authentication are selected by admitted receiver policy, never by email URLs. Use POST to the exact configured HTTPS endpoint, Content-Type application/json, Accept application/json and no content encoding. The closed request object has exactly profile, the string mail01, and request, the tuple object defined above. Success is HTTP 200, Content-Type application/json and a complete AN01 EvidenceSet JSON body. Mutual TLS authenticates a receiver certificate admitted by the issuer and bound to authorized query scopes. Endpoint configuration is administrative, not dynamic discovery. Retrieval MUST validate HTTPS hostname/certificate and applicable pins, constrain the resolved destination and the actual connected address, reject redirects, origin changes, unsolicited compression and HTTP fallback, and enforce a 10-second deadline and size limits before parsing. Block private, loopback and link-local addresses except for an explicitly administered endpoint. Prevent DNS rebinding and credential forwarding. Unauthorized queries MUST NOT disclose private state. An HTTP error, including 404 or 429, proves neither revocation nor permission.¶

The versioned AS01 development contract uses full prefixes bounded to 16 cuts/manifests and 128 events per log. Exceeding these bounds MUST withdraw the positive signal, not silently truncate history or restart genesis to evade revocation. A future continuity/compaction contract is needed for sustained operation beyond this bounded revision. Transport and node implementations remain separate operational dependencies; local evidence injection does not establish their conformance.¶

18.9. Evaluation Order and Time Intersection

Evaluate in this order: local policy/store/clock preconditions; parsing and profile selection; authenticated AS authority and permission; AN anchoring; P1 bindings and DKIM; admitted public OIDC projection; final time intersection; replay and durable acceptance. Stop at the first failed phase. Within a phase every failed mandatory check is nonpositive; diagnostic subcode ordering is not a wire guarantee for simultaneous faults. Structural success, a valid isolated signature, neutral status or anchor-pending status MUST NOT be promoted to VERIFIED.¶

Contract outcome classes are UNSUPPORTED_PROFILE, INVALID_EVIDENCE, NOT_AUTHORIZED, TEMPORARILY_UNVERIFIABLE, DUPLICATE_ACCEPTED, REPLAY_CONFLICT and VERIFIED. These are descriptive classes, not a newly registered Authentication-Results method or an extension to historical result registries. VERIFIED requires every real dependency. SMTP delivery policy remains local; XCIM failure does not universally mandate a 5xx. A policy requiring a verified XCIM signal cannot accept on an unavailable mandatory dependency.¶

For wall-clock interval [t-u,t+u], require u at most 60 seconds, this_update no later than t-u and t+u strictly earlier than the effective deadline. That deadline is the minimum of all used object, key, policy/manifest, state, permission, domain observation, binding and finalized-header windows. AS state is at most 300 seconds old; manifest and domain observation windows at most 86400 seconds; finalized header age is less than 120 seconds; local node-view cache age less than 30 seconds. Fetching or rereading MUST NOT restart those windows.¶

Use a monotonic clock for elapsed budgets and a bounded wall clock for signed times. Recheck immediately before acceptance, including time spent verifying and waiting for the store lock. Clock regression, unbounded uncertainty or expiry during verification prevents positive acceptance. These values are bounded-design parameters, not measured SLAs.¶

18.10. Replay, Durable Queue and Restrictive State

The local replay key uses the same tagged SHA-256/JCS construction with tag XCIM-MAIL01-REPLAY and array [issuer, app_id, app_epoch, permission_id, canonical_recipient, presentation_id]. The acceptance fingerprint uses tag XCIM-MAIL01-ACCEPTANCE and the object containing exactly reference and message_commitment. This fingerprint is a local record, not a new signed wire object.¶

All MX workers sharing an acceptance domain MUST serialize the acceptance transaction: read admitted policy and durable floors, verify the evidence and deadlines, compare replay, store the durable message/outbox, presentation record and new floors, then commit. Only after commit may the transport report acceptance. Invalid messages MUST NOT consume a nonce. A pre-commit crash rolls back acceptance state; a lost 250 response does not undo a committed message.¶

An already accepted identical fingerprint is idempotent and MUST NOT enqueue another delivery. Current policy and evidence are still checked before indicating a verified retry. A different fingerprint with the same replay key is REPLAY_CONFLICT. Durable enqueue does not by itself prove exactly-once final mailbox delivery; that requires cooperation from the downstream delivery system.¶

An authenticated signed denial may restrict trust before its anchor is available, but cannot create a positive signal. Preserve terminal states and restrictive floors after authenticating AS history and witnesses. Unauthenticated data MUST NOT update these records. An authenticated conflicting manifest or checkpoint at the same epoch/sequence quarantines the log. Missing, corrupt or unavailable storage, or an unadmitted policy change, requires withdrawal of the signal and authenticated administrative resynchronization. Never automatically replace a lost store with empty replay/floor state.¶

The local SQLite laboratory uses FULL synchronization, a serialized write transaction and a durable test outbox. It has no garbage collection and a 1000-acceptance quota. Operational garbage collection must preserve replay protection until no presentation can be accepted again and must preserve terminal lifecycle floors. Detecting rollback of an entire disk requires an external authenticated floor; ordinary persistence alone does not establish that property.¶

18.11. Privacy, Evidence and Remaining Operational Work

An issuer can lie about consent; a publisher can withhold renewal; root compromise exceeds the protection of individual object signatures. Anchoring does not prove truth or availability. Revocation freshness is bounded under the stated trust assumptions and is not instantaneous. RBA salts permit candidate-address guessing by parties that know possible addresses; commitments MUST NOT be described as encryption. State queries can reveal app/permission activity to the issuer. Require authorization, minimization, retention controls and rate limits, without erasing replay or terminal state still needed for safety.¶

The local integrated suite issues a synthetic OIDC receipt, signs a new RBA/MP, verifies authenticated authority/permission and AN artifact relationships, checks content and DKIM, and tests expiry, revocation memory, rollback, restarts and competing acceptance processes. Positive results are explicitly MAIL01_LOCAL_QUEUED or MAIL01_LOCAL_ALREADY_QUEUED, with no operational XCIM_PASS. Public provider, DNS and chain data in the suite are synthetic.¶

Real provider/browser and lifecycle administration, authenticated evidence transport, an admitted node/finality implementation, real MTA and distributed storage integration, sustained history continuity, independent security review and interoperability remain unproven. This draft may be reviewed with those limits; the suite does not close global implementation or operational readiness.¶

19.1. Role Obligations and Evidence

Consent Issuer

Validate identity and separate consent; issue exactly scoped receipts and RBAs; publish lifecycle and current authority under the selected profile.¶

Application Control and Sender

Authorize a finite MSA scope, isolate message-signing keys, sign one MP per recipient copy, preserve content commitments, and apply DKIM after XCIM fields.¶

Log and Publisher

Authenticate a consistent permission and authority cut, sequence and predecessor, current state or proven absence, signed validity, and the required publication evidence.¶

Receiver

Use previously accepted trust and the original local RCPT TO; verify all bindings, roles, publication, state, freshness, and DKIM; coordinate durable replay and SMTP acceptance. Unavailable evidence cannot authorize omission of a check.¶

Mirror and Evidence Transport

Transfer bounded evidence without acquiring authority by hosting it; enforce retrieval, cache, redirect, and resource policies.¶

These obligations describe the selected roles; they are not certification claims about the available fixtures. Reports must distinguish structural checks, cryptographic checks, integrated tests, and independent operation. Remaining specification work is listed in Section 25.¶

22.1. Media and JWS Type Identifiers

Section 18.2 enumerates the exact JWS typ strings. Historical +jcs strings are retained as signed protocol identifiers; +jcs is not treated as a registered structured suffix. The evidence HTTP transport uses application/json. A later revision must distinguish envelope, payload and HTTP media types, complete appropriate registration templates, and specify compatibility before changing signed typ values. The P1 +json names likewise do not imply completed registration.¶

22.2. Identifier Namespace

Selected objects retain provisional urn:xcim identifiers. This document does not establish a registered URN namespace. A later revision must either propose a namespace under [RFC8141] with assignment, persistence, equivalence and change-control rules, or define an alternative and explicit migration. Existing signed identifiers cannot be silently replaced.¶

22.3. Email Fields and Result Reporting

The candidate email field for this minimum is XCIM-Reference, with syntax in Section 13 and semantics in Section 18. Its proposed initial status is provisional, its protocol is mail, and the document author is the contact. The final field-registration request remains open. XCIM-Proof is excluded from MAIL01; its grammar is retained solely to identify the broader P1 framing.¶

This document defines no new Authentication-Results method. Internal XCIM result labels are not a registered method and cannot be represented as one. Future profile, object and result registries require explicit initial values and allocation policies using [RFC8126].¶

A.1. EVM Anchor Adapter

The selected AN01 design uses an immutable single-issuer/log EVM contract anchoring the exact C4 commitment, sequence and predecessor. Its ABI has a monotonic head, per-sequence records, idempotent retries and a distinct guardian with irreversible halt. The anchor identifier uses Keccak-256 over abi.encode of domain, chain ID, address, intent, identity, AS genesis, sequence, checkpoint and predecessor commitments. AS JCS/SHA-256 commitments and authorization signatures retain their algorithms.¶

Genesis remains the existing five-field AS object. An AnchorIntent commits to network, ABI, creation-code template and build recipe before deployment. A root-signed DeploymentBinding subsequently binds the actual address, creation input, runtime and finalized deployment. Neither genesis nor intent contains that future binding; no checkpoint contains its own receipt. AN01-F01 supplies new schemas and a pinned Solidity build. Real network bootstrap, deployment evidence and binding lifecycle remain pending.¶

The recommended opt-in trial is Amoy, chain ID 80002, with a receiver-operated node validating Bor/Heimdall execution and consensus. Polygon documents milestone finality separately from parent checkpoints and provides the finalized RPC tag in its finality documentation. The receiver would verify event-block ancestry to the accepted finalized header, and compare code/getters at that same canonical block hash. Two remote RPC observations would be a separate test policy, never a consensus fallback. No production network is selected.¶

Unmeasured trial limits preserve 300-second AS validity and propose a 120-second finalized-header age, 30-second locally timed view cache and 10-second RPC deadline. Publication cannot extend signed freshness. Finalized-state contradictions require quarantine rather than floor rollback. New AN01 C1/C7 wrappers separate authority evidence from anchor artifacts; the nested AS01-F01 evidence still requires a null slot. Durable storage and a complete live anchor verifier remain required.¶

See the AN01-P01 proposal for historical alternatives, exact ABI and acyclic commitments. AN01-F01 implements and compiles the contract. Its 34 local EVM cases, 46 steps and two context checks test actual bytecode. Eight new schemas have 19 structural cases; 65 artifact cases (four positive, 61 adversarial) use synthetic node views and root-signed bindings. These are same-project checks, not consensus authentication or independent operator interoperability. No public contract is deployed and no live finality verification is claimed. Operational validation remains outstanding.¶

AN01 binding signatures use the provisional type application/xcim-as-anchor-binding+jcs under distinct accepted root signers and the local policy epoch. The binding commitment is SHA-256 over the domain XCIM-AS-EVM-01-DEPLOYMENT-BINDING followed by one NUL and JCS payload bytes. A finalized-view reference cannot authenticate itself. The fixture checker always reports consensus verification false and cannot assert XCIM_PASS. See AN01-F01 for source, schemas, deterministic fixtures, build instructions and the partial coverage map of the original 20 network scenarios.¶

A.2. NB01-F01 Receiver Node and Authenticated Bootstrap

the receiver's own administrator quorum admits the node, network, software/configuration/genesis files, checkpoints, endpoint certificate pins and validity windows. Issuer authority does not enroll the receiver node. The local policy pins the exact JCS/SHA-256 bootstrap and accepted AN anchor context. Bootstrap signatures use Ed25519 and the provisional type application/xcim-nb-bootstrap+jcs with distinct receiver_node_admin signers. It is not an IANA registration or a public accreditation.¶

The read-only collector requires an existing local floor store, authenticated loopback HTTPS and bounded reads. It cross-checks Comet status and commit at H, requests the Heimdall-v2 latest milestone at H with an explicit height echo, and ties its end-block hash to a Bor finalized chain. Parent-hash traversal links the selected cut to the anchor receipt; code and getters use the same canonical block hash. Canonical checkpoints and deployment history rely on the admitted validating node. Stable read barriers and persistent floors detect contradictions. No latest/safe or two-provider fallback is enabled.¶

SQLite node floors use transactions, compare-and-swap revision, monotonic hashes/heights and persistent quarantine. Missing stores, changed policy or failed recovery cannot silently reset trust. This does not protect against physical disk rollback or provide atomic multi-MX SMTP acceptance. Operators still must establish process and configuration provenance, secure channels, clocks and recovery.¶

NB01-F01 supplies seven schemas, 62 synthetic wire/bootstrap cases (two positive, 60 adversarial), 12 structural cases, eight store checks and 18 transport checks, including a full mock round through actual pinned loopback TLS. No real Amoy node or bootstrap was installed or admitted. The adapter delegates consensus to an admitted node; it does not verify BFT signatures or return XCIM_PASS. See NB01-F01 contracts and closure gates. Live API compatibility, authenticated real checkpoints/node admission, integration with real-node AN/AS/P1 verification, measured operation and independent review remain open. Operational validation remains outstanding.¶