feat: merge alpha to main

[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
• 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

  • Added support for modern cryptographic algorithms (ECDSA-SD-2023 and BBS-2023) alongside legacy signatures.
  • Added support for W3C Verifiable Credentials Data Model v2.0.
  • Extended JSON-LD contexts for commercial documents (bill of lading, certificates of origin, promissory notes, warehouse receipts).

• Documentation

  • Enhanced package READMEs with migration guides and comprehensive examples for modern cryptosuites.
  • Marked w3c-cli package as deprecated.

• Bug Fixes

  • Improved credential status verification for multiple credential status entries.

• Chores

  • Updated package versions and dependencies to alpha releases.
  • Added comprehensive test coverage for multi-cryptosuite workflows.

[coderabbitai]

Walkthrough

Adds comprehensive support for modern cryptosuites (ECDSA-SD-2023, BBS-2023), W3C VC Data Model v2.0, Multikey DIDs, and BitstringStatusList credentials across multiple packages. Implements new JSON-LD contexts, key generation for modern suites, refactored credential signing/verification/derivation flows, enhanced error handling in CLI commands, and expanded test coverage.

Changes

Cohort / File(s)	Summary
Build & Config .gitignore, .nxignore, nx.json, netlify.toml, packages/declaration.d.ts	Updated gitignore to target JSON files; added w3c-cli to nxignore; removed w3c-cli from nx release projects; added CORS headers and redirect to netlify.toml; added ambient declarations for Digital Bazaar cryptosuites and jsonld packages.
Root & Scripts package.json, scripts/copy-files.sh	Added test:skip-cache and lint:fix scripts; added @types/uuid; removed jsonld-signatures; expanded build script to copy new context files and generate netlify headers.
w3c-cli Deprecation & Metadata apps/w3c-cli/package.json, apps/w3c-cli/CHANGELOG.md, apps/w3c-cli/README.md, apps/w3c-cli/project.json.deprecated	Bumped version to 1.3.0-alpha.12; marked package deprecated; updated README with deprecation banner and expanded documentation; added changelog entry; added deprecation header comment.
w3c-cli Command Refactoring apps/w3c-cli/src/commands/key-pair.ts, apps/w3c-cli/src/commands/did.ts, apps/w3c-cli/src/commands/sign.ts, apps/w3c-cli/src/commands/verify.ts, apps/w3c-cli/src/commands/credentialStatus/create.ts, apps/w3c-cli/src/commands/credentialStatus/update.ts, apps/w3c-cli/src/commands/derive.ts	Unified error handling with try/catch in handlers; replaced direct fs usage with utility functions (readJsonFile, writeFile, isDirectoryValid); transitioned from early returns to exception-based error propagation; added support for multiple credentialStatus entries.
w3c-cli Utils & Tests apps/w3c-cli/src/utils.ts, apps/w3c-cli/tests/commands/key-pair.test.ts, apps/w3c-cli/tests/commands/did.test.ts, apps/w3c-cli/tests/commands/sign.test.ts, apps/w3c-cli/tests/commands/verify.test.ts, apps/w3c-cli/tests/fixtures/mockCredential.ts, apps/w3c-cli/tests/fixtures/mockDidWeb.ts, apps/w3c-cli/tests/main.test.ts	Updated utils error handling (writeFile/readJsonFile throw errors; isDirectoryValid returns false with warning); added comprehensive test suites for all commands; added mock fixtures for credentials and DID data.
w3c-context JSON-LD Contexts packages/w3c-context/src/context/{bill-of-lading-carrier,coo,data-integrity-v2,jws-2020-v1,multikey-v1,promissory-note,qrcode-context,render-method-context-v2,status-list-2021-v1,warehouse-receipt}.json	Added 10 new JSON-LD context definitions for modern cryptosuites (data-integrity, jws, multikey), render methods, and trade/commerce document types (bill-of-lading, COO, promissory note, warehouse receipt, QR code).
w3c-context Package & Docs packages/w3c-context/package.json, packages/w3c-context/CHANGELOG.md, packages/w3c-context/README.md, packages/w3c-context/tsconfig.{json,build.json}	Bumped to 1.3.0-alpha.12; added jsonld-signatures dependency; expanded README with comprehensive usage examples and context documentation; updated tsconfig to include declaration.d.ts.
w3c-context Implementation packages/w3c-context/src/index.ts, packages/w3c-context/src/lib/index.ts, packages/w3c-context/src/lib/types.ts	Restructured exports to split index and types re-exports; introduced getDocumentLoader function with DID resolution and context caching; added multiple context URL constants and context maps (renderContextsV2, qrCodeContexts, templateContexts); introduced DocumentLoader and DocumentLoaderObject types.
w3c-issuer Type System & Key Generation packages/w3c-issuer/src/lib/types.ts, packages/w3c-issuer/src/did-web/keyPair/types.ts, packages/w3c-issuer/src/did-web/wellKnown/types.ts	Added CryptoSuite enum (Bbs2023, EcdsaSd2023); extended VerificationType with Multikey; updated VerificationContext mapping; introduced MultikeyKeyPair, Bbs2023PrivateKeyPair, EcdsaSd2023PrivateKeyPair types; expanded BaseKeyPair type union.
w3c-issuer Key Pair Generation packages/w3c-issuer/src/did-web/keyPair/index.ts, packages/w3c-issuer/src/did-web/keyPair/bbs2023.ts, packages/w3c-issuer/src/did-web/keyPair/ecdsaSd2023.ts, packages/w3c-issuer/src/did-web/keyPair/index.test.ts	Added generateBbs2023KeyPair and generateEcdsaSd2023KeyPair functions; refactored generateKeyPair to dispatch to modern cryptosuites or legacy BLS based on type; extended tests for BBS-2023 and ECDSA-SD-2023 generation and determinism.
w3c-issuer DID Generation & Resolution packages/w3c-issuer/src/did-web/index.ts, packages/w3c-issuer/src/did-web/wellKnown/index.ts, packages/w3c-issuer/src/did-web/wellKnown/generate.ts, packages/w3c-issuer/src/did-web/wellKnown/query.ts, packages/w3c-issuer/src/did-web/wellKnown/query.test.ts	Exported resolve, resolveRepresentation, dereference, queryDidDocument functions; added Multikey support in well-known DID generation; introduced content-type negotiation and W3C DID Core compliance; refactored getDomain with robust URL parsing.
w3c-issuer Tests & Docs packages/w3c-issuer/CHANGELOG.md, packages/w3c-issuer/README.md, packages/w3c-issuer/package.json, packages/w3c-issuer/src/lib/index.ts, packages/w3c-issuer/src/did-web/README.md, packages/w3c-issuer/src/did-web/wellKnown/index.test.ts, packages/w3c-issuer/src/did-web/wellKnown/generate.test.ts, packages/w3c-issuer/tsconfig.{json,build.json}	Bumped to 1.3.0-alpha.10; added bls12-381-multikey and ecdsa-multikey dependencies; updated README with Multikey examples and CryptoSuite options; added extensive test coverage for modern cryptosuite DIDs; updated tsconfig.
w3c-credential-status Types & Validation packages/w3c-credential-status/src/lib/types.ts, packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.ts, packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.test.ts	Introduced CryptoSuiteName union type; made issuanceDate optional in RawCredentialStatusVC; added _checkCredentialSubjectForBitstringStatusListCredential; consolidated validation with generic _checkCredentialSubjectForStatusListCredential helper; added parameterized tests for both StatusList2021 and BitstringStatusList.
w3c-credential-status Implementation & Tests packages/w3c-credential-status/src/lib/index.ts, packages/w3c-credential-status/src/lib/index.test.ts, packages/w3c-credential-status/src/lib/utils.ts, packages/w3c-credential-status/src/lib/utils.test.ts, packages/w3c-credential-status/tsconfig.json	Updated defaults to BitstringStatusListCredential and ecdsa-sd-2023; added BitstringStatusListEntry support; introduced isCredentialStatusStatusList export; enhanced DocumentLoader integration in fetchCredentialStatusVC; added assertBitstringStatusListEntry and assertCredentialStatusStatusListType; updated key pair fixtures for multiple cryptosuites; updated tsconfig.
w3c-credential-status Package & Docs packages/w3c-credential-status/package.json, packages/w3c-credential-status/CHANGELOG.md, packages/w3c-credential-status/README.md	Bumped to 1.3.0-alpha.13; updated dependencies; added changelog for status list v2.0 support; expanded README with dual v1.1/v2.0 documentation, migration guide, and cryptosuite mappings.
w3c-vc Fixtures & Test Scenarios packages/w3c-vc/src/lib/__fixtures__/bbs2020-credentials.ts, packages/w3c-vc/src/lib/__fixtures__/key-pairs.ts, packages/w3c-vc/src/lib/__fixtures__/modern-credentials.ts, packages/w3c-vc/src/lib/__fixtures__/test-scenarios.ts	Added comprehensive fixtures for BBS-2020 credentials (v1.1 and v2.0, signed and derived), modern credentials, key pairs (BBS-2020, ECDSA-SD-2023, BBS-2023), and parameterized test scenarios for multi-cryptosuite testing.
w3c-vc Types & Helpers packages/w3c-vc/src/lib/types.ts, packages/w3c-vc/src/lib/helper/index.ts	Introduced CredentialSchema, TermsOfUse, RelatedResource, RefreshService, Evidence types; made issuanceDate optional; added DataIntegrityProof to ProofType; added CryptoSuiteName export; refactored _checkCredential to support v1.1/v2.0 dual-format validation with temporal checks; added schema validation; extended BitstringStatusListEntry support.
w3c-vc Credential Sign/Verify packages/w3c-vc/src/lib/sign/credentialStatus/index.ts, packages/w3c-vc/src/lib/verify/credentialStatus/index.ts, packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts	Added assertCredentialStatuses helper; extended verifyCredentialStatus to accept DocumentLoader and handle credential derivation on verification failure; added test scenarios for BitstringStatusListEntry and v2.0 contexts.
w3c-vc Core Implementation packages/w3c-vc/src/lib/w3c-vc.ts	Introduced modern cryptosuite support (ECDSA-SD-2023, BBS-2023) with DataIntegrityProof; added isRawDocumentV1_1/V2_0, isSignedDocumentV1_1/V2_0, isDerived predicates; refactored signCredential, verifyCredential, deriveCredential with cryptosuite dispatch, mandatory pointer extraction, and DocumentLoader integration; deprecated BbsBlsSignature2020 paths.
w3c-vc Tests & Package packages/w3c-vc/src/lib/w3c-vc.test.ts, packages/w3c-vc/src/index.ts, packages/w3c-vc/package.json, packages/w3c-vc/CHANGELOG.md, packages/w3c-vc/README.md, packages/w3c-vc/tsconfig.{json,build.json}	Replaced monolithic test with parameterized multi-cryptosuite scenarios; added BBS-2020 deprecation and backward compatibility tests; bumped to 1.3.0-alpha.17; added Digital Bazaar cryptosuite and data-integrity dependencies; restructured exports (removed local getDocumentLoader, added version-specific document predicates); expanded README with v2.0 examples and migration guide; updated tsconfig.
Root w3c Package packages/w3c/package.json, packages/w3c/CHANGELOG.md, packages/w3c/tsconfig.json	Bumped to 1.3.0-alpha.17; updated all transitive dependencies to alpha versions; added changelog entry; updated tsconfig to include declaration.d.ts.

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant signCredential as Sign Flow
    participant cryptosuite as Cryptosuite Factory
    participant DataIntegrity as DataIntegrityProof
    participant keyPair as PrivateKeyPair

    Caller->>signCredential: signCredential(credential, keyPair, cryptoSuite?)
    signCredential->>signCredential: prefill credential ID based on cryptoSuite
    alt cryptoSuite is ecdsa-sd-2023 or bbs-2023
        signCredential->>cryptosuite: createSignCryptosuite(cryptoSuite)
        cryptosuite-->>signCredential: cryptosuite instance
        signCredential->>DataIntegrity: sign with DataIntegrityProof
        DataIntegrity->>keyPair: extract secretKeyMultibase
        keyPair-->>DataIntegrity: multibase key
        DataIntegrity-->>signCredential: signed credential with proof
    else legacy BbsBlsSignature2020
        signCredential-->>signCredential: return deprecation error
    end
    signCredential-->>Caller: SignedVerifiableCredential

Loading

sequenceDiagram
    participant Caller
    participant verifyCredential as Verify Flow
    participant detect as Detect CryptoSuite
    participant cryptosuite as Cryptosuite Factory
    participant DocumentLoader
    participant derive as Derive if Needed

    Caller->>verifyCredential: verifyCredential(credential, options?)
    verifyCredential->>detect: identify proof type and cryptosuite
    alt proof is DataIntegrityProof (ecdsa-sd-2023/bbs-2023)
        detect-->>verifyCredential: modern cryptosuite
        verifyCredential->>cryptosuite: createVerifyCryptosuite(cryptoSuite)
        cryptosuite-->>verifyCredential: verification suite
        verifyCredential->>verifyCredential: verify with DataIntegrityProof
    else proof type indicates base proof exists
        verifyCredential->>derive: derive credential first
        derive-->>verifyCredential: derived credential
        verifyCredential->>verifyCredential: retry verification on derived
    else legacy BbsBlsSignature2020
        verifyCredential-->>verifyCredential: use legacy BBS path
    end
    verifyCredential-->>Caller: VerificationResult

Loading

sequenceDiagram
    participant Caller
    participant getDocumentLoader as Get Loader
    participant cache as Context Cache
    participant DIDResolver
    participant jsonldSig as jsonld-signatures

    Caller->>getDocumentLoader: getDocumentLoader(additionalContexts?)
    getDocumentLoader->>cache: create context cache map
    getDocumentLoader->>getDocumentLoader: build loader function
    getDocumentLoader->>getDocumentLoader: add custom context URLs
    alt URL is DID
        getDocumentLoader->>DIDResolver: resolve DID
        DIDResolver-->>getDocumentLoader: DID document
        getDocumentLoader->>cache: cache result
    else URL in pre-cached contexts
        cache-->>getDocumentLoader: cached document
    else URL is standard JSON-LD
        getDocumentLoader->>getDocumentLoader: fetch standard context
        getDocumentLoader->>cache: cache result
    end
    getDocumentLoader->>jsonldSig: extendContextLoader with loader
    jsonldSig-->>getDocumentLoader: extended loader
    getDocumentLoader-->>Caller: DocumentLoader function

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Specific areas requiring extra attention:

• Cryptosuite implementations (packages/w3c-vc/src/lib/w3c-vc.ts, packages/w3c-issuer/src/did-web/keyPair/*.ts): New ECDSA-SD-2023 and BBS-2023 implementations with Digital Bazaar libraries; verify correct suite initialization, key export formats, and proof generation.
• Sign/Verify/Derive refactoring (packages/w3c-vc/src/lib/w3c-vc.ts): Major control-flow changes with cryptosuite dispatch logic, mandatory pointer extraction, and fallback derivation on verification; ensure all paths properly handle DocumentLoader, error propagation, and version detection.
• CLI error handling overhaul (apps/w3c-cli/src/commands/*.ts): Unified try/catch pattern with utility-based file operations; verify that all error paths throw consistently and that logging is centralized without silent failures.
• Type system expansions (packages/w3c-issuer/src/lib/types.ts, packages/w3c-vc/src/lib/types.ts): New CryptoSuite enum, VerificationType.Multikey, and union type changes; check type consistency across dependent modules and key generation dispatch logic.
• DocumentLoader integration (packages/w3c-context/src/lib/index.ts, packages/w3c-vc/src/lib/verify/credentialStatus/index.ts): New loader caching, DID resolution, and context fetching; validate proper propagation through verify and credential-status flows, and verify no circular dependencies.
• JSON-LD context additions (packages/w3c-context/src/context/*.json): 10 new context files with complex nested structures; spot-check context structure correctness, IRI mappings, and @container/@type declarations for semantic accuracy.
• Test suite expansion (packages/w3c-vc/src/lib/w3c-vc.test.ts, etc.): Parameterized multi-cryptosuite scenarios; verify test isolation, mock completeness, and coverage of both happy paths and error cases for each new cryptosuite.
• Backward compatibility (packages/w3c-vc/src/lib/w3c-vc.ts): Deprecation warnings for BbsBlsSignature2020; ensure legacy credentials still verify correctly and migration guidance is clear.

Possibly related PRs

• feat: bbs2023 implementation #88: Implements overlapping BBS-2023/modern-cryptosuite support with shared w3c-cli and package.json changes.
• feat: add resolve, resolveRepresentation and dereference functions #87: Adds identical DID resolution helpers (resolve, resolveRepresentation, dereference) in packages/w3c-issuer/src/did-web/wellKnown/query.ts.
• feat: status list update for bbs and v2.0 #89: Modifies w3c-credential-status for BitstringStatusList/v2.0 support with overlapping validation and index.ts changes.

Suggested labels

released on @alpha``

Suggested reviewers

• rongquan1
• kmk142789

---

🐰 Modern cryptosuites bloom with grace,
Multikeys dance in cyberspace,
V2 contexts shine so bright,
Selective disclosure takes flight,
BBS legacy fades from sight! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'feat: merge alpha to main' is vague and generic, describing a mechanical merge action rather than the substantive changes in the PR.	Replace with a specific title highlighting the main feature: e.g., 'feat: add W3C VC Data Model 2.0 and modern cryptosuite support' or similar.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description check	✅ Passed	The PR description includes all required template sections (Summary, Changes, Issues, Releases) with substantive content explaining the breaking changes and new features.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ 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 alpha

---

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
10.4% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[coderabbitai]

Actionable comments posted: 14

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/README.md (1)

217-227: Clarify the deprecated example or remove it.

The example at lines 213–218 shows code that the comment says "will result in error", but there's no error handling demonstrated. This is confusing for users trying to understand the deprecated path. If the goal is to show what not to do, add a code comment or restructure to make it clear. Alternatively, remove the example entirely and rely on the migration guide.

Consider revising to:

// ⚠️ DEPRECATED: The following cryptosuite is no longer supported.
// DO NOT use this code in production. Use 'ecdsa-sd-2023' or 'bbs-2023' instead.
// Example of DEPRECATED approach (will fail):
/*
const credentialStatusVCV1 = await createCredentialStatusPayload(
  optionsV1, 
  keyPair, 
  'StatusList2021Credential',
  'BbsBlsSignature2020' // ⚠️ DEPRECATED
);
*/

// Use this instead for v1.1:
const credentialStatusVCV1 = await createCredentialStatusPayload(
  optionsV1, 
  keyPair, 
  'StatusList2021Credential',
  'ecdsa-sd-2023' // or 'bbs-2023'
);

apps/w3c-cli/src/commands/credentialStatus/create.ts (1)

51-56: Fix type mismatch: early return violates function signature.

The function signature declares Promise<CredentialStatusQuestionType> as the return type, but line 55 returns undefined after catching an error. This causes a type mismatch and could lead to runtime errors when the handler tries to access properties on answers at line 19.

Apply this diff to propagate the error properly:

  try {
    answers.keypairData = readJsonFile(answers.keyPairPath, 'key pair');
  } catch (err) {
-   console.error(chalk.red(`Invalid file path provided: ${answers.keyPairPath}`));
-   return;
+   throw new Error(`Invalid file path provided: ${answers.keyPairPath}`);
  }

This aligns with the error handling pattern used in other commands (e.g., derive.ts, sign.ts) where errors are thrown and caught by the handler's try-catch block.

🧹 Nitpick comments (20)

packages/w3c-vc/CHANGELOG.md (2)

1-7: Fix markdown heading hierarchy violations.

The file uses h1 (#) for version headers and h3 (###) for subsection headers, which violates markdown best practices by skipping h2. Subsection headers (Bug Fixes / Features) should use ## instead of ### to maintain proper heading hierarchy.

Apply this change to all version sections (shown for 1.3.0-alpha.17 as an example):

 # [1.3.0-alpha.17](...)
 
-### Bug Fixes
+## Bug Fixes
 
 * update check credential function ...

Also applies to: 8-14, 15-21, 22-28, 29-35, 36-42, 43-49, 50-56, 57-63, 64-70, 71-77, 78-84, 85-91, 92-98, 99-105, 106-112, 113-119

---

160-160: Standardize "qrcode" terminology.

Line 160 uses "qrcode" as a single word. Consider updating to "QR code" (two words, capitalized) to follow standard English terminology in changelog entries.

-* add qrcode context ([#55]...
+* add QR code context ([#55]...

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

9-12: Clarify modern cryptosuites in the Features section.

The Features section emphasizes legacy cryptosuites (BBS+ v1, JWS 2020, BLS12-381) but doesn't explicitly call out the modern cryptosuites (BBS-2023, ECDSA-SD-2023) that this PR introduces. Consider updating the cryptosuite bullet to highlight both legacy and modern support.

- **Cryptosuite Support**: Includes contexts for multiple cryptographic suites:
-   - BBS+ signatures (bbs-v1)
-   - JWS 2020 (jws-2020)
-   - BLS12-381 keys
+ **Cryptosuite Support**: Includes contexts for multiple cryptographic suites:
+   - Modern suites: BBS-2023, ECDSA-SD-2023 (via Data Integrity v2)
+   - Legacy suites: BBS+ v1, JWS 2020, BLS12-381

---

82-95: Expand context constants with modern cryptosuite examples.

The example shows basic context constants but omits modern cryptosuite-related constants (e.g., any BBS-2023 or ECDSA-SD-2023 constants). Adding examples of these constants would improve discoverability for developers using modern suites.

 ```typescript
 import { 
   DATA_INTEGRITY_V2_URL,
   MULTIKEY_V1_URL,
   VC_V1_URL
 } from '@trustvc/w3c-context';
 
 console.log(DATA_INTEGRITY_V2_URL); // https://w3id.org/security/data-integrity/v2
 console.log(MULTIKEY_V1_URL); // https://w3id.org/security/multikey/v1
+console.log(VC_V2_URL); // https://www.w3.org/ns/credentials/v2

</blockquote></details>
<details>
<summary>packages/w3c-credential-status/README.md (2)</summary><blockquote>

`368-381`: **Consider documenting the v1.1 path in the update example.**

The update revocation status example (Step 4) only shows the v2.0 approach with `'BitstringStatusListCredential'` and `'ecdsa-sd-2023'`. For completeness, add a note or alternate example showing how v1.1 users would update credentials with `'StatusList2021Credential'`, especially since this is marketed as a backward-compatible package.


Add a collapsible section or comment:
```typescript
// For v1.1 (legacy), use:
// credentialType: 'StatusList2021Credential'
// type in credentialSubject: 'StatusList2021'
// cryptoSuite: 'ecdsa-sd-2023' or 'bbs-2023' (modern suites recommended)

---

84-90: Add clarity on key pair initialization.

Both usage examples (Step 1 and Step 1 of the update workflow) import functions but don't show how to create or initialize keyPair or keypairData. Consider adding a brief note or link to explain where this comes from (e.g., @trustvc/w3c-issuer package or another source).

Add a comment such as:

// Note: keyPair should be imported or created from @trustvc/w3c-issuer
// or another key management module
import { PrivateKeyPair } from '@trustvc/w3c-issuer';

const keyPair: PrivateKeyPair = { /* your key data */ };

Also applies to: 313-322

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

208-289: Approve temporal validation with a logging improvement suggestion.

The dual-context temporal validation logic is comprehensive and correct:

• v2.0 format: properly validates optional validFrom/validUntil with temporal relationship checks
• v1.1 format: correctly validates required issuanceDate with optional expirationDate
• Current time validation ensures credentials aren't used before they're valid

However, the use of console.warn (lines 231, 273) in a library is not ideal.

Consider replacing console.warn with a proper logging abstraction or callback mechanism to allow consumers to handle expiration warnings according to their logging strategy:

-          console.warn('Credential has expired.');
-          // throw new Error('Credential has expired.');
+          // Consider: Pass warnings through a logger callback or emit events
+          // For now, maintaining backward compatibility with console.warn

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

80-149: Consider mocking external DID resolution for test reliability.

The tests rely on live external resources at trustvc.github.io. While this validates real-world behavior, it introduces dependencies on external availability and network conditions.

Consider using a test fixture or mock resolver to improve test isolation and reliability, especially for CI/CD pipelines.

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

59-72: Consider preserving error context in catch block.

The generic error message "Failed to resolve did" loses the original error details, which could be valuable for debugging.

Consider preserving the original error:

  } catch (err) {
-   throw new Error('Failed to resolve did');
+   throw new Error(`Failed to resolve did: ${err instanceof Error ? err.message : String(err)}`);
  }

This pattern applies to resolveRepresentation and dereference as well (lines 118-120, 189-191).

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

64-64: Consider consolidating duplicate type definitions.

The CryptoSuiteName type is defined identically in both packages/w3c-credential-status/src/lib/types.ts and packages/w3c-vc/src/lib/types.ts (line 93). Duplicate type definitions can lead to maintenance issues if the types diverge.

Consider exporting CryptoSuiteName from a single shared location (e.g., packages/w3c-vc/src/lib/types.ts) and importing it in packages/w3c-credential-status.

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

3-3: Consider bumping to 2.0.0-alpha for breaking changes.

The PR description explicitly mentions "breaking changes." According to semantic versioning, breaking changes should result in a major version bump. Consider changing the version to 2.0.0-alpha.10 instead of 1.3.0-alpha.10.

apps/w3c-cli/src/commands/derive.ts (2)

42-42: Remove redundant null check.

Since promptForInputs now throws errors instead of returning null (as seen in lines 96, 103, 107), the check if (!answers) return; is unreachable and redundant.

Apply this diff:

  try {
    const answers = await promptForInputs();
-   if (!answers) return;

    const { revealData, credentialData, outputPath } = answers;

---

96-96: Remove redundant null check.

The function readJsonFile (imported from utils) throws an error on failure rather than returning null, making this null check unreachable. The same pattern applies to line 103.

Apply this diff:

  const credentialData = readJsonFile(credentialPath, 'credential');
- if (!credentialData) throw new Error('Unable to read credential file');

  const { revealPath }: RevealQuestionType = (await inquirer.prompt(
    revealPrompt,
  )) as RevealQuestionType;

  const revealData = readJsonFile(revealPath, 'reveal');
- if (!revealData) throw new Error('Unable to read reveal file');

apps/w3c-cli/src/commands/verify.ts (1)

51-51: Consider explicit null/undefined handling.

The expression [].concat(credentialData?.credentialStatus) || [] may not behave as expected if credentialStatus is explicitly null or undefined. Consider:

-  const credentialStatuses = [].concat(credentialData?.credentialStatus) || [];
+  const credentialStatuses = credentialData?.credentialStatus 
+    ? [].concat(credentialData.credentialStatus) 
+    : [];

This makes the null/undefined handling more explicit.

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

30-35: Consider simplifying the chalk mock.

The chalk mock imports the original module but doesn't override any functionality, making the mock unnecessary. Since chalk is primarily used for output formatting in tests and the tests check for chalk.green() and chalk.red() calls, you can safely remove this mock entirely and use the actual chalk module.

Apply this diff to remove the unnecessary mock:

-vi.mock('chalk', async () => {
-  const originalChalk = await vi.importActual<typeof import('chalk')>('chalk');
-  return {
-    ...originalChalk,
-  };
-});

apps/w3c-cli/src/commands/sign.ts (2)

40-59: Remove redundant null checks.

Lines 43 and 52 check for falsy return values, but based on the refactored error handling (where promptForInputs and signCredentialWithKeyPair now throw errors instead of returning null), these checks are redundant. The functions will either return valid data or throw, making the null checks unreachable.

Apply this diff to remove the redundant checks:

 export const handler = async () => {
   try {
     const answers = await promptForInputs();
-    if (!answers) return;

     const { keypairData, credentialData, outputPath } = answers;

     // Sign the credential
     const signedCredential = await signCredentialWithKeyPair(
       credentialData,
       keypairData as PrivateKeyPair,
     );
-    if (!signedCredential) return;

     // Save the signed credential
     await saveSignedCredential(signedCredential, outputPath);
   } catch (err: unknown) {
     console.error(chalk.red(`Error: ${err instanceof Error ? err.message : err}`));
   }
 };

---

90-110: Remove redundant null checks after readJsonFile.

Lines 96 and 103 check if readJsonFile returns a falsy value and throw an error. However, the readJsonFile utility (as shown in the related code snippets) already throws an error on failure and never returns null. These checks are unreachable and can be removed.

Apply this diff:

 export const promptForInputs = async () => {
   const { keyPairPath }: KeyPairQuestionType = (await inquirer.prompt(
     keyPairPrompt,
   )) as KeyPairQuestionType;

   const keypairData = readJsonFile(keyPairPath, 'key pair');
-  if (!keypairData) throw new Error('Unable to read key pair file');

   const { credentialPath }: CredentialQuestionType = (await inquirer.prompt(
     credentialPrompt,
   )) as CredentialQuestionType;

   const credentialData = readJsonFile(credentialPath, 'credential');
-  if (!credentialData) throw new Error('Unable to read credential file');

   const { outputPath }: QuestionType = (await inquirer.prompt(outputPathPrompt)) as QuestionType;

   if (!isDirectoryValid(outputPath)) throw new Error('Output path is not valid');

   return { keypairData, credentialData, outputPath };
 };

apps/w3c-cli/src/commands/credentialStatus/update.ts (1)

18-32: Remove redundant null checks.

Lines 22 and 26 check for falsy return values from promptQuestions and createSignedCredentialStatus. However, based on the refactored error handling where these functions now throw errors instead of returning null/undefined, these checks are redundant and unreachable.

Apply this diff:

 export const handler = async () => {
   try {
     const answers = await promptQuestions();
-
-    if (!answers) return;

     const signedCSVC = await createSignedCredentialStatus(answers);
-
-    if (!signedCSVC) return;

     saveSignedCredentialStatus(signedCSVC, answers.outputPath);
   } catch (err: unknown) {
     console.error(chalk.red(`Error: ${err instanceof Error ? err.message : err}`));
   }
 };

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

69-75: Preserve the underlying verification error message

The thrown error currently ends up as "Failed to verify Credential Status VC: false", losing the descriptive message we just computed. Keep the detailed text so callers see the real reason.

-      const errorMessage = `Failed to verify Credential Status VC: ${vcStatusListVerificationResult.verified}`;
-      const detailedError = vcStatusListVerificationResult.error
-        ? `. Error: ${vcStatusListVerificationResult.error}`
-        : '';
-
-      console.error(errorMessage + detailedError);
-      throw new Error(errorMessage);
+      const errorMessage = 'Failed to verify Credential Status VC';
+      const detailedError = vcStatusListVerificationResult.error
+        ? `${errorMessage}: ${vcStatusListVerificationResult.error}`
+        : `${errorMessage}.`;
+
+      console.error(detailedError);
+      throw new Error(detailedError);

apps/w3c-cli/src/commands/key-pair.ts (1)

88-89: Remove duplicate success message

writeFile already emits a green “File written successfully…” log, so this extra console.log prints the same line twice. Dropping it keeps the CLI output clean without losing any feedback.

-  console.log(chalk.green(`File written successfully to ${keyFilePath}`));

📜 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 18802f2.

⛔ Files ignored due to path filters (1)

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

📒 Files selected for processing (97)

• .gitignore (1 hunks)
• .nxignore (1 hunks)
• apps/w3c-cli/CHANGELOG.md (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/src/commands/credentialStatus/create.ts (2 hunks)
• apps/w3c-cli/src/commands/credentialStatus/update.ts (4 hunks)
• apps/w3c-cli/src/commands/derive.ts (4 hunks)
• apps/w3c-cli/src/commands/did.ts (4 hunks)
• apps/w3c-cli/src/commands/key-pair.ts (3 hunks)
• apps/w3c-cli/src/commands/sign.ts (5 hunks)
• apps/w3c-cli/src/commands/verify.ts (5 hunks)
• apps/w3c-cli/src/utils.ts (3 hunks)
• apps/w3c-cli/tests/commands/did.test.ts (7 hunks)
• apps/w3c-cli/tests/commands/key-pair.test.ts (4 hunks)
• apps/w3c-cli/tests/commands/sign.test.ts (1 hunks)
• apps/w3c-cli/tests/commands/verify.test.ts (1 hunks)
• apps/w3c-cli/tests/fixtures/mockCredential.ts (1 hunks)
• apps/w3c-cli/tests/fixtures/mockDidWeb.ts (1 hunks)
• apps/w3c-cli/tests/main.test.ts (1 hunks)
• netlify.toml (1 hunks)
• nx.json (1 hunks)
• package.json (2 hunks)
• packages/declaration.d.ts (1 hunks)
• packages/w3c-context/CHANGELOG.md (1 hunks)
• packages/w3c-context/README.md (1 hunks)
• packages/w3c-context/package.json (2 hunks)
• packages/w3c-context/src/context/bill-of-lading-carrier.json (1 hunks)
• packages/w3c-context/src/context/coo.json (1 hunks)
• packages/w3c-context/src/context/data-integrity-v2.json (1 hunks)
• packages/w3c-context/src/context/jws-2020-v1.json (1 hunks)
• packages/w3c-context/src/context/multikey-v1.json (1 hunks)
• packages/w3c-context/src/context/promissory-note.json (1 hunks)
• packages/w3c-context/src/context/qrcode-context.json (1 hunks)
• packages/w3c-context/src/context/render-method-context-v2.json (1 hunks)
• packages/w3c-context/src/context/render-method-context.json (0 hunks)
• packages/w3c-context/src/context/status-list-2021-v1.json (1 hunks)
• packages/w3c-context/src/context/warehouse-receipt.json (1 hunks)
• packages/w3c-context/src/index.ts (1 hunks)
• packages/w3c-context/src/lib/index.ts (2 hunks)
• packages/w3c-context/src/lib/types.ts (1 hunks)
• packages/w3c-context/tsconfig.build.json (1 hunks)
• packages/w3c-context/tsconfig.json (1 hunks)
• packages/w3c-credential-status/CHANGELOG.md (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 (6 hunks)
• packages/w3c-credential-status/tsconfig.json (1 hunks)
• packages/w3c-issuer/CHANGELOG.md (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/index.ts (1 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/CHANGELOG.md (1 hunks)
• packages/w3c-vc/README.md (4 hunks)
• packages/w3c-vc/package.json (2 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 (11 hunks)
• packages/w3c-vc/src/lib/sign/credentialStatus/index.ts (2 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 (4 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/CHANGELOG.md (1 hunks)
• packages/w3c/package.json (2 hunks)
• packages/w3c/tsconfig.json (1 hunks)
• scripts/copy-files.sh (1 hunks)

💤 Files with no reviewable changes (1)

• packages/w3c-context/src/context/render-method-context.json

🧰 Additional context used

🧬 Code graph analysis (44)

apps/w3c-cli/tests/commands/sign.test.ts (4)

apps/w3c-cli/tests/fixtures/mockCredential.ts (1)

• mockCredential (3-26)

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

• VerifiableCredential (69-69)

apps/w3c-cli/src/commands/sign.ts (3)

• promptForInputs (90-110)
• signCredentialWithKeyPair (62-73)
• saveSignedCredential (76-87)

apps/w3c-cli/tests/fixtures/mockDidWeb.ts (1)

• mockKeyPair (3-11)

apps/w3c-cli/tests/commands/verify.test.ts (5)

apps/w3c-cli/tests/fixtures/mockCredential.ts (1)

• mockSignedCredential (28-39)

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

• getDocumentLoader (102-192)

apps/w3c-cli/tests/fixtures/mockDidWeb.ts (1)

• mockWellKnown (13-29)

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

• isCredentialStatusStatusList (113-122)

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

• verifyCredential (354-456)

apps/w3c-cli/tests/fixtures/mockCredential.ts (1)

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

• RawVerifiableCredential (92-92)
• SignedVerifiableCredential (71-90)

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

apps/w3c-cli/tests/fixtures/mockDidWeb.ts (2)

• mockKeyPair (3-11)
• mockWellKnown (13-29)

apps/w3c-cli/tests/fixtures/mockCredential.ts (2)

• mockCredential (3-26)
• mockSignedCredential (28-39)

apps/w3c-cli/src/types.ts (1)

• IssueDidInput (4-8)

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

• getDocumentLoader (102-192)

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

• isCredentialStatusStatusList (113-122)

apps/w3c-cli/src/commands/credentialStatus/create.ts (2)

apps/w3c-cli/src/commands/credentialStatus/update.ts (4)

• command (15-15)
• handler (18-32)
• promptQuestions (34-120)
• createSignedCredentialStatus (122-157)

apps/w3c-cli/src/utils.ts (1)

• isDirectoryValid (24-32)

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

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

• VerifiableCredential (69-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-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.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-context/src/lib/types.ts (1)

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

• DocumentLoaderObject (22-22)
• Document (21-21)
• DocumentLoader (20-20)

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/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/sign/credentialStatus/index.ts (2)

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

• VerifiableCredential (69-69)
• CredentialStatus (22-25)

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

• assertCredentialStatus (77-88)

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-credential-status/src/lib/utils.test.ts (1)

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

• fetchCredentialStatusVC (159-178)

apps/w3c-cli/src/commands/did.ts (2)

apps/w3c-cli/src/utils.ts (2)

• readJsonFile (14-21)
• isDirectoryValid (24-32)

apps/w3c-cli/src/types.ts (1)

• QuestionType (22-25)

apps/w3c-cli/tests/fixtures/mockDidWeb.ts (1)

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

• PrivateKeyPair (60-64)
• DidWellKnownDocument (83-85)

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/assertions.ts (2)

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

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

• CredentialContextVersion (89-92)
• DATA_INTEGRITY_V2_URL (25-25)

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

• assertCredentialStatusStatusListType (39-45)

apps/w3c-cli/src/commands/sign.ts (4)

apps/w3c-cli/src/commands/derive.ts (1)

• promptForInputs (90-110)

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

• PrivateKeyPair (60-64)

apps/w3c-cli/src/utils.ts (3)

• writeFile (4-11)
• readJsonFile (14-21)
• isDirectoryValid (24-32)

apps/w3c-cli/src/types.ts (2)

• CredentialQuestionType (14-16)
• QuestionType (22-25)

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

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/query.ts (1)

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

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

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

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

• BitstringStatusListCredentialStatus (27-31)

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

• DocumentLoader (17-17)

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

• getDocumentLoader (102-192)

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)

apps/w3c-cli/src/commands/key-pair.ts (2)

apps/w3c-cli/src/utils.ts (2)

• isDirectoryValid (24-32)
• writeFile (4-11)

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

• GeneratedKeyPair (41-41)

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

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

• DocumentLoader (17-17)

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

• SignedVerifiableCredential (71-90)

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

• fetchCredentialStatusVC (159-178)

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

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

apps/w3c-cli/src/commands/verify.ts (3)

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

• SignedVerifiableCredential (71-90)
• CredentialStatus (22-25)

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

• GeneralCredentialStatus (22-25)

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

• isCredentialStatusStatusList (113-122)

apps/w3c-cli/src/commands/credentialStatus/update.ts (2)

apps/w3c-cli/src/commands/credentialStatus/create.ts (5)

• command (12-12)
• handler (15-27)
• promptQuestions (29-135)
• createSignedCredentialStatus (137-173)
• saveSignedCredentialStatus (175-181)

apps/w3c-cli/src/utils.ts (2)

• readJsonFile (14-21)
• isDirectoryValid (24-32)

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

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

• CryptoSuiteName (94-94)

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)

apps/w3c-cli/tests/commands/did.test.ts (3)

apps/w3c-cli/src/commands/did.ts (3)

• promptQuestions (50-98)
• getIssuedDid (25-41)
• saveIssuedDid (43-48)

apps/w3c-cli/src/types.ts (1)

• IssueDidInput (4-8)

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

• IssuedDIDOption (4-6)

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

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

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

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

• queryDidDocument (7-7)

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-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/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)

apps/w3c-cli/tests/commands/key-pair.test.ts (1)

apps/w3c-cli/src/commands/key-pair.ts (2)

• promptQuestions (22-52)
• generateAndSaveKeyPair (54-91)

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/helper/index.ts (6)

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 (89-92)

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

• assertCredentialStatuses (20-34)

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

• assertBitstringStatusListEntry (127-127)

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

• BitstringStatusListCredentialStatus (27-31)

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-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-vc/src/lib/types.ts (1)

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

• CryptoSuiteName (64-64)

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

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

• isRawDocumentV1_1 (33-33)
• isRawDocument (28-28)
• isRawDocumentV2_0 (34-34)
• isSignedDocument (29-29)
• isSignedDocumentV1_1 (35-35)
• 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 (89-92)
• getDocumentLoader (102-192)

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

• PrivateKeyPair (60-64)

apps/w3c-cli/src/commands/derive.ts (3)

apps/w3c-cli/src/commands/sign.ts (1)

• promptForInputs (90-110)

apps/w3c-cli/src/utils.ts (3)

• writeFile (4-11)
• readJsonFile (14-21)
• isDirectoryValid (24-32)

apps/w3c-cli/src/types.ts (2)

• RevealQuestionType (18-20)
• QuestionType (22-25)

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 (2)

• bbs2020CredentialV1_1 (3-68)
• bbs2020CredentialV2_0 (152-216)

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

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

🪛 Gitleaks (8.28.0)

apps/w3c-cli/tests/main.test.ts

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

(generic-api-key)

---

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

(generic-api-key)

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

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

(generic-api-key)

---

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

(generic-api-key)

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

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

(generic-api-key)

---

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

(generic-api-key)

---

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

(generic-api-key)

🪛 LanguageTool

packages/w3c/CHANGELOG.md

[grammar] ~160-~160: Ensure spelling is correct
Context: ...12) (2025-05-14) ### Bug Fixes * add qrcode context ([#55](https://github.com/Trust...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

apps/w3c-cli/CHANGELOG.md

[grammar] ~132-~132: Ensure spelling is correct
Context: ...12) (2025-05-14) ### Bug Fixes * add qrcode context ([#55](https://github.com/Trust...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

packages/w3c-vc/CHANGELOG.md

[grammar] ~160-~160: Ensure spelling is correct
Context: ...12) (2025-05-14) ### Bug Fixes * add qrcode context ([#55](https://github.com/Trust...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

packages/w3c-credential-status/CHANGELOG.md

[grammar] ~132-~132: Ensure spelling is correct
Context: ....8) (2025-05-14) ### Bug Fixes * add qrcode context ([#55](https://github.com/Trust...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

packages/w3c-context/CHANGELOG.md

[grammar] ~125-~125: Ensure spelling is correct
Context: ....8) (2025-05-14) ### Bug Fixes * add qrcode context ([#55](https://github.com/Trust...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🪛 markdownlint-cli2 (0.18.1)

packages/w3c/CHANGELOG.md

4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

11-11: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

18-18: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

25-25: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

32-32: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

39-39: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

46-46: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

53-53: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

60-60: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

67-67: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

74-74: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

81-81: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

88-88: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

95-95: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

102-102: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

109-109: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

116-116: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

packages/w3c-vc/CHANGELOG.md

4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

11-11: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

18-18: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

25-25: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

32-32: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

39-39: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

46-46: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

53-53: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

60-60: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

67-67: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

74-74: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

81-81: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

88-88: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

95-95: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

102-102: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

109-109: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

116-116: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

packages/w3c-credential-status/CHANGELOG.md

4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

11-11: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

18-18: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

25-25: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

32-32: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

39-39: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

46-46: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

53-53: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

60-60: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

67-67: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

74-74: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

81-81: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

88-88: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

packages/w3c-context/CHANGELOG.md

4-4: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

11-11: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

18-18: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

25-25: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

32-32: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

39-39: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

46-46: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

53-53: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

60-60: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

67-67: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

74-74: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

81-81: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

packages/w3c-issuer/README.md

32-32: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

39-39: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

46-46: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

---

102-102: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Document BitstringStatusList support mentioned in the PR.

The PR objectives state support for "BitstringStatusList compatible with W3C VC Data Model 2.0," but this isn't documented in the Available Context URLs section. Line 63 references "Status List 2021 v1"—clarify whether this is equivalent, or add a separate BitstringStatusList entry if it's a distinct context.

🤖 Prompt for AI Agents

packages/w3c-context/README.md lines 54-81: The README lists "Status List 2021
v1" but the PR mentions explicit support for a BitstringStatusList compatible
with W3C VC Data Model 2.0; update the Available Context URLs to either (a)
clarify that `https://w3id.org/vc/status-list/2021/v1` is the same as the
BitstringStatusList and add a parenthetical note to that entry, or (b) if
BitstringStatusList uses a distinct context, add a new bullet with the exact
BitstringStatusList context URL and a short label (e.g., "Bitstring Status List
— W3C VC Data Model 2.0") and include a one-line description; ensure wording
matches the PR claim and update any nearby text to remove ambiguity.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Replace example.com with a production-appropriate domain.

The context uses https://example.com/terms for all term IRIs. The example.com domain is reserved for documentation and examples per RFC 2606 and should not be used in production contexts. Consider using:

• A domain owned by the project (e.g., https://trustvc.io/terms)
• A permanent identifier service like https://w3id.org/ (which is commonly used for W3C contexts)

This ensures the context IRIs are resolvable and under the project's control.

Apply this pattern throughout the file:

-      "@id": "https://example.com/terms#cooId"
+      "@id": "https://trustvc.io/terms#cooId"

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

🤖 Prompt for AI Agents

In packages/w3c-context/src/context/coo.json lines 1-196, the context uses
placeholder IRIs under https://example.com/terms; replace every occurrence of
"https://example.com/terms" with your production-controlled terms base IRI
(e.g., https://trustvc.io/terms or a w3id.org IRI) so all "@id" values point to
resolvable, project-owned identifiers, update any nested contexts the same way,
ensure the chosen domain supports HTTPS and will serve or redirect to the
JSON‑LD context, and run any CI/consumers that validate context resolution to
confirm all references resolve correctly.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Replace example.com with production-ready IRIs.

All term IRIs use the https://example.com/terms# namespace, which is a placeholder domain. For production use, these should be replaced with a proper, permanent domain controlled by your organization.

Consider using a domain like https://trustvc.github.io/vocab/warehouse-receipt# or similar, aligned with your organization's vocabulary hosting strategy.

🤖 Prompt for AI Agents

packages/w3c-context/src/context/warehouse-receipt.json lines 1-89: the JSON-LD
context uses placeholder IRIs under https://example.com/terms#, which are not
production-ready; replace all example.com term IRIs with your permanent,
organization-controlled vocabulary IRIs (e.g.,
https://trustvc.github.io/vocab/warehouse-receipt# or your canonical domain),
updating every "@id" value consistently (including nested
goods/brand/piles/etc.) and ensure the new host serves the vocabulary at those
IRIs or redirects to a maintained documentation page.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Document all possible values for CredentialStatusPurpose.

The type definition comment shows only 'revocation' | 'suspension', but the type at line 471 includes 'message'. Update the inline comment to match:

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

// Choose between 'revocation', 'suspension', or 'message'
const purpose: CredentialStatusPurpose = 'revocation';

🤖 Prompt for AI Agents

In packages/w3c-credential-status/README.md around lines 113 to 118, the inline
documentation for CredentialStatusPurpose is missing the 'message' variant;
update the type comment and the explanatory line to include 'message' so the
example and comment match the actual type definition (i.e., document
'revocation', 'suspension', and 'message' in the example).

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Document the purpose and usage of 'message' in CredentialStatusPurpose.

The type definition includes 'message' as a valid option (line 471), but it is never explained in the README. Either document what 'message' means and when to use it, or remove it from the type if it is not yet supported.

Can you clarify whether 'message' is a supported purpose and provide usage guidance if so?

---

I'll verify the review comment by searching the codebase for information about the 'message' purpose and its usage.

---

🏁 Script executed:

#!/bin/bash
# Search for 'message' references in the README
echo "=== Searching README for 'message' documentation ==="
fd -e md -x grep -n "message" {} + | head -20

echo -e "\n=== Checking the specific README file ==="
fd "README.md" -x grep -n "message" {} +

echo -e "\n=== Searching for CredentialStatusPurpose usage in implementation files ==="
rg -n "CredentialStatusPurpose" --type=ts --type=js -C 3

echo -e "\n=== Searching for 'revocation\|suspension\|message' patterns in source ==="
rg -n "revocation|suspension|message" --type=ts --type=js -g "!node_modules" -C 2 | head -40

Length of output: 21422

---

Let me search for additional context about the 'message' purpose:

Remove 'message' from CredentialStatusPurpose type or document its intended usage.

The type definition includes 'message' (line 471 of README), but it's not supported by the validation logic. The assertAllowedStatusPurpose function in packages/w3c-credential-status/src/lib/BitstringStatusList/assertions.ts (line 52) explicitly allows only ['revocation', 'suspension'] and rejects any other value with the error: "Unsupported statusPurpose: statusPurpose must be 'revocation' or 'suspension'."

Additionally, the CLI offers only these two options (lines 80–91 of create.ts) and all tests use only these values. Unless 'message' is intended for future support with accompanying documentation, it should be removed from the type definition to avoid misleading developers.

🤖 Prompt for AI Agents

In packages/w3c-credential-status/README.md around lines 452 to 472, the
CredentialStatusPurpose type includes 'message' which is not supported by
validation, CLI, or tests; remove 'message' from the type definition and any
examples in this README so CredentialStatusPurpose becomes only 'revocation' |
'suspension', or alternatively if 'message' is intended keep it and update
assertAllowedStatusPurpose, CLI options, tests, and documentation to fully
support and document its semantics; ensure the README, assertion code, and CLI
stay consistent.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

🧩 Analysis chain

Update JSDoc and verify single-label domain rejection is intentional.

The refactored getDomain function introduces stricter validation that may reject previously valid inputs:

1. JSDoc comment is outdated: The comment states the function "strips the query, hash and protocol" but doesn't mention the new validation behavior (hostname must contain a dot, returns undefined for invalid URLs).

2. Single-label domain rejection: Line 64-66 rejects hostnames without a dot (e.g., localhost, internal network names). If this is intentional for production use, it's fine, but it represents a breaking change from more permissive validation.

Apply this diff to update the JSDoc:

 /**
- * Strip the query, hash and protocol from the domain.
+ * Parse and validate a domain, stripping the query, hash, and protocol.
+ * Returns undefined if the domain is invalid or doesn't contain a TLD.
  *
  * @param {string} domain - Domain name (e.g., https://example.com/part/index?id=123)
- * @returns {string} - Domain name (e.g., example.com/part/index)
+ * @returns {string | undefined} - Domain name (e.g., example.com/part/index) or undefined if invalid
  */

Verify that all callsites handle the undefined return value and that rejecting single-label domains is the intended behavior:

---

🏁 Script executed:

#!/bin/bash
# Search for usages of getDomain to verify error handling
rg -n -C3 'getDomain\s*\(' --type=ts

Length of output: 1989

---

Let me look at the full test file to understand the test coverage better:

---

🏁 Script executed:

#!/bin/bash
# Check test file to see if there are tests for single-label domains or edge cases
cat packages/w3c-issuer/src/lib/index.test.ts | head -50

Length of output: 815

---

🏁 Script executed:

#!/bin/bash
# Get more details from the test file to see edge case coverage
fd 'index.test.ts' -t f --exec cat {} \;

Length of output: 42994

---

Update JSDoc comment—callsite error handling and validation design confirmed.

The getDomain function refactoring introduces stricter validation, and verification confirms this is properly handled:

1. Callsite verified: The single usage in query.ts:29 correctly handles the undefined return with if (!domainHostname) { throw new Error('Invalid domain'); }, so error handling is in place.

2. JSDoc outdated: Must be updated to reflect the new validation behavior and undefined return type. The existing comment states "Strip the query, hash and protocol" but omits the hostname validation and return type change.

3. Single-label domain rejection intentional: Test coverage (only multi-label domains like example.com) indicates the dot-requirement for TLD validation is the intended design.

Apply this diff to update the JSDoc:

 /**
- * Strip the query, hash and protocol from the domain.
+ * Parse and validate a domain, stripping the query, hash, and protocol.
+ * Returns undefined if the domain is invalid or lacks a TLD (no dot in hostname).
  *
  * @param {string} domain - Domain name (e.g., https://example.com/part/index?id=123)
- * @returns {string} - Domain name (e.g., example.com/part/index)
+ * @returns {string | undefined} - Domain name (e.g., example.com/part/index) or undefined if invalid
  */

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

🤖 Prompt for AI Agents

In packages/w3c-issuer/src/lib/index.ts around lines 53 to 74, the JSDoc above
getDomain is outdated: update it to state that the function accepts a readonly
string, prepends a protocol if missing, parses and validates the URL, rejects
single-label hostnames (requires a dot/TLD), returns undefined for invalid input
or parse failures, and returns the hostname plus the pathname when pathname is
not just '/' (i.e., hostname or hostname + pathname); note callers must handle
undefined (query.ts already does).

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify test completeness: missing mocks may cause flakiness.

This test calls verifyCredentialStatus(credentialStatus2) without mocking fetchCredentialStatusVC or verifyCredential. This could lead to:

• Unintended network calls
• Test flakiness if external resources are unavailable
• Inconsistent test behavior

Run the following script to check if there are global mocks or if this test relies on real HTTP calls:

---

🏁 Script executed:

#!/bin/bash
# Check if credentialStatus2's statusListCredential URL is mocked elsewhere
rg -C3 'https://trustvc.github.io/did/credentials/statuslist/2' packages/w3c-vc/src/

Length of output: 1025

---

---

🏁 Script executed:

```shell
#!/bin/bash
# Check for global mocks, beforeEach, beforeAll, and jest.mock in the test file
rg -n '(beforeEach|beforeAll|jest\.mock|jest\.spyOn|nock)' packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts | head -30

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Get the full test file structure around the test in question
sed -n '1,199p' packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts | tail -100

Length of output: 3601

---

🏁 Script executed:

#!/bin/bash
# Check if verifyCredentialStatus function mocks its dependencies internally or if there's an import mock
rg -n 'import.*fetchCredentialStatusVC|import.*verifyCredential|jest\.mock' packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts

Length of output: 51

---

🏁 Script executed:

#!/bin/bash
# Look for afterEach to see what's being cleaned up
rg -A10 'afterEach' packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts

Length of output: 844

---

🏁 Script executed:

#!/bin/bash
# Check the actual verifyCredentialStatus implementation to see if it handles mocking
rg -n 'export.*verifyCredentialStatus' packages/w3c-vc/src/lib/verify/credentialStatus/

Length of output: 105

---

---

🏁 Script executed:

```shell
#!/bin/bash
# Get the full import section of the test file
sed -n '1,20p' packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts

Length of output: 932

---

🏁 Script executed:

#!/antml:parameter_description
# Check where w3c_credential_status is imported from and verify the full context
rg -B5 'w3c_credential_status' packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts | head -20

Length of output: 624

---

🏁 Script executed:

#!/bin/bash
# Look at the implementation to understand dependencies
sed -n '21,50p' packages/w3c-vc/src/lib/verify/credentialStatus/index.ts

Length of output: 1064

---

Add missing mocks to test for credential status verification with ECDSA-SD-2023.

The test at lines 188-199 calls verifyCredentialStatus(credentialStatus2) without mocking fetchCredentialStatusVC or verifyCredential, unlike all other tests in this file. This causes actual network calls to https://trustvc.github.io/did/credentials/statuslist/2, making the test unreliable and violating unit test isolation principles.

Add the required mocks before the test assertions:

vi.spyOn(w3c_credential_status, 'fetchCredentialStatusVC').mockResolvedValue(
  credentialStatusVC_ECDSA_SD_2023,
);
vi.spyOn(w3c_vc, 'verifyCredential').mockResolvedValue({ verified: true });

Ensure credentialStatusVC_ECDSA_SD_2023 fixture is defined with the appropriate ECDSA-SD-2023 and v2.0 context matching the test intent.

🤖 Prompt for AI Agents

In packages/w3c-vc/src/lib/verify/credentialStatus/index.test.ts around lines
188-199, the test calls verifyCredentialStatus(credentialStatus2) but fails to
mock fetchCredentialStatusVC and verifyCredential, causing real network calls;
add spies to mock w3c_credential_status.fetchCredentialStatusVC to resolve to
the credentialStatusVC_ECDSA_SD_2023 fixture and w3c_vc.verifyCredential to
resolve to { verified: true } before invoking verifyCredentialStatus, ensure the
credentialStatusVC_ECDSA_SD_2023 fixture exists and includes the ECDSA-SD-2023
and v2.0 context expected by the test, and clean up/restore the spies after the
test if other tests rely on original behavior.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Handle derivation failures before re-verification

If deriveCredential returns an error (e.g., unsupported cryptosuite or invalid pointers), derivedResult.derived will be undefined, and verifyCredential will throw a generic _checkCredential failure. That swallows the real cause and makes debugging impossible. Bail out early with the derivation error instead.

       if (
         !vcStatusListVerificationResult?.verified &&
         vcStatusListVerificationResult.error?.includes(DERIVE_CREDENTIAL_ERROR)
       ) {
         const derivedResult = await deriveCredential(vcStatusList, []);
+        if (!derivedResult?.derived) {
+          const deriveError = derivedResult?.error ?? 'Unknown derivation error.';
+          return {
+            error: `Failed to derive Credential Status VC prior to verification: ${deriveError}`,
+          };
+        }
         vcStatusListVerificationResult = await verifyCredential(derivedResult.derived, options);
       }

📝 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

	const derivedResult = await deriveCredential(vcStatusList, []);
	vcStatusListVerificationResult = await verifyCredential(derivedResult.derived, options);
	}
	const derivedResult = await deriveCredential(vcStatusList, []);
	if (!derivedResult?.derived) {
	const deriveError = derivedResult?.error ?? 'Unknown derivation error.';
	return {
	error: `Failed to derive Credential Status VC prior to verification: ${deriveError}`,
	};
	}
	vcStatusListVerificationResult = await verifyCredential(derivedResult.derived, options);
	}

🤖 Prompt for AI Agents

In packages/w3c-vc/src/lib/verify/credentialStatus/index.ts around lines 63-65,
the code calls verifyCredential(derivedResult.derived) without checking whether
deriveCredential returned an error or undefined derived value; this causes
verifyCredential to throw a generic error that hides the real derivation
failure. Fix by checking the result of deriveCredential: if it indicates an
error (or derived is undefined) immediately return or throw that derivation
error (or a wrapped error preserving the original message) instead of calling
verifyCredential, ensuring types are handled and error details are propagated
for upstream handling.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Use getFirstContext() helper to safely access context.

The code directly accesses credential['@context'][0] without ensuring @context is an array. While _checkCredential validates that @context exists, it may be a string rather than an array. Use the getFirstContext helper function that safely handles both cases.

Apply this diff:

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

📝 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

	// Determine required mandatory pointers based on credential format
	const firstContext = credential['@context'][0];
	const isV2 = firstContext === CredentialContextVersion.v2;
	// Determine required mandatory pointers based on credential format
	const firstContext = getFirstContext(credential);
	const isV2 = firstContext === CredentialContextVersion.v2;

🤖 Prompt for AI Agents

In packages/w3c-vc/src/lib/w3c-vc.ts around lines 280 to 283, the code directly
indexes credential['@context'][0] which can throw when @context is a string;
replace this direct access by calling the existing getFirstContext(credential)
helper to safely obtain the first context (handling string or array), then use
that result to set isV2 (i.e., const firstContext = getFirstContext(credential);
const isV2 = firstContext === CredentialContextVersion.v2).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Avoid mutating the caller's revealedAttributes array.

Line 496 creates a reference to revealedAttributes, and line 527 pushes to this array, mutating the caller's original array. This is an unexpected side effect.

Apply this diff to create a copy:

-        const selectivePointers = revealedAttributes;
+        const selectivePointers = [...revealedAttributes];

📝 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

	const selectivePointers = revealedAttributes;
	// Check if this is already a derived credential by examining the proofValue structure
	const isAlreadyDerived = !(await baseProofDetectors[cryptosuite as SupportedCryptosuite](
	proof.proofValue as string,
	));
	if (isAlreadyDerived) {
	return {
	error: `${cryptosuite} derived credentials cannot be further derived. Multiple rounds of derivation are not supported by this cryptosuite.`,
	};
	}
	// Extract mandatory pointers from the base proof
	const mandatoryPointers = await extractMandatoryPointers(
	proof.proofValue as string,
	cryptosuite,
	);
	// Check if credentialSubject is already in mandatory pointers or selective pointers
	const hasCredentialSubjectInMandatory = mandatoryPointers.some((pointer) =>
	pointer.startsWith('/credentialSubject'),
	);
	const hasCredentialSubjectInSelective = selectivePointers.some((pointer) =>
	pointer.startsWith('/credentialSubject'),
	);
	if (!hasCredentialSubjectInMandatory && !hasCredentialSubjectInSelective) {
	// Only add /credentialSubject if it's not already in mandatory pointers
	// and no credentialSubject properties are selected
	// This ensures the derived credential remains valid per W3C VC specification
	selectivePointers.push('/credentialSubject');
	}
	const selectivePointers = [...revealedAttributes];
	// Check if this is already a derived credential by examining the proofValue structure
	const isAlreadyDerived = !(await baseProofDetectors[cryptosuite as SupportedCryptosuite](
	proof.proofValue as string,
	));
	if (isAlreadyDerived) {
	return {
	error: `${cryptosuite} derived credentials cannot be further derived. Multiple rounds of derivation are not supported by this cryptosuite.`,
	};
	}
	// Extract mandatory pointers from the base proof
	const mandatoryPointers = await extractMandatoryPointers(
	proof.proofValue as string,
	cryptosuite,
	);
	// Check if credentialSubject is already in mandatory pointers or selective pointers
	const hasCredentialSubjectInMandatory = mandatoryPointers.some((pointer) =>
	pointer.startsWith('/credentialSubject'),
	);
	const hasCredentialSubjectInSelective = selectivePointers.some((pointer) =>
	pointer.startsWith('/credentialSubject'),
	);
	if (!hasCredentialSubjectInMandatory && !hasCredentialSubjectInSelective) {
	// Only add /credentialSubject if it's not already in mandatory pointers
	// and no credentialSubject properties are selected
	// This ensures the derived credential remains valid per W3C VC specification
	selectivePointers.push('/credentialSubject');
	}

🤖 Prompt for AI Agents

In packages/w3c-vc/src/lib/w3c-vc.ts around lines 496 to 528, the code assigns
revealedAttributes to selectivePointers and then pushes '/credentialSubject',
mutating the caller's array; create a shallow copy of revealedAttributes (e.g.,
using [...revealedAttributes] or Array.from(revealedAttributes]) and use that
copy for selectivePointers so any push or modification does not affect the
original array, keep the rest of the logic the same and ensure selectivePointers
is used thereafter instead of the original reference.