Working draft for public review. Not a stable standard, IETF adoption, certification or production recommendation. Experimental profiles require explicit opt-in.

XCIM Issuer Metadata 0.2

WD-02 · Capability advertisement and receiver-local trust

1. Object selection

This profile defines xcim_version: "0.2", object_type: "issuer_metadata" using the revision-specific schema. Its JWS protected typ is application/xcim-issuer-metadata+jcs. This metadata version does not change application registrations, batch manifests, OIDC receipts or other 0.1 wire objects. Historical metadata 0.1 remains an OIDC-only contract.

xcim_versions lists supported receipt wire versions; issuance_profiles_supported lists the supported receipt issuance profiles. Both lists MUST be nonempty and unique. oidc_hosted_consent requires version 0.1; evp_hosted_consent requires version 0.2. An implementation supporting both advertises both versions and both profiles. Unknown profiles or versions fail schema selection, rather than triggering fallback.

Advertisement MUST describe an integration actually enabled by the issuer. It is not a browser/provider test result. A receiver MUST additionally enable each selected profile under local policy, including explicit opt-in for EVP. A receipt tuple absent from accepted metadata MUST NOT receive a positive result. The signed receipt remains the authority for selecting its exact receipt schema; metadata cannot relabel it.

2. Trust and accreditation

accreditation_reference is required but MAY be null. Null means that the metadata asserts no registry accreditation. It does not prevent a receiver from accepting the issuer through independently provisioned local pins, nor does it authorize any receiver to trust a self-published key. No dummy accreditation record is required for the Amoy pin-based model.

A non-null reference identifies an HTTPS registry, accreditation ID/epoch and entry URI. The registry URI is not fixed to an operator. An accreditation 0.2 object uses protected typ: application/xcim-issuer-accreditation+jcs and identifies that same registry and issuer. The receiver MUST authenticate its signature using an independently accepted registry key, require matching registry/issuer/ID/epoch/key commitments, and enforce current status, time and compromise policy. Following an entry URI MUST NOT bootstrap a new trust root.

The URI comparison is exact after validating the selected schema and configured authority. A different spelling or unaccepted registry is not an alias. Existing 0.1 registry-bound objects are historical artifacts, not a universal requirement for a new issuer. Implementations MUST declare which metadata/accreditation version and trust path they accept.

3. Required negative cases

Tests MUST reject EVP advertisement without receipt version 0.2, OIDC advertisement without receipt version 0.1, duplicate/unknown capabilities, unknown metadata versions, altered signatures, unsupported receiver profiles and accreditation references whose authority or binding is not accepted. Both null-accreditation and an independently selected registry MUST validate structurally; neither is a trust decision by itself.

The source bundle tests schema and deterministic binding cases using synthetic data. It does not accredit issuers or distribute production trust roots.