Two organisations can implement the same standard and still fail to exchange usable evidence. They may select different optional features, disagree about trust anchors, interpret status information differently or omit an operational rule that the standard leaves to the ecosystem.

A standard defines a common language

Specifications reduce ambiguity by defining data structures, messages and processing rules. They allow teams to build components that can, in principle, understand one another. But identity exchanges also depend on policy: which credentials are accepted, what assurance is required, which verifiers are authorised and how revocation is checked.

Those choices are often made in an implementation profile, a national regulation, a trust framework or an ecosystem agreement. The profile must identify exact versions and resolve options without silently weakening security or privacy.

Turn a profile into tests

A useful interoperability plan includes more than a happy-path exchange. It tests malformed inputs, unsupported algorithms, unknown issuers, expired credentials, stale status data, replay, wrong audiences and missing trust configuration. It also records which side owns each failure and what the user or operator sees.

The OpenID Foundation’s High Assurance Interoperability Profile selects requirements across issuance, presentation, SD-JWT VC and ISO mdoc. The European Digital Identity Wallet Architecture and Reference Framework adds ecosystem-specific components and procedures. Neither makes testing optional: implementations still need reproducible fixtures and independent peers.

Keep versions visible

Standards evolve at different speeds. As of this article’s publication, the IETF SD-JWT-based Verifiable Digital Credentials document is an Internet-Draft, RFC 9901 is final, and ISO/IEC 18013-5:2021 is under revision. A procurement or implementation record should state the edition and profile it uses rather than simply say “ISO-compliant” or “OpenID-compatible”.

A practical sequence

  1. Agree the service purpose, participants and legal authority.
  2. Select the credential format, protocol versions and profile.
  3. Define trust sources, status and failure policy.
  4. Publish a test suite with positive and negative cases.
  5. Run independent interoperability sessions and preserve evidence.
  6. Reassess the profile when standards or law change.

References