feat: w3c vc data model 2.0 support with modern cryptosuites, bitstringstatuslist, and fixes

[Moiz47]

Summary

Breaking changes and bug fixes from alpha branch

Changes

• w3c vc data model 2.0 support
• support for modern cryptosuite ecdsa-sd-2023 and bbs-2023
• support for bitstringstatuslist with w3c vc data model 2.0
• depreciate BBS202 for signing new documents
• w3c resolve, deference, resolveRepresentation functions for compliance.
• Bug fixes including, but not limited to, render method issues, expired and redacted document checks, CLI fixes, and more

Issues

Issues and stories related to w3c vc data model 2.0, modern crypto suites, compliance, and bug fixes

Releases

Channels: latest

Summary by CodeRabbit

• New Features

  • Modern cryptosuites (ECDSA‑SD‑2023, BBS‑2023), Multikey support, and Data Integrity proofs
  • W3C Verifiable Credentials v2.0 support alongside v1.1; selective disclosure and derivation
  • DID resolution/representation and dereference endpoints

• Documentation

  • Expanded guides, migration path from legacy BbsBlsSignature2020, and updated examples for modern flows

• Tests

  • Extensive fixture-driven tests covering modern cryptosuites and mixed scenarios

• Chores

  • Deprecated legacy w3c‑cli package

[coderabbitai]

Walkthrough

Deprecates the w3c-cli app and upgrades the TrustVC suite to alpha releases with broad v2.0 and modern-cryptosuite support: new JSON‑LD contexts, multikey multibase key handling, BBS‑2023 / ECDSA‑SD‑2023 cryptosuites, DID resolution APIs (resolve/represent/dereference), and many test/fixture and type updates.

Changes

Cohort / File(s)	Summary
Deprecation & Build config /.nxignore, nx.json, apps/w3c-cli/project.json.deprecated, apps/w3c-cli/package.json	Exclude apps/w3c-cli from NX; mark CLI package deprecated; remove from release.projects; bumped CLI package to an alpha pre-release.
CLI docs & tests apps/w3c-cli/README.md, apps/w3c-cli/tests/main.test.ts	Add deprecation notice and legacy docs; update tests to mock new issueDID shape and use VerificationType enum.
Ambient declarations packages/declaration.d.ts	Add ambient module declarations for Digital Bazaar cryptosuites, jsonld, and related packages.
JSON‑LD contexts & loader packages/w3c-context/src/context/*.json, packages/w3c-context/src/lib/index.ts	Add data-integrity-v2, multikey-v1, render-method-context-v2, status-list-2021-v1 contexts; export new context URL constants; extend document loader to resolve DID fragments to verification methods.
Context package metadata packages/w3c-context/package.json, packages/w3c-context/tsconfig*.json	Bump package version; update jsonld-signatures; include ../declaration.d.ts in tsconfig includes.
Credential‑status changes packages/w3c-credential-status/src/lib/*, packages/w3c-credential-status/package.json, packages/w3c-credential-status/README.md, tsconfig.json	Add BitstringStatusList support, new CryptoSuiteName type, change default to BitstringStatusListCredential + ecdsa-sd-2023, add runtime validation and wrappers; docs updated; version bumped.
Issuer — multikey & key generation packages/w3c-issuer/src/did-web/keyPair/*, packages/w3c-issuer/src/did-web/keyPair/index.ts, types.ts, package.json, tsconfig*.json	Add BBS‑2023 and ECDSA‑SD‑2023 key generators; multikey/multibase fields added to types; routing for modern cryptosuites; new digital‑bazaar deps and version bump; include ../declaration.d.ts.
Issuer — wellKnown / DID operations packages/w3c-issuer/src/did-web/wellKnown/*.ts, packages/w3c-issuer/src/did-web/index.ts	Add Multikey handling in wellKnown DID generation; add and export DID core helpers resolve, resolveRepresentation, dereference and tests; update related types and tests.
DID query & resolver packages/w3c-issuer/src/did-web/wellKnown/query.ts, query.test.ts	New resolve/representation/dereference implementations wrapping did-resolver with content negotiation, fragment dereference, and errors; tests extended.
VC core — signing/verify/derive packages/w3c-vc/src/lib/w3c-vc.ts, packages/w3c-vc/src/lib/helper/index.ts, packages/w3c-vc/src/lib/verify/credentialStatus/index.ts	Add DataIntegrityProof paths and cryptosuite integrations for ecdsa-sd-2023 and bbs-2023; introduce version guards (isRawDocumentV1_1/V2_0, isSignedDocumentV1_1/V2_0), isDerived, mandatory-pointers handling, derive-before-verify fallback, and many validation/ID prefilling changes.
VC types, fixtures & tests packages/w3c-vc/src/lib/types.ts, __fixtures__/*, w3c-vc.test.ts, src/index.ts	Add CredentialSchema, Evidence, RefreshService, DataIntegrityProof types; add many modern & legacy fixtures and scenario-driven tests; export new helpers and type updates; package.json dependency updates.
w3c package meta packages/w3c/package.json, package.json (root)	Bump monorepo package versions to 1.3.0-alpha.*, update inter-package alpha deps and remove root jsonld-signatures dependency.
TypeScript include updates packages/*/tsconfig.json, tsconfig.build.json (multiple)	Add ../declaration.d.ts to include paths across packages to pick up ambient declarations.
Documentation packages/w3c-context/README.md, packages/w3c-credential-status/README.md, packages/w3c-issuer/README.md, packages/w3c-vc/README.md, packages/w3c-issuer/src/did-web/README.md	Substantial README rewrites emphasizing v2.0 support, migration notes, modern cryptosuites, multikey examples, and updated API examples.

Sequence Diagram(s)

sequenceDiagram
    actor Client
    participant signVC as signCredential()
    participant prefill as prefilCredentialId()
    participant pointers as getMandatoryPointers()
    participant signer as CryptosuiteSigner
    participant loader as DocumentLoader

    Client->>signVC: credential + keyPair + (ecdsa-sd-2023)
    signVC->>prefill: prefilCredentialId()
    signVC->>pointers: getMandatoryPointers()
    signVC->>loader: getDocumentLoader()
    signVC->>signer: createEcdsaSd2023SignCryptosuite()
    signVC->>signer: sign(credential)
    signer-->>signVC: SignedCredential (DataIntegrityProof)
    signVC-->>Client: signed credential

Loading

sequenceDiagram
    actor Client
    participant verifyVC as verifyCredential()
    participant detector as baseProofDetector
    participant verifier as CryptosuiteVerifier
    participant derive as deriveCredential()

    Client->>verifyVC: signed credential
    verifyVC->>detector: detect base proof (ecdsa/bbs)
    alt verifier succeeds
        verifyVC->>verifier: verify(...)
        verifier-->>verifyVC: success
    else "Use deriveCredential() first" error
        verifyVC->>derive: deriveCredential(cred, [])
        derive-->>verifyVC: derived credential
        verifyVC->>verifier: verify(derived)
    end
    verifyVC-->>Client: verification result

Loading

sequenceDiagram
    participant App
    participant Loader as DocumentLoader
    participant Resolver as DIDResolver
    participant Cache

    App->>Loader: resolveDid(did:web:example#key-1)
    Loader->>Cache: check cache
    alt fragment present
        Loader->>Resolver: resolve(did:web:example)
        Resolver-->>Loader: didDocument
        Loader->>Loader: extract verificationMethod by fragment
        Loader->>Cache: store merged doc
        Loader-->>App: merged `@context` + verificationMethod doc
    else no fragment
        Loader->>Resolver: resolve(did:web:example)
        Resolver-->>Loader: didDocument
        Loader->>Cache: store document
        Loader-->>App: full didDocument
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Areas requiring extra attention:

• packages/w3c-vc/src/lib/w3c-vc.ts — signing/verify/derive paths, mandatory-pointer logic, cryptosuite selection, and error flows.
• packages/w3c-issuer/src/did-web/keyPair/index.ts & new keyPair modules — multikey generation, seed handling, deterministic behavior.
• packages/w3c-issuer/src/did-web/wellKnown/query.ts — DID resolution/representation/dereference, content negotiation, and error mapping.
• packages/w3c-context/src/lib/index.ts — document loader fragment resolution and caching correctness.
• packages/w3c-credential-status/src/lib/index.ts & utils — default API changes and multi-version branching.

Possibly related PRs

• feat: status list update for bbs and v2.0 #89 — Appears to make the same credential-status default/type changes (BitstringStatusListCredential / ecdsa-sd-2023) and related tests.
• feat: add bbs-2023 and ecdsa-sd-2023 key generation and did support #67 — Adds multikey modern cryptosuite support and keypair generators (BBS‑2023, ECDSA‑SD‑2023); strong overlap with issuer changes.
• feat: add resolve, resolveRepresentation and dereference functions #87 — Adds the DID core resolution functions (resolve, resolveRepresentation, dereference) that are implemented/expanded here.

Suggested labels

released on @alpha``

Suggested reviewers

• rongquan1
• nghaninn

Poem

🐰
I hopped through contexts, soft and spry,
From BLS to Multikey I learned to fly.
V2 proofs twinkle, cryptosuites sing,
The CLI naps while the new bells ring.
A nibble of code — a shiny thing!

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description follows the template with all required sections (Summary, Changes, Issues, Releases) and provides substantive content about the major features and fixes included.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Title check	✅ Passed	The PR title accurately summarizes the main changes: W3C VC Data Model 2.0 support, modern cryptosuites, BitstringStatusList, and associated fixes.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/rebase-main

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot
12.4% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 10

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

packages/w3c-credential-status/src/lib/utils.ts (1)

39-58: Remove duplicate assertCredentialStatusStatusListType export.

Lines 39-58 now declare assertCredentialStatusStatusListType twice. TypeScript treats this as a duplicate export and the CI already fails with “Multiple exports with the same name assertCredentialStatusStatusListType.” Keep only the widened implementation that admits both 'StatusList2021Entry' and 'BitstringStatusListEntry' and delete the legacy definition. Otherwise the package will not build.

packages/w3c-credential-status/src/lib/index.test.ts (1)

1-179: Remove duplicate export of assertCredentialStatusStatusListType in utils.ts.

The duplicate export at line 52 in packages/w3c-credential-status/src/lib/utils.ts is causing the vitest transform error and blocking the pipeline. Line 39 contains the correct implementation supporting both StatusList2021Entry and BitstringStatusListEntry. Remove the duplicate function definition at line 52–64.

🧹 Nitpick comments (7)

packages/w3c-credential-status/README.md (2)

231-264: Add a v1.1 signCredential result example for completeness.

Both detailed result examples (ECDSA-SD-2023 and BBS-2023) show v2.0 format with BitstringStatusListEntry and DataIntegrityProof. To help users transitioning from v1.1 or comparing formats, include a corresponding example result for v1.1 (using StatusList2021Entry and the legacy proof format). This strengthens documentation coverage for both versions.

Also applies to: 268-302

---

368-381: Update revocation example only demonstrates v2.0—add v1.1 alternative or clarify scope.

The "Update revocation status for existing VC" section (lines 368–381) uses only v2.0 credential types (BitstringStatusList, BitstringStatusListCredential, 'ecdsa-sd-2023'). Since the README emphasizes dual v1.1/v2.0 support, either add a parallel v1.1 example here or explicitly note that this section applies to v2.0 deployments only. This prevents confusion for users maintaining v1.1 credentials.

apps/w3c-cli/tests/main.test.ts (1)

332-360: Assertions correctly verify the new API structure.

The test properly verifies that didHandler extracts wellKnownDid and didKeyPairs from the issueDID result and writes them to separate files. Enum usage at lines 348 and 359 is consistent with the mock.

Consider extracting the mock data structure to a shared fixture (similar to mockWellKnown and mockKeyPair from line 15) to reduce duplication between the mock setup (lines 296-324) and these assertions. This would improve maintainability if the structure changes in the future.

Example refactor in tests/fixtures/:

export const mockIssueDIDResult = {
  wellKnownDid: {
    '@context': [...],
    id: 'did:web:example.com',
    verificationMethod: [...],
    // ... rest of structure
  },
  didKeyPairs: {
    controller: 'did:web:example.com',
    // ... rest of structure
  },
};

packages/w3c-vc/src/lib/verify/credentialStatus/index.ts (1)

69-75: Consider including detailed error in thrown exception.

The detailed error is logged but not included in the thrown Error, which may hinder debugging. Since this is a library function where detailed error information is valuable for developers, consider either:

1. Including detailedError in the thrown exception message, or
2. Adding a comment explaining why detailed errors are intentionally excluded (e.g., security/privacy concerns)

If detailed errors should be included, apply this diff:

-      throw new Error(errorMessage);
+      throw new Error(errorMessage + detailedError);

Or document the reason for exclusion:

       console.error(errorMessage + detailedError);
+      // Throw only basic message to avoid exposing sensitive verification details
       throw new Error(errorMessage);

apps/w3c-cli/README.md (1)

3-6: Clear deprecation warning, but consider adding migration guidance.

The deprecation banner effectively communicates:

• The package is no longer maintained
• The technical reason (legacy BBS+ vs modern cryptosuites)

However, users would benefit from guidance on:

• Which packages/tools to use instead
• How to migrate from legacy cryptosuites to modern ones (ECDSA-SD-2023, BBS-2023)
• Link to migration documentation or examples

Consider adding a migration section after the deprecation warning:

 > This CLI package has been deprecated and is no longer maintained. The CLI was built using legacy BBS+ cryptosuites that have been superseded by modern W3C Data Integrity cryptosuites (ECDSA-SD-2023, BBS-2023).
+> 
+> **Migration Path:**
+> - Use the [`@trustvc/w3c-vc`](https://github.com/TrustVC/w3c/tree/main/packages/w3c-vc) package directly for credential operations
+> - See the [W3C VC Data Model 2.0 migration guide](link-to-guide) for updating to modern cryptosuites

packages/w3c-issuer/src/did-web/keyPair/bbs2023.ts (1)

15-17: Consider a more descriptive error message.

The error message "Invalid seed" could be more specific to help developers understand that a seed is required for BBS-2023 key generation.

  if (!seed) {
-    throw new Error('Invalid seed');
+    throw new Error('Seed is required for BBS-2023 key pair generation');
  }

packages/w3c-vc/src/lib/__fixtures__/key-pairs.ts (1)

8-34: Consider documenting the origin of test fixtures.

The test fixtures are well-structured with appropriate fields for each cryptosuite. However, hardcoded cryptographic key material in test fixtures should ideally be documented with their generation method or source seed to ensure reproducibility and aid future maintenance.

Example documentation:

/**
 * BBS-2020 test key pair
 * Generated from seed: [seed value if applicable]
 */
export const bbs2020KeyPair: BBSPrivateKeyPair = {
  // ...
};

This is optional but improves maintainability for future developers.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a74ae32 and 2938a2a.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (64)

• .nxignore (1 hunks)
• apps/w3c-cli/README.md (1 hunks)
• apps/w3c-cli/package.json (2 hunks)
• apps/w3c-cli/project.json.deprecated (1 hunks)
• apps/w3c-cli/tests/main.test.ts (3 hunks)
• nx.json (1 hunks)
• package.json (0 hunks)
• packages/declaration.d.ts (1 hunks)
• packages/w3c-context/README.md (1 hunks)
• packages/w3c-context/package.json (2 hunks)
• packages/w3c-context/src/context/data-integrity-v2.json (1 hunks)
• packages/w3c-context/src/context/multikey-v1.json (1 hunks)
• packages/w3c-context/src/context/render-method-context-v2.json (1 hunks)
• packages/w3c-context/src/context/status-list-2021-v1.json (1 hunks)
• packages/w3c-context/src/lib/index.ts (5 hunks)
• packages/w3c-context/tsconfig.build.json (1 hunks)
• packages/w3c-context/tsconfig.json (1 hunks)
• packages/w3c-credential-status/README.md (11 hunks)
• packages/w3c-credential-status/package.json (2 hunks)
• packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.test.ts (2 hunks)
• packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.ts (3 hunks)
• packages/w3c-credential-status/src/lib/index.test.ts (3 hunks)
• packages/w3c-credential-status/src/lib/index.ts (5 hunks)
• packages/w3c-credential-status/src/lib/types.ts (2 hunks)
• packages/w3c-credential-status/src/lib/utils.test.ts (1 hunks)
• packages/w3c-credential-status/src/lib/utils.ts (4 hunks)
• packages/w3c-credential-status/tsconfig.json (1 hunks)
• packages/w3c-issuer/README.md (6 hunks)
• packages/w3c-issuer/package.json (2 hunks)
• packages/w3c-issuer/src/did-web/README.md (1 hunks)
• packages/w3c-issuer/src/did-web/index.ts (1 hunks)
• packages/w3c-issuer/src/did-web/keyPair/bbs2023.ts (1 hunks)
• packages/w3c-issuer/src/did-web/keyPair/ecdsaSd2023.ts (1 hunks)
• packages/w3c-issuer/src/did-web/keyPair/index.test.ts (3 hunks)
• packages/w3c-issuer/src/did-web/keyPair/index.ts (3 hunks)
• packages/w3c-issuer/src/did-web/keyPair/types.ts (1 hunks)
• packages/w3c-issuer/src/did-web/wellKnown/generate.test.ts (1 hunks)
• packages/w3c-issuer/src/did-web/wellKnown/generate.ts (3 hunks)
• packages/w3c-issuer/src/did-web/wellKnown/index.test.ts (3 hunks)
• packages/w3c-issuer/src/did-web/wellKnown/index.ts (3 hunks)
• packages/w3c-issuer/src/did-web/wellKnown/query.test.ts (3 hunks)
• packages/w3c-issuer/src/did-web/wellKnown/query.ts (2 hunks)
• packages/w3c-issuer/src/did-web/wellKnown/types.ts (3 hunks)
• packages/w3c-issuer/src/lib/types.ts (3 hunks)
• packages/w3c-issuer/tsconfig.build.json (1 hunks)
• packages/w3c-issuer/tsconfig.json (1 hunks)
• packages/w3c-vc/README.md (4 hunks)
• packages/w3c-vc/package.json (1 hunks)
• packages/w3c-vc/src/index.ts (2 hunks)
• packages/w3c-vc/src/lib/__fixtures__/bbs2020-credentials.ts (1 hunks)
• packages/w3c-vc/src/lib/__fixtures__/key-pairs.ts (1 hunks)
• packages/w3c-vc/src/lib/__fixtures__/modern-credentials.ts (1 hunks)
• packages/w3c-vc/src/lib/__fixtures__/test-scenarios.ts (1 hunks)
• packages/w3c-vc/src/lib/helper/index.ts (12 hunks)
• packages/w3c-vc/src/lib/sign/credentialStatus/index.ts (0 hunks)
• packages/w3c-vc/src/lib/types.ts (3 hunks)
• packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts (7 hunks)
• packages/w3c-vc/src/lib/verify/credentialStatus/index.ts (2 hunks)
• packages/w3c-vc/src/lib/w3c-vc.test.ts (1 hunks)
• packages/w3c-vc/src/lib/w3c-vc.ts (8 hunks)
• packages/w3c-vc/tsconfig.build.json (1 hunks)
• packages/w3c-vc/tsconfig.json (1 hunks)
• packages/w3c/package.json (2 hunks)
• packages/w3c/tsconfig.json (1 hunks)

💤 Files with no reviewable changes (2)

• package.json
• packages/w3c-vc/src/lib/sign/credentialStatus/index.ts

🧰 Additional context used

🧬 Code graph analysis (28)

packages/w3c-issuer/src/did-web/keyPair/ecdsaSd2023.ts (1)

packages/w3c-issuer/src/did-web/keyPair/types.ts (1)

• DidWebGeneratedKeyPair (12-24)

packages/w3c-vc/src/lib/verify/credentialStatus/index.ts (1)

packages/w3c-vc/src/lib/w3c-vc.ts (2)

• verifyCredential (354-456)
• deriveCredential (465-563)

packages/w3c-vc/src/lib/__fixtures__/modern-credentials.ts (1)

packages/w3c-vc/src/lib/types.ts (1)

• VerifiableCredential (69-69)

packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.test.ts (1)

packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.ts (2)

• _checkCredentialSubjectForStatusList2021Credential (127-135)
• _checkCredentialSubjectForBitstringStatusListCredential (142-150)

packages/w3c-issuer/src/did-web/wellKnown/query.test.ts (1)

packages/w3c-issuer/src/did-web/wellKnown/query.ts (3)

• resolve (59-72)
• resolveRepresentation (82-121)
• dereference (131-192)

packages/w3c-vc/src/lib/__fixtures__/test-scenarios.ts (5)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (3)

• BBSPrivateKeyPair (65-68)
• EcdsaSd2023PrivateKeyPair (79-81)
• Bbs2023PrivateKeyPair (75-78)

packages/w3c-vc/src/lib/types.ts (2)

• SignedVerifiableCredential (71-90)
• VerifiableCredential (69-69)

packages/w3c-vc/src/lib/__fixtures__/key-pairs.ts (3)

• bbs2020KeyPair (8-15)
• ecdsa2023KeyPair (17-24)
• bbs2023KeyPair (26-34)

packages/w3c-vc/src/lib/__fixtures__/bbs2020-credentials.ts (4)

• bbs2020CredentialV1_1 (3-68)
• bbs2020DerivedCredentialV1_1 (70-150)
• bbs2020CredentialV2_0 (152-216)
• bbs2020DerivedCredentialV2_0 (218-296)

packages/w3c-vc/src/lib/__fixtures__/modern-credentials.ts (2)

• modernCredentialV1_1 (4-64)
• modernCredentialV2_0 (67-126)

packages/w3c-credential-status/src/lib/types.ts (1)

packages/w3c-vc/src/lib/types.ts (1)

• CryptoSuiteName (94-94)

packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.ts (1)

packages/w3c-credential-status/src/lib/types.ts (1)

• VCBitstringCredentialSubject (7-12)

packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts (2)

packages/w3c-vc/src/lib/types.ts (1)

• SignedVerifiableCredential (71-90)

packages/w3c-credential-status/src/lib/types.ts (2)

• CredentialStatusType (19-19)
• CredentialStatusPurpose (20-20)

packages/w3c-credential-status/src/lib/utils.test.ts (1)

packages/w3c-credential-status/src/lib/utils.ts (1)

• fetchCredentialStatusVC (172-191)

packages/w3c-vc/src/lib/w3c-vc.test.ts (2)

packages/w3c-vc/src/lib/__fixtures__/test-scenarios.ts (2)

• bbs2020TestScenarios (34-49)
• modernCryptosuiteTestScenarios (52-85)

packages/w3c-vc/src/lib/w3c-vc.ts (3)

• signCredential (253-345)
• deriveCredential (465-563)
• verifyCredential (354-456)

packages/w3c-issuer/src/did-web/wellKnown/generate.test.ts (2)

packages/w3c-issuer/src/did-web/wellKnown/generate.ts (1)

• generateWellKnownDid (21-126)

packages/w3c-issuer/src/lib/types.ts (1)

• VerificationContext (21-33)

packages/w3c-issuer/src/did-web/keyPair/bbs2023.ts (1)

packages/w3c-issuer/src/did-web/keyPair/types.ts (2)

• DidWebGenerateKeyPairOptions (3-10)
• DidWebGeneratedKeyPair (12-24)

packages/w3c-vc/src/lib/__fixtures__/key-pairs.ts (1)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (3)

• BBSPrivateKeyPair (65-68)
• EcdsaSd2023PrivateKeyPair (79-81)
• Bbs2023PrivateKeyPair (75-78)

packages/w3c-issuer/src/did-web/keyPair/index.ts (4)

packages/w3c-issuer/src/lib/types.ts (2)

• GenerateKeyPairOptions (39-39)
• GeneratedKeyPair (41-41)

packages/w3c-issuer/src/did-web/keyPair/bbs2023.ts (1)

• generateBbs2023KeyPair (12-39)

packages/w3c-issuer/src/did-web/keyPair/ecdsaSd2023.ts (1)

• generateEcdsaSd2023KeyPair (12-31)

packages/w3c-issuer/src/did-web/keyPair/bls12381.ts (1)

• generateBls12381KeyPair (12-34)

packages/w3c-credential-status/src/lib/utils.ts (1)

packages/w3c-credential-status/src/lib/types.ts (1)

• BitstringStatusListCredentialStatus (27-31)

packages/w3c-issuer/src/did-web/wellKnown/index.test.ts (3)

packages/w3c-vc/src/lib/__fixtures__/key-pairs.ts (1)

• bbs2023KeyPair (26-34)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (3)

• IssuedDID (97-100)
• Bbs2023PrivateKeyPair (75-78)
• EcdsaSd2023PrivateKeyPair (79-81)

packages/w3c-issuer/src/did-web/wellKnown/index.ts (1)

• issueDID (24-69)

packages/w3c-issuer/src/did-web/wellKnown/generate.ts (1)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (3)

• ECDSAKeyPair (42-49)
• Bbs2023KeyPair (57-57)
• EcdsaSd2023KeyPair (58-58)

packages/w3c-vc/src/lib/types.ts (1)

packages/w3c-credential-status/src/lib/types.ts (1)

• CryptoSuiteName (64-64)

packages/w3c-issuer/src/did-web/wellKnown/index.ts (2)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (1)

• PrivateKeyPair (60-64)

packages/w3c-issuer/src/lib/types.ts (1)

• VerificationContext (21-33)

packages/w3c-credential-status/src/lib/index.test.ts (2)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (3)

• BBSPrivateKeyPair (65-68)
• EcdsaSd2023PrivateKeyPair (79-81)
• Bbs2023PrivateKeyPair (75-78)

packages/w3c-credential-status/src/lib/index.ts (1)

• createCredentialStatusPayload (44-106)

packages/w3c-vc/src/lib/__fixtures__/bbs2020-credentials.ts (1)

packages/w3c-vc/src/lib/types.ts (1)

• SignedVerifiableCredential (71-90)

packages/w3c-issuer/src/did-web/keyPair/index.test.ts (1)

packages/w3c-issuer/src/did-web/keyPair/index.ts (1)

• generateKeyPair (49-103)

packages/w3c-context/src/lib/index.ts (1)

packages/w3c-context/src/lib/types.ts (2)

• Document (8-8)
• DocumentLoaderObject (10-14)

packages/w3c-issuer/src/did-web/wellKnown/query.ts (1)

packages/w3c-issuer/src/did-web/index.ts (3)

• resolve (7-7)
• resolveRepresentation (7-7)
• dereference (7-7)

packages/w3c-vc/src/lib/helper/index.ts (5)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (3)

• BBSPrivateKeyPair (65-68)
• Bbs2023PrivateKeyPair (75-78)
• EcdsaSd2023PrivateKeyPair (79-81)

packages/w3c-vc/src/lib/types.ts (3)

• VerifiableCredential (69-69)
• CredentialSchema (27-30)
• RawVerifiableCredential (92-92)

packages/w3c-context/src/lib/index.ts (1)

• CredentialContextVersion (90-93)

packages/w3c-credential-status/src/lib/utils.ts (1)

• assertBitstringStatusListEntry (140-140)

packages/w3c-credential-status/src/lib/types.ts (1)

• BitstringStatusListCredentialStatus (27-31)

packages/w3c-credential-status/src/lib/index.ts (5)

packages/w3c-credential-status/src/lib/types.ts (4)

• CreateVCCredentialStatusOptions (14-17)
• CryptoSuiteName (64-64)
• RawCredentialStatusVC (43-52)
• GeneralCredentialStatus (22-25)

packages/w3c-issuer/src/did-web/wellKnown/types.ts (1)

• PrivateKeyPair (60-64)

packages/w3c-credential-status/src/lib/BitstringStatusList/types.ts (1)

• VCCredentialStatusType (16-16)

packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.ts (2)

• _checkCredentialSubjectForStatusList2021Credential (127-135)
• _checkCredentialSubjectForBitstringStatusListCredential (142-150)

packages/w3c-context/src/lib/index.ts (2)

• CredentialContextVersion (90-93)
• DATA_INTEGRITY_V2_URL (26-26)

packages/w3c-vc/src/lib/w3c-vc.ts (4)

packages/w3c-vc/src/index.ts (11)

• isRawDocumentV1_1 (33-33)
• isRawDocument (28-28)
• isRawDocumentV2_0 (34-34)
• isSignedDocumentV1_1 (35-35)
• isSignedDocument (29-29)
• isSignedDocumentV2_0 (36-36)
• isDerived (37-37)
• signCredential (30-30)
• DocumentLoader (20-20)
• getDocumentLoader (27-27)
• deriveCredential (26-26)

packages/w3c-vc/src/lib/types.ts (5)

• RawVerifiableCredential (92-92)
• SignedVerifiableCredential (71-90)
• CryptoSuiteName (94-94)
• SigningResult (5-8)
• ProofType (96-96)

packages/w3c-vc/src/lib/helper/index.ts (4)

• getFirstContext (134-137)
• _checkKeyPair (38-63)
• _checkCredential (167-336)
• prefilCredentialId (543-571)

packages/w3c-context/src/lib/index.ts (2)

• CredentialContextVersion (90-93)
• getDocumentLoader (103-193)

🪛 GitHub Actions: CI

packages/w3c-credential-status/src/lib/utils.ts

[error] 52-52: Multiple exports with the same name "assertCredentialStatusStatusListType". The symbol has already been declared.

packages/w3c-credential-status/src/lib/index.test.ts

[error] 1-1: Test suite failed: 2 failed tests in total (vitest transform error due to duplicate export in utils.ts).

🪛 Gitleaks (8.28.0)

packages/w3c-issuer/src/did-web/wellKnown/index.test.ts

[high] 41-41: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

🔇 Additional comments (42)

apps/w3c-cli/tests/main.test.ts (2)

265-416: Comprehensive test coverage for the DID command.

The test suite properly covers:

• Successful DID generation with the new structured response
• Early exit when DID already exists (line 363)
• Error handling when issueDID fails (line 391)

All test scenarios correctly handle the updated API structure.

---

294-325: Mock structure correctly reflects issueDID API.

The mock accurately represents the IssuedDID type with wellKnownDid and didKeyPairs properties. The implementation in packages/w3c-issuer/src/did-web/wellKnown/index.ts returns this exact structure. The Bls12381G2Key2020 verification type used in the mock is one of the supported legacy key types, and the enum usage improves type safety over string literals.

packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts (2)

3-3: LGTM! Good addition of cleanup hook.

Adding afterEach with vi.restoreAllMocks() ensures mocks are properly cleaned up between tests, preventing test pollution.

Also applies to: 79-81

---

9-9: LGTM! Clear fixture naming for multi-version testing.

Renaming to credentialStatusVC_BBS_V1 and adding credentialStatus2 with BitstringStatusListEntry improves clarity and supports testing both credential status types.

Also applies to: 71-77

.nxignore (1)

1-1: LGTM! Consistent with CLI deprecation strategy.

Excluding apps/w3c-cli from Nx processing aligns with the deprecation notices added elsewhere in the PR.

packages/w3c-context/package.json (2)

3-3: Alpha pre-release version appropriately reflects major changes.

The version bump to 1.3.0-alpha.12 correctly signals pre-release status for the significant updates in this PR (W3C VC Data Model 2.0, modern cryptosuites).

---

37-37: Compatibility verified—upgrade to jsonld-signatures v11.5.0 is safe.

All APIs used in the codebase are stable in v11: sign(), verify(), derive(), and extendContextLoader() all exist and work as expected. No deprecated parameters (compactProof, owner, creator, PublicKeyProofPurpose) are present, and suite constructors use compatible patterns (new DataIntegrityProof({ signer?, cryptosuite })). The codebase intentionally maintains v7 alongside v11 for backward compatibility with older BBS+ suites while using v11 for modern proofs—a sound approach. The upgrade is compatible with the current usage patterns.

packages/w3c-credential-status/tsconfig.json (1)

5-5: LGTM! Standard ambient declarations pattern.

Including ../declaration.d.ts provides TypeScript with ambient type definitions for untyped modules. This aligns with similar changes across other packages in the monorepo.

nx.json (1)

53-53: LGTM! Removal of deprecated CLI from release projects.

Removing @trustvc/w3c-cli from the release projects array is appropriate given the package deprecation documented throughout this PR.

apps/w3c-cli/project.json.deprecated (1)

1-4: LGTM! Clear deprecation documentation.

The header comments effectively communicate:

• The deprecation status
• Why the file was renamed (to exclude from NX builds)
• The technical reason for deprecation (incompatibility with modern cryptosuites)

This approach preserves the configuration for reference while excluding it from active builds.

packages/w3c-issuer/package.json (2)

3-3: LGTM! Alpha version reflects significant cryptosuite additions.

The version bump to 1.3.0-alpha.10 appropriately signals the addition of modern cryptosuite support (BBS-2023, ECDSA-SD-2023) as a pre-release.

---

32-33: LGTM! Multikey dependencies support modern W3C cryptosuites.

Adding Digital Bazaar's multikey packages enables support for:

• BLS12-381 multikey for BBS-2023
• ECDSA multikey for ECDSA-SD-2023

These align perfectly with the PR objectives for W3C VC Data Model 2.0 compliance.

packages/w3c-context/README.md (1)

1-177: LGTM! Excellent documentation improvements.

The comprehensive rewrite significantly improves developer experience by providing:

• Clear feature overview and installation instructions
• Practical usage examples for common scenarios
• Complete list of cached context URLs
• Modern cryptosuite guidance (BBS-2023, ECDSA-SD-2023)
• API reference and constants

This documentation effectively supports the W3C VC Data Model 2.0 migration.

apps/w3c-cli/README.md (1)

9-9: LGTM! "Legacy Documentation" label appropriately frames preserved content.

The section header clearly signals that the following documentation is for legacy reference only, which is helpful for existing users while discouraging new adoption.

packages/w3c-issuer/tsconfig.build.json (1)

10-10: LGTM — Ambient declarations included consistently with other packages.

This follows the same pattern as packages/w3c-context and packages/w3c-vc, incorporating the parent-level declaration.d.ts file during build.

packages/w3c-vc/tsconfig.json (1)

6-6: LGTM — Development TypeScript config properly includes ambient declarations.

Including ../declaration.d.ts in the dev tsconfig.json enables IDE and type-checking support for ambient module declarations during development.

packages/w3c-context/tsconfig.json (1)

6-6: LGTM — Development config includes ambient declarations alongside source files.

This mirrors the pattern in packages/w3c-vc/tsconfig.json and ensures TypeScript in the dev environment can resolve ambient module declarations.

packages/w3c-credential-status/package.json (2)

3-3: Version bump to 1.3.0-alpha.13 is appropriate for alpha release cycle.

The version increment follows the pattern of bumping to 1.3.0-alpha.N for the coordinated alpha release, distinct from the deprecated CLI package (1.3.0-alpha.12).

---

32-33: Dependency versions verified on NPM.

Both @trustvc/w3c-context@1.3.0-alpha.12 and @trustvc/w3c-issuer@1.3.0-alpha.10 are published on NPM. The caret constraints (^1.3.0-alpha.12 and ^1.3.0-alpha.10) will resolve to these versions as specified and will not inadvertently pull incompatible pre-release versions from the registry.

packages/w3c-vc/tsconfig.build.json (1)

11-11: The change is valid and follows the established monorepo pattern.

Verification confirms that packages/declaration.d.ts exists, contains valid TypeScript ambient module declarations, and the relative path correctly resolves from packages/w3c-vc/. The pattern is consistent with other packages in the monorepo (w3c-issuer, w3c-context) that also include this declaration file. No conflicts, duplicates, or circular dependencies exist.

apps/w3c-cli/package.json (1)

3-5: No issues found; alpha versions verified and deprecation messaging confirmed.

All four alpha version dependencies exist on NPM and are correctly referenced in the package.json:

• @trustvc/w3c-context@1.3.0-alpha.11 ✓
• @trustvc/w3c-credential-status@1.3.0-alpha.11 ✓
• @trustvc/w3c-vc@1.3.0-alpha.12 ✓
• @trustvc/w3c-issuer@1.3.0-alpha.9 ✓

Deprecation is explicitly communicated through both the description and deprecated fields with clear reasoning. The version transition to 1.3.0-alpha.12 is appropriate for a pre-release deprecated package.

packages/w3c-context/tsconfig.build.json (1)

11-15: I can see the JSON context files definitely exist. Let me verify the declaration.d.ts file and check the build output handling:

Now let me verify the build process and check if there's a mechanism to copy JSON files to dist:

Now let me check the build script and verify the actual build configuration:

Verify JSON context files are properly bundled in dist output—tsconfig include alone is insufficient.

The TypeScript compiler doesn't automatically copy JSON files to output; even with src/**/*.json in include and resolveJsonModule enabled, JSON files require a separate build step. The 19 JSON context files in src/context/ (including render-method-context-v2.json) must be explicitly copied or bundled as part of the build process. Verify that your build script includes a task to copy JSON context files to the dist directory, or confirm that your build tool (webpack, tsc, etc.) is configured to emit them.

packages/w3c-context/src/context/render-method-context-v2.json (1)

1-13: All verification checks passed.

The render-method-context-v2.json context is correctly integrated:

• Imported and exported in packages/w3c-context/src/lib/index.ts (lines 20, 38)
• Registered in the renderContextsV2 object (lines 69-71)
• Merged into the document loader (line 113)
• Used in test fixtures (packages/w3c-vc/src/lib/fixtures/modern-credentials.ts)

packages/w3c-vc/src/lib/w3c-vc.test.ts (1)

122-316: Great end-to-end coverage for modern suites

Appreciate the scenario-driven tests that exercise signing, derivation, mandatory pointer handling, repeated derivation guards, and tamper detection across both ECDSA-SD-2023 and BBS-2023. This gives strong regression coverage for the new cryptosuite paths.

packages/w3c-issuer/src/did-web/keyPair/index.test.ts (1)

121-197: Excellent test coverage for modern cryptosuites!

The test suites for BBS-2023 and ECDSA-SD-2023 are comprehensive and well-structured. They properly validate:

• Multikey type assignment
• Multibase encoding formats (zUC prefix for BBS public keys, zDn for ECDSA-SD)
• Seed handling and deterministic behavior for BBS-2023
• Non-deterministic key generation for ECDSA-SD-2023

packages/w3c/package.json (1)

3-38: LGTM! Coordinated alpha release.

The version bumps across all @TrustVC packages are consistent and properly aligned for the alpha release featuring W3C VC Data Model 2.0 and modern cryptosuite support.

packages/w3c-issuer/src/did-web/wellKnown/generate.ts (1)

42-45: LGTM! Multikey support properly integrated.

The Multikey verification method handling follows the established pattern for other key types. The duplicate key check using publicKeyMultibase and the conditional property assignment are correctly implemented.

Also applies to: 97-103

packages/w3c-issuer/src/lib/types.ts (1)

3-6: LGTM! Type definitions are well-structured.

The new CryptoSuite enum, Multikey verification type, and associated context mapping are correctly defined. The union type for BaseKeyPair.type elegantly supports both legacy and modern cryptosuites, and the GeneratedKeyPair type appropriately combines required and optional fields.

Also applies to: 18-18, 32-32, 36-36, 41-41

packages/w3c-issuer/src/did-web/keyPair/bbs2023.ts (1)

20-38: LGTM! BBS-2023 key generation correctly implemented.

The implementation properly uses the W3C standard algorithm BBS-BLS12-381-SHA-256 and correctly handles multibase encoding. The .slice(1) operation on Line 33 appropriately removes the multibase prefix for the base58 representation.

packages/w3c-issuer/src/did-web/wellKnown/generate.test.ts (1)

221-421: Excellent comprehensive test coverage!

The test suites for BBS-2023, ECDSA-SD-2023, and mixed cryptosuites are thorough and well-structured. They properly validate:

• Verification method structure and properties
• Context inclusion for modern cryptosuites
• Duplicate key detection using publicKeyMultibase
• Coexistence of legacy and modern key types

The mixed cryptosuites test is particularly valuable for ensuring backward compatibility.

packages/w3c-issuer/src/did-web/keyPair/types.ts (1)

8-9: LGTM! Type extensions for Multikey support.

The addition of secretKeyMultibase and publicKeyMultibase fields consistently extends both the options and generated key pair types to support modern Multikey-based cryptosuites.

Also applies to: 14-19

packages/w3c-vc/src/lib/__fixtures__/modern-credentials.ts (1)

1-126: LGTM! Well-structured test fixtures.

The fixtures correctly represent the differences between W3C VC Data Model v1.1 and v2.0, with appropriate context URLs and date field naming (expirationDate vs validUntil). The reuse of identical credentialSubject data across both versions enables consistent testing.

packages/w3c-issuer/src/did-web/wellKnown/index.ts (1)

47-58: LGTM! Proper Multikey handling for modern cryptosuites.

The conditional logic correctly constructs Multikey-based key pairs with appropriate fields (secretKeyMultibase, publicKeyMultibase) and conditionally includes seedBase58 only for BBS-2023. The context is properly set for Multikey verification methods.

packages/w3c-issuer/src/did-web/wellKnown/types.ts (1)

35-81: LGTM! Clean type definitions for Multikey support.

The type definitions properly extend the key pair hierarchy to support modern cryptosuites with Multikey verification methods, while maintaining backward compatibility with legacy BLS and ECDSA key pairs.

packages/w3c-issuer/src/did-web/wellKnown/query.test.ts (1)

80-223: LGTM! Comprehensive test coverage for W3C DID resolution functions.

The tests properly cover happy paths and error scenarios for resolve, resolveRepresentation, and dereference functions, including content-type negotiation, fragment dereferencing, and error handling for unsupported formats and invalid DIDs.

packages/w3c-vc/src/lib/__fixtures__/test-scenarios.ts (1)

1-85: LGTM! Well-organized parameterized test scenarios.

The test scenario interfaces and data arrays provide clean separation between legacy BBS2020 and modern cryptosuites (ECDSA-SD-2023, BBS-2023), enabling comprehensive parameterized testing across different VC versions.

packages/w3c-vc/src/lib/__fixtures__/bbs2020-credentials.ts (1)

1-296: LGTM! Complete BBS2020 credential fixtures.

The fixtures provide comprehensive test data for both standard and derived BBS2020 credentials across v1.1 and v2.0, including proper proof structures, context URLs, and date field conventions for each version.

packages/w3c-issuer/src/did-web/wellKnown/index.test.ts (2)

39-44: Static analysis false positive: test fixture, not a real secret.

The secretKeyMultibase value on line 41 is a test fixture key used for deterministic testing, not a production secret. This can be safely ignored.

---

194-362: LGTM! Comprehensive test coverage for modern cryptosuites.

The test suite properly validates BBS-2023 and ECDSA-SD-2023 key generation, including:

• Multikey verification method structure
• Proper context inclusion
• Seed-based vs. random key generation
• Mixed cryptosuite DID handling

packages/w3c-credential-status/src/lib/index.test.ts (1)

20-37: I need to search the test file for mock declarations and how createCredentialStatusPayload is being used. Let me check for mocking patterns and the function calls themselves.

Based on my verification, I need to provide a final response. Let me check what we've learned:

From the npm documentation, createCredentialStatusPayload function helps create a signed credential status Verifiable Credential (VC), taking a key pair for signing and returning a signed credential. This means the function performs actual cryptographic signing operations.

The rg output showed that the key pairs are passed directly to function calls at lines 73, 108, and 144 in the test file. However, I haven't been able to confirm through my searches whether the test is mocked or if it's actually performing signing operations. Without access to mock declarations in the test file (which would require code inspection), I cannot definitively determine if the placeholder secret keys will cause failures.

The review comment raises a valid concern about placeholder cryptographic key material potentially breaking signing operations, but verification requires examining the complete test file context to determine if cryptographic functions are mocked.

packages/w3c-context/src/lib/index.ts (1)

49-71: Nice registry expansion.

The additional contexts (Data Integrity v2, Multikey v1, render v2, Status List 2021) are wired cleanly into the loader, broadening coverage without breaking existing callers.

packages/w3c-vc/src/lib/helper/index.ts (1)

134-155: Good use of a shared context helper.

Exporting getFirstContext centralizes context normalization and avoids repeated JSON-LD plumbing in downstream modules.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify dependency version alignment across the monorepo.

The CLI depends on four TrustVC packages at specific alpha versions. Ensure these versions:

1. Are consistent with versions specified in other packages (e.g., w3c-credential-status, w3c-vc)
2. Don't have conflicting peerDependencies or transitive dependencies
3. Are appropriately pinned for a deprecated package

---

🏁 Script executed:

#!/bin/bash
# Description: Check dependency version consistency across packages

echo "Comparing version constraints in package.json files:"
echo -e "\n--- apps/w3c-cli/package.json ---"
rg '@trustvc/(w3c-context|w3c-credential-status|w3c-vc|w3c-issuer)' apps/w3c-cli/package.json

echo -e "\n--- packages/w3c-credential-status/package.json ---"
rg '@trustvc/(w3c-context|w3c-issuer)' packages/w3c-credential-status/package.json

echo -e "\n--- packages/w3c-vc/package.json (if present) ---"
rg '@trustvc/(w3c-context|w3c-credential-status|w3c-issuer)' packages/w3c-vc/package.json 2>/dev/null || echo "File not provided in review"

Length of output: 578

---

Address critical version misalignments across monorepo packages.

The CLI's dependencies diverge significantly from other packages:

• @trustvc/w3c-context: CLI pins ^1.3.0-alpha.11, but w3c-credential-status requires ^1.3.0-alpha.12
• @trustvc/w3c-issuer: CLI pins ^1.3.0-alpha.9, while both w3c-credential-status and w3c-vc require ^1.3.0-alpha.10
• @trustvc/w3c-credential-status: CLI pins ^1.3.0-alpha.11, but w3c-vc requires ^1.3.0-alpha.13

These version mismatches will result in multiple package versions being installed, potentially causing runtime incompatibilities and transitive dependency conflicts. Update all four dependencies in apps/w3c-cli/package.json to align with the highest versions specified across the monorepo, or use exact pinning (~ or exact versions) if these are pre-release dependencies with strict compatibility requirements.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

🧩 Analysis chain

Verify example.org URIs align with W3C VC Data Model 2.0 specification.

The @id values use https://example.org/terms# URIs. Confirm these are appropriate placeholder URIs or if they should reference official W3C vocabulary terms. If these are production values, they should be properly documented or standardized.

---

🌐 Web query:

What are the standard W3C vocabulary terms for render methods and template names in VC Data Model 2.0?

💡 Result:

Short answer

• The VC Data Model v2.0 reserves the renderMethod property (vocabulary: https://www.w3.org/2018/credentials#renderMethod). (w3.org)

• The W3C "Verifiable Credential Rendering Methods" spec defines the TemplateRenderMethod type and its standard fields: id, type (must be "TemplateRenderMethod"), renderSuite, name, description, and renderProperty. (i.e., these are the standard vocabulary terms to express template-based render methods). (w3.org)

Notes

• Implementations sometimes add non‑standard fields such as templateName or template content (seen in several ecosystems), but the normative field names for template-based render methods in the W3C spec are the ones listed above. (w3.org)

Citations:

• 1: https://www.w3.org/TR/2023/WD-vc-data-model-2.0-20230611/?utm_source=openai
• 2: https://www.w3.org/TR/vc-render-method/?utm_source=openai
• 3: https://www.w3.org/TR/vc-render-method/?utm_source=openai

---

Now let me examine the codebase context to better understand the file purpose and scope:

---

🏁 Script executed:

```shell
#!/bin/bash
# Check file context and purpose
cat packages/w3c-context/src/context/render-method-context-v2.json

Length of output: 301

---

🏁 Script executed:

#!/bin/bash
# Search for other uses of example.org in the project
rg -n "example\.org" --type=json packages/

Length of output: 1491

---

🏁 Script executed:

#!/bin/bash
# Search for templateName usage in the codebase
rg -n "templateName" --type=json --type=ts --type=js packages/

Length of output: 946

---

---

🏁 Script executed:

#!/bin/bash
# Check for README or documentation explaining the context files
find packages/w3c-context -name "README*" -o -name "*.md" | head -20
cat packages/w3c-context/README.md 2>/dev/null || echo "No README found"

Length of output: 5338

---

🏁 Script executed:

#!/bin/bash
# Check package.json for context about w3c-context package
cat packages/w3c-context/package.json | head -30

Length of output: 688

---

Update templateName field to align with W3C Verifiable Credential Rendering Methods specification.

The render-method-context-v2.json file defines a custom TrustVC context with example.org placeholder URIs, which is appropriate for this business-specific context. However, the W3C Verifiable Credential Rendering Methods spec defines standard field names including "name" for template-based render methods, whereas this context uses the non-standard templateName field. This creates inconsistency with the W3C specification. Update the field from templateName to name to align with normative W3C terms.

🤖 Prompt for AI Agents

In packages/w3c-context/src/context/render-method-context-v2.json around lines 7
to 9, the context defines "templateName" as a custom term which diverges from
the W3C Verifiable Credential Rendering Methods spec; replace the "templateName"
mapping with "name" (i.e., change the context key from "templateName" to "name"
while keeping its URI value) so the field aligns with the normative W3C term for
template-based render methods.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Add explicit @version: 1.1 wherever @protected is used

The canonical StatusList2021 context declares @version: 1.1 at the top level and in each scoped sub-context. Without it, processors that default to JSON-LD 1.0 (including older stacks we still ship via jsonld-signatures-v7) will throw because @protected is a 1.1-only keyword. Please mirror the official context and add @version: 1.1 to the root and nested contexts to avoid interoperability breaks.

 {
   "@context": {
+    "@version": 1.1,
     "@protected": true,
     "StatusList2021Credential": {
       "@id": "https://w3id.org/vc/status-list#StatusList2021Credential",
       "@context": {
+        "@version": 1.1,
         "@protected": true,
         "id": "@id",
         "type": "@type",
         "description": "http://schema.org/description",
         "name": "http://schema.org/name"
       }
     },
     "StatusList2021": {
       "@id": "https://w3id.org/vc/status-list#StatusList2021",
       "@context": {
+        "@version": 1.1,
         "@protected": true,
         "id": "@id",
         "type": "@type",
         "statusPurpose": "https://w3id.org/vc/status-list#statusPurpose",
         "encodedList": "https://w3id.org/vc/status-list#encodedList"
       }
     },
     "StatusList2021Entry": {
       "@id": "https://w3id.org/vc/status-list#StatusList2021Entry",
       "@context": {
+        "@version": 1.1,
         "@protected": true,
         "id": "@id",
         "type": "@type",
         "statusPurpose": "https://w3id.org/vc/status-list#statusPurpose",
         "statusListIndex": "https://w3id.org/vc/status-list#statusListIndex",
         "statusListCredential": {
           "@id": "https://w3id.org/vc/status-list#statusListCredential",
           "@type": "@id"
         }
       }
     }
   }
 }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	"@context": {
	"@protected": true,
	"StatusList2021Credential": {
	"@id": "https://w3id.org/vc/status-list#StatusList2021Credential",
	"@context": {
	"@protected": true,
	"id": "@id",
	"type": "@type",
	"description": "http://schema.org/description",
	"name": "http://schema.org/name"
	}
	},
	"StatusList2021": {
	"@id": "https://w3id.org/vc/status-list#StatusList2021",
	"@context": {
	"@protected": true,
	"id": "@id",
	"type": "@type",
	"statusPurpose": "https://w3id.org/vc/status-list#statusPurpose",
	"encodedList": "https://w3id.org/vc/status-list#encodedList"
	}
	},
	"StatusList2021Entry": {
	"@id": "https://w3id.org/vc/status-list#StatusList2021Entry",
	"@context": {
	"@protected": true,
	"id": "@id",
	"type": "@type",
	"statusPurpose": "https://w3id.org/vc/status-list#statusPurpose",
	"statusListIndex": "https://w3id.org/vc/status-list#statusListIndex",
	"statusListCredential": {
	"@id": "https://w3id.org/vc/status-list#statusListCredential",
	"@type": "@id"
	}
	}
	}
	"@context": {
	"@version": 1.1,
	"@protected": true,
	"StatusList2021Credential": {
	"@id": "https://w3id.org/vc/status-list#StatusList2021Credential",
	"@context": {
	"@version": 1.1,
	"@protected": true,
	"id": "@id",
	"type": "@type",
	"description": "http://schema.org/description",
	"name": "http://schema.org/name"
	}
	},
	"StatusList2021": {
	"@id": "https://w3id.org/vc/status-list#StatusList2021",
	"@context": {
	"@version": 1.1,
	"@protected": true,
	"id": "@id",
	"type": "@type",
	"statusPurpose": "https://w3id.org/vc/status-list#statusPurpose",
	"encodedList": "https://w3id.org/vc/status-list#encodedList"
	}
	},
	"StatusList2021Entry": {
	"@id": "https://w3id.org/vc/status-list#StatusList2021Entry",
	"@context": {
	"@version": 1.1,
	"@protected": true,
	"id": "@id",
	"type": "@type",
	"statusPurpose": "https://w3id.org/vc/status-list#statusPurpose",
	"statusListIndex": "https://w3id.org/vc/status-list#statusListIndex",
	"statusListCredential": {
	"@id": "https://w3id.org/vc/status-list#statusListCredential",
	"@type": "@id"
	}
	}
	}

🤖 Prompt for AI Agents

In packages/w3c-context/src/context/status-list-2021-v1.json around lines 2 to
37, the JSON-LD contexts use the JSON-LD 1.1-only keyword "@protected" but do
not declare "@version": "1.1"; add "@version": "1.1" at the root "@context"
object and inside each nested "@context" (for StatusList2021Credential,
StatusList2021, and StatusList2021Entry) so each context explicitly declares
JSON-LD 1.1, matching the canonical StatusList2021 context and preventing
processors from treating the document as JSON-LD 1.0.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Inconsistency in CredentialStatusPurpose type definition.

The type definition at line 471 includes 'message' as a valid purpose:

type CredentialStatusPurpose = 'revocation' | 'suspension' | 'message';

However, the usage example at line 114 only documents 'revocation' and 'suspension'. Clarify whether 'message' is a valid purpose value and, if so, provide a usage example or explain its semantics.

Also applies to: 471-472

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Clarify the deprecation example—is it demonstrating expected error or runnable code?

The v1.1 example at line 217 uses 'BbsBlsSignature2020' with an inline comment stating it "will result in error." However, the surrounding code context suggests this is meant as an executable example. The comment is misleading—either remove this example entirely (since it won't run), or clarify that this shows what not to do and should not be executed.

Suggested fix:

-const credentialStatusVCV1 = await createCredentialStatusPayload(
-  optionsV1, 
-  keyPair, 
-  'StatusList2021Credential', // v1.1 credential type
-  'BbsBlsSignature2020' // ⚠️ DEPRECATED - this will result in error. Use modern cryptosuites
-);
+// ⚠️ WARNING: BbsBlsSignature2020 is deprecated. Use modern cryptosuites instead.
+// Do not use this code in production:
+// const credentialStatusVCV1 = await createCredentialStatusPayload(
+//   optionsV1, 
+//   keyPair, 
+//   'StatusList2021Credential', // v1.1 credential type
+//   'BbsBlsSignature2020' // DEPRECATED
+// );

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In packages/w3c-credential-status/README.md around lines 217 to 218, the example
lists 'BbsBlsSignature2020' with a comment saying it "will result in error"
while the surrounding code appears runnable; either remove the deprecated
algorithm from the runnable example or explicitly mark this snippet as a
not-to-be-executed "do not use" example and replace the runnable example with a
supported modern cryptosuite (or show both: a commented-out deprecated example
labeled "illustrative — do not run" and a working example using a modern suite).
Ensure the README text clearly states the deprecated example is intentionally
non-runnable and provide the corrected working example or removal accordingly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Return notFound when a fragment can’t be resolved

If a caller dereferences did:web:example.com#missing, we currently fall through and return the entire DID document. That silently masks the failure and violates the DID Core dereferencing contract, which requires error: notFound when the fragment target does not exist. Downstream clients will misinterpret the response as a successful dereference. Please fail fast instead of returning the full document.

-    dereferencingMetadata.contentType = accept ?? dereferencingMetadata.contentType;
-
-    if (did.includes('#')) {
-      const verificationMethod = didDocument.verificationMethod?.find((vm) => vm.id === did);
-      if (verificationMethod) {
-        return {
-          contentStream: JSON.stringify(verificationMethod),
-          contentMetadata,
-          dereferencingMetadata,
-        };
-      }
-    }
-
-    const documentToReturn = { ...didDocument };
-    if (documentToReturn && accept === 'application/did+json') {
-      delete documentToReturn['@context'];
-    }
-
-    return {
-      contentStream: JSON.stringify(documentToReturn),
-      contentMetadata,
-      dereferencingMetadata,
-    };
+    if (did.includes('#')) {
+      const verificationMethod = didDocument.verificationMethod?.find((vm) => vm.id === did);
+      if (!verificationMethod) {
+        const errorMetadata = { ...dereferencingMetadata, error: 'notFound' };
+        delete errorMetadata.contentType;
+        return {
+          contentStream: '',
+          contentMetadata,
+          dereferencingMetadata: errorMetadata,
+        };
+      }
+
+      return {
+        contentStream: JSON.stringify(verificationMethod),
+        contentMetadata,
+        dereferencingMetadata: {
+          ...dereferencingMetadata,
+          contentType: accept ?? dereferencingMetadata.contentType,
+        },
+      };
+    }
+
+    const documentToReturn = { ...didDocument };
+    if (documentToReturn && accept === 'application/did+json') {
+      delete documentToReturn['@context'];
+    }
+
+    return {
+      contentStream: JSON.stringify(documentToReturn),
+      contentMetadata,
+      dereferencingMetadata: {
+        ...dereferencingMetadata,
+        contentType: accept ?? dereferencingMetadata.contentType,
+      },
+    };

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In packages/w3c-issuer/src/did-web/wellKnown/query.ts around lines 168 to 188,
if the incoming DID contains a fragment (contains '#') but no matching
verificationMethod is found, you must not fall through to return the whole DID
document; instead immediately return a dereferencing response with
dereferencingMetadata.error set to "notFound" and no content (empty or null
contentStream and minimal/empty contentMetadata). Update the branch so that
after searching and not finding the fragment target you construct and return {
contentStream: '', contentMetadata: {}, dereferencingMetadata: {
...existingFields, error: 'notFound' } } (or equivalent) to signal the fragment
resolution failure.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Add mocks for test isolation.

This test lacks the mocking setup present in other tests, making it an integration test that will attempt real network calls and credential verification. This breaks test isolation and will fail if the network is unavailable or the credential status VC doesn't exist at the URL.

Apply this diff to add proper mocking:

 it('should verify a credential status successfully with ECDSA-SD-2023 and v2.0 context', async () => {
+  // Mock a status list VC with ECDSA-SD-2023 cryptosuite
+  const credentialStatusVC_ECDSA_SD_V2: SignedVerifiableCredential = {
+    '@context': [
+      'https://www.w3.org/ns/credentials/v2',
+      'https://w3id.org/vc/status-list/2021/v1',
+    ],
+    id: 'https://trustvc.github.io/did/credentials/statuslist/2',
+    type: ['VerifiableCredential', 'BitstringStatusListCredential'],
+    issuer: 'did:web:trustvc.github.io:did:1',
+    validFrom: '2024-11-10T08:49:52.435Z',
+    credentialSubject: {
+      id: 'https://trustvc.github.io/did/credentials/statuslist/2#list',
+      type: 'BitstringStatusList',
+      statusPurpose: 'revocation',
+      encodedList: 'H4sIAAAAAAAAA-3BMQEAAAwCoH32b7RoxvAB8gcAAAAAAAAAAAAAAAAAAACMFVeOQ9sAQAAA',
+    },
+    proof: {
+      type: 'DataIntegrityProof',
+      cryptosuite: 'ecdsa-sd-2023',
+      created: '2024-11-10T08:49:54Z',
+      proofPurpose: 'assertionMethod',
+      proofValue: 'u...',
+      verificationMethod: 'did:web:trustvc.github.io:did:1#keys-1',
+    },
+  };
+
+  vi.spyOn(w3c_credential_status, 'fetchCredentialStatusVC').mockResolvedValue(
+    credentialStatusVC_ECDSA_SD_V2,
+  );
+  vi.spyOn(w3c_vc, 'verifyCredential').mockResolvedValue({ verified: true });
+
   const { status } = await verifyCredentialStatus(credentialStatus2);
   expect(status).toBe(true);

   // Test with different index to verify it returns false
   const { status: status2, purpose } = await verifyCredentialStatus({
     ...credentialStatus2,
     statusListIndex: '10',
   });
   expect(status2).toBe(false);
   expect(purpose).toBe('revocation');
 });

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	it('should verify a credential status successfully with ECDSA-SD-2023 and v2.0 context', async () => {
	const { status } = await verifyCredentialStatus(credentialStatus2);
	expect(status).toBe(true);
	// Test with different index to verify it returns false
	const { status: status2, purpose } = await verifyCredentialStatus({
	...credentialStatus2,
	statusListIndex: '10',
	});
	expect(status2).toBe(false);
	expect(purpose).toBe('revocation');
	});
	it('should verify a credential status successfully with ECDSA-SD-2023 and v2.0 context', async () => {
	// Mock a status list VC with ECDSA-SD-2023 cryptosuite
	const credentialStatusVC_ECDSA_SD_V2: SignedVerifiableCredential = {
	'@context': [
	'https://www.w3.org/ns/credentials/v2',
	'https://w3id.org/vc/status-list/2021/v1',
	],
	id: 'https://trustvc.github.io/did/credentials/statuslist/2',
	type: ['VerifiableCredential', 'BitstringStatusListCredential'],
	issuer: 'did:web:trustvc.github.io:did:1',
	validFrom: '2024-11-10T08:49:52.435Z',
	credentialSubject: {
	id: 'https://trustvc.github.io/did/credentials/statuslist/2#list',
	type: 'BitstringStatusList',
	statusPurpose: 'revocation',
	encodedList: 'H4sIAAAAAAAAA-3BMQEAAAwCoH32b7RoxvAB8gcAAAAAAAAAAAAAAAAAAACMFVeOQ9sAQAAA',
	},
	proof: {
	type: 'DataIntegrityProof',
	cryptosuite: 'ecdsa-sd-2023',
	created: '2024-11-10T08:49:54Z',
	proofPurpose: 'assertionMethod',
	proofValue: 'u...',
	verificationMethod: 'did:web:trustvc.github.io:did:1#keys-1',
	},
	};
	vi.spyOn(w3c_credential_status, 'fetchCredentialStatusVC').mockResolvedValue(
	credentialStatusVC_ECDSA_SD_V2,
	);
	vi.spyOn(w3c_vc, 'verifyCredential').mockResolvedValue({ verified: true });
	const { status } = await verifyCredentialStatus(credentialStatus2);
	expect(status).toBe(true);
	// Test with different index to verify it returns false
	const { status: status2, purpose } = await verifyCredentialStatus({
	...credentialStatus2,
	statusListIndex: '10',
	});
	expect(status2).toBe(false);
	expect(purpose).toBe('revocation');
	});

🤖 Prompt for AI Agents

In packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts around lines
188 to 199, the test currently performs real network/DID operations; add mocks
to isolate it: mock the HTTP request that fetches the status list credential URL
to return a canned VC JSON matching credentialStatus2, mock any DID resolver or
key/verification calls used by verifyCredentialStatus to return successful
verification for the original index and a revoked (or false) result for
statusListIndex '10', and ensure mocks are cleaned up after the test; follow the
same mocking pattern used in the other tests in this file (intercept fetch/DID
resolution, return fixture VC, stub verification functions) so the test runs
deterministically without network access.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify that empty array derivation reveals necessary fields.

The derivation flow calls deriveCredential(vcStatusList, []) with an empty array, which means only mandatory pointers from the base proof are revealed. For status list credentials, ensure that the mandatory pointers in base credentials include all necessary fields (e.g., encodedList, statusPurpose) for status verification to work correctly.

Run the following script to check how credential status VCs with modern cryptosuites are structured:

---

🏁 Script executed:

#!/bin/bash
# Description: Search for test fixtures or examples of status list VCs with ECDSA-SD-2023 or BBS-2023
# to verify they include proper mandatory pointers

echo "Searching for status list VC fixtures with modern cryptosuites..."
rg -n -A20 -B5 'BitstringStatusList|StatusList2021' --type ts | rg -A20 'ecdsa-sd-2023|bbs-2023'

echo -e "\nSearching for credentialSubject in status list contexts..."
rg -n 'credentialSubject.*encodedList|encodedList.*BitstringStatusList' --type ts -C3

Length of output: 12136

---

---

🏁 Script executed:

#!/bin/bash
# Description: Find where status list VCs are signed and check mandatory pointer configuration

echo "Searching for where status list VCs are signed with selective disclosure cryptosuites..."
rg -n 'sign.*BitstringStatusList|sign.*StatusList.*ecdsa-sd-2023|sign.*StatusList.*bbs-2023' --type ts -C3

echo -e "\nSearching for mandatory or selectivePointers configuration in status list signing..."
rg -n 'mandatoryPointers|selectivePointers' --type ts -C3

echo -e "\nSearching for proof creation in credentialStatus signing flow..."
fd -e ts -path '*/sign/credentialStatus/*' --exec cat {} +

Length of output: 10224

---

🏁 Script executed:

#!/bin/bash
# Description: Find where status list VCs are signed and check mandatory pointer configuration

echo "Searching for where status list VCs are signed with selective disclosure cryptosuites..."
rg -n 'sign.*statusPayload|sign.*credentialStatus|signCredential.*ecdsa-sd-2023|signCredential.*bbs-2023' --type ts -C5

echo -e "\nSearching for mandatory or selectivePointers configuration..."
rg -n 'mandatoryPointers|selectivePointers' --type ts -C3

echo -e "\nSearching for credential status signing implementation..."
find packages -name 'index.ts' -path '*/sign/credentialStatus/*' -exec cat {} +

Length of output: 13675

---

---

🏁 Script executed:

#!/bin/bash
# Description: Find coreMandatoryPointers definition and trace how it's set for status list VCs

echo "Searching for coreMandatoryPointers definition..."
rg -n 'coreMandatoryPointers\s*=' --type ts -B5 -A5

echo -e "\nSearching for where mandatory pointers might be defined based on credential type..."
rg -n 'encodedList|statusPurpose' --type ts | grep -i 'pointer\|mandatory' -C3

echo -e "\nSearching signCredential full function to see coreMandatoryPointers logic..."
rg -n -A50 'const coreMandatoryPointers' --type ts

Length of output: 4993

---

Status list VCs lack necessary mandatory pointers for secure derivation.

The status list VCs are signed with only core mandatory pointers (/issuer and date field), which do not include /credentialSubject/encodedList or /credentialSubject/statusPurpose. When deriveCredential(vcStatusList, []) is called with an empty array, only the mandatory pointers are revealed—resulting in a derived credential missing these critical fields required for status verification.

Add encodedList and statusPurpose to mandatory pointers when signing status list VCs with selective disclosure cryptosuites (ecdsa-sd-2023, bbs-2023). Modify the status list signing flow in packages/w3c-vc/src/lib/sign/credentialStatus/index.ts or the credential helper to pass explicit mandatory pointers that include /credentialSubject/encodedList and /credentialSubject/statusPurpose.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Fix context detection for string-valued @context.

credential['@context'][0] pulls a single character when @context is a string, so v2 credentials collapse into the v1.1 branch and fail signing (missing /issuanceDate, wrong mandatory pointers, etc.). Route this through getFirstContext so both strings and arrays are handled consistently.

-      const firstContext = credential['@context'][0];
+      const firstContext = getFirstContext(credential);
       const isV2 = firstContext === CredentialContextVersion.v2;

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In packages/w3c-vc/src/lib/w3c-vc.ts around lines 281 to 304, the code reads
credential['@context'][0] which returns a single character when @context is a
string; replace that access with a call to
getFirstContext(credential['@context']) (or equivalent helper) so both string
and array forms yield the correct first context value, then use the returned
value to set isV2 and the subsequent coreMandatoryPointers logic; ensure
getFirstContext is imported/available and add a null/undefined guard if needed
so the v2/v1.1 branch selection and mandatory pointer population behave
correctly.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Allow verification of base DataIntegrity proofs.

Rejecting base (proofValue header even) DataIntegrity proofs forces every relying party to derive before verification, so freshly issued ECDSA-SD/BBS-2023 credentials can never verify. The verification suites handle base and derived proofs; just run them instead of emitting an error.

-          if (isBaseCredential) {
-            // This is a base proof - modern cryptosuites require derivation before verification
-            return {
-              verified: false,
-              error: `${cryptosuite} base credentials must be derived before verification. Use deriveCredential() first.`,
-            };
-          }
-
           // Create the appropriate verification cryptosuite
           const verifyCryptosuite =
             cryptosuite === 'ecdsa-sd-2023'
               ? createEcdsaSd2023VerifyCryptosuite()
               : createBbs2023VerifyCryptosuite();

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	if (cryptosuite === 'ecdsa-sd-2023' || cryptosuite === 'bbs-2023') {
	// Check if this is a base credential (non-derived) by examining the proofValue structure
	const isBaseCredential = await baseProofDetectors[cryptosuite as SupportedCryptosuite](
	proof.proofValue as string,
	);
	if (isBaseCredential) {
	// This is a base proof - modern cryptosuites require derivation before verification
	return {
	verified: false,
	error: `${cryptosuite} base credentials must be derived before verification. Use deriveCredential() first.`,
	};
	}
	// Create the appropriate verification cryptosuite
	const verifyCryptosuite =
	cryptosuite === 'ecdsa-sd-2023'
	? createEcdsaSd2023VerifyCryptosuite()
	: createBbs2023VerifyCryptosuite();
	verificationResult = await jsonldSignatures.verify(credential, {
	suite: new DataIntegrityProof({
	cryptosuite: verifyCryptosuite,
	}),
	purpose: new AssertionProofPurpose(),
	documentLoader,
	});
	} else {
	return {
	verified: false,
	error: `DataIntegrityProof with cryptosuite "${cryptosuite}" is not supported for verification.`,
	};
	}
	if (cryptosuite === 'ecdsa-sd-2023' || cryptosuite === 'bbs-2023') {
	// Check if this is a base credential (non-derived) by examining the proofValue structure
	const isBaseCredential = await baseProofDetectors[cryptosuite as SupportedCryptosuite](
	proof.proofValue as string,
	);
	// Create the appropriate verification cryptosuite
	const verifyCryptosuite =
	cryptosuite === 'ecdsa-sd-2023'
	? createEcdsaSd2023VerifyCryptosuite()
	: createBbs2023VerifyCryptosuite();
	verificationResult = await jsonldSignatures.verify(credential, {
	suite: new DataIntegrityProof({
	cryptosuite: verifyCryptosuite,
	}),
	purpose: new AssertionProofPurpose(),
	documentLoader,
	});
	} else {
	return {
	verified: false,
	error: `DataIntegrityProof with cryptosuite "${cryptosuite}" is not supported for verification.`,
	};
	}

[tradetrustimda]

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[tradetrustimda]

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[tradetrustimda]

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[tradetrustimda]

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[tradetrustimda]

🎉 This PR is included in version 2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀