Frequently asked questions

Is XCIM a standard?

XCIM has been published as an individual Internet-Draft with intended status Experimental. It is not an approved RFC or an adopted IETF standard. The substantive scope correction is published; the status above identifies the current revision.

Does XCIM compete with the Email Verification Protocol?

No. EVP verifies that a user controls an email address. XCIM uses validated address-control evidence from EVP, OAuth with provider API verification or OIDC as input to a separate permission decision. XCIM records which identified sender entity the recipient authorized, for which communication purposes, and the resulting portable permission state.

Can XCIM use EVP, OAuth or OIDC?

Yes. Revision -03 specifies three alternative methods to establish control of the email address giving consent. The issuer can use any one admitted method, with its required signature, account, origin, session and freshness checks. OAuth requires authorization code with PKCE and an authenticated provider API returning the verified email of the account authorizing the transaction. A token or login alone does not grant communication permission. The same recipient must separately accept the identified sender and communication types.

Does EVP verification mean the user accepted marketing?

No. Email-address verification is not communication permission. Marketing, newsletter, promotional and other optional purposes require an explicit XCIM decision against a defined Consent Manifest.

Does XCIM still require a Google OAuth client?

No as a protocol requirement. OIDC remains a supported identity-evidence profile, but the consented sender entity is independent from an OAuth client. Experimental EVP support can remove the need for vendor OAuth configuration where browser/provider support is available.

Is EVP production-ready?

XCIM currently treats EVP as experimental. It is an active Internet-Draft and browser-origin-trial feature, and its browser/provider behavior may change. OIDC remains available as a fallback/reference identity-evidence path.

Is the network live?

No production verification infrastructure or trust assertions are active. xcim.net reports the public operational state.

Does XCIM replace SPF, DKIM, or DMARC?

No. Those mechanisms continue to authenticate sending infrastructure and domains. XCIM explores evidence about explicit recipient consent to an identified sender for specified communication types.

Does a valid proof guarantee inbox delivery?

No. The recipient system retains full control over filtering, abuse prevention, trust selection and delivery.

Does XCIM publish recipient addresses?

The design goal is to avoid exposing plain recipient identifiers in public infrastructure. The precise privacy-preserving representation is not yet normative and remains subject to security review.

Can I implement it now?

Earlier schemas, vectors, Python/Node checks and managed company/ESP pilots remain available as historical evidence. They do not establish conformance to the corrected consent protocol. Use the current draft status above to identify the specification under review.

Can an ESP evaluate a company's list?

Yes, in the Emabled managed pilot. The company grants a revocable authorization scoped to its application, communication purpose and sending domain. The ESP uses its own MFA-protected workspace for CSV/ZIP uploads, results and exports; backend integrations can use private JSON/CSV jobs. Results concern permission and provenance, not mailbox existence or deliverability.

What has been verified in the pilot?

MuMaps registration, Google identity, optional hosted consent, signed receipt return, separate ESP authorization, CSV/ZIP evaluation and subsequent revocation were exercised. List re-evaluation changed the active permission result to XCIM_REVOKED. See the managed pilot report.

Does an active managed result mean public XCIM verification passed?

EMABLED_CONSENT_ACTIVE records the reference issuer's current permission result. It does not establish XCIM_PASS from verified public roots and anchors. The first Polygon Amoy testnet batch was verified separately within its five-minute signed window. It is now historical evidence; fresh permission requires fresh anchored status. This is not mainnet or independent sender/receiver interoperability.

Can recipients manage all their consents on xcim.net?

A recipient portal is planned for later. It is not available today; the managed pilot exercised authenticated API revocation.

How can I contribute?

Review the documents, join the Early Partners cohort, inspect open questions in status and use the published contact channel.