eXplicit Consent-Identified Mail (XCIM)
draft-saez-xcim-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Damian Saez | ||
| Last updated | 2026-10-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-saez-xcim-04
Network Working Group D. Saez
Internet-Draft We Are 14 Inc
Intended status: Experimental 26 October 2026
Expires: 29 April 2027
eXplicit Consent-Identified Mail (XCIM)
draft-saez-xcim-04
Abstract
XCIM specifies evidence that a party controlling an email address
explicitly consented to receive defined types of communication from
an identified sender. A trusted third-party Consent Attester
verifies address control, observes a separate affirmative decision,
and signs an attestation binding the recipient, sender, and agreed
types. Blockchain anchoring provides immutable evidence of the
attestation under an admitted finality policy. Authenticated
lifecycle events and fresh status distinguish the historical decision
from current consent.
XCIM concerns the consent relationship independently of individual
email messages. It does not sign, inspect, classify, or authenticate
their content. A receiving email service may use verified current
consent as a positive policy signal after independently establishing
the sender identity relevant to its query. This document defines a
portable consent object format and verification contract, together
with requirements for separately admitted blockchain adapters. It
does not select a universal blockchain network or claim operational
readiness.
An alternative shared revocation profile allows reusable original
grants and incremental withdrawal distribution. It replaces repeated
individual positive-status statements with authenticated,
sufficiently recent synchronization evidence covering a sender epoch.
Endpoint design and data-flow optimization remain implementation
choices.
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/.
Saez Expires 29 April 2027 [Page 1]
Internet-Draft XCIM 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 29 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope Correction from Revisions -00 and -01 . . . . . . . 4
1.2. Changes from Revision -02 . . . . . . . . . . . . . . . . 4
1.3. Changes from Revision -03 . . . . . . . . . . . . . . . . 4
2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements Language and Roles . . . . . . . . . . . . . . . 5
4. Consent Flow and Trust Boundaries . . . . . . . . . . . . . . 6
5. Common Wire Rules and Cryptography . . . . . . . . . . . . . 7
6. Trust Policy, Keys and Sender Epochs . . . . . . . . . . . . 8
7. Recipient Address Representation . . . . . . . . . . . . . . 9
8. Sender Binding . . . . . . . . . . . . . . . . . . . . . . . 9
9. Consent Attestation . . . . . . . . . . . . . . . . . . . . . 10
9.1. Address Control and Separate Consent Decision . . . . . . 11
9.1.1. OIDC Address Control (oidc-01) . . . . . . . . . . . 12
9.1.2. OAuth-Based Provider Verification (oauth-01) . . . . 12
9.1.3. EVP Address Control (evp-01) . . . . . . . . . . . . 14
9.1.4. Common Explicit Decision . . . . . . . . . . . . . . 17
10. Withdrawal and Immutable Lifecycle . . . . . . . . . . . . . 18
11. Fresh Current Status . . . . . . . . . . . . . . . . . . . . 19
12. Immutable Blockchain Evidence . . . . . . . . . . . . . . . . 20
12.1. Anchor Batch . . . . . . . . . . . . . . . . . . . . . . 20
12.2. Blockchain Adapter Contract and Limits . . . . . . . . . 21
13. Evidence Set and Acquisition . . . . . . . . . . . . . . . . 22
14. Consent Verification and Results . . . . . . . . . . . . . . 23
15. Shared Revocation Synchronization (SR01) . . . . . . . . . . 24
Saez Expires 29 April 2027 [Page 2]
Internet-Draft XCIM October 2026
15.1. Scope, Encoding and Authority . . . . . . . . . . . . . 25
15.2. Revocation History and Immutable Log Heads . . . . . . . 26
15.3. Fresh Shared Synchronization Checkpoint . . . . . . . . 27
15.4. Complete Local Views and Incremental Acquisition . . . . 28
15.5. Evidence Set and Verification . . . . . . . . . . . . . 29
16. Optional Consumption by Email Services . . . . . . . . . . . 30
17. Security Considerations . . . . . . . . . . . . . . . . . . . 31
18. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
18.1. EVP Evidence and Origin Privacy . . . . . . . . . . . . 33
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
20. Conformance, Validation and Remaining Work . . . . . . . . . 33
20.1. EVP Profile Validation . . . . . . . . . . . . . . . . . 34
20.2. OAuth Provider Profile Validation . . . . . . . . . . . 35
21. Implementation Status . . . . . . . . . . . . . . . . . . . . 35
22. Normative References . . . . . . . . . . . . . . . . . . . . 36
23. Informative References . . . . . . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
The question addressed by XCIM is whether the party controlling
recipient address R explicitly authorized identified sender S to send
communications of type T, as attested by accepted third party A, and
whether that consent remains current. The evidence can be created
and verified before any email exists. Verifying it neither consumes
the consent nor authorizes a different sender or communication type.
A sender in this model is the company or other entity that receives
the consent. A technical application, email service provider, OAuth
client, domain, and signing key can support that entity but are not
automatically equivalent identities. The third party binds the
recipient's decision to the identity and scope actually presented to
the recipient.
Cryptographic signatures authenticate the attester and the recorded
statement. Blockchain evidence preserves its committed history under
the selected consensus and finality assumptions. Neither mechanism
independently observes a human decision or makes a dishonest attester
truthful. Explicit trust in the third party remains part of the
protocol.
Saez Expires 29 April 2027 [Page 3]
Internet-Draft XCIM October 2026
1.1. Scope Correction from Revisions -00 and -01
Revisions -00 and -01 made a direct-email presentation profile
mandatory, including Message Presentation (MP), Message Signer
Authorization (MSA), message content commitments, DKIM checks, and
SMTP replay coordination. That integration exceeded the intended
scope of XCIM. Revision -02 replaced it with a consent protocol that
is independent of individual messages. This is a substantive scope
and wire-format change, not a title-only revision.
P1 and MAIL01 objects are not accepted as C01 merely by changing
their labels. Historical documents and signed bytes retain their
original interpretations. Their message-processing requirements and
tests do not define conformance to this revision. The consent,
identity, cryptographic and publication concepts that remain relevant
are specified explicitly below.
1.2. Changes from Revision -02
Revision -03 specified EVP, OAuth-based provider verification and
OIDC as alternative address-control methods. No method is
universally required. It separates their issuance procedures from
the common explicit-consent decision, defines the attester and
delegated-origin roles, and requires method-specific admission
policy. The consent relationship, communication types, lifecycle and
blockchain requirements retain their -02 meanings. No individual
email message becomes a core protocol input.
C01 retains profile string xcim-consent-01 because the existing
oidc-01 fields and their signed meaning are preserved; evp-01 and
oauth-01 are explicit new method values. An implementation of -02
that does not support a method MUST reject it rather than reinterpret
it as oidc-01. Local admission configuration MUST name the method
explicitly when upgrading. Historical WD receipt 0.2 objects are not
C01 objects and MUST NOT be relabelled or converted without a new
conforming attestation.
1.3. Changes from Revision -03
This revision adds Shared Revocation Synchronization (SR01), an
explicitly admitted alternative to the individual C01 status path.
Original C01 grants and their finite validity are preserved. An
attester publishes authenticated withdrawals and shared checkpoints;
a verifier can retain grants and a complete revocation history and
obtain only incremental changes. The new profile is xcim-consent-
sync-01. Existing C01 objects are not relabelled, and C01-only
verifiers cannot accept the new evidence set. No opt-in/unsubscribe
product, campaign workflow or per-message processing is required by
Saez Expires 29 April 2027 [Page 4]
Internet-Draft XCIM October 2026
the core.
2. Scope and Non-Goals
The core covers address control at the time of consent, the sender
identity and scope shown to the recipient, the descriptions of the
accepted communication types, third-party attestation, immutable
blockchain evidence, authenticated withdrawal, and current-state
verification. Promotional and transactional communications are
examples of types for which explicit consent can be given. A
transactional relationship is not itself explicit consent.
There is no XCIM requirement to sign or hash an email, carry a
particular email header, create one copy per recipient, generate a
per-message token, or contact the attester for every email. Email
content, MIME, transport paths, forwarding, message replay, SMTP
acceptance, and mailbox delivery are outside this core. An
implementation MUST NOT require any of them as inputs to core consent
verification.
A consent result does not certify that a particular message belongs
to the queried type. Classification and use of that result belong to
the consuming application. XCIM does not guarantee message safety,
legal compliance, continued mailbox ownership, or inbox placement.
3. Requirements Language and Roles
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 party whose control of an email address is established
for the consent decision; this does not require proof of a civil
identity.
Sender The identified company or other entity and bounded scope to
which consent is granted.
Consent Attester The third party that establishes address control,
observes explicit consent, and signs attestations and lifecycle
observations. This corresponds to the earlier Consent Issuer
role.
Publisher The party making commitments and lifecycle evidence
available and anchoring historical records in an admitted
blockchain.
Saez Expires 29 April 2027 [Page 5]
Internet-Draft XCIM October 2026
Verifier A party evaluating consent evidence under previously
accepted trust and finality policy. It need not operate an email
service.
Communication type A stable, versioned description of the class of
communications agreed to, within the sender scope. It is not a
classification of an individual email.
C01 The portable consent object and verification profile defined
here, with profile string xcim-consent-01.
4. Consent Flow and Trust Boundaries
Recipient -- address control + explicit decision --> Attester
Sender ---- entity/scope enrollment ---------------> Attester
Attester -- signed consent/lifecycle --------------> Publisher
Publisher - commitments --------------------------> Blockchain
Verifier -- recipient/sender/type query -----------> Evidence
Verifier -- accepted trust + verified chain proof -> Consent result
Email service (optional) --------------------------> Uses result
Figure 1
1. The attester authenticates enrollment of the sender identity and
scope.
2. The attester establishes control of the recipient address and
observes a separate affirmative decision for the frozen sender,
notice and type definitions.
3. The attester issues the signed consent and publishes an immutable
commitment, directly or in the batch defined below, on an
admitted blockchain.
4. Authenticated withdrawal events remove accepted types without
changing the historical grant. Fresh signed status reports the
current projection.
5. A verifier checks the exact queried relationship, attestation,
historical blockchain evidence and current status. Repeated
verification does not consume the grant.
An identity provider and the Consent Attester are different roles
even if one organization performs both. The sender's claim that a
recipient consented is insufficient. Evidence transport and
discovery do not establish trust. A signature by an otherwise
unknown attester cannot install that attester into verifier policy.
Saez Expires 29 April 2027 [Page 6]
Internet-Draft XCIM October 2026
Two explicit verification paths are defined: the existing individual
C01 status path and the SR01 shared revocation path in Section 15.
Neither renews the recipient decision when evidence is refreshed.
The per-consent status steps above describe C01; SR01 substitutes the
shared verification rules without removing grant, authority or
blockchain checks.
5. Common Wire Rules and Cryptography
C01 uses JSON [RFC8259], JCS [RFC8785], SHA-256 [RFC6234], Ed25519
[RFC8032], and JWS Flattened JSON Serialization [RFC7515]. The fully
specified JOSE algorithm identifier is Ed25519, following [RFC9864].
All objects specified here are closed: unknown members are rejected.
An unsupported profile is not interpreted as an older profile.
Input MUST be valid UTF-8 without duplicate member names or invalid
Unicode scalar values. JSON number tokens MUST be non-negative
integers without fractional or exponent syntax, from 0 through
9007199254740991. Boolean values are not integers. Implicit Unicode
normalization is forbidden. JCS ordering and encoding apply exactly;
already signed protected headers and payloads MUST contain their
canonical bytes.
Each envelope contains exactly protected, payload, and signature,
encoded with canonical unpadded base64url [RFC4648]. Decode and re-
encode equality, including unused trailing bits, is REQUIRED. The
protected header contains exactly alg, kid, and typ; alg is Ed25519
and typ is application/xcim-consent+json. The type is provisional
and not registered. No unprotected header, detached payload,
b64=false, key URL, embedded key, or algorithm fallback is accepted.
The signature is 64 octets over the ASCII protected segment, a
period, and the ASCII payload segment.
Every signed payload contains profile equal to xcim-consent-01, its
kind, and issuer. The issuer is identical across all objects
combined in an Evidence Set. Payload commitments use the following
function; the signature envelope is not hashed. Signed kind and
profile prevent cross-family reuse.
H(P) = base64url(SHA-256(
UTF8("XCIM-C01-OBJECT") || 0x00 || JCS(P)))
Hashes and recipient salts decode to 32 octets. Times are non-
negative integer UTC seconds since the Unix epoch; expiry is
exclusive. Epochs and type versions start at one. Issuer, sender,
type, policy, log and anchor-profile identifiers are absolute ASCII
HTTPS URIs, at most 512 characters, without userinfo, query or
fragment; they are compared exactly and MUST NOT trigger automatic
Saez Expires 29 April 2027 [Page 7]
Internet-Draft XCIM October 2026
discovery. consent_id and event_id are lowercase UUID version 4 URNs
as specified in [RFC9562]. Random identifiers and salts MUST be
generated with a cryptographically secure random source.
kid is 1 to 200 printable ASCII characters. Text fields contain 1 to
4096 Unicode scalar values unless a narrower rule is given. Type
arrays contain 1 to 64 entries with unique type_id values, sorted in
ASCII order of type_id. Arrays of type identifiers use the same
ordering and uniqueness. An ordinary JWS envelope is at most 128
KiB; an anchor_batch JWS envelope is at most 512 KiB, with decoded
payload at most 256 KiB. Complete evidence is at most 2 MiB and JSON
depth at most 16. A batch has at most 4096 leaves. Limits are
applied before expensive work; partial verification is not success.
6. Trust Policy, Keys and Sender Epochs
Before evaluating evidence, the verifier administrator installs
policy binding the exact issuer to an accepted third-party attester,
role-authorized public keys, key identifiers, issuance windows,
compromise/revocation state, sender epoch restrictions, admitted
address-control policies, withdrawal procedures, supported blockchain
profiles, clock bounds and policy expiry. The configuration is
authenticated local input, not a member of untrusted Evidence Sets.
No trust-on-first-use or self-declared accreditation is implied.
kind required signing role
sender sender_binding
consent consent_attestation
revocation consent_revocation
status consent_status
anchor_batch anchor_publication
The signature MUST be authorized for its role and issuer at
issued_at, or this_update for status, or created_at for a batch.
Current policy determines whether historical signatures remain
acceptable after key retirement or compromise. Routine key rotation
need not erase historical evidence. The status signing key MUST also
be authorized at evaluation time; its validity end limits the
positive-result deadline. Compromise handling can invalidate
previously accepted signatures under authenticated policy.
Role delegation is not inferred. Rotation and recovery require
authenticated administrator configuration; new keys cannot authorize
their own admission. Losing a policy or rollback-protection store
requires authenticated recovery. A missing store MUST NOT silently
become an empty trusted history.
Saez Expires 29 April 2027 [Page 8]
Internet-Draft XCIM October 2026
The attester MUST stop issuing positive status for a sender epoch
retired because the identified entity or consent scope changed. A
verifier MUST honor known epoch restrictions and MUST NOT return to
an older epoch. Changing a domain or technical key does not transfer
a consent relationship to another company. A new entity, broader
scope, or new epoch requires a new recipient decision and a new
consent identifier.
Each admitted address-control policy MUST identify exactly one
supported method and its immutable validation rules. Admission of
one method MUST NOT admit another implicitly. A changed external
revision, validation rule or delivery-mode authority requires a new
policy identifier and explicit admission. Unknown methods or
policies MUST NOT yield a positive consent result. Merely adding a
method to a schema grants no trust.
7. Recipient Address Representation
The selected address_profile is ascii-idna15-1. Remove only outer SP
and HTAB and require exactly one @. The local part is an ASCII dot-
atom: letters, digits and !#$%&'*+-/=?^_`{|}~ separated by single
periods. It contains 1 to 64 octets, with no leading, trailing or
consecutive periods. Its case, periods and plus tags are preserved.
No provider-specific alias equivalence or local-part lowercasing is
inferred.
Map the domain using non-transitional UTS #46 revision 31 with STD3
rules and Unicode 15.1.0 data [UTS46] [IDNAMAP151], then apply
IDNA2008 validation including hyphen, Bidi and Joiner checks
[RFC5890] [RFC5891]. The result is lowercase A-labels of 1 to 63
octets, a domain of at most 253 octets, and a complete address of at
most 254 octets. Reject a trailing domain period. Quoted local
parts and SMTPUTF8 addresses are unsupported by this address profile.
Changing tables or equivalence rules requires another profile.
The canonical address is a private verifier input, not an email body
or header. The attester derives the recipient commitment from its
authenticated observation. A recomputable hash supplied by a sender
does not establish address control.
8. Sender Binding
The payload has exactly the following members, in addition to the
common semantic constraints:
profile, kind, issuer, sender_id, sender_epoch, name, scope,
entity_evidence_commitment, issued_at, expires_at
Saez Expires 29 April 2027 [Page 9]
Internet-Draft XCIM October 2026
kind is sender. name and scope identify the company or other entity
and exact brand/service boundaries shown to the recipient. The
attester MUST authenticate the enrolling actor's authority to
represent that entity and retain the observed identity and scope
evidence. A display name supplied by the sender is insufficient.
entity_evidence_commitment is a 32-octet commitment to randomized
private evidence under the admitted attester policy; it is opaque to
the verifier and does not claim a universal legal-entity
certification.
sender_id is an issuer-assigned stable identifier and MUST NOT be
reassigned to another entity. sender_epoch is positive. The binding
has finite validity with issued_at earlier than expires_at. Consent
embeds H of this exact binding. The signed name and scope, rather
than an unrelated website label, are presented during the consent
decision. A technical application identifier can be mapped to this
identity by a consuming application but cannot silently enlarge the
consent scope.
9. Consent Attestation
The payload has exactly the following members, in addition to the
common semantic constraints:
profile, kind, issuer, consent_id, sender_id, sender_epoch,
sender_binding_commitment, address_profile, recipient_salt,
recipient_commitment, types, notice, control, decision,
accepted_at, issued_at, expires_at
kind is consent and decision is exactly explicit_consent. Each types
entry contains exactly type_id, version, title and description. The
descriptions are the meanings accepted by the recipient and are
covered by the signature. notice contains exactly language and text;
language is 1 to 35 ASCII characters. control contains exactly
method, policy_id, observed_at and evidence_commitment. method is
evp-01, oauth-01 or oidc-01. policy_id identifies an immutable policy
admitted by the verifier for that exact method. The opaque 32-octet
evidence commitment binds the randomized private observation and
decision record retained by the attester.
Require control.observed_at no later than accepted_at, accepted_at no
later than issued_at, and issued_at earlier than finite expires_at.
The sender binding MUST already be valid at accepted_at, its
commitment and sender identity/epoch MUST match exactly, and its
expiry MUST be no earlier than the consent expiry. The admitted
policy specifies a maximum age between control observation and
acceptance; arbitrarily old authentication is not accepted as current
observation.
Saez Expires 29 April 2027 [Page 10]
Internet-Draft XCIM October 2026
recipient_salt is a fresh random 32-octet value. With the canonical
private address, compute the following exact commitment. The signed
grant and its salt are access-controlled evidence; only commitments
are published in the public anchor batch.
recipient_commitment = base64url(SHA-256(
UTF8("XCIM-C01-RECIPIENT") || 0x00 || JCS([
issuer, consent_id, sender_id, sender_epoch,
address_profile, recipient_salt, canonical_recipient
])))
Every accepted type is explicit. There is no wildcard, implied
affiliate permission or inference from a transactional relationship.
Changing a description or adding a type requires a new affirmative
decision for that meaning and a new consent identifier. Identical
identifiers with broader descriptions MUST NOT preserve the old
consent. The evidence does not assert that any actual email matches
a type description.
The tuple (issuer, sender_id, sender_epoch, type_id, version) MUST
identify one immutable title and description. A changed definition
requires a higher version or a new type_id, as well as a new consent
decision. A verifier MUST compare a definition with any previously
authenticated definition for that tuple or one supplied by its
trusted consuming policy; different meanings at the same tuple are a
conflict, not an expansion of consent. An unknown definition can be
learned only from accepted attestation evidence, not from an
unauthenticated sender label.
9.1. Address Control and Separate Consent Decision
Address control and communication consent are separate operations.
XCIM supports EVP (evp-01), OAuth-based provider verification (oauth-
01), and OpenID Connect (oidc-01) as alternatives. An attester MAY
implement one or more; a deployment selects a method supported by
both the attester and the verifier's admitted policy. These are
alternative evidence paths, not cumulative prerequisites or a
requirement to migrate to EVP. OAuth-based verification obtains
address evidence from an admitted provider API; OIDC validates an ID
Token under its authentication protocol. OAuth authorization alone
is not proof of address control. None of these operations grants
communication consent. Unrelated API authorization and backend
authentication remain outside this choice.
Saez Expires 29 April 2027 [Page 11]
Internet-Draft XCIM October 2026
9.1.1. OIDC Address Control (oidc-01)
OIDC processing uses OpenID Connect Core 1.0 incorporating errata set
2 [OIDCCore] and JWT security guidance [RFC8725]. The attester
preselects provider issuer, permitted keys/algorithms, clients,
address-authority policy, consent origin and return URI. Use
authorization code flow with PKCE and session-bound state and nonce.
Token claims MUST NOT choose the trusted provider or cause arbitrary
discovery.
Validate the signature, issuer, audience, authorized party where
applicable, subject, nonce, times and address claims under that
policy. The admitted provider must be authoritative for the observed
address; email_verified alone is insufficient. The observed
canonical address MUST match the frozen recipient. Raw tokens,
subjects, credentials and email addresses MUST NOT be placed in
public logs or on chain.
The authenticated address claims MUST include email_verified as the
Boolean true for the address used. If the address is obtained from
the OIDC UserInfo endpoint, validate that endpoint under the admitted
provider policy and require its subject to match the validated ID
Token subject. A verified claim still requires the provider's
address-authority assessment; it does not establish perpetual
ownership of the mailbox.
Record control.method as oidc-01 only after validating the ID Token
and the address-authority policy. An access token, authorization
code or user-supplied email MUST NOT substitute for that validation.
control.observed_at records successful validation, not the time a
login page was opened. Apply [RFC9700] to the underlying OAuth flow
and use PKCE S256 [RFC7636]. A failure MUST NOT be relabelled as
success under oauth-01; changing methods requires a new, explicitly
selected and independently validated flow.
9.1.2. OAuth-Based Provider Verification (oauth-01)
This method uses the authorization-code grant of [RFC6749] with
[RFC9700] and PKCE S256 [RFC7636] to access a provider's
authenticated account address service. OAuth does not define a
universal verified-email response. Consequently, oauth-01
additionally requires an immutable provider profile admitted under
control.policy_id. A provider that offers only an editable contact
field, an unverified address or token-activity information cannot
satisfy this method.
Saez Expires 29 April 2027 [Page 12]
Internet-Draft XCIM October 2026
The provider profile MUST identify the authorization server, exact
HTTPS authorization, token and account-address endpoints, API
revision, registered client and redirect URI, required least-
privilege scopes, response schema, authenticated account identifier,
and the exact semantics and provenance of the provider's address-
verification evidence. It MUST explain why that provider is accepted
as authoritative for the address and how current account control is
established. A display name, username, domain suffix or flag named
verified is insufficient without those semantics. Changes to those
rules require new policy admission.
For this method the attester is the OAuth client, including any
backend component it operates under the same trust boundary. It MUST
start a fresh authorization transaction bound to the recipient's
browser and pending consent session. Freeze the provider profile,
client, exact redirect URI, sender binding, notice and type
definitions before redirect. Generate independent unpredictable
state and PKCE verifier values and validate their transaction
binding. Protect against authorization-server mix-up, code
injection, replay and cross-site request forgery. Redeem the code
once at the preconfigured token endpoint with the same redirect URI
and PKCE verifier, and authenticate the client where required.
The attester MUST obtain the token through that transaction, not
accept an arbitrary bearer token from a sender or browser. Implicit,
password and client-credentials grants do not satisfy this profile.
A refresh token or preexisting application session alone MUST NOT
create a new address observation for consent issuance. Check token
response type, granted scopes and lifetime under the provider
profile. Tokens need not be JWTs: decoding a token or obtaining an
active introspection result is not proof of address control.
Using that token, the attester MUST request the authenticated current
account's address evidence directly over certificate-validated HTTPS
at the admitted resource endpoint. It MUST NOT use an arbitrary
address-lookup endpoint or an account identifier supplied by the
sender. Reject unexpected redirects, malformed or ambiguous
responses, expired credentials, insufficient scopes and failed
account binding. The response MUST bind a provider-authenticated
account identifier to the verified address, and the profile MUST
establish that this is the account that authorized the transaction.
An API accessible with an app-only credential or returning a client-
selected account does not establish that binding.
The address evidence MUST represent verified control under the
admitted profile, not merely a deliverability check or an address the
account can edit without verification. If several addresses are
returned, the chosen one MUST individually satisfy that profile;
Saez Expires 29 April 2027 [Page 13]
Internet-Draft XCIM October 2026
selecting a primary address does not imply verification. Apply
Section 7 only after validating provider evidence. Preserve the
local part and compare the result with any frozen expected recipient.
If none was specified, freeze the validated address and present it to
the recipient before the separate decision. Account or address
mismatch MUST terminate the flow.
The admitted policy MUST fix finite transaction and observation-to-
decision age bounds, each no greater than 300 seconds for oauth-01.
The transaction MUST be unexpired when the API response is validated
and when the decision is accepted. A new API read MUST NOT reset the
transaction deadline or turn cached historical verification into a
fresh user transaction. control.observed_at is the time the attester
successfully validates the current provider response. The provider
profile MUST specify acceptable age or revalidation rules for the
underlying address evidence; the response retrieval time alone cannot
establish it.
After a separate affirmative decision, record control.method as
oauth-01 and the corresponding admitted policy_id. The randomized
private evidence commitment MUST bind the provider profile and
revision, account/address observation, transaction binding and
validation outcome, sender binding, notice, type definitions and
decision. Raw access tokens, refresh tokens, authorization codes and
client secrets MUST NOT appear in the consent object, public logs or
blockchain. Keep credentials only as needed for the verification
transaction, protected from disclosure. The private evidence record
need not retain reusable credentials.
A later verifier evaluates the attester's admitted method and policy
and the ordinary C01 consent evidence. It does not call the provider
API for each email or receive an access token. OAuth scope approval
remains distinct from approval of communication types. Token expiry
or revocation does not by itself revoke XCIM consent; XCIM withdrawal
and fresh status determine current permission.
9.1.3. EVP Address Control (evp-01)
The external protocol for this method is revision -02 of
[I-D.hardt-email-verification]. It remains Work in Progress. The
attester MUST validate the presentation according to that revision's
Sections 2.8, 3, 5.3 and 6.5, including the hash input specified in
Section 6.4, and apply [RFC8725]. A browser trial or future EVP
revision is not automatically interchangeable with this revision.
The browser obtains an issuer-signed Email Verification Token (EVT)
and presents it with a Key Binding JWT (KB-JWT). The attester uses
the authenticated address observation as one input to its consent
Saez Expires 29 April 2027 [Page 14]
Internet-Draft XCIM October 2026
session. The EVP issuer establishes address control; the Consent
Attester observes and attests the separate recipient decision. These
roles MUST NOT be conflated with the sender entity receiving consent.
For XCIM, the admitted policy MUST fix the external revision, allowed
algorithms, discovery and address-authority rules, validation
software version, delivery mode, exact verification origin, and time
bounds. It MUST NOT select these authorities from an unverified
token or browser-supplied assertion. Discovery MUST use
authenticated HTTPS and a trusted DNS resolution policy, with bounded
retrieval, cache lifetime, redirects and key-set size. Reject
destinations outside that policy, including local or private network
addresses unless separately configured. DNSSEC validation or an
authenticated pinned delegation MAY strengthen domain authority;
ordinary DNS resolution does not imply DNSSEC proof.
Generate a fresh, unpredictable session nonce with at least 128 bits
of entropy before requesting address evidence. The attester MUST
bind it to exactly one pending consent context. The expected
recipient may initially be unset, but MUST be frozen from the
validated address before the consent presentation and affirmative
decision. A submitted form value alone MUST NOT select the attested
recipient. Once frozen, the address, sender, types or verification
origin MUST NOT be replaced within that context; a change requires a
new nonce and session.
All external address comparisons MUST use the external protocol's
exact comparison rules before applying the C01 address
representation. When the session already has an expected address,
the validated address MUST match it under those rules before the
session can proceed. Then canonicalize the verified address under
Section 7 and bind it to the consent recipient. The attester MUST
NOT lowercase the local part, remove tags or dots, or substitute a
sender's customer-list entry. An unsupported address is not silently
converted. For a private address, consent applies only to the
validated address presented to the recipient for this decision, not
to its underlying mailbox or other aliases.
Saez Expires 29 April 2027 [Page 15]
Internet-Draft XCIM October 2026
The policy MUST set finite maximum ages for both token issue times
and the pending session. For this XCIM method, each maximum MUST be
no greater than 300 seconds; permitted clock uncertainty MUST be no
greater than 60 seconds. With validation time t and uncertainty u,
require each issue time i to satisfy i <= t-u and t+u-i <= its
maximum age. The session MUST remain unexpired at validation and
acceptance; an additional token expiry, when present, MUST also be
enforced. The token age limit MUST NOT be reset by reloading or
relaying evidence. control.observed_at is the attester's successful
validation time. The admitted maximum observation-to-decision age
MUST be finite and no greater than 300 seconds for evp-01.
9.1.3.1. Attester Origin and Delegated Origin
In attester-origin mode, the attester is the EVP relying party and
validates the presentation against its own preconfigured HTTPS origin
and pending-session nonce. It then presents the frozen sender,
notice and type definitions for a separate affirmative decision.
In delegated-origin mode, a sender or its service operates the EVP
relying-party origin and relays the complete raw presentation to the
attester over an authenticated, confidential backchannel. The
attester MUST preauthorize that exact origin and backend principal
for evidence submission on behalf of the identified sender. This
authority neither permits granting consent nor permits signing XCIM
attestations. The attester MUST validate the raw evidence itself; a
backend's verified=true assertion is insufficient.
Before collecting evidence, the attester MUST freeze the delegated
origin and nonce in its consent session. An authenticated backend
MAY propose a cryptographically random nonce, but the attester MUST
admit and bind it before evidence collection. At submission it MUST
recheck the delegation, backend principal, session, sender, nonce,
expected origin and expiry. Evidence addressed to the delegated
origin MUST NOT be relabelled as evidence addressed to the attester's
origin.
The browser then reaches the attester's top-level consent surface
through a single-use session continuation bound to the same browser
context. The attester MUST authenticate that continuation and
protect the decision against cross-site request forgery, session
fixation and clickjacking. A leaked session identifier, sender-
controlled return URL or bare redirect MUST NOT enable another
browser to approve the verified recipient's consent. Only the
attester observes the final affirmative action. The handoff API,
credentials and browser transport are deployment choices; this
document does not prescribe vendor endpoints.
Saez Expires 29 April 2027 [Page 16]
Internet-Draft XCIM October 2026
9.1.3.2. Attestation Mapping and Failure Handling
After validating EVP and observing the separate decision, the
attester sets control.method to evp-01, control.policy_id to the
admitted EVP policy, and control.observed_at to the recorded
validation time. The existing private evidence commitment MUST bind
the exact validated presentation, its session and origin, the policy
and adapter version, sender binding, canonical recipient, notice,
type definitions and affirmative decision. Its randomized opening
remains private under attester policy. It is not a public EVT
fingerprint or a new bearer token. No additional member is added to
the closed control object.
The signed consent, publication, withdrawal and fresh-status
procedures are the same for all three address-control methods. A
later XCIM verifier checks the attester's admitted method and policy;
it does not replay the browser's EVP transaction or receive raw
identity tokens. Token expiry after issuance does not revoke
consent. Conversely, a valid token cannot override a withdrawal or
renew a grant.
Missing browser or provider support, an absent token or a cancelled
verification MUST NOT be recorded as successful address control.
Invalid, mismatched or replayed evidence MUST be rejected. An
attester MAY offer OAuth-based provider verification or OIDC as a
separately selected flow with a fresh challenge and its own
validation. Such a grant MUST record oauth-01 or oidc-01
respectively. A switch MUST NOT copy an earlier decision, bypass
validation, or convert an EVP failure into consent. Unsupported EVP
does not by itself establish fraud.
9.1.4. Common Explicit Decision
The server-side session freezes sender binding, recipient, notice,
exact type definitions, selected control method and policy, method-
specific authority and transaction challenge, verification and
consent origins, return URI and expiry. The attester MUST observe a
separate affirmative recipient action in that same authenticated
context. Login, registration, purchase, a preselected option or a
sender-supplied record does not constitute that action. The
implementation retains evidence linking the address observation,
presentation and decision.
Saez Expires 29 April 2027 [Page 17]
Internet-Draft XCIM October 2026
Consume the consent-session decision authority and persist the
decision and issued grant atomically. A denial is terminal for the
session. A retry retrieves the same recorded result and cannot
create or broaden another grant. Refresh or login alone cannot renew
consent. Multiple types can be accepted in one consent session;
issuance is independent of email transmissions.
Successful address-control validation consumes the method's
transaction challenge exactly once and records an identity-verified
state bound to the consent session. That state permits only the
subsequent decision in the same unexpired context. It is not an
issued consent grant. Denial, timeout or loss of continuity
terminates the context without granting permission. The later atomic
decision transaction consumes the remaining consent-session
authority.
10. Withdrawal and Immutable Lifecycle
The payload has exactly the following members, in addition to the
common semantic constraints:
profile, kind, issuer, event_id, consent_id, consent_commitment,
sequence, previous_event_commitment, type_ids, actor, method,
evidence_commitment, requested_at, effective_at, issued_at
kind is revocation. sequence starts at one for each consent and
increases by one. previous_event_commitment is H(consent) for the
first event and H of the previous revocation thereafter.
consent_commitment is always H of the original consent. event_id MUST
be unique in that chain. type_ids is a nonempty sorted unique subset
of the original types, excluding any type already removed. There are
at most 64 events because every event irreversibly removes at least
one of at most 64 original types.
actor is recipient, sender, or attester. These mean respectively an
authenticated recipient withdrawal, an authenticated sender surrender
or restriction, and an authenticated protective action by the
attester. All events are signed by the attester, which retains
private evidence of the actual actor and authority. method matches
[A-Za-z0-9._-]{1,64} and identifies a request procedure admitted in
policy. A sender MUST NOT be allowed to assert that it acted as the
recipient.
Saez Expires 29 April 2027 [Page 18]
Internet-Draft XCIM October 2026
The private evidence commitment binds authenticated actor, random
request nonce, consent, affected types and outcome. Require
consent.issued_at <= requested_at <= effective_at <= event.issued_at.
effective_at and event.issued_at MUST NOT decrease across the chain.
The minimum does not schedule future-effective revocations. Request
authentication, nonce consumption, event sequencing and state update
MUST be one durable transaction.
The first committed valid removal of overlapping types wins. Retries
return the existing result; disjoint removals serialize in the same
event chain. There is no event that grants, extends or reactivates
consent. Regrant requires a new explicit decision and identifier.
Withdrawal is terminal for the affected type in the old grant.
Publish and anchor revocations as immutable historical events. An
authenticated withdrawal removes the positive signal immediately,
including while its anchor is pending. An attester MUST NOT issue
active status for a removed type after committing its withdrawal.
Withholding a withdrawal anchor cannot restore consent. A deployment
specifies its publication-delay policy and reports breaches; this
core does not claim instantaneous blockchain finality.
11. Fresh Current Status
This section defines the individual C01 path, retained for
compatibility. Its 300-second interval applies to a signed
statement, not to the original consent and not to a requirement to
refresh all stored grants periodically. The separately admitted SR01
path in Section 15 replaces this individual status requirement with
shared synchronization evidence.
The payload has exactly the following members, in addition to the
common semantic constraints:
profile, kind, issuer, consent_id, consent_commitment, sender_id,
sender_epoch, sequence, event_head, active_type_ids, this_update,
next_update
kind is status. sequence is the number of complete revocation events
supplied, from zero through 64. event_head is H(consent) at zero and
H of the last event otherwise. active_type_ids is the sorted set of
original type identifiers minus the cumulative removed types; it may
be empty. Every identifier, issuer and commitment MUST match the
exact grant and lifecycle. Missing intermediate events or a
different projection are invalid.
Saez Expires 29 April 2027 [Page 19]
Internet-Draft XCIM October 2026
this_update is no earlier than consent.issued_at and every supplied
event.issued_at. It is earlier than next_update, with an interval no
greater than 300 seconds. next_update is no later than the consent
and sender-binding expiries. An expired grant need not receive
another positive status. Status is signed by a currently authorized
consent_status key.
Snapshot renewal at the same sequence may change only this_update and
next_update. A different event head, active set or other semantic
field at the same sequence is a conflict. A verifier MUST retain
authenticated terminal removals and sequence/epoch floors. Known
later restrictions override an older still-unexpired active view.
Unauthenticated input MUST NOT advance those records. Conflicting
authenticated history requires quarantine and authenticated recovery.
Fresh status is the trusted attester's current projection, not an
independent proof that a dishonest attester concealed no withdrawal.
It does not require a new blockchain transaction for each query.
Repeated reads and cache retrieval MUST NOT extend its signed
lifetime. These controls protect lifecycle state, not email replay
or SMTP queues.
12. Immutable Blockchain Evidence
12.1. Anchor Batch
The payload has exactly the following members, in addition to the
common semantic constraints:
profile, kind, issuer, log_id, sequence,
previous_batch_commitment, created_at, leaves
kind is anchor_batch. sequence is a positive safe integer for an
issuer/log. previous_batch_commitment is null only for sequence one;
otherwise it is H of the immediately previous batch. leaves is an
ASCII sorted array of 1 to 4096 unique object-commitment strings. It
can aggregate consent and revocation commitments. The complete list
accompanies an inclusion check; this bounded profile uses no
additional Merkle path format.
For each checked object, H of its payload MUST occur exactly in
leaves and its issued_at MUST be no later than created_at. Verify
the batch signature under the anchor_publication role and compute C =
H(batch). The admitted blockchain adapter MUST establish that this
exact C was anchored in the accepted issuer/log, network and anchor
context. Further objects require another batch, not truncation or a
history reset.
Saez Expires 29 April 2027 [Page 20]
Internet-Draft XCIM October 2026
Publishers preserve the batch sequence and predecessor and MUST NOT
publish conflicting batches at one sequence. The deployment binds
that history to its admitted anchoring mechanism. Known conflicts or
rollback withdraw the positive signal. Grant inclusion is historical
evidence; it does not replace the status algorithm. Full consent or
recipient mapping payloads MUST NOT be placed on a public blockchain
by this profile.
12.2. Blockchain Adapter Contract and Limits
The payload has exactly the following members, in addition to the
common semantic constraints:
profile_id, network_id, genesis_hash, anchor_id, block_hash,
transaction_hash, record_index, batch_commitment, proof
This is an unsigned evidence wrapper, not another signed C01 kind.
profile_id selects a previously admitted adapter. network_id,
genesis_hash, anchor_id, block_hash and transaction_hash are nonempty
ASCII strings of at most 512 characters whose exact encodings are
defined by that adapter; record_index is a non-negative safe integer,
batch_commitment a C01 hash, and proof a bounded JSON object. Schema
acceptance does not authenticate any of these values.
An admitted adapter MUST specify network and genesis identification,
anchor authority/location and code or transaction semantics, exact
committed bytes, inclusion proofs, consensus/finality verification,
history continuity, halt/conflict handling and recovery. Its trusted
configuration is installed independently of the wrapper. It MUST
return an authenticated commitment and network/anchor context that
the caller compares with the expected batch and policy. An issuer-
controlled adapter cannot grant itself trust.
A transaction URL, issuer-supplied finalized flag, successful HTTPS
response or agreement between untrusted RPC servers is not verified
consensus. A verifier MUST NOT return CONSENT_CURRENT without actual
historical inclusion and finality verification through an admitted
adapter. Unavailable required evidence yields INDETERMINATE; an
unsupported profile is not a fallback to unanchored consent.
This core specifies the adapter boundary but does not select a
universal blockchain network, consensus bootstrap or chain-specific
proof encoding. Peers need a common admitted adapter to interoperate
end to end. Those deployment dependencies remain explicit.
Operating a node is one possible implementation and is not a
universal requirement on every consuming email service. No live Amoy
deployment or finality result is claimed by this revision.
Saez Expires 29 April 2027 [Page 21]
Internet-Draft XCIM October 2026
The previous AN01 EVM contract work can be reused to publish a C01
batch commitment under a separately specified deployment/profile.
Its application to an earlier AS checkpoint does not make AN01-F01
Evidence Sets compatible with C01. No historical checkpoint is
relabeled. Blockchain remains part of the protocol; the separation
does not create an unanchored profile with the same positive result.
13. Evidence Set and Acquisition
The closed evidence format in this section is C01. SR01 uses the
distinct evidence format in Section 15.5. A missing C01 status
cannot be excused without explicitly selecting and fully verifying
that alternative profile.
The payload has exactly the following members, in addition to the
common semantic constraints:
profile, sender, consent, revocations, status, consent_anchor,
revocation_anchors
profile is xcim-consent-01. sender, consent and status are JWS
envelopes of the corresponding kinds; revocations is an ordered array
of revocation JWS envelopes. consent_anchor contains exactly batch (a
batch JWS) and evidence (the anchor wrapper). revocation_anchors is
an array of objects containing exactly event_id, batch and evidence,
with unique event_id values naming supplied revocations. Missing
withdrawal anchors are reported as pending and never imply active
consent.
All signed issuer values MUST match. Every internal sender
identifier, epoch, consent identifier, commitment and lifecycle link
MUST match exactly. Mixing internally inconsistent objects is
INVALID_EVIDENCE, even when their individual signatures verify. A
missing required member is a structural error; an unavailable
required proof is not evidence of revocation or permission.
Evidence can be exchanged through configured authenticated HTTPS,
authorized local storage or another admitted channel. HTTP transport
uses application/json. This revision does not standardize discovery,
endpoint request syntax or query-credential provisioning. Peers
preconfigure these deployment interfaces; transport alone does not
establish consent.
Evidence access MUST be authorized for the requested recipient/sender
scope. Network retrieval MUST verify certificates and the configured
origin, bound sizes and timeouts, avoid credential leakage, and
reject unsolicited redirects, compression and destination changes.
Resolved and connected addresses must comply with policy to prevent
Saez Expires 29 April 2027 [Page 22]
Internet-Draft XCIM October 2026
SSRF and DNS rebinding. Sender-provided URLs cannot install
endpoints or trust. A network error, HTTP 404 or rate limit does not
prove absence or withdrawal.
14. Consent Verification and Results
This section specifies C01 verification and common result meanings.
SR01 reuses the grant, query, authority and result semantics, but
substitutes Section 15.5 for the individual status and evidence-set
checks. The selected profile MUST accompany a reported result.
The verifier takes an authenticated local query containing the
canonical recipient, issuer, sender_id, sender_epoch, type_id, type
version, evaluation time, accepted policy, and evidence. A consuming
application establishes the relationship between its authenticated
sender context and this sender identity. No email message, header,
DKIM result, MP or MSA is a core input.
1. Check policy, clock and persistent-state availability; apply
limits, parsing, profile and closed-object rules.
2. Authenticate the issuer, signatures, roles and issuance windows;
require identical internal identities and commitments.
3. Validate the sender binding, attestation, exact queried address
commitment, type/version, explicit decision, admitted address-
control method and times.
4. Verify the complete terminal revocation chain and status
projection; apply known authenticated sender-epoch and withdrawal
restrictions.
5. Verify consent inclusion in the exact signed batch and historical
blockchain inclusion/finality through the admitted adapter.
6. Intersect current policy, status-key, binding, consent and status
validity with the clock bounds; return the corresponding result.
For local time t and uncertainty u, u MUST be at most 60 seconds.
For a positive result require this_update <= t-u, t+u <
min(next_update, consent expiry, binding expiry, policy expiry,
status-key validity end), and t+u-this_update <= 300 seconds. Re-
evaluate time before returning or reusing a result. An unbounded
clock, stale status, expired policy or missing trusted recovery state
cannot yield a positive result. No cache grace period extends an
authenticated deadline.
CONSENT_CURRENT All mandatory checks succeeded for the exact queried
Saez Expires 29 April 2027 [Page 23]
Internet-Draft XCIM October 2026
relationship and type. Actual blockchain verification is
required.
CONSENT_REVOKED An authenticated applicable withdrawal is
established. Missing finality for that withdrawal cannot restore
consent.
CONSENT_EXPIRED The authenticated grant or sender binding has
expired; it cannot establish current consent.
NO_MATCH Internally consistent evidence does not cover the queried
recipient, sender, epoch or type/version.
INVALID_EVIDENCE Malformed data, invalid signatures, contradictory
internal scope, broken lifecycle links or an invalid projection.
UNSUPPORTED_PROFILE The profile or required algorithm is
unsupported; no downgrade is permitted.
INDETERMINATE Required evidence, finality, current authority or
freshness is unavailable, or trusted histories conflict.
These are core result labels, not an Authentication-Results method.
No result asserts that an email is safe, authenticated, correctly
categorized or deliverable. A repeated query for the same valid
relationship does not consume consent. Invalid data MUST NOT create
persistent restrictions; authenticated restrictive events MAY be
retained before their anchors arrive. Known withdrawal takes
precedence over older active status. Implementations MUST NOT
convert an indeterminate result into positive consent.
15. Shared Revocation Synchronization (SR01)
This section defines the alternative verification profile xcim-
consent-sync-01 (SR01). It reuses original C01 sender bindings,
grants, revocations and anchor batches without changing their signed
bytes, commitments or finite validity. It replaces the individual
status object only on this explicitly selected path. A C01-only
verifier MUST reject the SR01 evidence profile. Neither path renews
the recipient's decision or requires another address-control
transaction merely to refresh evidence.
Saez Expires 29 April 2027 [Page 24]
Internet-Draft XCIM October 2026
The protocol specifies evidence and verification, not subscriber-list
management, campaigns, opt-in/unsubscribe interfaces, database design
or endpoint syntax. An attester can distribute original grants once
and subsequent grants and revocations incrementally. A verifier can
retain them and evaluate locally. Transport batching, caching and
notifications are implementation choices; they MUST NOT change the
meaning of a positive result.
15.1. Scope, Encoding and Authority
One SR01 stream covers every C01 grant and withdrawal for the exact
tuple (issuer, sender_id, sender_epoch), including grants issued
before the stream was initialized. The issuer MUST authenticate a
complete starting history before offering SR01 for that tuple. It
MUST NOT create separate undisclosed histories for different clients,
omit expired-grant withdrawals from the established history, or reuse
the tuple for a reset stream. The stream is append-only. A
snapshot-based or filtered-subset bootstrap is not defined by this
version.
SR01 objects use the closed JSON, integer, canonical base64url,
identifier, JCS and Ed25519 rules in this document. Signed SR01
envelopes use protected typ application/xcim-consent-sync+json; alg
and kid have their existing meanings. C01 embedded envelopes retain
application/xcim-consent+json. The hash HS(X) is base64url(SHA-
256(UTF8("XCIM-SR01-OBJECT") || 0x00 || JCS(X))); H(X) continues to
mean the C01 object commitment. Domain prefixes are literal ASCII
strings followed by one zero octet. No hash is calculated over a
signature envelope in place of its decoded payload.
SR01 signed objects require separately admitted key roles:
revocation_log for log heads and revocation_checkpoint for
synchronization checkpoints. They do not inherit consent_status
authority implicitly. Their issuer and sender tuple MUST match the
configured stream and queried grant. Keys must be valid when the
object was issued; the checkpoint key must also be currently
authorized when relied upon. Existing historical-signature, policy,
sender-epoch restriction and conflict rules still apply.
A verifier MUST select SR01 through authenticated local admission
policy. A sender-provided URL, profile field or transport response
cannot install trust, enable SR01 or downgrade a failure to another
path. An administrator can admit both profiles explicitly; known
authenticated withdrawals and authority restrictions apply across
both.
Saez Expires 29 April 2027 [Page 25]
Internet-Draft XCIM October 2026
15.2. Revocation History and Immutable Log Heads
The initial stream commitment is HS of this exact genesis object:
{
"profile": "xcim-consent-sync-01",
"kind": "revocation_genesis",
"issuer": "https://attester.example/issuer",
"sender_id": "https://attester.example/senders/company",
"sender_epoch": 1
}
The example tuple is illustrative, not a trust configuration. A
stream entry is an unsigned object with exactly these fields:
profile, kind, issuer, sender_id, sender_epoch, sequence,
previous_entry_commitment, event_commitment
profile is xcim-consent-sync-01 and kind is revocation_entry.
sequence is a positive safe integer starting at one and increasing by
one for every withdrawal in this sender epoch.
previous_entry_commitment is the genesis commitment for entry one and
HS of the preceding entry thereafter. event_commitment is H of the
separately supplied, signed C01 revocation payload. An entry has no
independent signature: its inclusion is authenticated by the signed
log head and hash chain. The event's own signature authenticates the
withdrawal before publication or finality.
Every committed withdrawal MUST be included exactly once, in an order
preserving each grant's revocation chain. The issuer MUST bind it to
the stream of the grant's actual sender tuple. Verifiers MUST check
the event signature, issuer, unique event identifier, grant
identifier/commitment consistency, per-grant sequences, previous-
event links, nondecreasing lifecycle times and terminal nonduplicated
type removals. For a grant not yet obtained, retain its opaque
identifier, commitment and withdrawal chain; validate its scope,
initial types and grant-relative times before evaluating that grant.
No recipient address or original grant is required to distribute
another grant's revocation event.
A signed log-head payload has exactly these fields:
profile, kind, issuer, sender_id, sender_epoch, sequence,
event_head, issued_at
kind is revocation_log_head; sequence is the number of entries,
including zero; event_head is the genesis commitment at zero or HS of
the last entry otherwise. issued_at is no earlier than issuance of
Saez Expires 29 April 2027 [Page 26]
Internet-Draft XCIM October 2026
all included events. At an unchanged sequence the issuer MUST reuse
the same log-head payload; re-signing with another admitted key does
not change HS. A conflicting payload at the same sequence is a
conflict requiring quarantine and authenticated recovery.
SR01 preserves the C01 blockchain division of responsibilities: a
positive result requires actual historical grant inclusion/finality
verification; withdrawals are published and anchored as immutable C01
lifecycle events, with pending withdrawal anchors reported
separately. A known authenticated withdrawal applies before its
anchor is final. The shared head and checkpoint replace the trusted
individual status projection; they are not themselves mandatory
blockchain transactions or proof of independently observed absence of
withdrawals.
Refreshing a checkpoint does not require re-anchoring the original
grant or writing an unchanged stream to the chain. Withdrawal
publication-delay policy and breach reporting remain required as in
C01. Pending withdrawal anchors cannot restore removed types, and
need not block an unrelated remaining type when all other checks
succeed. This path does not claim a stronger blockchain guarantee
for current state than C01. A verifier cannot use a known superseded
head to produce a positive result. Compact snapshots or additional
checkpoint anchoring guarantees require an explicitly specified
extension; they cannot be claimed from this profile alone.
15.3. Fresh Shared Synchronization Checkpoint
A signed checkpoint has exactly these fields:
profile, kind, issuer, sender_id, sender_epoch,
log_head_commitment, covered_at, this_update, next_update
profile is xcim-consent-sync-01; kind is revocation_checkpoint;
log_head_commitment is HS of the selected signed log-head payload.
covered_at asserts a complete publication cut for this sender epoch:
all withdrawals durably committed through that cut are included in
the referenced head. The issuer MUST establish this boundary
consistently with its withdrawal transaction and publication queue.
It MUST NOT refresh covered_at by merely signing a new clock value
over a view that excludes earlier committed withdrawals. A time-
based query on an asynchronously updated replica alone is
insufficient.
The issuer MUST NOT issue a checkpoint omitting a withdrawal already
committed before checkpoint creation, even if it chooses an earlier
covered_at. Withdrawals committed after the checkpoint's cut are
included in a subsequent head. The verifier still trusts the
Saez Expires 29 April 2027 [Page 27]
Internet-Draft XCIM October 2026
attester's completeness assertion: neither the signature nor
anchoring independently detects every concealed real-world
withdrawal.
Require log_head.issued_at <= covered_at <= this_update < next_update
and next_update - covered_at <= 300 seconds. At evaluation time t
with trusted clock uncertainty u, require u <= 60 seconds,
this_update <= t-u, t+u < next_update and t+u-covered_at <= 300
seconds. Also require grant.issued_at <= covered_at. These retain
the earlier experimental 300-second exposure budget at shared-scope
level; they are not per-recipient renewal intervals or measured
service targets. The issuer may create checkpoints on demand. No
activity is required for an idle scope merely because it contains
stored grants.
A checkpoint does not extend grant expiry, sender-binding expiry,
authority validity or an older checkpoint. A recipient does not
repeat consent when a checkpoint changes. Refresh can change
covered_at, this_update and next_update without changing the log head
if no withdrawal occurred. Persist a monotonic covered_at floor as
well as stream sequence/head floors; reject older coverage on reuse.
Current key and policy deadlines can shorten usable time further.
15.4. Complete Local Views and Incremental Acquisition
A verifier initializes from the configured tuple's genesis and
verifies every entry through the selected log head. It can obtain
this history in bounded pages and retain it durably. After
initialization it only needs entries after its applied sequence.
Pages contain pairs of entry and signed revocation envelope; at most
1024 pairs and 2 MiB of decoded JSON per page are permitted,
whichever limit is reached first. Pages, transport cursors and
notifications are not independently sufficient proof of completion.
The verifier MUST check the expected tuple, exact next sequence,
previous-entry commitment and event commitment for each entry, and
compare the final sequence and event_head to the selected
authenticated log head. It MUST keep incomplete acquisition
candidates separate from the authenticated durable view, and MUST NOT
authorize from a partially downloaded history or advance its trusted
cursor without applying the corresponding validated removals
atomically. Duplicate delivery of identical entries may be ignored;
conflicting authenticated histories require quarantine, while an
unsigned conflicting candidate alone is rejected without poisoning
trusted floors. Out-of-order entries can be buffered within local
limits but cannot bridge a missing sequence. An empty page is
meaningful only when the complete local history already matches the
authenticated head.
Saez Expires 29 April 2027 [Page 28]
Internet-Draft XCIM October 2026
A response filtered to only some recipients cannot prove completeness
for this full-sender stream. Access MUST be authorized for its
entire sender/epoch scope. An ESP not authorized for that scope can
use the separately admitted individual C01 path. Implementations
MUST NOT expose a public directory of grants or revocations. Opaque
grant identifiers and commitments still expose activity patterns and
require access control.
Persist the applied sequence, head, coverage floor, per-grant
removals and conflict state together. Learning a valid newer head
establishes a known-history floor even before the missing entries are
fetched; it prevents positive reliance on older views. A newer
unauthenticated claim MUST NOT advance any floor. A known
authenticated withdrawal applies independently of stream
synchronization. Backup rollback, missing durable state or an
unavailable retained history requires authenticated recovery or full
replay before positives resume. This version does not authorize
pruning history needed by a new verifier.
A local view can remain usable until its bounded deadline when no
newer restriction or head is known. The profile does not promise
instantaneous global revocation over an asynchronous network.
Network failure or inability to establish completeness yields
uncertainty for affected queries, not an inferred withdrawal or a
positive permission. Push notifications can reduce delay; resumable
acquisition and authenticated coverage establish correctness.
15.5. Evidence Set and Verification
An SR01 evidence set has exactly these members:
profile, sender, consent, consent_anchor, log_head,
checkpoint, revocation_anchors
profile is xcim-consent-sync-01. sender and consent are original C01
JWS envelopes; consent_anchor is the existing C01 anchor wrapper.
log_head and checkpoint are SR01 JWS envelopes. revocation_anchors
has the C01 format and names only withdrawal events for the queried
grant found in the complete history; missing anchors are reported as
pending, not as restored permission. The verifier's complete
authenticated local view is a separate trusted input, not an asserted
ready flag supplied by the sender. Bootstrap pages can be conveyed
separately through any admitted channel. Each envelope is bounded by
the applicable existing object limits.
The SR01 verifier MUST perform all C01 grant, sender, exact query,
type-definition, address-control method, policy, authority, signature
and historical grant-anchor checks. It MUST NOT require or fabricate
Saez Expires 29 April 2027 [Page 29]
Internet-Draft XCIM October 2026
an individual C01 status. Instead it MUST validate the shared
objects, their scope and authority, the complete history and
synchronization boundary defined above. From that history it
reconstructs the queried grant's terminal per-type removals and
validates its C01 withdrawal chain. Known authenticated applicable
removals take precedence over older positives and pending anchors.
A positive result requires the grant and binding not to be expired,
the checkpoint key currently authorized, policy current, the original
grant's required blockchain evidence actually verified, and the local
view complete through the selected head with sufficiently recent
coverage. Evaluate supplied withdrawal anchors and report their
pending status as in C01. Re-evaluate time before returning or
reusing a result; the conservative usable deadline is the minimum of
checkpoint.next_update, covered_at + 300, grant expiry, binding
expiry, policy expiry and checkpoint-key validity end, with the clock
uncertainty accounted for. Retrieval, cache hits, retries and
idempotency replay MUST NOT restart any deadline.
Use the existing result meanings for the exact queried relationship:
CONSENT_CURRENT only after all SR01 checks; CONSENT_REVOKED for a
known authenticated applicable withdrawal; CONSENT_EXPIRED for the
original finite expiry; NO_MATCH for a different query tuple;
INVALID_EVIDENCE for malformed or invalid evidence;
UNSUPPORTED_PROFILE for an unadmitted path; and INDETERMINATE for
missing updates, stale coverage, unavailable authority/finality or
authenticated conflicts. Record the selected profile with the result
so an SR01 decision cannot be misrepresented as C01 conformance.
The attester does not need to re-sign every positive relationship.
The verifier still checks each relationship it relies on locally.
Shared signature, history and anchor checks may be cached by exact
commitments and trusted policy context, while current authority,
known restrictions and deadlines remain applicable. Initial history
acquisition, new grants, withdrawal bursts, fanout and recovery
remain real costs; this revision makes no measured throughput or cost
claim.
16. Optional Consumption by Email Services
A receiving email service may first use its existing authentication
mechanisms to establish a sender context, map that context to the
identified sender named in the consent, then verify XCIM for its
recipient and a requested communication type. It may use
CONSENT_CURRENT as one positive policy input. This integration is
optional and does not change core conformance.
Saez Expires 29 April 2027 [Page 30]
Internet-Draft XCIM October 2026
DKIM [RFC6376] associates a signing domain with signed message
material; DKIM2 [I-D.ietf-dkim-dkim2-spec] develops message
authentication, handling history and replay-related mechanisms.
Neither is the recipient's decision to grant a company communication
permission. They can complement XCIM without becoming dependencies
of consent verification. A shared provider's authenticated domain
does not automatically identify the company that benefits from a
consent.
The integration MUST establish that identity mapping and MUST NOT
borrow another tenant's consent. Determining a particular message's
type is external to XCIM. A sender merely labeling an email
transactional does not prove its category or widen its grant.
Positive consent does not require inbox delivery; missing XCIM does
not universally require rejection. Unsubscribe mechanisms such as
[RFC8058] can supply a withdrawal request through an authenticated
integration, but do not create an original consent decision.
17. Security Considerations
Relevant attackers include a sender fabricating consent, an
unauthorized actor controlling a consent UI, a dishonest accepted
attester, a compromised signing key, a publisher withholding
withdrawals, a verifier using stale state, and a malicious blockchain
endpoint. Exact identity, type and commitment checks prevent
substitution only under the admitted trust assumptions. A
cryptographically valid lie remains a lie by the attester.
A compromised sender or shared service MUST NOT create a grant by
presenting an address hash or another company's binding. Enrollment
and decision evidence require authenticated observations by the third
party. Consent presentation must clearly identify the company, scope
and meanings being accepted. An opaque type token is insufficient
for informed selection.
Address control is observed at consent time. Reassignment, account
takeover and loss of control can undermine later assumptions; finite
expiry, authenticated withdrawal and policy-driven reauthentication
limit exposure. This revision does not claim continuous proof of
mailbox ownership. Freshness bounds limit stale acceptance under an
honest publishing attester; they are not a measured revocation SLA or
protection against concealed withdrawals by that attester.
Saez Expires 29 April 2027 [Page 31]
Internet-Draft XCIM October 2026
History and cache recovery MUST preserve known terminal withdrawals
and epoch restrictions. Durable local storage alone cannot detect
rollback of an entire disk; a deployment requiring that protection
needs an authenticated external recovery floor. An anchor proves
committed history under its finality model, not data availability or
correct state computation. No synthetic chain observation may be
promoted to real consensus evidence.
SR01 adds complete-history bootstrap, authenticated coverage
boundaries and durable synchronization floors. A signed current
timestamp over an incomplete or old publication view is insufficient.
Full-stream access, withdrawal bursts, unbounded retained history and
sender-scope fanout can cause resource or availability pressure.
Implementations must bound acquisition work and return uncertainty
rather than skip checks. Comparing authenticated views can reveal
equivocation, but an isolated verifier still trusts the attester not
to conceal pre-publication withdrawals.
18. Privacy Considerations
Public batches and chain records contain commitments, not recipient
addresses, raw identity tokens, credentials or private consent
inputs. The signed grants, salts, sender/type descriptions and
address mappings remain access-controlled evidence. A known salt
permits testing candidate addresses and is not encryption.
Randomized private-evidence commitments also require careful handling
of their openings.
Queries, timestamps and issuer/sender relationships can reveal
recipient interests even without plaintext addresses. Apply access
authorization, data minimization, retention controls and rate limits.
Private-data deletion does not erase an immutable public commitment;
it can make later evidence unavailable. Loss of access must not be
misreported as proof of withdrawal or current consent.
SR01 revocation streams contain opaque grant identifiers,
commitments, type identifiers and timing for one sender epoch. They
do not require recipient addresses or original grants, but they can
reveal activity patterns. Stream access must be authorized for the
whole scope. This version does not define recipient-filtered
completeness proofs; implementations needing narrower disclosure can
retain the individually admitted C01 path.
Saez Expires 29 April 2027 [Page 32]
Internet-Draft XCIM October 2026
18.1. EVP Evidence and Origin Privacy
EVP evidence MUST NOT appear in public consent objects, logs,
blockchain records, callback URLs or analytics. Minimize private
retention and protect retained evidence with access controls and
encryption. A delegated-origin flow exposes its presentation to both
the relying party and attester; it MUST NOT be described as hiding
the recipient from either. An attester serving multiple senders can
correlate observations even when the external protocol limits issuer
visibility. XCIM does not expand a private-address grant to another
origin, address or sender.
19. IANA Considerations
This revision defines no email header and no Authentication-Results
method. It uses the existing HTTPS URI and UUID URN namespaces,
rather than claiming a registered xcim URN namespace. The JWS typ
value application/xcim-consent+json is a provisional protocol
identifier; no media-type registration is established by this
Internet-Draft. Evidence HTTP transport uses application/json.
Before an eventual RFC, the media-type registration and any registry
for interoperable address-control or blockchain profiles need
concrete templates, allocation policies and change control. A future
change to a signed typ or identifier requires explicit version
selection and migration, not rewriting prior signed bytes. The
result labels here do not imply IANA assignment.
The SR01 profile string xcim-consent-sync-01, its object kinds, key
roles and protected typ application/xcim-consent-sync+json are
experimental identifiers for this document. They do not represent
completed media-type or IANA registrations. Unknown profiles and
roles are not implicitly admitted.
20. Conformance, Validation and Remaining Work
Conformance is evaluated separately for sender enrollment/
attestation, consent issuance, lifecycle/status publication,
blockchain adapters, and consent verification. A core verifier MUST
work without an SMTP transaction, email body, message signature or
per-message replay store. A complete positive result additionally
requires a real admitted blockchain adapter; schema or signature
success alone is not sufficient.
Necessary tests include a valid query without an email, repeated
verification without consuming a grant, independently selected types,
partial and complete withdrawals, expired and stale evidence, altered
signatures, recipient and sender substitution, shared-provider tenant
Saez Expires 29 April 2027 [Page 33]
Internet-Draft XCIM October 2026
confusion, wrong type/version, unauthorized actor requests, state
rollback, conflicting history and incorrect blockchain context. Test
reports identify the exact objects, policy, adapter, software and
limits used.
The core object and lifecycle rules are specified in this revision.
Remaining interoperability work is explicit: chain-specific proof
encodings and authenticated finality/bootstrap profiles; discovery
and credential provisioning for evidence services; portable sender-
enrollment assurance policies; and final registration/migration
templates. Closure requires exact formats, trust inputs and
adversarial vectors for each selected profile. These dependencies
cannot be bypassed to obtain CONSENT_CURRENT.
Independent security/privacy review, actual identity-provider flows,
live chain verification, separately operated interoperability and
workload measurements remain evidence tasks. They are not claimed by
local fixtures and do not require adding message-processing
obligations to XCIM.
SR01 conformance requires tests of complete replay, incremental
acquisition, missing and duplicate entries, invalid event signatures,
wrong scope, conflicting heads, stale coverage with a fresh
signature, rollback and restart, new grants against old coverage,
partial withdrawal, regrant, original expiry, authority changes,
pending withdrawal anchors and known withdrawals across both
profiles. Test-only blockchain adapters cannot produce operational
positive results. Measure repeated-query workloads against on-demand
C01 batches; include bootstrap, recovery, many small scopes, fanout
and mass withdrawals.
20.1. EVP Profile Validation
Tests MUST distinguish external-token validation, session/handoff
binding, explicit decision, signed-object verification and current-
state verification. Include valid evidence without consent, wrong or
reused nonce, wrong origin, recipient substitution, stale tokens,
substituted issuer or browser keys, invalid token linkage, unadmitted
policy, expired delegation, cross-browser continuation, fallback
mislabelling, denial, retry, and withdrawal after EVP-based issuance.
Passing schema tests does not validate an EVP transaction.
Interoperability evidence MUST identify the exact external revision,
browser transport, provider, adapter, policy and delivery mode.
Closure requires a successful browser-to-attester flow and
adversarial cases for that same combination, followed by independent
reproduction. Browser and IETF EVP specifications may differ; such
differences require an explicit compatibility profile and review, not
Saez Expires 29 April 2027 [Page 34]
Internet-Draft XCIM October 2026
silent acceptance under evp-01. This revision fixes the IETF
revision used for evp-01 but does not claim that every available
browser implements it.
20.2. OAuth Provider Profile Validation
Before admitting an OAuth provider profile, document its exact
endpoint and response mapping and test a successful code/PKCE/API
transaction plus wrong state, wrong verifier, reused code, provider
mix-up, token substitution, insufficient scopes, inactive
credentials, account substitution, unverified address, stale address
evidence and unexpected redirect cases. Test a successful address
check followed by denial or no consent action, and confirm that
neither issues a grant. Test method switching, policy isolation and
withdrawal after issuance separately. Closure requires repeatable
provider/adapter evidence and independent reproduction; C01 object
fixtures do not demonstrate those transactions.
21. Implementation Status
This section is informative, following [RFC7942]. The project
maintains local C01 schemas and a reference verifier with positive
and adversarial fixtures. These exercise consent objects,
signatures, recipient/sender/type relationships, lifecycle, freshness
and batch commitments independently of email messages. Test keys and
simulated anchor adapters are explicitly non-operational.
A simulated adapter may report successful consent checks for a test
case but MUST NOT produce an operational CONSENT_CURRENT result. No
real EVP, OAuth or OIDC provider/browser integration for this C01
profile, deployed C01 blockchain profile, independent
interoperability or production security assurance is claimed.
Previous P1/MAIL01 test counts remain historical evidence for those
profiles and are not reused as proof that this corrected scope has
been validated.
The local examples also exercise signed evp-01 and oauth-01 consent
objects and method-specific policy admission. Their address-control
observations are synthetic. They are not an EVP issuer, browser,
OAuth client/API adapter or token validator, and do not establish
external-protocol conformance.
Saez Expires 29 April 2027 [Page 35]
Internet-Draft XCIM October 2026
SR01 is a new experimental wire and verification contract in this
revision. Local shared-history fixtures, schemas or component tests
do not establish an operational integrated SR01 service, durable
distributed recovery, measured scale, live blockchain verification or
independent interoperability. Historical C01 suite results are not
SR01 conformance results. The retained-history bootstrap is
deliberately explicit; compact snapshots and stronger checkpoint
anchoring guarantees are not specified by this version.
22. Normative References
[I-D.hardt-email-verification]
Hardt, D. and S. Goto, "Email Verification Protocol", Work
in Progress, Internet-Draft, draft-hardt-email-
verification-02, Work in Progress , 25 August 2026,
<https://datatracker.ietf.org/doc/html/draft-hardt-email-
verification-02>.
[IDNAMAP151]
Unicode Consortium, "Unicode IDNA Mapping Table Version
15.1.0", 10 August 2023,
<https://www.unicode.org/Public/idna/15.1.0/
IdnaMappingTable.txt>.
[OIDCCore] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", 15 December 2023,
<https://openid.net/specs/openid-connect-core-
1_0-errata2.html>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<https://www.rfc-editor.org/info/rfc5891>.
Saez Expires 29 April 2027 [Page 36]
Internet-Draft XCIM October 2026
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, May 2015,
<https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7636] Sakimura, N., Bradley, J., and N. Agarwal, "Proof Key for
Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/rfc/rfc7636>.
[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>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, May 2024,
<https://www.rfc-editor.org/rfc/rfc9562>.
[RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"Best Current Practice for OAuth 2.0 Security", RFC 9700,
DOI 10.17487/RFC9700, January 2025,
<https://www.rfc-editor.org/rfc/rfc9700>.
Saez Expires 29 April 2027 [Page 37]
Internet-Draft XCIM October 2026
[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>.
[UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility
Processing", Unicode Technical Standard 46, revision 31,
Unicode 15.1.0, 5 September 2023,
<https://www.unicode.org/reports/tr46/tr46-31.html>.
23. Informative References
[I-D.ietf-dkim-dkim2-spec]
Clayton, R., Chuang, W., and B. Gondwana, "DomainKeys
Identified Mail Signatures v2 (DKIM2)", Work in Progress,
Internet-Draft, draft-ietf-dkim-dkim2-spec-07, Work in
Progress , 18 October 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dkim-
dkim2-spec-07>.
[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>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8058] Levine, J. and T. Herkula, "Signaling One-Click
Functionality for List Email Headers", RFC 8058,
DOI 10.17487/RFC8058, January 2017,
<https://www.rfc-editor.org/info/rfc8058>.
Author's Address
Damian Saez
We Are 14 Inc
Email: damian@xcim.org
Saez Expires 29 April 2027 [Page 38]