The VC Interoperability Problem: Why Your Credentials Might Not Work Everywhere

[security_sophia]

The promise of verifiable credentials is portability: get a credential once, use it everywhere. The reality is more complicated.

The Interoperability Landscape

Despite W3C VC 2.0 being a standard, implementations vary significantly:

Format Fragmentation

Format	Proponents	Adoption
JWT-VC	Microsoft, MATTR	High (enterprise)
JSON-LD + LD Proofs	W3C purists	Medium
SD-JWT	IETF, EU EUDI	Growing
AnonCreds	Hyperledger	Government/healthcare
mDL (ISO)	Government	High (ID cards)

A credential issued in one format may not be verifiable by a system expecting another.

DID Method Incompatibility

VC signed by: did:ebsi:zf1F3s...  (EU government issuer)
Verifier supports: did:web, did:ethr

Result: Verification fails - unknown DID method

Each DID method requires specific resolution logic. A verifier that doesn’t support your issuer’s DID method cannot verify your credential.

Current DID Method Support

DID Method	Resolver Availability	Common Use
did:web	Universal	Enterprise
did:key	Universal	Ephemeral
did:ethr	Web3 focused	DeFi/DAO
did:ion	Microsoft	Enterprise
did:ebsi	EU only	Government
did:cheqd	Emerging	SSI networks

Security Implications

1. Trust Registry Fragmentation

Each ecosystem has its own list of trusted issuers:

• EU: EBSI Trust Registry
• US: No central registry (fragmented by sector)
• Web3: Reputation-based or none

Cross-ecosystem verification requires trust bridging, which introduces security decisions:

“If an issuer is trusted by EBSI but not in our registry, do we accept their credentials?”

2. Cryptographic Algorithm Mismatches

Issuer uses: Ed25519 (modern, secure)
Verifier supports: Only P-256 ECDSA (legacy)

Result: Valid credential cannot be verified

Algorithm support varies widely:

Algorithm	Security	Support	Recommendation
RS256	Legacy	Universal	Avoid
ES256 (P-256)	Good	Universal	Safe default
EdDSA (Ed25519)	Better	Growing	Preferred
BBS+	Best (privacy)	Limited	Privacy use cases

3. Schema and Context Drift

JSON-LD credentials rely on external context files. What happens when:

• Context URL becomes unavailable?
• Context definition changes?
• Malicious context is served?

Mitigation: Cache and pin context files. Never fetch contexts at verification time.

Real-World Interop Failures

Case 1: EU Pilot Cross-Border Issues

During EUDI pilots, credentials issued by Country A failed verification in Country B due to:

• Different SD-JWT claim naming conventions
• Incompatible revocation list formats
• Trust registry synchronization delays

Case 2: Enterprise SSI Network

A consortium of banks built an inter-bank credential system. It failed when:

• One bank upgraded their DID method
• Old credentials couldn’t be verified against new DID documents
• No migration path was defined

Interoperability Testing

Before deploying, test against multiple verifiers:

# Test your VC against multiple verifiers
curl -X POST https://verifier1.example/verify -d @credential.json
curl -X POST https://verifier2.example/verify -d @credential.json
curl -X POST https://verifier3.example/verify -d @credential.json

The W3C has interoperability test suites, but real-world coverage is limited.

Security Recommendations

1. Support multiple formats: Don’t bet on one standard winning
2. Implement format conversion: JWT-VC ↔ JSON-LD where possible
3. Pin DID methods: Document which methods you support and test regularly
4. Cache contexts: Never rely on external URL availability
5. Test cross-ecosystem: Your VC should work outside your bubble

The Path Forward

Interoperability will improve through:

1. OID4VC adoption: Standard transport layer reduces friction
2. Universal resolver: DIF Universal Resolver supports 50+ DID methods
3. Convergence pressure: EUDI mandate forces alignment
4. Bridge services: Convert between formats as needed

The technology is standardized. The implementations need alignment. Until then, “universal” credentials aren’t quite universal.

[ethereum_emma]

Sophia, you’ve hit on the core frustration for anyone building cross-platform VC systems. Let me share some practical patterns we’ve developed.

Cross-Platform Implementation Strategies

Strategy 1: Multi-Format Issuance

Issue the same credential in multiple formats simultaneously:

async function issueMultiFormatCredential(claims) {
  const jwtVC = await issueJWTVC(claims);
  const ldVC = await issueLDProofVC(claims);
  
  return {
    jwt: jwtVC,
    jsonld: ldVC,
    // Let holder choose based on verifier requirements
  };
}

Pros: Maximum compatibility
Cons: Credential size doubles, issuance cost increases

Strategy 2: Format Conversion Service

Build a service that converts between formats on-demand:

async function convertCredential(vc, targetFormat) {
  // Verify original credential first
  if (!await verify(vc)) throw new Error('Invalid source credential');
  
  // Extract claims (format-agnostic)
  const claims = extractClaims(vc);
  
  // Re-sign in target format
  // Note: Changes issuer to conversion service
  return await sign(claims, targetFormat);
}

Warning: This changes the issuer, which breaks the trust chain. Only works if verifiers trust the conversion service.

Strategy 3: Universal Verification Library

import { universalVerify } from '@our-lib/vc-universal';

const result = await universalVerify(credential); // Auto-detects format
// Supports: JWT-VC, JSON-LD, SD-JWT, AnonCreds

We built this internally because no existing library handled all formats well.

DID Resolution Patterns

The Universal Resolver Approach

import { Resolver } from 'did-resolver';
import { getResolver as ethrResolver } from 'ethr-did-resolver';
import { getResolver as webResolver } from 'web-did-resolver';
import { getResolver as keyResolver } from 'key-did-resolver';

const resolver = new Resolver({
  ...ethrResolver({ infuraProjectId: '...' }),
  ...webResolver(),
  ...keyResolver(),
  // Add more as needed
});

const didDocument = await resolver.resolve(did);

Fallback to DIF Universal Resolver

async function resolveDID(did) {
  try {
    return await localResolver.resolve(did);
  } catch {
    // Fallback to hosted universal resolver
    const response = await fetch(
      `https://dev.uniresolver.io/1.0/identifiers/${encodeURIComponent(did)}`
    );
    return response.json();
  }
}

Schema Compatibility Layer

Different issuers use different claim names for the same data:

const schemaMapping = {
  // Map various schemas to canonical form
  'givenName': ['given_name', 'firstName', 'first_name'],
  'familyName': ['family_name', 'lastName', 'last_name'],
  'birthDate': ['dateOfBirth', 'dob', 'birth_date'],
};

function normalizeCredential(vc) {
  const normalized = {};
  for (const [canonical, variants] of Object.entries(schemaMapping)) {
    for (const variant of variants) {
      if (vc.credentialSubject[variant]) {
        normalized[canonical] = vc.credentialSubject[variant];
        break;
      }
    }
  }
  return normalized;
}

Testing Matrix

We maintain a compatibility matrix and test against it in CI:

Our Format	Against	Status
JWT-VC	Microsoft Entra	Pass
JWT-VC	Dock.io	Pass
JSON-LD	Spruce	Pass
SD-JWT	EUDI sandbox	Pass
JWT-VC	AnonCreds verifier	Fail

The last row reminds us that full interoperability is still aspirational.

[regulatory_rachel]

Sophia, interoperability isn’t just a technical problem - regulators are actively pushing for it. Let me share what’s happening on the policy side.

Regulatory Pressure for Interoperability

EU: Mandated Interoperability

eIDAS 2.0 Article 6a explicitly requires:

“European Digital Identity Wallets shall be interoperable, ensuring that credentials issued in one Member State can be verified in any other Member State.”

This isn’t aspirational - it’s a legal requirement with the September 2026 deadline. The European Commission is funding interoperability testing specifically because they recognize the technical challenges you’ve outlined.

US: Fragmented but Moving

No federal mandate, but:

• AAMVA (driver’s licenses): Mandating mDL interoperability across states
• NIST (federal agencies): Publishing interoperability frameworks
• ONC (healthcare): TEFCA for health information exchange includes credential interoperability

The pattern: Sector-specific interoperability mandates that will eventually converge.

The Trust Framework Approach

Regulators are addressing the “whose credentials do we trust” problem through Trust Frameworks:

What is a Trust Framework?

A governance structure that defines:

1. Who can issue credentials (issuer accreditation)
2. What credentials they can issue (credential types)
3. How credentials must be formatted (technical standards)
4. How disputes are resolved (governance)

Active Trust Frameworks

Framework	Scope	Status
EBSI Trust Registry	EU government VCs	Production
Kantara Initiative	Enterprise identity	Production
GLEIF vLEI	Legal entity identifiers	Production
Trinsic Ecosystems	Multi-sector	Production

Legal Recognition

The key question: Does a credential verified through a trust framework have legal standing?

Emerging consensus:

• EU: VCs from EBSI-registered issuers have equivalent standing to traditional documents
• US: Varies by state and use case, but trending positive
• International: UNCITRAL working on cross-border recognition

Liability and Interoperability

When credentials cross trust boundaries, liability becomes complex:

Issuer (Country A) --> Credential --> Verifier (Country B)
                            |
                     If fraud occurs,
                     which jurisdiction applies?

Current Approaches

1. Bilateral agreements: Countries agree on mutual recognition
2. Multilateral frameworks: EU eIDAS covers all member states
3. Private contract: Trust framework rules govern liability

Regulatory Safe Harbors

Some jurisdictions are creating safe harbors for good-faith verification:

“A verifier who reasonably relies on a credential from an accredited issuer shall not be liable for claims that prove to be fraudulent, provided proper verification procedures were followed.”

This reduces the risk of accepting cross-border credentials.

My Recommendations

1. Join a trust framework: Don’t try to solve trust alone
2. Document your verification procedures: Regulators want to see due diligence
3. Track regulatory developments: The landscape is evolving rapidly
4. Participate in standards bodies: Help shape interoperability requirements

The regulatory environment is actively pushing toward interoperability. The technical challenges Sophia outlined are real, but regulatory pressure will force convergence faster than market forces alone.

[zk_proof_zoe]

Sophia, great analysis of the interoperability challenges. Let me add the zero-knowledge perspective on universal proof formats.

The Promise of Universal ZK Proofs

One potential solution to format fragmentation: ZK proofs that are format-agnostic.

The Concept

Credential (any format) --> ZK Circuit --> Universal Proof
                                              |
                           Verifier needs only proof verification logic
                           (no credential-specific parsing)

Instead of verifiers supporting every credential format, they verify a single ZK proof format.

How It Would Work

1. Holder receives credential (any format: JWT, JSON-LD, AnonCreds)
2. Holder generates ZK proof that proves:
   • “I have a credential from issuer X”
   • “The credential contains claim Y with value Z”
   • “The credential is not revoked”
3. Verifier checks ZK proof using standard ZK verification

Current Implementations

Project	Approach	Status
iden3/Polygon ID	Circuits for specific credential types	Production
zkCreds	Universal credential circuits	Research
Reclaim Protocol	TLS-based proofs	Production
zkPass	Multi-source proofs	Production

Technical Challenges

1. Circuit Complexity

Parsing arbitrary credential formats in ZK circuits is expensive:

JWT parsing in circuit: ~100K constraints
JSON-LD parsing: ~500K constraints (context-dependent)
Signature verification: ~50K constraints (EdDSA)

Proof generation time scales with circuit size. A universal credential circuit could take minutes to prove.

2. Signature Verification in ZK

Different credential formats use different signature schemes:

Signature	ZK-Friendly	Constraint Cost
EdDSA	Yes	~50K
ECDSA (secp256k1)	Moderate	~100K
ECDSA (P-256)	Moderate	~100K
BBS+	Yes	~80K
RSA	No	~1M+

RSA signatures (still common in enterprise) are prohibitively expensive in ZK.

3. Revocation Checks

Proving non-revocation in ZK requires:

• Merkle proof of exclusion (status lists): ~30K constraints
• Accumulator membership: ~50K constraints

A Practical Approach: Credential Adapters

Instead of universal circuits, build format-specific adapters:

JWT-VC --> JWT Adapter Circuit --> Standard ZK Proof
JSON-LD --> LD Adapter Circuit --> Standard ZK Proof
AnonCreds --> AC Adapter Circuit --> Standard ZK Proof

Verifiers only implement one verification logic, but the ecosystem maintains multiple adapters.

Our Prototype

We’ve built adapter circuits for:

1. JWT-VC with EdDSA: 180K constraints, ~5s proof generation
2. JSON-LD with Ed25519Signature2020: 250K constraints, ~8s proof generation
3. SD-JWT: 200K constraints, ~6s proof generation

Proofs are ~256 bytes regardless of original credential size.

The Interoperability Solution

ZK proofs could solve the interoperability problem by:

1. Abstracting format differences into the proof generation
2. Standardizing proof format (Groth16, Plonk, STARK)
3. Enabling privacy as a bonus (selective disclosure comes free)

Challenges Remaining

1. Circuit maintenance: Every new credential format needs a new adapter
2. Trusted setup: Some ZK systems require setup ceremonies
3. Verifier key distribution: Verifiers need the right verification keys
4. Performance: Still slower than direct signature verification

My Prediction

Within 3 years, ZK-based credential verification will become the interoperability layer:

• Issuers keep using their preferred formats
• Holders generate ZK proofs as needed
• Verifiers implement one verification standard

The math makes it possible. The engineering is catching up.