Related work
XCIM is intended to complement - not replace - the deployed email authentication, identity-evidence and policy ecosystem.
| Mechanism | What it establishes | Relationship to XCIM |
|---|---|---|
| SPF | Authorized sending hosts for a domain | Remains part of message authentication |
| DKIM | Domain-associated message signatures | Protects message integrity; XCIM adds permission evidence |
| DMARC | Identifier alignment and domain policy | Continues to govern domain authentication policy |
| ARC | Authenticated handling chain | Can preserve authentication context through intermediaries |
| One-click unsubscribe | Standard unsubscribe interaction | Addresses recipient opt-out, not portable grant verification |
| Email Verification Protocol (EVP) | Browser-mediated, provider-backed evidence that the user controls an email address | Experimental candidate Identity Evidence profile for XCIM; it does not establish communication permission |
| OpenID Connect | Identity-provider authentication and claims | Supported Identity Evidence profile and fallback |
| Certificate Transparency v2 | Auditable certificate logs | Provides design precedent for public append-only evidence |
EVP and XCIM
EVP and XCIM are complementary.
XCIM uses the resulting identity input for a separate email consent attestation; it does not reinterpret identity verification as opt-in.
EVP answers: Does the current user control this email address?
XCIM answers: Did this independently verified recipient explicitly authorize this application for these defined communication purposes?
XCIM does not extend EVP tokens with marketing or transactional claims. Communication-purpose semantics remain inside the XCIM Consent Manifest and XCIM receipt. The Chrome August 2026 update and WICG repository are experimental references, not endorsements.
References describe conceptual relationships. They do not imply standards-track status or interoperability with XCIM.