Standards and conformance

This page lists each specification and protocol IXO Credentials builds on, the version it implements, and what it does and does not use from each. Read it to decide whether a wallet, issuer or verifier from outside IXO can work with IXO Credentials, or to check a claim about the system. IXO implements a profile of each standard (the IXO Credential Profile v1): one way of doing each thing, applied the same way by every IXO issuer, verifier and wallet.

Summary

Two of the credential standards are still drafts: SD-JWT VC and Token Status List. The field names IXO relies on (vct, cnf, status, status_list, statuslist+jwt, ttl) have not changed across recent drafts. The SD-JWT VC changes from -24 to -26 answer IESG review comments (clarifications of issuer key discovery, an update to RFC 7800 for cnf, and editorial fixes); the code has not been re-checked against -26 line by line. A change in a later draft or in the final RFC would be handled as a new profile version.

How the standards fit together

SD-JWT (RFC 9901)

Uses: the compact serialization; object-property disclosures (§4.2.1) and, when verifying, nested object and array-element disclosures processed recursively (§4.2.4, §4.2.6, §7.1); _sd_alg: sha-256; decoy digests (§4.2.5); the Key Binding JWT with typ: kb+jwt, aud, nonce, iat and sd_hash (§4.3); verification by the holder (§7.2, the kit's verifyIssuedCredential) and by the verifier (§7.3, the kit's verifyPresentation).

Does not use: the JWS JSON serialization (§8). Presentations without key binding are refused. IXO issuers issue flat credentials (every disclosure is a top-level claim), and a verifier can ask only for top-level claims.

SD-JWT VC

Uses: typ: dc+sd-jwt; the registered claims iss, sub, iat, nbf, exp, cnf, vct and status; key binding through cnf.jwk; the verification rules.

Issuer key discovery: SD-JWT VC defines two mechanisms (an HTTPS iss with JWT VC Issuer Metadata, or an x5c certificate chain) and lets an ecosystem define others, provided an attacker cannot choose the mechanism. Under the IXO profile iss is always a DID (did:ixo or did:web), and the signing key is the one the JOSE kid names under assertionMethod on that DID document. That is the only mechanism.

Does not use: JWT VC Issuer Metadata, x5c, type metadata retrieval by verifiers, vct#integrity and aka_vcts. Verifiers match vct as an exact string and never fetch it.

Profile rules for any issuer: the kit's verifier requires sub and exp, and refuses iss, nbf, exp, cnf, vct, vct#integrity, aka_vcts and status as disclosures. It still accepts the older typ: vc+sd-jwt.

Consequence: a verifier outside IXO can check an IXO credential only if it resolves did:ixo or did:web and follows this key rule.

OpenID4VCI 1.0

Uses:

• the pre-authorized code flow (§3.5) and nothing else;
• credential offers by reference (§4.1.3): the offer inbox holds a credential_offer_uri, and the issuer mints a fresh pre-authorized code on every fetch (5 minutes, single use at IXO issuers). Offers by value (§4.1.1) are accepted for other issuers;
• the token endpoint with anonymous pre-authorized access (§6), including authorization_details of type openid_credential, echoed with credential_identifiers;
• OAuth authorization server metadata (RFC 8414) with pre-authorized_grant_anonymous_access_supported: true and token_endpoint_auth_methods_supported: ["none"];
• the nonce endpoint (§7) and the jwt key proof with typ: openid4vci-proof+jwt and a DID URL in kid (Appendix F.1);
• the credential endpoint with exactly one proof (§8.2) and the credentials / notification_id response (§8.3);
• the notification endpoint (§11);
• issuer metadata at /.well-known/openid-credential-issuer/<path> (§12.2), listing EdDSA and Ed25519;
• the SD-JWT VC format profile, dc+sd-jwt (Appendix A.3).

IXO additions, invisible to the protocol: offers reach the wallet through the offer inbox, addressed to a DID, instead of a QR code (the offer object is standard); and subject binding: the issuer refuses a proof whose key is not on the subject's own DID document, which answers the replay risk of pre-authorized codes.

Does not use: the authorization code flow (§3.4), transaction codes (tx_code), batch issuance (§3.3.2), deferred issuance at IXO issuers (the kit wallet can poll a deferred endpoint; the Auth Hub does not), encrypted credential requests and responses (§10), signed issuer metadata (§12.2.3), key attestations (Appendix D), and jwk or x5c key proofs.

OpenID4VP 1.0

Uses:

• a signed request object, typ: oauth-authz-req+jwt (§5, RFC 9101), passed by reference through request_uri with the default GET method;
• the decentralized_identifier client identifier prefix (§5.9.3): the request is signed by a key on the verifier's DID document, named by kid. IXO requires that key under authentication or assertionMethod;
• response_type: vp_token, nonce and state;
• the Digital Credentials Query Language (DCQL, §6), restricted to a subset: one-segment claim paths, format dc+sd-jwt, value matching on iss to name accepted issuers. credential_sets, claim_sets, trusted_authorities and nested paths are refused; unknown members are ignored and multiple: true is answered with one presentation;
• the vp_token object keyed by credential query id (§8.1);
• direct_post.jwt responses (§8.3), encrypted with ECDH-ES to a P-256 key in client_metadata.jwks, with A128GCM (the default) or A256GCM. Plain direct_post only in local development;
• wallet error responses (§8.5), sent only after the person decided;
• the request as a link, openid4vp://?client_id=…&request_uri=…, for wallets other than the Auth Hub;
• replay protection through the KB-JWT's aud (the full client identifier) and nonce;
• vp_formats_supported with Ed25519 and EdDSA.

IXO addition: requests reach the Auth Hub through the presentation broker, addressed to a DID. Other wallets can use the standard link.

Does not use: scope-based requests, request_uri_method: post, transaction_data, verifier_info, verifier attestations, the Digital Credentials API (Appendix A), other credential formats, client identifier prefixes other than decentralized_identifier, and the same-device redirect with a response code. IXO flows are cross-device; a verifier binds each answer to the person it asked.

Token Status List

Uses: the status list in JSON with a compressed byte array; the status list token as a JWT, typ: statuslist+jwt, with sub, iat, exp, ttl and status_list; the status.status_list claim with uri and idx; the values VALID (0) and INVALID (1); retrieval over HTTP as application/statuslist+jwt with CORS for everyone; the validation rules, including that the token's sub equals the credential's uri and that an index outside the list is a refusal.

IXO choice: issuers upload their signed tokens to the Credentials worker's registry, and credentials point there. The standard only requires that the uri resolves. Clients never follow redirects when fetching a list (the standard says they should); this is a security rule of the kit.

Does not use: the CWT format, status list aggregation, historical resolution, and status types other than valid and invalid (any non-zero value is reported as revoked).

DIDs: DID v1.0, did:web and did:ixo

• DID v1.0 defines the identifiers and documents. IXO reads verificationMethod, authentication and assertionMethod with Ed25519 keys. DID v1.1 is a W3C Candidate Recommendation (March 2026); IXO has not moved to it.
• did:web identifies services. did:web:HOST resolves to https://HOST/.well-known/did.json, did:web:HOST:A:B to https://HOST/A/B/did.json, a port written %3A. Only the canonical spelling is accepted (lower-case host, punycode for international names, no IP address), so one DID has one spelling. Every DID is its own sender, exactly as written; there is no grouping by domain.
• did:ixo identifies people (did:ixo:ixo1…) and entities (did:ixo:entity:…). Documents live on the IXO chain and are read through IXO Blocksync. Other DID methods, did:key included, are refused.

UCAN

Every call to the Credentials worker carries a UCAN invocation: Authorization: Bearer with a base64 CAR, addressed to the worker's did:web, valid at most 300 seconds, used once, and signed at every link by a did:ixo or did:web. IXO adds one rule on top of UCAN: the invocation carries the request-binding fact { "method": "<HTTP method>", "path": "<full path>" }, so a token works for exactly one request. Delegations can only narrow what they were given, and revoked delegations are refused through the UCAN store. The person's offer consent (credentials/offer) and standing consents (credentials/present) are UCAN delegations too.

UCAN is IXO's choice for service authentication; it is not part of any credential standard, and a party that ignores the worker never sees it.

JOSE algorithms in use

ECDSA (ES256) and other key types are not supported for signatures.

Where IXO is stricter than the standards

• Key binding is mandatory on every presentation.
• Status is mandatory, and verifiers fail closed when a list cannot be read.
• Issuers must check that the proof key belongs to the subject.
• There is one way to find an issuer's key.
• Request objects deposited at the worker must carry exp and live at most 24 hours.
• Outbound fetches never follow redirects and refuse private addresses.

Conformance matrix

The standards review checked 52 areas of the five credential standards against the code: 26 implemented, 11 profile choices (implemented, narrowed on purpose; a counterpart outside the subset gets a clear error) and 15 not supported. The not supported areas are listed in the "Does not use" lines above.

Independent implementations agreed with IXO's own output in that review: jose 6.2.13 verified the request object, the key proof and the status list token and decrypted the response JWE; @sd-jwt/sd-jwt-vc 0.23.0 accepted a Self-minted credential and a kit-built presentation with key binding; the kit decoded both Token Status List test vectors. These probes ran before the fix rounds and have not been re-run since.

EU Digital Identity Wallet

The European Digital Identity (EUDI) Wallet is the wallet framework of the EU Digital Identity Regulation. Its technical rules are in the EUDI Wallet Architecture and Reference Framework (ARF); the current version is ARF 3.0.0 (23 July 2026, readable at eudi.dev). For remote flows the ARF uses the OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0, Final since 24 December 2025.

IXO Credentials is built on the same core standards as the EUDI Wallet: SD-JWT VC, OpenID4VCI, OpenID4VP with DCQL, and Token Status List. It is aligned with, not certified against, the ARF. It is not an EUDI Wallet, it does not claim conformance to the ARF or to HAIP, and an EUDI Wallet or an EUDI relying party cannot be assumed to work with it.

The differences:

Because the core formats and protocols are the same, moving towards the ARF is a matter of the items in this table (certificates and trust lists, ES256, the authorization code flow, attestations, and the missing presentation channels), not of a new credential format.

Related pages

• IXO Credentials overview
• Request proof
• Issue a credential
• Credentials API reference