Consent protocol: Internet-Draft -03
XCIM records explicit consent from the person controlling a recipient email address to an identified sender for specified types of communication. An independent third party attests the consent, with immutable evidence anchored in a blockchain.
Revision -03 specifies EVP, OAuth with authenticated provider API verification, and OpenID Connect (OIDC) as alternative methods to establish control of the email address giving consent. An issuer may use any one admitted method after its required checks. Address verification alone does not grant permission: the same recipient must separately and explicitly accept the identified sender and communication types.
Corrected scope and revision status · eXplicit Consent-Identified Mail (XCIM): draft-saez-xcim-03 · Published text.
This is an individual Internet-Draft with intended status Experimental. Publication does not imply IETF endorsement, working-group adoption or an approved RFC. Amoy provisioning and live-node trials remain paused.
Draft-00 editorial preview
Historical pre-submission preview; this earlier working copy was not submitted. The current publication status and corrected scope are linked above. D01–D03 project design adoption does not constitute IETF adoption.
RFCXML source · Plain text · Development artifacts and pending dependencies
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. AS Anchor Adapter: Adopted N1-N6 and Local AN01-F01 . . 15
15. NB01-F01 Receiver Node and Authenticated Bootstrap . . . . . 17
16. Receiver Verification Algorithm . . . . . . . . . . . . . . . 18
17. Freshness, Caching, and Result Semantics . . . . . . . . . . 19
18. Operational and Deployment Considerations . . . . . . . . . . 20
19. Conformance and Test Evidence . . . . . . . . . . . . . . . . 20
20. Security Considerations . . . . . . . . . . . . . . . . . . . 20
TBD Expires 22 April 2027 [Page 2]
Internet-Draft XCIM Editorial Skeleton October 2026
21. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
22.1. Media Types and JWS Types . . . . . . . . . . . . . . . 21
22.2. Identifier Namespace . . . . . . . . . . . . . . . . . . 21
22.3. Email Fields, Results, Profiles, and Extensions . . . . 21
23. Artifact Distribution and Reproducibility . . . . . . . . . . 22
24. Implementation Status and Remaining Evidence . . . . . . . . 22
25. Community Review and Proposed Next Steps . . . . . . . . . . 22
26. Normative References (Candidate Set) . . . . . . . . . . . . 22
27. Informative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Source Mapping and Open-Issue Ledger . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
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. 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
TBD Expires 22 April 2027 [Page 15]
Internet-Draft XCIM Editorial Skeleton October 2026
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 (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 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 (https://xcim.org/standardization/anchor-
adapter/) 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
TBD Expires 22 April 2027 [Page 16]
Internet-Draft XCIM Editorial Skeleton October 2026
fixture checker always reports consensus verification false and
cannot assert XCIM_PASS. See AN01-F01
(https://xcim.org/standardization/an01/) for source, schemas,
deterministic fixtures, build instructions and the partial coverage
map of the original 20 network scenarios.
15. 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
(https://xcim.org/standardization/nb01/). Live API compatibility,
authenticated real checkpoints/node admission, integrated AN/AS/P1
verification, measured operation and independent review remain open.
G04-G06 remain partial.
TBD Expires 22 April 2027 [Page 17]
Internet-Draft XCIM Editorial Skeleton October 2026
16. 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.
TBD Expires 22 April 2027 [Page 18]
Internet-Draft XCIM Editorial Skeleton October 2026
17. 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.
TBD Expires 22 April 2027 [Page 19]
Internet-Draft XCIM Editorial Skeleton October 2026
18. 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.
19. 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.
20. 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.
TBD Expires 22 April 2027 [Page 20]
Internet-Draft XCIM Editorial Skeleton October 2026
21. 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.
22. 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.
22.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.
22.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.
22.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.
TBD Expires 22 April 2027 [Page 21]
Internet-Draft XCIM Editorial Skeleton October 2026
23. 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.
24. 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.
25. 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.
26. 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>.
TBD Expires 22 April 2027 [Page 22]
Internet-Draft XCIM Editorial Skeleton October 2026
[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>.
[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>.
27. 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>.
TBD Expires 22 April 2027 [Page 23]
Internet-Draft XCIM Editorial Skeleton October 2026
[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.
* 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 24]