Implementation
This page records implementation evidence from earlier XCIM working drafts and managed pilots. It does not establish implementation or interoperability of the corrected consent protocol. The current scope and publication status are linked above.
Latest specification · draft-saez-xcim-04
Experimental individual Internet-Draft. A bounded C01/SR01 testnet pilot verified consent reuse and revocation on 26 October 2026; production readiness remains open.
Reference implementation: Emabled
This page describes one implementation, not a required issuer or product. The Working Draft and schemas record the earlier product-independent design. Working-draft publication does not upgrade a running implementation.
Emabled implements the managed XCIM Consent Issuer and operator surfaces used in earlier managed XCIM pilot tests. The deployed sandbox supports company and ESP workspaces, OIDC-based identity evidence, issuer-hosted consent, application and manifest publication, signed receipt issuance, revocation, authorized list evaluation, lifecycle webhooks and public signing keys. Its first public event/state roots and proof set are anchored on a Polygon test network. This historical snapshot does not provide continuously fresh status.
A profile-neutral Identity Evidence layer is implemented. An experimental EVP-01 adapter is deployed for vendor-origin handoff; EVP inside Emabled Hosted Consent remains unavailable. Public delivery-mode capabilities are available at the issuer capabilities endpoint. Profile status is driven by identity-evidence.json.
| Surface | Current implementation | Boundary |
|---|---|---|
| Operator console | OIDC authentication, hosted-consent onboarding, MFA and workspace controls | Separate company and ESP roles; authorized pilot access |
| Identity evidence | OIDC-01 managed pilot; experimental EVP-01 vendor-origin handoff | Profile maturity is not external standards status |
| Consent issuer | Issuer-hosted consent session using a versioned manifest | Reference flow, not universal conformance |
| Receipts and revocation | KMS-backed Ed25519 signatures and lifecycle worker | Emabled issuer semantics |
| Application identity | XCIM Application ID, application key, metadata and current domain bindings | Independent of any one OAuth client |
| Public discovery | Issuer key set and service health | No public XCIM registry or resolver yet |
Reference implementation evidence
Reviewed 2026-10-26. Each row identifies its implementation scope. The 26 October C01/SR01 pilot is separate from the earlier-profile managed pilot and frozen reference fixtures. No production trust network or independent ESP interoperability is claimed.
| Capability | State | Evidence and scope |
|---|---|---|
| C01/SR01 consent lifecycle | Verified bounded testnet pilot · 26 Oct 2026 | One fresh MuMaps consent: CURRENT, cached CURRENT without renewal, incremental REVOKED and persisted REVOKED. Both anchors verified under admitted testnet trust. Same operator; pilot closed; production gates remain. |
| Company onboarding | Operational pilot | Company workspace, application setup, site DNS, signed manifest, sending-domain authority and return configuration. |
| Identity and hosted consent | Verified managed pilot | MuMaps registration uses one Google authorization, followed by a separate, optional purpose-specific consent decision. |
| Receipts and revocation | Verified managed pilot | Signed receipt issuance, authenticated API revocation and subsequent list re-evaluation were exercised end to end. |
| Managed ESP list evaluation | Verified managed pilot | Separate ESP workspace with MFA, revocable company authorization, JSON/CSV jobs, CSV/ZIP console uploads and authenticated result exports. |
| Lifecycle webhooks | Deployed; external test pending | Signed delivery infrastructure, company delivery history and recovery controls are implemented; an external receiver test remains a release gate. |
| Draft implementation artifacts | Published draft | Working Draft 02 with Erratum E1 publishes 33 unchanged schemas and corrected Python/Node tools, with 12 new E1 regression tests. Original WD-01 and WD-02 releases remain unchanged; synthetic checks are not live proof verification. |
| Public proof verification | Verified test-network snapshot | First public batch finalized on a Polygon test network: 19 events and four MuMaps proofs, checked by separate verification implementations. Historical evidence only; the five-minute status window has expired. Not mainnet or independent sender/receiver interoperability. |
| Emabled SDK distribution | Private packages tested | .NET and TypeScript integration packages have consumer tests; public npm/NuGet releases are pending. |
Managed pilot report · Shared implementation status JSON
Earlier pilot evidence is preserved in the historical test-network report. It does not demonstrate operational C01/SR01 conformance.
Company and ESP integration
- The company configures its application, signed manifest, sending domain and consent return.
- The recipient authenticates with Google and chooses optional purposes on the issuer-hosted consent page. Registration and marketing permission are separate decisions.
- Emabled signs the receipt and returns it through the bound application flow.
- The company authorizes an ESP for a specific application, purpose, domain, validity period and list budget.
- The ESP submits JSON jobs or uploads CSV/ZIP through its workspace, then downloads authenticated results.
- Authenticated revocation changes current permission state; a later evaluation reflects the revoked permission.
Managed list results report issuer permission. The pilot observed
EMABLED_CONSENT_ACTIVE, XCIM_REVOKED and
XCIM_NONE. An active issuer result is not a public proof
XCIM_PASS. A separate receiver verified the first test-network
snapshot within its signed freshness window; that is not a current
result for every list row or a completed fresh CSV/ZIP public-proof replay.
List evaluation does not establish mailbox existence or inbox placement.
Historical working-draft identity profiles
Maturity labels below describe XCIM profile maturity, not the standards status of the external protocol. They do not establish implementation of the corrected C01 profile.
| Profile | Purpose | Maturity |
|---|---|---|
| EVP-01 | Email-provider-backed address control | Experimental |
| OIDC-01 | Identity-provider-backed authentication | Supported draft profile |
Protocol roles
- Identity Issuer
- Provides independently verifiable identity evidence, such as EVP or OIDC evidence.
- XCIM Consent Issuer
- Validates acceptable identity evidence, presents the Consent Manifest, records the decision, and signs the XCIM receipt.
- Application
- Requests consent for a defined application identity, manifest and purpose.
- Sender
- Attaches the XCIM reference and proof to a message.
- Verifier
- Validates evidence and applies local trust and delivery policy.
Application identity
The XCIM application identity is not defined by an OAuth client. It is anchored by the XCIM Application ID, application key, metadata, and current domain bindings. OIDC client IDs are profile-specific integration metadata.
Verification sequence
- Validate ordinary message authentication and parsing.
- Resolve the issuer and select an explicitly trusted assurance profile.
- Validate proof signatures, application and domain bindings, time limits and anti-replay context.
- Resolve current permission state; stale or unavailable state remains indeterminate.
- Return a structured result to local receiver policy.
Interoperability boundary
The deployed Emabled flow demonstrates implementation feasibility. Draft schemas, serialization decisions and vectors are already published. Independent conformance still requires reviewed profile external review, ongoing fresh public proofs, resolver distribution and tests between independent implementations. No implementation should treat the sandbox as a production trust root or sole abuse control.