Standards Compliance

Overview

TCS implements a complete stack of open standards for verifiable credential issuance, presentation, and trust establishment. OID4VCI profiles are conformance-passed, while OID4VP profiles are currently in conformance processing.

Spec version pinning

TCS tracks the OpenID Foundation Implementer’s Drafts for OID4VCI and OID4VP. The dc+sd-jwt credential format is pinned to draft-ietf-oauth-sd-jwt-vc-15 (verified end-to-end against this revision; the underlying @sd-jwt/sd-jwt-vc library version is ^0.19.0). These specifications are still evolving — see the Standards Table below per protocol, and the Roadmap and Known Gaps section for what we explicitly do not yet implement.

---

Standards Table

Standard	Specification	Implementation	Status
OID4VCI	OpenID for Verifiable Credential Issuance — tracking the latest published Implementer’s Draft	Pre-authorized code flow (production), credential offer management, issuer metadata discovery. Authorization code flow on roadmap.	Conformance passing
OID4VP	OpenID for Verifiable Presentations — tracking the latest published Implementer’s Draft	DCQL queries, JAR request objects, direct_post response mode, VP Token validation	Conformance processing
HAIP v1	High Assurance Interoperability Profile 1.0	ES256 signing, X.509 certificate binding, mandatory DPoP nonces, client attestation support	OID4VCI passing / OID4VP processing
SD-JWT VC draft-15	IETF SD-JWT-based Verifiable Credentials — pinned to draft-ietf-oauth-sd-jwt-vc-15	dc+sd-jwt credential format, selective disclosure, Type Metadata Documents (§5)	Implemented
Token Status List draft-21	IETF Token Status List — pinned to draft-ietf-oauth-status-list-21	status.status_list reference on X.509-issued credentials, public statuslist+jwt endpoint, revoke / suspend / reinstate	Implemented
DPoP	RFC 9449 — Demonstrating Proof-of-Possession	Token binding with JWK thumbprint, server-issued nonces, JTI replay protection	Implemented
PKCE	RFC 7636 — Proof Key for Code Exchange	S256 challenge method for authorization code flow	Implemented
JAR	RFC 9101 — JWT-Secured Authorization Requests	Signed request objects for OID4VP verification flows	Implemented
PAR	RFC 9126 — Pushed Authorization Requests	Server-side session creation before authorization redirect	Implemented
OAuth 2.0 AS Metadata	RFC 8414 — OAuth 2.0 Authorization Server Metadata	/.well-known/oauth-authorization-server discovery endpoint	Implemented
ISO 27001	Information Security Management	Operational security controls governing TCS infrastructure and processes	Organization-stated certification claim
ISO 27701	Privacy Information Management	Privacy controls for credential data handling and storage	Organization-stated certification claim

---

Standard Details

OID4VCI v1 — OpenID for Verifiable Credential Issuance

TCS implements two issuance flows defined by OID4VCI:

• Pre-Authorized Code Flow (production): The issuer creates a credential offer containing a pre-authorized code. The holder wallet exchanges this code for an access token, then uses the token to request the credential. No user interaction with the authorization server is required.
• Authorization Code Flow (roadmap, not in production): The wallet would initiate issuance through PAR, authenticate at the authorization endpoint, receive an authorization code, exchange it for an access token, and request the credential. Underlying primitives (PAR, PKCE) are implemented and exercised by conformance tests; the issuer-side flow: "authorization-code" switch is not yet wired through. See the Roadmap.

DPoP-bound access tokens are supported on the production flow per HAIP requirements.

OID4VP v1 — OpenID for Verifiable Presentations

TCS implements OID4VP v1 with the following capabilities:

• DCQL (Digital Credentials Query Language) queries for specifying required credentials
• JAR (JWT-Secured Authorization Requests) for signing request objects with application/oauth-authz-req+jwt content type
• direct_post response mode for VP Token submission
• Cross-device and same-device flows with session status polling and optional redirect URIs

HAIP v1 — High Assurance Interoperability Profile

HAIP defines a constrained profile of OID4VCI and OID4VP for high-assurance use cases. TCS satisfies HAIP requirements including:

• ES256 (P-256) as the required signing algorithm for X.509-bound credentials
• Mandatory DPoP nonces on every token and credential request
• Client attestation JWT support (OAuth-Client-Attestation and OAuth-Client-Attestation-PoP headers)
• dc+sd-jwt as the credential format

HAIP requires ES256 + x5c, not EdDSA

HAIP v1 admits only ES256 (P-256) with an x5c certificate chain on the issuer side. The OIDF HAIP conformance suite actively rejects EdDSA + x5c. Issuers and verifiers targeting HAIP must register on the X.509 / ES256 path — the did:iota / EdDSA path is incompatible with HAIP and will fail conformance. See Signing Algorithms for path selection.

Before integrating on the HAIP path, contact the TCS team. The X.509 / x5c path requires Trust Model coordination — your verifier needs to trust the issuer’s CA root and the issuer’s x5c chain needs to terminate at a root the verifier accepts. We handle this pairing as part of onboarding rather than leaving it to runtime discovery.

IETF SD-JWT VC draft-15

TCS uses the IETF SD-JWT VC specification for its credential format, pinned to draft-ietf-oauth-sd-jwt-vc-15. This is distinct from W3C Verifiable Credentials Data Model 2.0 — the two specifications are mutually exclusive per IETF SD-JWT VC §1.2.

Key characteristics:

• Format identifier: dc+sd-jwt
• Flat claims structure with selective disclosure via the _sd mechanism
• Type metadata discovery through VCT URIs served by the Schema Registry
• Key binding JWTs for holder proof-of-possession during presentation

IETF Token Status List draft-21

Revocation is published as a Token Status List, pinned to draft-ietf-oauth-status-list-21. A credential issued on the X.509 / x5c path carries a status.status_list reference naming a list URI and an index within it:

{
  "status": {
    "status_list": {
      "uri": "https://issuer.turingspace.co/acme/status-lists/0",
      "idx": 4711
    }
  }
}

The URI serves a signed statuslist+jwt (Content-Type: application/statuslist+jwt) holding two bits per credential: valid, revoked, or suspended. The endpoint is public and unauthenticated — any relying party can resolve it without a TCS account. Revoking, suspending or reinstating a credential re-signs the list immediately, so the published token always reflects committed state.

Credentials issued on the did:iota path carry no status reference and are not revocable through this mechanism.

Freshness is a per-verifier property, not a guarantee we can make for you. Whether the TCS Verifier Service rejects a revoked credential is a per-deployment setting; where it is on, the list is fetched on every verification, so a revocation takes effect within roughly one round trip. A third-party verifier caches at its own discretion, bounded only by the ttl the token advertises — 300 seconds by default, adjustable by the operator without a code release. Draft-21 §8.2 asks relying parties to honour ttl, but that is a SHOULD at best, so a third-party verifier may serve a staler answer than the list contains. Design revocation timelines around the ttl you publish, not around realtime.

The token’s iss is not a spec guarantee. Draft-21 §5.1 does not define iss for a Status List Token, and a third-party relying party has no obligation to check it. The trust binding is the signer: TCS’s verifier requires the list token to be signed by the same leaf certificate that signed the credential, comparing the two x5c headers directly. Treat the signer as the authority, never the iss string.

uri + index is a persistent correlator. The pair is fixed for the life of the credential and visible to every verifier the credential is presented to, which makes it a stable identifier across unrelated verifiers (§12.5). What the mechanism does provide is Herd Privacy on the issuer side — the token covers the whole list, so fetching it tells the issuer that someone checked the list, never which credential was presented. That is not presentation unlinkability, and should not be described as such. Unlinkable presentation requires batch-issued single-use credentials, which is an issuance-side concern.

DPoP — RFC 9449

DPoP prevents token theft by binding access tokens to the client’s key pair. TCS enforces:

• JWK thumbprint (jkt) binding stored with each access token
• Server-issued DPoP nonces with 300-second expiry
• JTI (JWT ID) replay protection backed by database tracking
• IAT (issued-at) validation with 300-second maximum age and 60-second clock skew tolerance
• Supported algorithms: EdDSA, ES256

PKCE — RFC 7636

All authorization code flows require PKCE with the S256 challenge method. The code verifier and challenge are validated during token exchange to prevent authorization code interception.

JAR — RFC 9101

The Verifier Service signs OID4VP request objects as JWTs with content type application/oauth-authz-req+jwt. Wallets fetch the signed request object from the request URI and verify the signature before processing the authorization request.

PAR — RFC 9126

The Authorization Server exposes a PAR endpoint that accepts authorization request parameters and returns a request_uri. This URI is then used at the authorization endpoint, keeping sensitive parameters server-side and reducing URL length.

OAuth 2.0 AS Metadata — RFC 8414

The /.well-known/oauth-authorization-server endpoint publishes the Authorization Server’s capabilities, including supported grant types, endpoints, code challenge methods, and DPoP signing algorithms.

---

OIDF Conformance Testing

TCS runs the OpenID Foundation conformance suite against its endpoints. The status below reflects whether all required test plans for each profile pass; it does not imply OIDF certification (no certification has been granted as of this writing — conformance certification is a separate program).

Profile	Suite	Result
OID4VCI Credential Issuer	OID4VCI Conformance Suite	Passing
OID4VP Verifier	OID4VP Conformance Suite	Processing
HAIP + OID4VCI Issuer	HAIP Conformance Suite + OID4VCI	Passing
HAIP + OID4VP Verifier	HAIP Conformance Suite + OID4VP	Processing

The conformance suite emulates a wallet client and validates that the TCS endpoints produce spec-compliant responses for all required protocol interactions, including error cases. To request a copy of the latest test plan output, contact the team.

---

Signing Algorithms

TCS supports two signing paths, selected based on the issuer’s key material:

Algorithm	Curve	Key Type	Use Case	Credential Header
EdDSA	Ed25519	DID-based	Issuers using IOTA DID verification methods	kid referencing the DID verification method
ES256	P-256 (secp256r1)	X.509-based	Issuers using X.509 certificates (required by HAIP)	x5c containing the certificate chain

Note: did:key generation is available in Holder Service for wallet interoperability. This is a holder-side capability and does not constitute an additional issuer signing path — TCS issuer signing remains limited to the two paths above.

---

Cryptographic Binding Methods

TCS supports two cryptographic binding methods for credential proof-of-possession:

Method	Description
did	The holder proves possession of a DID verification method by signing a proof JWT with the corresponding private key
jwk	The holder proves possession of a standalone key pair by including the public key as a JWK in the proof JWT header

---

Credential Format

TCS uses a single credential format across all issuance flows:

Property	Value
Format identifier	dc+sd-jwt
Selective disclosure	_sd claim mechanism (hash-based)
Key binding	Key Binding JWT appended to the SD-JWT string
Type metadata	VCT URI resolving to a Type Metadata Document served by the Schema Registry
Claims structure	Flat (no nested credentialSubject wrapper)

---

Wallet Interoperability

TCS issues dc+sd-jwt credentials and accepts presentations via OID4VP DCQL. Because both protocols are still pre-final, real-world interop depends on the wallet’s profile choices (proof type, binding method, request signing). The table below reflects what is currently substantiated by TCS internal test fixtures — it is not an OpenID Foundation interop certification, and it is intentionally conservative.

Wallet	Issuance (OID4VCI)	Presentation (OID4VP)	Notes
Turing Space Holder Service (custodial wallet)	Tested	Tested	First-party reference path; exercised by TCS service tests

Third-party wallet results will be added to this table only once a dated test artefact exists — we deliberately do not list “untested” wallets, since that itself can read as an interop claim. If you need a specific wallet integration confirmed before engaging, contact the team — we can run a profile-matching session and share the resulting test output.

---

Roadmap and Known Gaps

To make procurement decisions easier, we list what TCS does not currently implement, and the rationale or planned timing for each.

Capability	Status	Notes
ISO/IEC 18013-5 mDoc / mDL	Not implemented	TCS issues only dc+sd-jwt. Deployments requiring EUDIW PID-mDoc parity must combine TCS with a separate mDoc stack.
W3C VC Data Model 1.1 / 2.0 (subject credentials)	Out of scope by design	The IETF SD-JWT VC spec §1.2 treats W3C VCDM and SD-JWT VC as mutually exclusive. The only W3C-format artefact TCS produces is the DIF Well-Known DID Configuration credential for domain linkage.
OpenID Federation / EBSI TIR / ETSI Trusted List integration	Not implemented	TCS operates a scoped issuer allowlist within the TCS deployment. Cross-ecosystem trust currently bridges via the X.509 / x5c path with an externally-anchored CA — see Architecture & Security.
OID4VCI Authorization Code Flow	Roadmap	Pre-Authorized Code Flow is the production path; the auth-code flow is in active development.
did:web / did:jwk issuer DIDs	Not implemented	Issuers currently use either did:iota or X.509 certificates. See DIDs for the rationale.

---

What’s Next

• Architecture & Security — Understand the system architecture and security layers
• API Reference — Explore the complete endpoint surface across all services
• Authentication — Understand API Key, JWT, and DPoP authentication patterns