We Are 14 Inc

damian@xcim.org

email consent authorization XCIM specifies experimental evidence linking purpose-specific communication authorization to an application, an original email recipient, and message content. A signed receipt records an issuer's observation of consent; a receiver also verifies current permission, signing authority, freshness, authenticated publication, and DKIM. The minimum direct-email profile uses one recipient and purpose per message copy, issuer-signed recipient binding, and application-authorized message signatures. This document defines a bounded experimental integration and identifies unresolved lifecycle, history-continuity, and registration questions. It does not establish the truth of an issuer's consent observation or claim production readiness.

Introduction and Problem Statement Email authentication and communication authorization answer different questions. A receiver can authenticate sending infrastructure without learning whether a recipient authorized a particular application to send communications for a particular purpose. XCIM explores interoperable evidence for that authorization and its revocation across issuers, senders, and receivers that do not share a private product integration. The baseline is . A valid signature records an issuer's attestation; it does not establish that the issuer observed a truthful or non-deceptive consent decision. Public commitments preserve authenticated history under a publication policy, while the receiver remains responsible for its trust and delivery policies. The minimum profile is MAIL01, specified in . This document is an individual experimental proposal. Its normative rules describe the bounded profile; distinguishes unresolved design questions from future implementation evidence. Neither an Internet-Draft nor the available local tests constitute IETF endorsement or operational certification.

Scope, Use Cases, and Related Work The minimum profile combines the core authorization model with direct email: one application/epoch, one original SMTP envelope recipient, one purpose, and explicit_consent per message copy. It selects OIDC-01 receipt 0.1, P1 binding objects, AS01-F01 authority and state, and AN01-F01 anchored evidence. Required authenticated publication and anchor verification remain part of the profile. EVP and other authorization classes are outside this revision. The baseline distinguishes explicit consent, a transactional relationship, a service acknowledgement, and a preference. MAIL01 supports only the first of these; it does not relabel the other kinds. Identity authentication remains distinct from communication permission. XCIM does not guarantee message safety, legal compliance, mailbox existence, or inbox placement. It complements SPF, DKIM, DMARC, ARC, unsubscribe mechanisms, and ordinary abuse controls. Product billing, account provisioning, and private list-evaluation APIs are outside the proposed protocol scope. For the proposed first profile, emit separate copies for different envelope recipients. Compare the exact original RCPT TO from trusted receiver context, before alias rewriting; visible To/Cc/Bcc fields are not that authority. SMTPUTF8, quoted local parts, mailing-list expansion, and forwarding do not inherit a positive P1 authorization. ARC does not create a grant for a different destination. MAIL01 fixes the selected dependencies and their integration. Broader discovery, alternate publication profiles and migrations are not implicitly enabled. Further related-work review can inform later revisions without changing the meaning of the selected signed objects.

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.

Initial Related-Work Comparison SPF authorizes hosts for SMTP domain identities, while DKIM binds selected message content to a signing domain. DMARC 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 authenticates a chain of intermediary authentication assessments; it does not create permission for a new destination. One-click unsubscribe provides list-header signaling for removal and complements, rather than establishes, the current permission presented by a message. NO-SOLICITING 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.

Requirements Language and Terminology 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. The overview sections describe the selected object families; defines their minimum integration. The open issues in do not permit omitting a required check or selecting a weaker fallback. Historical object families and broader P1 framing are identified explicitly and do not expand MAIL01 conformance.

Recipient

The person or destination to which a communication authorization is bound.

Application

A stable application identity with keys, epochs, and metadata, distinct from a sending domain or OAuth client.

Identity Issuer

An authority supplying identity assertions under a selected identity profile.

Consent Issuer

An authority validating identity evidence, controlling consent presentation, and signing receipts.

Log Operator

An operator publishing append-only history and authenticated current-state commitments.

Sender

An application or authorized sending infrastructure presenting XCIM evidence with email.

Receiver

A verifier applying accepted issuer trust and local message-handling policy.

Resolver, Mirror, or Monitor

A component transporting or inspecting evidence without obtaining trust merely by hosting it.

Architecture and Trust Boundaries

Conceptual Flow Identity Issuer ---- identity evidence ---> Consent Issuer Recipient ---------- separate decision ---> Consent Issuer Application -------- signed manifest -----> Consent Issuer Consent Issuer ----- receipt/events ------> Log / Publisher Sender ------------ message/evidence -----> Receiver Log / Publisher ---- authenticated state -> Receiver Local trust policy ----------------------> Receiver

A receiver authenticates component relationships and current authority, rather than trusting the presence of a receipt, header, HTTPS endpoint, or chain transaction. An Identity Issuer and a Consent Issuer are distinct roles even when one organization performs both. Recipient mapping is authenticated by the RBA and checked against trusted SMTP context. Trust is installed administratively, and evidence is retrieved from configured endpoints as specified in . Automatic trust discovery is outside this minimum.

Versions, Profiles, and Historical Compatibility Document revision, signed-object wire version, and profile selection are separate. WD-02-E1 retains core objects and OIDC receipts at wire 0.1; experimental EVP receipts use 0.2, and metadata/accreditation 0.2 do not migrate other object families. Schema-union support does not enable an experimental profile. The baseline requires exact dispatch by signed version, object type, and issuance profile. Unsupported combinations and unknown critical extensions are rejected. Existing signed objects, commitments, timestamps, and historical interpretations MUST NOT be rewritten by an editorial revision. MAIL01 fixes the minimum accepted tuples and historical exceptions in the integration contract. Additional families or migrations require explicit version selection; broad migration tooling remains outside this revision. See . Historical EdDSA tuples remain distinct from P1, AS, AN, and NB families using explicit Ed25519 identifiers. There is no algorithm fallback or rewriting of signed typ/version values. The selected tuple catalog is specified in ; additional families require a separately specified migration.

Identifiers, Encodings, Canonicalization, and Time The baseline uses typed opaque identifiers, canonical unpadded base64url encodings for most 32-byte hashes, and UTC timestamps. Some publication-profile fields explicitly use hexadecimal encodings instead. Exact matching and normalization depend on the selected object/profile. Base64url follows Section 5, with padding omitted where required by the object contract; receivers check the exact canonical encoding, including unused trailing bits. Historical textual timestamps use with per-profile zone constraints. P1 iat/exp instead use integer seconds since the Unix epoch; the two representations are not interchangeable signed values. JSON parsing precedes schema and signature semantics. E1 restricts raw number tokens in JSON to the grammar below and the interoperable integer range from -9007199254740991 through 9007199254740991. Epochs start at one. Fractional and exponent forms are rejected before host numeric conversion, including forms that would round to an integer. Duplicate members and invalid Unicode scalar values are rejected. number-token = ["-"] ("0" / (%x31-39 *DIGIT)) DIGIT = %x30-39 Canonicalization uses JCS , including unsigned UTF-16 code-unit ordering. A raw -0 token can canonicalize to 0, but signed segments must already contain their required canonical bytes. Parsing an already-created host object cannot recover a number token's original form. The email baseline preserves ASCII dot-atom local-part case, dots, and plus tags and normalizes the domain using the specified IDNA mapping. Post-mapping DNS validity is checked again. Quoted local parts and SMTPUTF8 are outside that profile. EVP issuer normalization is not OIDC issuer matching and must not replace it. The address profile uses non-transitional UTS #46 mapping with STD3 rules and Unicode 15.1.0 tables, including validation after mapping. The local reference implementation uses idna 3.10. The protocol selects the table version, not an unspecified library default; a table change requires a new address profile. The mapping reference is UTS #46 revision 31 for Unicode 15.1.0 and its versioned data , applied with IDNA definitions and procedures . Newer Unicode tables and provider-specific mailbox equivalence are not enabled by this revision. MAIL01 specifies the minimum parsing, address, table-version and temporal rules. Independent reproduction of all canonicalization cases remains an external-validation task. See .

Cryptographic Envelopes and Commitments The baseline uses SHA-256 , Ed25519 , and JWS Flattened JSON Serialization with canonical protected/payload bytes. The protected header carries alg, kid, and the object-specific typ. The signing input is the ASCII protected segment, a dot, and the ASCII payload segment. Ed25519 signs that input directly. Receipt, batch, application, identity, and chain-signing keys have different authorities. Unprotected security headers, algorithm substitution, undefined detached semantics, and unknown critical extensions cannot establish valid baseline evidence. Consent manifest 0.1 has a historical inline-signature exception. Receipt commitments hash the defined payload, not an arbitrary outer envelope. Domain tags and byte encodings are part of the contract. MAIL01 specifies domain-separated commitments, role-specific algorithm selection and historical exceptions. Existing signed bytes MUST NOT be relabeled. Independent cryptographic review remains outstanding. See .

Application, Domain, and Issuer Authority The application identity is bound to active keys and epochs. Domain bindings distinguish organizational, rfc5322_from, dkim_signing, envelope_from, link_domain, and consent_presentation_delegate roles. Authority is evaluated for the role actually used, including its validity and lifecycle; ownership transfers cannot inherit an unrelated epoch. Baseline receivers select trusted issuers through explicit local pins or authenticated registry chains rooted in previously accepted authority. Metadata 0.2 advertises capabilities and can have null accreditation. Discovery and advertised keys do not establish initial trust. MAIL01 uses administrative pins, role-specific signed authority, bounded freshness, and configured evidence endpoints. Portable enrollment and recovery ceremonies across unrelated operators remain design questions in . Metadata alone cannot establish initial authority. P1 defines issuer key role recipient_binding and application-controlled Message Signer Authorization (MSA) objects for delegated message_presentation keys. Each MSA needs authenticated current revocation/epoch state, not just a signed expiry. Existing metadata does not gain new key roles implicitly.

Authority and State Objects AS01-F01 defines the selected C1-C8 authority and state contracts. Its objects have distinct versions and do not extend closed WD-02-E1 objects implicitly. 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 .

Identity Evidence and Issuer-Controlled Consent The Consent Issuer validates identity independently of vendor assertions and binds it to a frozen session containing recipient, application/epoch, nonce, return binding, and manifest. Authentication precedes consent acceptance, which precedes receipt issuance. The consent decision takes place on an issuer-controlled top-level surface and is distinct from authentication or registration. OIDC-01 uses receipt 0.1 and profile oidc_hosted_consent. Its baseline requires issuer/key/audience/time/nonce validation, active client binding, expected-address checks, and a versioned provider authority policy. Raw identity tokens and recipient addresses are excluded from public receipts and logs. EVP-01 uses experimental receipt 0.2 and explicit opt-in. Identity validation uses OpenID Connect Core 1.0 incorporating errata set 2 , especially ID Token validation, together with JWT security guidance . These references do not make an OAuth/OIDC authorization decision a communication grant. MAIL01 specifies the selected provider-policy and receipt mapping; real-provider conformance remains unproven. MAIL01 specifies issuer session, claim validation, consent transaction and public mapping requirements. Its local synthetic-provider adapter does not establish browser or real-provider conformance; EVP remains outside the minimum. See .

Receipts and Permission Lifecycle A receipt records an immutable historical decision for an application, pairwise recipient, and explicit purposes/authorization kinds. It is not a perpetual permission to send. A receiver additionally evaluates current permission state and current application, key, and domain authority. Revocation appends an authenticated lifecycle event and changes the current-state projection while preserving the issuance receipt. Integration requests cannot allow a vendor to create a recipient grant by asserting a lifecycle action. Session retries require idempotent terminal handling. The minimum defines identity and consent issuance, finite permission expiry, authenticated current-state and latest-event checks, and rejection of revoked state. Complete producer-side actor authorization and conflict handling for every lifecycle transition remain open in . A valid inclusion proof alone does not demonstrate that the original actor was authorized.

Portable Recipient Mapping A receiver knows its intended SMTP envelope recipient or authenticated evaluation target. An issuer/app-scoped HMAC pairwise identifier cannot by itself prove the relationship to that address because the receiver does not hold the issuer's private pairwise key. The baseline requires an authenticated mapping binding the exact canonical target, issuer, application/epoch, and pairwise ID. A sender's assertion or recomputable salted recipient digest is insufficient. Missing or untrusted mapping MUST withhold a positive baseline result. A Recipient Binding Attestation (RBA), signed by the Consent Issuer, binds issuer, application/epoch, receipt commitment, permission, purpose, authorization kind, and pairwise recipient to an address commitment. The issuer computes it from an authenticated private observation, not a sender-supplied digest. RBA renewal cannot create consent. The signed object includes a 32-byte random salt. The address input is the closed projection of issuer, app_id, app_epoch, receipt_id, receipt_commitment, permission_id, purpose_id, authorization_kind, pairwise_id, address_profile, recipient_domain, salt, and canonical_recipient. Only the last member is private and omitted from the RBA. The receiver supplies it from its original SMTP recipient context. address_commitment = base64url(SHA-256( UTF8("XCIM-RECIPIENT-BINDING-P1\0") || JCS(address_input))) The receiver checks the declared recipient_domain against that exact canonical destination and recomputes the commitment. A reusable RBA does not establish current permission: the full receipt/state/authority algorithm still applies. No pairwise derivation secret is shared and no per-message issuer call is required by this construction. The selected P1 schemas and MAIL01 commitment rules define this mapping. A known salt permits offline candidate address tests; RBA and salt are not public-log material and do not establish anonymity. This object does not alter receipt 0.1.

Email Presentation and Message Binding Message syntax follows and the envelope context follows SMTP . The initial profile keeps its ASCII header and original-recipient restrictions; it does not infer an envelope destination from visible message fields. MAIL01 carries XCIM-Reference and excludes XCIM-Proof. Relied-upon fields are added before DKIM signing and covered by valid DKIM evidence. Duplicate or injected fields and copied presentations for the wrong recipient, application, purpose, or sender authority cannot produce a positive authorization result. A Message Presentation (MP) signed by an application-authorized message key commits to the full RBA and MSA JWS envelopes, content, scope, random presentation_id, validity, and exact From/DKIM domains. A Message Signer Authorization (MSA), signed by application control, authorizes a delegate key/thumbprint, role, app/epoch, finite purposes/classes/domains, authority_epoch, and validity. It cannot grant consent or authorize subdelegation. Thumbprints use . The application keeps its control key. Using only RBA plus a shared DKIM domain would conflate tenants unless the DKIM key had separately established exclusive application authority. P1 uses the application/delegate signature plus DKIM. An issuer token for every message is another alternative, with availability and traffic-disclosure costs. Isolate delegated MP keys and signing APIs by application/epoch and delegate. A signing oracle that accepts arbitrary requests across tenants defeats this separation and is a sender compromise, not a protection supplied by the existence of a second signature. MAIL01 integrates authenticated authority and anchored-artifact checks with P1, defines phase ordering and a durable local replay/outbox transaction. Proof is outside its minimum revision. Real MTA integration, distributed storage and independent review remain unproven. See . Historical shadow-mode encodings are not accepted by MAIL01. Header presence alone cannot establish authorization. Registration questions are described in .

Content Commitment Use RFC 6376 relaxed header/body canonicalization 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.

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 . Content hashes, DKIM, RBA signatures, and current state are complementary checks. DKIM processing uses with its applicable updates . 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.

P1-01 Development Schemas, Grammar, and Fixtures The P1-01 source package contains closed JSON Schema 2020-12 payload schemas for RBA, MSA and MP, shared definitions, a protected JWS header, flattened JWS envelope and Reference wrapper. Schema identifiers under xcim.invalid are local development identifiers resolved offline; they do not claim publication or registration. Proposed typ strings likewise remain unregistered development names. The grammar below uses and case-sensitive values from . It describes raw fields including final CRLF. Names are case-insensitive; values/order are exact. Resource, cardinality, base64url, JSON/JCS, schema and cryptographic checks are additional semantic constraints. xcim-field = xcim-reference-field / xcim-proof-field xcim-reference-field = "XCIM-Reference" ":" FWS p1-value CRLF xcim-proof-field = "XCIM-Proof" ":" FWS p1-value CRLF p1-value = %s"v=p1;" FWS %s"data=" segment *(FWS segment) segment = 1*76b64urlchar b64urlchar = ALPHA / DIGIT / "-" / "_" FWS = 1*WSP / (*WSP CRLF 1*WSP) WSP = SP / HTAB SP = %x20 HTAB = %x09 CRLF = %x0D.0A ALPHA = %x41-5A / %x61-7A DIGIT = %x30-39 MAIL01 requires exactly one Reference and no Proof. The broader P1 grammar recognizes Proof only for explicit rejection or future profiles; syntactic validity does not enable it. The 16384-octet Reference limit includes its name, colon, folding and CRLF. Each physical line is at most 998 octets excluding CRLF. Join only FWS-separated fragments and require canonical unpadded base64url, strict safe-integer JSON at depth at most 32, and exact JCS bytes. RBA/MSA/MP schemas and transport acceptance do not authenticate current authority, grant state, Proof, or distributed replay. The fixture checker explicitly refuses to use a supplied Proof as authority while its verifier is pending. FRAME_OK tests only framing; P1_BINDING_FIXTURE_OK tests signatures/relationships under TEST ONLY pins and synthetic state and always reports can_assert_xcim_pass=false. P1-01 includes 91 binding cases (7 positive and 84 adversarial), 24 structural cases and 20 header cases. Fixture DKIM uses real Ed25519-SHA256 signatures with offline TEST ONLY DNS records, per . Singleton oversigning excludes Bcc following DKIM guidance; Bcc remains subject to MP content commitment and cardinality rules. A separate Node check reproduces positive-vector signatures and commitments without Python helpers; it is not a second complete receiver or independent operator. The selected schemas and canonical-byte rules are in . MAIL01 supplies the integration and multi-fault evaluation order. Fixture-only authority records are not trust anchors, and registration remains provisional.

Transparency, Current-State Proofs, and Publication The baseline combines an append-only event tree, authenticated sparse current-state tree, signed batches, and an externally verified anchor. Event tree history and current permission state have different roles. A proof bundle transports component evidence but does not gain authority merely from an outer wrapper or its generated_at timestamp. Batch preparation freezes consistent event/state snapshots. Retried publication preserves frozen bytes; later downloads cannot refresh a signed validity window. The Amoy testnet profile fixes additional genesis, proof-set, signer, chain, and finality relationships. MAIL01 transfers exact sparse/event-tree reconstruction and commitment rules and selects the existing AS/AN anchored families. A chain-independent profile is not introduced; full-prefix history bounds and unproven finality remain explicit. See . C4 commits to an unchanged signed WD permission batch and a separate AS authority event/state projection from one logical write cut. A new external anchor commits to C4, its sequence, predecessor, issuer/log and profile. A new checkpoint and zero-event permission batch are required to renew unchanged state; rewrapping an old batch is not renewal. C3 has the same observation time as C4 and cannot extend it. The existing Amoy 0.1 anchor does not authenticate these new authority roots. AN01 defines the selected anchor ABI/genesis; authentic deployment identity and finality verification are required for operational use. No real deployment is claimed here. The profile retains explicit anchoring; a log/witness alternative without a chain would be a separate profile. Signatures, logs and anchors alone do not prove that every state transition was authorized or the projection was computed correctly; monitoring and issuer trust remain necessary.

Receiver Verification Algorithm The following overview lists the required relationships. It is not an alternative evaluation order: specifies the ordered phases and the acceptance transaction.

1. Apply resource limits and strict JSON/base64url parsing.
2. Select exact supported versions, schemas, profile, and trust policy.
3. Resolve role-authorized receipt and batch keys with lifecycle policy.
4. Validate canonical signatures, receipt commitment, issuer, and receipt validity.
5. Bind recipient, application/epoch, permission, purpose, and authorization kind to the message or evaluation context.
6. For P1, verify the RBA/MSA/MP signatures, exact scope, signer role, delegation limits, current MSA/key state, temporal relationships, envelope commitments, and complete message-content commitment.
7. Validate issuance-event commitments, inclusion, and required history continuity.
8. Establish the selected anchor and authenticated batch roots, including profile-specific genesis/proof-set checks.
9. Validate state key, sparse proof, identity/epoch, status, and latest-event relationship.
10. Establish current application/key and role-specific domain authority.
11. Intersect authenticated validity intervals with local maximum-age policy.
12. For P1, require a qualifying DKIM signature with exact domain and actual field/full-body coverage. Reevaluate current evidence and expiry at acceptance and coordinate durable replay/SMTP acceptance; rejected input cannot consume a presentation identifier.
13. Return a specific result and non-sensitive diagnostics; apply delivery policy independently.

MAIL01 defines deterministic phase ordering, derived verification context and the acceptance transaction. The local requirements-to-tests matrix records coverage and the remaining real-provider, transport and node boundaries. See .

Freshness, Caching, and Result Semantics XCIM_PASS and XCIM_PASS_CACHED require accepted, sufficiently fresh authenticated evidence for the intended context. Cache retrieval cannot extend signed validity. XCIM_PASS_ANCHOR_PENDING is a historical spelling classified as neutral in baseline registry 0.2. Revoked, stale, indeterminate, unavailable-anchor, and invalid-log-proof outcomes are distinct. Unavailable or untrusted evidence is not PASS; losing a positive XCIM signal does not by itself require mail rejection. Issuer-side permission results and synthetic fixture outcomes are not public-proof results. MAIL01 fixes bounded clock, age, expiry and local-cache rules, including re-evaluation at commit. These are design bounds, not measured revocation latency or operational SLAs. See . with local time t and bounded uncertainty u, require an observation start s to satisfy s <= t-u, and every exclusive deadline e to satisfy t+u < e. Intersect checkpoint/control-head validity, maximum ages, manifest, trust policy, receipt, RBA/MSA/MP, required keys, state/domain observation and the selected anchor policy. No cache grace extends expiry; reevaluate at SMTP acceptance and on exported reuse. The selected experiment parameters are 300 seconds of state age, 60 seconds snapshot cadence, up to 60 seconds of clock uncertainty and 24 hours maximum root-manifest age. A 120-second p99 revocation-publication target is unmeasured and is not a security bound. Publication-key compromise or withholding a newer root manifest is not covered by a five-minute revocation claim. Root and recovery channels require separate tests. Persist accepted manifest/head/checkpoint high-water marks and observed state tombstones. Authenticated newer evidence supersedes an older still unexpired view; same-sequence conflicting commitments trigger quarantine. Loss of floors requires trusted resynchronization, not trust-on-first-use from email. Proven absence, missing proof, expiry, revocation and network failure are distinct. MAIL01 specifies precedence and durable acceptance. AS01-F01 component fixtures check bounded full history offline without operating SMTP or a live anchor.

Operational and Deployment Considerations The selected resource, time and history bounds define this experiment, not measured service levels. Before a deployment claims suitability for a workload, it needs evidence size, retrieval count, latency, publication cadence, revocation propagation and CPU/memory/network measurements under declared message rates and cache conditions. Loss of evidence or freshness withdraws the positive XCIM signal; local mail policy remains separate. Operators must account for replay pressure, lookup abuse, durable-state recovery and issuer availability. Forwarding and list expansion are outside the selected profile. No real-node trial or production availability claim is made by this draft.

Minimum Direct Email Integration Contract (MAIL01) This section specifies the bounded Reference-only integration of P1, AS01-F01 and AN01-F01 for this revision. It defines the selected minimum profile without changing historical signed objects or waiving anchor verification. The companion versioned contracts , and define the selected structural families and publication algorithms. Their development identifiers do not imply IANA registration.

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.

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 . 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.

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.

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 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.

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 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.

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.

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 . 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.

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 . 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.

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.

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.

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.

Conformance and Test Evidence Baseline reports name document revision, role, supported object versions/profiles, schema manifest digest, date, trust/finality/freshness policy, tests, and limitations. Schema acceptance, cryptographic fixtures, separate implementations, and independently operated interoperability are distinct evidence categories. MAIL01 specifies the bounded minimum integration and its local conformance cases. Real transport, lifecycle administration, node finality, MTA integration, history compaction and independent reproduction remain necessary before a global implementation-readiness claim. See .

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 .

Security Considerations The threat model includes malicious or compromised senders, issuers, applications, logs, resolvers, mirrors, trust sources, chain/RPC sources, and keys. Relevant attacks include false consent observations, deceptive presentation, replay, split views, stale authority, metadata substitution, domain transfer, SSRF, and resource exhaustion. An accepted issuer can attest falsely. Cryptographic integrity and publication ordering do not establish truth of the original identity or consent observation. Receiver trust policy and remedies for compromise must be explicit. The minimum analysis treats a malicious sender, compromised delegate, dishonest accepted issuer, withholding publisher, untrusted resolver, replaying intermediary, and compromised receiver host as distinct actors. Scope/signature checks limit cross-application or cross-recipient reuse; current authority and bounded validity limit stale acceptance only under their stated trust assumptions. Root-manifest withholding can outlast the five-minute state window. Receiver-host compromise can defeat local trust, clock, and durable floors. Neither an anchor nor a second signature removes these residual risks. The required signature, scope, age, resource, transport and durable-state checks address these attacks under the selected trust assumptions. This initial analysis has not received independent cryptographic review. In particular, the open lifecycle and continuity questions in prevent a general claim of sustained secure operation.

Privacy Considerations Public receipts, logs, and chain data exclude recipient email addresses, raw external identity tokens, credentials, private keys, and predictable unsalted email hashes. Pairwise identifiers reduce correlation but do not guarantee anonymity; timing, application/purpose metadata, and queries can still reveal relationships. Evidence services require authorized queries and resource limits as specified in . Public commitments and private mappings have different retention needs. Compromised issuers, message observers and evidence services can correlate activity; minimized fields do not eliminate those risks. Private identity and consent inputs flow to the Consent Issuer; public logs receive commitments and opaque identifiers. The direct-email RBA, MSA, and MP reach the sender and intended receiver with the message. Lookup timing and identifiers can expose relationships to evidence services. An RBA salt known to a message observer permits address guesses to be tested; it is not encryption. Retention, access control, and deletion of private mappings and receiver replay records remain profile obligations, not guarantees supplied by permanent public commitments.

IANA Considerations This revision uses provisional identifiers and makes no claim of IANA assignment. The following proposals and unresolved choices are submitted for review; no new registry or structured suffix is established here.

Media and JWS Type Identifiers 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.

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 with assignment, persistence, equivalence and change-control rules, or define an alternative and explicit migration. Existing signed identifiers cannot be silently replaced.

Email Fields and Result Reporting The candidate email field for this minimum is XCIM-Reference, with syntax in and semantics in . 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 .

Artifact Distribution and Reproducibility WD-02-E1 supplies a revision-specific source archive, schemas, registries, deterministic vectors, and fixture tools with a manifest. Historical published artifacts remain frozen. A hash manifest provides integrity comparison, not independently established release authority. The normative project dependencies are the identified WD-02-E1, P1-01, AS01-F01 and AN01-F01 revisions, not an unversioned latest implementation. An implementation report must identify the exact source revision and schema manifest it used. Public test keys are not operational credentials, and successful manifest verification establishes byte integrity rather than trust in an issuer.

Implementation Status This section is informative. MAIL01 has a same-project local integration suite with 52 passing cases covering synthetic identity/consent issuance, recipient and message bindings, authenticated authority and permission, anchor-artifact relationships, DKIM, replay, revocation memory, expiry at acceptance, restart and concurrent local acceptance. The provider, DNS and chain observations are synthetic. The durable outbox is local SQLite, not a deployed MTA or distributed MX service. P1, AS01 and AN01 supply structural and adversarial component fixtures. The local EVM tests exercise contract bytecode, while node/bootstrap tests use synthetic observations. None establishes real consensus/finality, independent interoperability or a production revocation latency. explains the role of implementation reports. Real OIDC flows, authenticated evidence services, node admission/finality, MTA/distributed storage, independent review and workload measurements remain future validation. They are separate from the unresolved specification questions in and are not prerequisites to discussing this initial Internet-Draft.

Open Design Questions and Closure Criteria The bounded MAIL01 integration is specified in this revision. The following questions delimit what remains incomplete; they do not authorize weaker verification or imply that an operational deployment has been validated. Implementations must fail to produce a positive result when a required input or proof cannot be established.

OI-01: Authority enrollment and recovery

The receiver uses an administratively installed trust policy and checks signed current application, domain, key and MSA state. Portable procedures for authenticating administrative actors, observing domain possession, changing owners and provisioning recovery across unrelated operators are not fully specified. Closure requires explicit authenticated inputs, role/epoch constraints, conflict and compromise handling, and positive and adversarial vectors for those procedures. Metadata discovery alone must never confer authority.

OI-02: Complete permission lifecycle producer

Issuance, finite expiry, current-state/latest-event verification, revocation rejection and receiver memory are specified. The full producer-side transition/actor contract for lifecycle requests, conflicting actions and recovery remains incomplete. The receiver relies on its accepted issuer's attestation of those observations. Closure requires a transition table with authorized actors, authenticated request inputs, idempotency and ordering rules, atomic event/state publication, and vectors showing that revocation or an unrelated actor cannot create a new grant.

OI-03: Sustained history continuity

AS01-F01 uses full prefixes bounded to 16 cuts/manifests and 128 events per log. Exhaustion withdraws the positive signal. There is no silent truncation or genesis reset. Closure for sustained operation requires a versioned continuity/compaction protocol preserving revocation, latest-event bindings and rollback protection for existing and new receivers, with boundary, restart and adversarial proof vectors. This revision remains explicitly bounded until such a protocol is defined.

OI-04: Registration and migration

The field, type and namespace decisions in remain provisional. Closure requires concrete registration templates or a chosen existing namespace, allocation/change-control rules where relevant, and versioned migration that does not reinterpret existing signed bytes. The selected minimum does not define an Authentication-Results method.

Independent security/privacy review, real transport/provider/node/MTA integration, interoperability and load testing are future evidence tasks described in . They cannot substitute for resolving a missing protocol rule, and the absence of those trials does not prevent publication of a draft that states its limits.

Review Objectives Review is requested on the usefulness of purpose-specific authorization for direct email, the issuer trust model, recipient/content binding, revocation and privacy tradeoffs, and the open questions in . This is an individual proposal with intended status Experimental; it does not claim working-group adoption, community consensus or a production deployment.

Normative References Unicode Consortium We Are 14 Inc We Are 14 Inc We Are 14 Inc Informative References XCIM protocol editors

Experimental Anchor and Node Adapters This informative appendix summarizes the anchor and node adapter work. The required MAIL01 publication checks remain in force; synthetic observations do not replace them. No real Amoy node admission, deployment or live-finality result is claimed.

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.

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.