email consent authorization XCIM associates a recipient's purpose-specific communication authorization with an application, identity evidence, and currently authorized sending infrastructure. Signed receipts record historical decisions; receivers additionally evaluate current permission state, authority, freshness, and local trust policy. This document is an initial editorial skeleton derived from XCIM Working Draft 02 with Erratum E1. It outlines protocol components and proposes issuer-signed recipient binding and application-signed message presentation for direct mail. It is incomplete and does not yet define an independently implementable email profile. Local Editorial Status This file has not been submitted as an Internet-Draft. The document name, author marked TBD, Experimental category, and IPR attribute are provisional rendering metadata. G17 and G18 require confirmation before submission. No Working Group adoption or community consensus is claimed. Markers G01 through G20 correspond to the companion readiness matrix and decisions IETF-D01 through IETF-D20. The project adopted D01-D06 as its design direction on 19 October 2026; D07-D20 remain open. This is not IETF adoption or a production recommendation. Baseline descriptions below summarize WD-02-E1; complete field definitions, algorithms, and references remain to be transferred. This skeleton neither changes signed historical objects nor supersedes the published Working Draft.

Introduction, Editorial Status, 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. OPEN G17/G18: confirm real authors, contribution rights, document name, intended category, and IPR metadata; complete normative transfer and submission checks. The local rendering metadata is provisional.

Scope, Use Cases, and Related Work ADOPTED PROJECT DIRECTION P1 / G01: use one document containing the core and an initial direct-mail profile: one application/epoch, one original SMTP envelope recipient, one purpose, and explicit_consent per message copy. Use OIDC-01 receipt 0.1 and the baseline current-state/publication model, including its required anchor until G06 is resolved. EVP remains experimental. The baseline distinguishes explicit consent, a transactional relationship, a service acknowledgement, and a preference. P1 proposes supporting 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. OPEN G01: D01 is accepted as project direction. Complete comparison with related consent work, and specify all mandatory profile dependencies. The companion SCOPE-AND-BINDING-PROPOSAL.md records P1's alternatives and closure conditions. These development additions do not change WD-02-E1. Details appear in and .

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.

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 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. The topology above does not define a portable recipient mapping or discovery transport. Those contracts remain open in G02 and G04.

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. OPEN G07 / IETF-D07: enumerate the complete accepted tuples including alg and typ, future issuance rules, downgrade resistance, and historical acceptance. New semantics require an explicitly selected version/profile.

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. JSON parsing precedes schema and signature semantics. E1 restricts raw number tokens 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. 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. OPEN G08 / IETF-D08: transfer the complete encoding/address procedures, Unicode/IDNA version policy, exact field bounds, and temporal ordering rules from core sections 5-6 and bindings sections 1-3. A new table version must not silently change historical recipient commitments.

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. OPEN G07: WD-02 uses alg EdDSA while deprecates that polymorphic JOSE identifier and defines the specific Ed25519 identifier. The primitive is not thereby deprecated. Select a versioned future issuance/acceptance policy; changing the protected header changes signed bytes. This skeleton does not authorize relabeling old signatures. OPEN G08/G18: transfer complete domain-separated formulas, inline manifest rules, object-specific types, and key representation requirements. Candidate references below are not a complete dependency inventory.

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. OPEN G04 / IETF-D04: specify portable discovery and lifecycle objects, transport, cache limits, compromise/rotation recovery, and current application/domain/key authority. Resolve redirect/DNS/SSRF defenses and authenticated registry updates without a fixed commercial operator. P1 additionally proposes 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.

AS-01 Authority and State Direction and Development Fixtures ADOPTED PROJECT DIRECTION G04-G06: the companion AUTHORITY-STATE-PROPOSAL.md defines candidate contracts C1-C8. AS-01 is a new explicitly selected anchored profile, not an extension of a closed WD-02-E1 object. M/O closure remains incomplete. A1-A6 are adopted; AS01-F01 supplies 19 closed schemas, 97 fixture scenarios and 37 structural cases. Eight scenarios verify positive authority relations, two verify transition/recovery artifacts and 87 are adversarial. No live endpoints are implemented. 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. Local pins are proposed first; a registry path needs its own 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. A1-A6 are adopted project direction; schemas and offline fixtures now concretize that direction. Exact anchor ABI/finality, DNS/possession, actor authentication, durable recovery/floors and result/algorithm registrations remain open dependencies. The evidence-set development schema requires anchor_evidence to be null and never establishes an anchored public-proof result. The P1 checker still refuses Proof.

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. OPEN G13 / IETF-D13: transfer the complete OIDC mapping and normative external references; define the minimum supported identity profile. EVP cannot be claimed as externally interoperable without a pinned external protocol/browser/adapter combination and end-to-end evidence.

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. OPEN G05/G09/G18: transfer complete state transitions, actor authority, receipt field semantics, idempotency behavior, and latest-event binding; provide role-specific positive and negative conformance cases.

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. ADOPTED PROJECT DIRECTION P1 / G02: a Recipient Binding Attestation (RBA), signed by the Consent Issuer, binds issuer, application/epoch, exact receipt commitment, permission, purpose, authorization kind, and pairwise recipient to an address commitment. The issuer computes it from an authenticated private observation, not from a sender-supplied address digest. RBA renewal cannot create consent. A 32-byte random salt is included in the signed object. 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. 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. OPEN G02: D02 is accepted as project direction. Closed local payload schemas and signed fixtures are available in P1-01; authority/lifecycle, privacy review, and external implementation remain open. A known salt permits offline candidate-address tests; do not publish RBA/salt in public logs or claim anonymity. This proposed object does not alter receipt 0.1.

Email Presentation and Message Binding The provisional baseline fields are XCIM-Reference and optional XCIM-Proof. Relied-upon fields are added before DKIM signing and covered by valid DKIM evidence. Duplicate/injected fields and copied proofs for the wrong recipient, application, purpose, or sender authority cannot produce a positive authorization result. ADOPTED PROJECT DIRECTION P1 / G03: a Message Presentation (MP) signed by an application-authorized message key commits to the full RBA and MSA JWS envelopes and to the message content, plus scope, random presentation_id, validity, and exact From/DKIM domains. MSA is an application-control-key signature authorizing the delegate's public key/thumbprint, role, app/epoch, finite purposes/classes/domains, authority_epoch, and validity; it cannot grant consent or authorize further delegation. 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 instead proposes 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. OPEN G03: D03 is accepted as project direction. P1-01 provides closed schemas, ABNF and signed positive/adversarial binding fixtures. Complete authority/revocation-state and Proof contracts, result mapping, external canonicalization review, MTA measurements and distributed SMTP replay. Local fixtures are not evidence of a complete receiver or independent interoperability. The released shadow-mode adapter illustrates a development encoding; it does not settle the portable mapping or production grammar. A receiver cannot infer authorization from header presence alone. Related work and registration actions remain in G01 and G12.

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

Proposed Signing Order, Transport, and Replay Obtain RBA/MSA, freeze message content, compute its commitment, sign MP, add the presentation wrapper and optional proof field, then DKIM-sign. The message commitment excludes XCIM/DKIM fields to avoid circularity. RBA/MSA envelope commitments use distinct domain-separated hashes; all duplicated scope fields must match receipt and permission exactly. The candidate 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. Proof uses a separate field with the same development framing. No sender-selected fetch URL or fallback to the legacy URL adapter is proposed. Complete ABNF remains open. 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/Proof and critical fields. Oversigning singleton fields is proposed to detect extra occurrences. Content hashes, DKIM, RBA signatures, and current state are complementary checks. Candidate pilot limits: RBA/MP lifetimes up to 24 hours, MP expiry bounded by RBA/MSA expiry, MSA up to seven days with separately verified current state, and at most 60 seconds of future iat tolerance. Expiry is exclusive with no grace extension. State freshness can be much shorter. Field limits of 16 KiB Reference and 48 KiB Proof and depth 32 are proposals requiring measurement, not operator-agreed 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. Exactly one Reference and at most one Proof are allowed, with no Proof alone or fallback to a legacy URL adapter. Limits count field names, colons, folding and CRLF: 16384 octets Reference, 49152 Proof, 65536 total; each physical line is at most 998 octets excluding CRLF. Join only FWS- separated base64url fragments and require canonical unpadded encoding, 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. See the development source package for exact schemas, canonical bytes, deterministic vectors, error labels, checks and unresolved dependencies. Final multi-fault result precedence and registration remain open. No synthetic authority/state record is standardized by this delivery.

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. OPEN G06 / IETF-D06: transfer exact tree/proof/commitment algorithms and decide required publication properties and supported profiles. WD-02 core sections 14-15 currently require anchor verification; a chain-independent profile would require an explicit new design and trust model rather than omission of an existing verification step. Amoy is experimental and does not nominate a universal production network. ADOPTED DIRECTION AS-01 / G06: 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. AS anchor ABI, contract identity, genesis and finality policy are blocking G06-M choices. No new contract has been deployed. The proposal 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.

AS Anchor Adapter: Adopted N1-N6 and Local AN01-F01 ADOPTED PROJECT DIRECTION N1-N6: a new immutable single-issuer/log EVM contract anchors the exact C4 commitment, sequence and predecessor. The proposed 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 a domain, chain ID, contract address, intent, identity, AS genesis, sequence, checkpoint and predecessor commitments. AS JCS/SHA-256 commitments and authorization signatures retain their existing 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. N1-N6 are now adopted; 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. G06-M/O remains open. 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 DEVELOPMENT IMPLEMENTATION: 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, integrated AN/AS/P1 verification, measured operation and independent review remain open. G04-G06 remain partial.

Receiver Verification Algorithm The baseline core section 15 specifies the following ordered checks. This outline needs complete input/output contracts and profile details before it can serve as an independent implementation specification.

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. Validate issuance-event commitments, inclusion, and required history continuity.
7. Establish the selected anchor and authenticated batch roots, including profile-specific genesis/proof-set checks.
8. Validate state key, sparse proof, identity/epoch, status, and latest-event relationship.
9. Establish current application/key and role-specific domain authority.
10. Intersect authenticated validity intervals with local maximum-age policy.
11. Return a specific result and non-sensitive diagnostics; apply delivery policy independently.

OPEN G09 / IETF-D09: turn each step into a deterministic contract, with requirement-to-test mapping, supported-role declarations, and multifault precedence coordinated with G05.

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. OPEN G05 / IETF-D05: define profile-specific clock skew, age limits, expiry boundaries, result precedence, absence semantics, and outage behavior. Amoy's five-minute bound is profile-specific; it is not a universal value adopted by this skeleton. Continuous freshness and concurrent-revocation behavior require operational evidence. ADOPTED DIRECTION AS-01 / G05: 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. Candidate trial 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. Detailed candidate precedence and M/O closure requirements are in AS-01 Sections 8-11; AS01-F01 checks a bounded full history offline, without operating a durable store, SMTP or live anchor.

Operational and Deployment Considerations OPEN G16 / IETF-D16: measure reference and stapled modes under declared message sizes, rates, cache settings, and network conditions. Report proof size, retrieval count, p50/p95 latency, publication cost/cadence, revocation propagation, and CPU/memory/network limits. Agree budgets with operators before using measurements as acceptance criteria. Describe degraded service, recovery, replay pressure, lookup abuse, historical verification, forwarding, and list expansion. No production availability or performance target is established by the existing historical testnet snapshot.

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. OPEN G09: specify per-role minimum behavior and test coverage, including wrong version/key role/recipient/purpose, canonical-byte differences, tampered proofs, stale state, authority expiry, domain transfer, unavailable sources, and duplicates/replay. The minimum mandatory profile is still G01.

Security Considerations Analysis must cover malicious or compromised senders, issuers, applications, logs, resolvers, mirrors, trust registries, chain/RPC sources, and keys. Relevant failures 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. OPEN G14 / IETF-D14: complete the threat model and obtain a versioned independent review with findings and dispositions. The released internal artifact checklist is not an independent cryptographic review.

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. OPEN G14: document data flows, query authorization, receiver exposure, enumeration/correlation risks, retention/deletion, salt/key lifecycle, and consent UI risks. Evaluate proposed recipient mapping G02 before choosing public fields. Fixtures and reports must use sanitized data and public test-only keys where appropriate.

IANA Considerations This skeleton defines no completed registration request. The following candidate actions remain open; project registries and provisional strings do not constitute IANA assignments.

Media Types and JWS Types OPEN G10 / IETF-D10: inventory envelope, payload, HTTP content type, and JWS typ independently and choose registration templates. The baseline uses application/xcim-receipt+jcs and other provisional names. The consulted suffix registry does not list +jcs as of 2026-10-19. Do not silently replace signed typ values with another suffix.

Identifier Namespace OPEN G11 / IETF-D11: baseline objects use urn:xcim identifiers; the consulted namespace registry does not list xcim as of 2026-10-19. Evaluate registration under or an alternative existing namespace, with assignment, persistence, equivalence, change control, and explicit historical compatibility.

Email Fields, Results, Profiles, and Extensions OPEN G12 / IETF-D12: prepare candidate XCIM-Reference/XCIM-Proof field registrations after grammar review; determine whether an Authentication-Results method is appropriate and define its grammar and results if proposed. Inventory profile/object/result/extension spaces and justify IANA versus project allocation. Specify initial values and policies with guidance.

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. OPEN G19 / IETF-D19: define the source/release policy for this work, licenses, integrity/authentication, and clean-room build instructions. Align exact revisions of repositories and archives or label their differences. Implementers must not require private product components.

Implementation Status and Remaining Evidence As recorded in the project baseline evaluated on 2026-10-19, available evidence includes synthetic Python/Node fixtures, an operator-managed application/ESP pilot, and a historical Amoy snapshot. These do not establish independent sender/receiver interoperability or currently fresh permission. No independent security review is asserted. OPEN G15 / IETF-D15: recruit consenting independent teams and record exact revisions, shared dependencies, tests, failures, and limitations. Include a second issuer before claiming multi-issuer interoperability. Open reviews and trials need not be completed to publish an initial Internet-Draft that accurately describes its limitations.

Community Review and Proposed Next Steps OPEN G20 / IETF-D20: prepare a problem-focused pitch and seek review in an appropriate forum. DISPATCH is a possible initial venue under its current charter. No external contact, adoption, or sponsorship is recorded by this skeleton. Forum selection and document category remain proposals.

Normative References (Candidate Set) Informative References XCIM protocol editors

Source Mapping and Open-Issue Ledger The companion READINESS-MATRIX.md defines G01-G20 with evidence and closure criteria; DECISIONS.md records IETF-D01-IETF-D20 as open proposals. This local appendix can be reworked for a public issue tracker before submission. Neither file constitutes adoption of a proposed design.

• Core sections 1-4 map to scope, terminology, and architecture.
• Core sections 2, 5-7 and bindings sections 1-3 map to versions, encodings, cryptography, and authority.
• Core sections 8-10 and OIDC/EVP profiles map to identity, consent, and permission lifecycle.
• Bindings section 4 and core section 17 map to portable recipient and email binding.
• Core sections 11-16 and the Amoy profile map to publication, verification, and freshness.
• Core sections 18-20 map to security, privacy, conformance, and implementation evidence.

G17 and G18 remain open for author/contact data, rights, final document name/category, complete normative transfer, reference verification, and submission-tool checks. Technical issue markers can remain in an early draft if their limitations are explicit. No submission has taken place.