



Network Working Group                                        T. TBD, Ed.
Internet-Draft                                           19 October 2026
Intended status: Experimental                                           
Expires: 22 April 2027


         XCIM: Verifiable Communication Authorization for Email
                          draft-author-xcim-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.



TBD                       Expires 22 April 2027                 [Page 1]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 22 April 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction, Editorial Status, and Problem Statement . . . .   3
   2.  Scope, Use Cases, and Related Work  . . . . . . . . . . . . .   3
   3.  Requirements Language and Terminology . . . . . . . . . . . .   4
   4.  Architecture and Trust Boundaries . . . . . . . . . . . . . .   5
   5.  Versions, Profiles, and Historical Compatibility  . . . . . .   5
   6.  Identifiers, Encodings, Canonicalization, and Time  . . . . .   6
   7.  Cryptographic Envelopes and Commitments . . . . . . . . . . .   6
   8.  Application, Domain, and Issuer Authority . . . . . . . . . .   7
     8.1.  AS-01 Authority and State Direction and Development
           Fixtures  . . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Identity Evidence and Issuer-Controlled Consent . . . . . . .   9
   10. Receipts and Permission Lifecycle . . . . . . . . . . . . . .   9
   11. Portable Recipient Mapping  . . . . . . . . . . . . . . . . .  10
   12. Email Presentation and Message Binding  . . . . . . . . . . .  11
     12.1.  Proposed Content Commitment  . . . . . . . . . . . . . .  12
     12.2.  Proposed Signing Order, Transport, and Replay  . . . . .  12
   13. P1-01 Development Schemas, Grammar, and Fixtures  . . . . . .  13
   14. Transparency, Current-State Proofs, and Publication . . . . .  15
     14.1.  AN01-P01 Anchor Adapter Proposal: Open Choices N1-N6 . .  15
   15. Receiver Verification Algorithm . . . . . . . . . . . . . . .  16
   16. Freshness, Caching, and Result Semantics  . . . . . . . . . .  17
   17. Operational and Deployment Considerations . . . . . . . . . .  18
   18. Conformance and Test Evidence . . . . . . . . . . . . . . . .  19
   19. Security Considerations . . . . . . . . . . . . . . . . . . .  19
   20. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19



TBD                       Expires 22 April 2027                 [Page 2]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   21. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     21.1.  Media Types and JWS Types  . . . . . . . . . . . . . . .  20
     21.2.  Identifier Namespace . . . . . . . . . . . . . . . . . .  20
     21.3.  Email Fields, Results, Profiles, and Extensions  . . . .  20
   22. Artifact Distribution and Reproducibility . . . . . . . . . .  20
   23. Implementation Status and Remaining Evidence  . . . . . . . .  21
   24. Community Review and Proposed Next Steps  . . . . . . . . . .  21
   25. Normative References (Candidate Set)  . . . . . . . . . . . .  21
   26. Informative References  . . . . . . . . . . . . . . . . . . .  22
   Appendix A.  Source Mapping and Open-Issue Ledger . . . . . . . .  22
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  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 [XCIMWD].  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.

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




TBD                       Expires 22 April 2027                 [Page 3]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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 Section 11 and
   Section 12.

3.  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 [RFC2119] [RFC8174] 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.



TBD                       Expires 22 April 2027                 [Page 4]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   Resolver, Mirror, or Monitor  A component transporting or inspecting
      evidence without obtaining trust merely by hosting it.

4.  Architecture and Trust Boundaries

    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

                         Figure 1: Conceptual Flow

   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.

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









TBD                       Expires 22 April 2027                 [Page 5]

Internet-Draft           XCIM Editorial Skeleton            October 2026


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

   JSON number token: -?(0|[1-9][0-9]*)

   Canonicalization uses JCS [RFC8785], 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.

7.  Cryptographic Envelopes and Commitments

   The baseline uses SHA-256, Ed25519 [RFC8032], and JWS Flattened JSON
   Serialization [RFC7515] 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.




TBD                       Expires 22 April 2027                 [Page 6]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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 [RFC9864] 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.

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









TBD                       Expires 22 April 2027                 [Page 7]

Internet-Draft           XCIM Editorial Skeleton            October 2026


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




TBD                       Expires 22 April 2027                 [Page 8]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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.

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

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







TBD                       Expires 22 April 2027                 [Page 9]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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.

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

   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.









TBD                       Expires 22 April 2027                [Page 10]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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.

12.  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 [RFC7638].  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.




TBD                       Expires 22 April 2027                [Page 11]

Internet-Draft           XCIM Editorial Skeleton            October 2026


12.1.  Proposed Content Commitment

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

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

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

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

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




TBD                       Expires 22 April 2027                [Page 12]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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.

13.  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 [RFC5234] and case-sensitive values from
   [RFC7405].  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.













TBD                       Expires 22 April 2027                [Page 13]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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

   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
   [RFC8463].  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.







TBD                       Expires 22 April 2027                [Page 14]

Internet-Draft           XCIM Editorial Skeleton            October 2026


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

14.1.  AN01-P01 Anchor Adapter Proposal: Open Choices N1-N6

   PROPOSED, NOT ADOPTED: 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



TBD                       Expires 22 April 2027                [Page 15]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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.  Schemas, source/compiler,
   real network bootstrap and deployment evidence 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 (https://docs.polygon.technology/pos/concepts/finality/
   finality/).  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 C1/C7 schemas, durable storage and a
   complete anchor verifier are required; AS01-F01 still requires a null
   slot.

   See the AN01-P01 proposal (https://xcim.org/standardization/anchor-
   adapter/) for alternatives, exact ABI, acyclic commitments and N1-N6
   closure criteria.  Local ABI/layout checks do not execute its 20
   planned EVM/network scenarios.  No contract is implemented or
   deployed and no live finality verification is claimed.  G06-M/O
   remains open.

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




TBD                       Expires 22 April 2027                [Page 16]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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.

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








TBD                       Expires 22 April 2027                [Page 17]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   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.

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






TBD                       Expires 22 April 2027                [Page 18]

Internet-Draft           XCIM Editorial Skeleton            October 2026


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

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

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





TBD                       Expires 22 April 2027                [Page 19]

Internet-Draft           XCIM Editorial Skeleton            October 2026


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

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

21.2.  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 [RFC8141] or an alternative existing
   namespace, with assignment, persistence, equivalence, change control,
   and explicit historical compatibility.

21.3.  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 [RFC8126] guidance.

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






TBD                       Expires 22 April 2027                [Page 20]

Internet-Draft           XCIM Editorial Skeleton            October 2026


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

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

25.  Normative References (Candidate Set)

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
              September 2011, <https://www.rfc-editor.org/rfc/rfc6376>.

   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
              RFC 7405, December 2014,
              <https://www.rfc-editor.org/rfc/rfc7405>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7515>.






TBD                       Expires 22 April 2027                [Page 21]

Internet-Draft           XCIM Editorial Skeleton            October 2026


   [RFC7638]  Jones, M. and N. Sakimura, "JSON Web Key (JWK)
              Thumbprint", RFC 7638, September 2015,
              <https://www.rfc-editor.org/rfc/rfc7638>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032, January 2017,
              <https://www.rfc-editor.org/rfc/rfc8032>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8463]  Levine, J., "A New Cryptographic Signature Method for
              DomainKeys Identified Mail (DKIM)", RFC 8463, September
              2018, <https://www.rfc-editor.org/rfc/rfc8463>.

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8785>.

26.  Informative References

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, April 2017,
              <https://www.rfc-editor.org/rfc/rfc8141>.

   [RFC9864]  Jones, M.B. and O. Steele, "Fully-Specified Algorithms for
              JSON Object Signing and Encryption (JOSE) and CBOR Object
              Signing and Encryption (COSE)", RFC 9864, October 2025,
              <https://www.rfc-editor.org/rfc/rfc9864>.

   [XCIMWD]   XCIM protocol editors, "XCIM Protocol - Working Draft 02
              with Erratum E1", 15 October 2026,
              <https://xcim.org/spec/v0.1/wd-02-e1/>.

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




TBD                       Expires 22 April 2027                [Page 22]

Internet-Draft           XCIM Editorial Skeleton            October 2026


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

Author's Address

   TBD (editor)

























TBD                       Expires 22 April 2027                [Page 23]
