chore: add multikey and data integrity support

[rongquan1]

Summary by CodeRabbit

New Features

• Added new JSON-LD context files for bill of lading carrier, COO, data integrity, multikey, promissory note, QR code, status list, and warehouse receipt.
• Expanded context support and constants for QR code and template documents.
• Enhanced CLI with improved error handling and support for multiple credential statuses.
• Added optional QR code property to signed credentials.

Bug Fixes

• Improved context handling, error messages, and caching in CLI and libraries.
• Fixed checks for expired and redacted documents.
• Enhanced domain validation and DID resolution logic.

Documentation

• Significantly expanded README and changelogs for context and CLI packages.
• Added detailed usage instructions and context listings.

Tests

• Added and updated test suites and fixtures for new features, error handling, and context coverage.

Chores

• Updated package versions and dependencies across all packages.
• Added scripts for linting and testing, and improved .gitignore handling.
• Added Netlify configuration for CORS and redirect rules.

[coderabbitai]

Walkthrough

This update introduces new JSON-LD contexts, improves error handling and validation in CLI commands, and enhances test coverage with new fixtures and comprehensive tests. Several packages are upgraded to stable releases, and documentation—including READMEs and changelogs—is significantly expanded. Utility and type exports are refined, and a Netlify configuration is added for CORS and redirects.

Changes

Files / Groups	Change Summary
.gitignore	Changed ignore pattern for public/context/ to only ignore *.json files.
netlify.toml, scripts/copy-files.sh	Added Netlify config for CORS and redirects; script now copies additional context files and writes Netlify config.
apps/w3c-cli/CHANGELOG.md, packages/w3c-context/CHANGELOG.md, packages/w3c-credential-status/CHANGELOG.md, packages/w3c-issuer/CHANGELOG.md, packages/w3c-vc/CHANGELOG.md, packages/w3c/CHANGELOG.md	Expanded and detailed changelogs for multiple packages, documenting stable releases and bug fixes.
apps/w3c-cli/package.json, packages/w3c-context/package.json, packages/w3c-credential-status/package.json, packages/w3c-issuer/package.json, packages/w3c-vc/package.json, packages/w3c/package.json	Updated package versions and dependencies to new stable releases.
apps/w3c-cli/src/commands/credentialStatus/create.ts, apps/w3c-cli/src/commands/credentialStatus/update.ts, apps/w3c-cli/src/commands/derive.ts, apps/w3c-cli/src/commands/did.ts, apps/w3c-cli/src/commands/key-pair.ts, apps/w3c-cli/src/commands/sign.ts, apps/w3c-cli/src/commands/verify.ts, apps/w3c-cli/src/utils.ts	Centralized and improved error handling, replaced direct fs operations with utility functions, and enhanced validation logic in CLI commands.
apps/w3c-cli/tests/commands/did.test.ts, apps/w3c-cli/tests/commands/key-pair.test.ts, apps/w3c-cli/tests/commands/sign.test.ts, apps/w3c-cli/tests/commands/verify.test.ts, apps/w3c-cli/tests/main.test.ts	Added or updated tests for CLI commands, focusing on error handling, mocks, and comprehensive coverage.
apps/w3c-cli/tests/fixtures/mockCredential.ts, apps/w3c-cli/tests/fixtures/mockDidWeb.ts	Added new test fixtures for credentials and DID/keypair data.
packages/w3c-context/README.md	Expanded README with detailed usage, API, and development instructions.
packages/w3c-context/src/context/*.json	Added new JSON-LD context files: bill-of-lading-carrier, coo, data-integrity-v2, multikey-v1, promissory-note, qrcode-context, status-list-2021-v1, warehouse-receipt.
packages/w3c-context/src/context/render-method-context.json	Removed trailing blank line.
packages/w3c-context/src/index.ts	Added explicit type-only exports for improved TypeScript compatibility.
packages/w3c-context/src/lib/index.ts	Added new context imports, updated exported context collections, and switched DID resolution to use queryDidDocument.
packages/w3c-credential-status/src/lib/index.ts, packages/w3c-credential-status/src/lib/utils.ts	Added utility and assertion functions for StatusList2021 credential status type checking.
packages/w3c-issuer/src/did-web/index.ts	Exported queryDidDocument function.
packages/w3c-issuer/src/lib/index.ts	Improved domain parsing and validation logic in getDomain.
packages/w3c-vc/src/index.ts	Changed some exports to type-only exports.
packages/w3c-vc/src/lib/helper/index.ts	Changed credential status validation to use a consolidated assertion and softened expiration enforcement from error to warning.
packages/w3c-vc/src/lib/sign/credentialStatus/index.ts	Added assertCredentialStatuses for multi-status validation.
packages/w3c-vc/src/lib/types.ts	Added optional qrCode property to SignedVerifiableCredential type.
packages/w3c-vc/src/lib/w3c-vc.test.ts	Added QR code context and property to test data.
packages/w3c-vc/src/lib/w3c-vc.ts	Changed isSignedDocument to a type predicate function.
package.json	Added scripts for skipping Nx cache in tests and lint auto-fixing; added @types/uuid as a dev dependency.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant CLI_Command
    participant Utils
    participant FS
    participant Logger

    User->>CLI_Command: Run command (e.g., sign, verify, did)
    CLI_Command->>Utils: Validate input (read file, check dir)
    Utils->>FS: Perform file system operation
    FS-->>Utils: Return result or throw error
    Utils-->>CLI_Command: Return or throw error
    CLI_Command->>Logger: Log error if caught
    CLI_Command-->>User: Output result or error message

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Suggested labels

released

Poem

A rabbit hopped through fields of code,
New contexts sprouting down the road.
Errors now caught, with warnings bright,
Test carrots nibbled left and right.
Type exports pruned, dependencies bloom—
This patch brings springtime to the room!
🐇✨

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

npm error code ERR_SSL_WRONG_VERSION_NUMBER
npm error errno ERR_SSL_WRONG_VERSION_NUMBER
npm error request to https://10.0.0.28:4873/npm/-/npm-8.19.4.tgz failed, reason: C0AC95DEE97F0000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:354:
npm error
npm error A complete log of this run can be found in: /.npm/_logs/2025-07-24T02_14_22_929Z-debug-0.log

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/add-multikey-data-integrity-support

---

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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[sgtx-nghaninn]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 12

🔭 Outside diff range comments (3)

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

130-134: expect(...).equals(...) is not a Vitest/Jest matcher – tests will fail.

Vitest follows Jest’s matcher API (toEqual, toBe, etc.). The Chai-style equals function is not attached to expect, so these calls will throw TypeError: expect(...).equals is not a function.

-expect(signedCredential.error).equals('"privateKeyBase58" property in keyPair is required.');
+expect(signedCredential.error).toEqual(
+  '"privateKeyBase58" property in keyPair is required.',
+);

Please replace every .equals(...) occurrence with .toEqual(...) (or .toBe(...) for primitives) throughout the file.

Also applies to: 150-156, 191-194

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

76-87: Improve error handling in saveDerivedCredential function.

The function catches errors but throws a generic error message, losing the original error information which could be valuable for debugging.

export const saveDerivedCredential = async (
  derivedCredential: SignedVerifiableCredential,
  outputPath: string,
) => {
  const filePath = `${outputPath}/derived_vc.json`;
  try {
    writeFile(filePath, derivedCredential);
    console.log(chalk.green(`Derived credential saved successfully to ${filePath}`));
  } catch (err) {
-   throw new Error(`Unable to save derived credential to ${filePath}`);
+   throw new Error(`Unable to save derived credential to ${filePath}: ${err instanceof Error ? err.message : err}`);
  }
};

---

61-73: Update derivedCredential function to use consistent error handling.

This function still uses the old error handling pattern (console.error + return null) while other functions have been updated to throw errors. This inconsistency makes the handler function's error checking at line 51 necessary but creates a mixed error handling approach.

export const derivedCredential = async (
  credentialData: SignedVerifiableCredential,
  revealData: ContextDocument,
): Promise<SignedVerifiableCredential> => {
  const result = await deriveCredential(credentialData, revealData);

  if (result?.derived) {
    return result.derived;
  } else {
-   console.error(chalk.red(`Error: ${result.error}`));
-   return null;
+   throw new Error(result.error || 'Failed to derive credential');
  }
};

This change would eliminate the need for the null check in the handler function and provide consistent error handling throughout the module.

🧹 Nitpick comments (21)

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

36-38: New deps – verify necessity & compatibility

jsonld-signatures@^7.0.0 is added while did-resolver remains.
• If DID resolution was fully migrated to queryDidDocument, consider dropping did-resolver to avoid dead weight.
• Confirm jsonld-signatures v7 is compatible with Node ≥18 and any bundlers used in downstream projects.

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

32-34: Consider tighter dependency ranges for safety.

All dependencies are declared with caret (^), which permits future minor/patch releases. Given these packages evolve rapidly, a breaking change shipped under the same major version could slip through. If stability is a priority for downstream consumers, you might want to:

-    "@trustvc/w3c-context": "^1.2.13",
-    "@trustvc/w3c-issuer": "^1.2.4",
+    "@trustvc/w3c-context": "1.2.13",
+    "@trustvc/w3c-issuer": "1.2.4",

A lock-file alone cannot help library consumers who install this as a dependency.

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

13-19: Great to see QR-code coverage added, but verify VC logic handles it.

The added qrCode property is not asserted anywhere in the test. To guard against regressions, consider asserting that the signed VC still contains the qrCode block after the round-trip:

@@
     const signedCredential = await signCredential(credential, signingKeyPair);
+    expect(signedCredential.signed.qrCode).toEqual({
+      type: 'TrustVCQRCode',
+      uri: 'https://localhost:3000/qrcode',
+    });

This ensures signing/deriving does not accidentally strip the new field.

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

37-40: Align dependency versions with the library packages to avoid peer-dependency warnings.

@trustvc/w3c-vc is pinned to ^1.2.17, while its transitive peers (context, credential-status) are at ^1.2.13. Make sure these ranges remain mutually compatible; otherwise, publish a coordinated release (e.g., all packages at 1.2.18) to keep the ecosystem in lock-step.

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

30-41: Consider refactoring to reduce code duplication.

The new function follows the correct pattern but duplicates logic from assertCredentialStatusType. Consider refactoring to reduce duplication while maintaining type safety.

+/**
+ * Asserts the type of the credential status for specific supported types.
+ * @param type - The type of the credential status.
+ * @param supportedTypes - Array of supported types.
+ * @throws {Error} - Throws an error if the type is not supported.
+ */
+const assertCredentialStatusTypeInternal = <T>(type: T, supportedTypes: T[]): void => {
+  if (!supportedTypes.includes(type)) {
+    throw new Error(`Unsupported type: ${type}`);
+  }
+};

 export const assertCredentialStatusType = <T>(type: T): void => {
-  const supportedTypes: T[] = ['StatusList2021Entry', 'TransferableRecords'] as T[];
-
-  if (!supportedTypes.includes(type)) {
-    throw new Error(`Unsupported type: ${type}`);
-  }
+  assertCredentialStatusTypeInternal(type, ['StatusList2021Entry', 'TransferableRecords'] as T[]);
 };

 export const assertCredentialStatusStatusListType = <T>(type: T): void => {
-  const supportedTypes: T[] = ['StatusList2021Entry'] as T[];
-
-  if (!supportedTypes.includes(type)) {
-    throw new Error(`Unsupported type: ${type}`);
-  }
+  assertCredentialStatusTypeInternal(type, ['StatusList2021Entry'] as T[]);
 };

packages/w3c-context/src/context/qrcode-context.json (1)

1-20: JSON-LD context structure is correct, consider domain ownership.

The JSON-LD context follows proper specification with appropriate use of @protected, @version, and type definitions. The xsd:anyURI type for the uri property is semantically correct.

Consider using your own domain instead of example.org for production contexts:

{
  "@context": {
    "@version": 1.1,
    "@protected": true,
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "qrCode": {
-     "@id": "https://example.org/terms#qrCode",
+     "@id": "https://trustvc.io/terms#qrCode",
      "@context": {
        "@protected": true,
        "uri": {
-         "@id": "https://example.org/terms#uri",
+         "@id": "https://trustvc.io/terms#uri",
          "@type": "xsd:anyURI"
        },
        "type": {
-         "@id": "https://example.org/terms#type"
+         "@id": "https://trustvc.io/terms#type"
        }
      }
    }
  }
}

This ensures you maintain control over the vocabulary definitions and aligns with your domain ownership.

packages/w3c-credential-status/CHANGELOG.md (1)

32-32: Fix markdown heading hierarchy violations.

The static analysis tool correctly identifies heading level issues where h3 headings appear without proper h2 parents, violating markdown standards (MD001).

Apply this pattern to fix the heading hierarchy:

-### Bug Fixes
+## Bug Fixes

This should be applied to lines 32, 39, and 46 to maintain proper heading structure throughout the changelog.

Also applies to: 39-39, 46-46

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

41-59: Good centralized error handling implementation!

The try-catch wrapper provides consistent error handling and formatting. However, consider removing the null checks on lines 43 and 52 (if (!answers) return; and if (!signedCredential) return;) since the functions now throw errors on failure rather than returning null.

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

---

84-86: Consider preserving original error information.

The current implementation replaces the original error with a generic message, which may lose valuable debugging information.

  } catch (err) {
-   throw new Error(`Unable to save signed credential to ${filePath}`);
+   throw new Error(`Unable to save signed credential to ${filePath}: ${err instanceof Error ? err.message : err}`);
  }

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

32-43: Remove redundant mock declarations.

The mocks for fs and chalk don't override any functionality and just return the original modules. These can be removed to simplify the test setup.

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

---

99-99: Remove unnecessary spy creation.

Since verifyCredential is already mocked, creating a spy on the actual implementation doesn't serve any purpose here.

-const verifyCredentialSpy = vi.spyOn(w3cVc, 'verifyCredential');

And update the expectation to use the mocked function directly:

-expect(verifyCredentialSpy).toHaveBeenCalledWith(mockSignedCredential);
+expect(verifyCredential).toHaveBeenCalledWith(mockSignedCredential);

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

184-195: Fix misleading test description.

The test description mentions "log" but the test actually expects an error to be thrown.

-it('should log "KeyPair already exists" error and return undefined', async () => {
+it('should throw "KeyPair already exists" error', async () => {

---

197-207: Fix another misleading test description.

Similar to the previous test, this description is incorrect about the expected behavior.

-it('should log generic "Error generating DID token" for other errors and return undefined', async () => {
+it('should throw generic "Error generating DID token" for other errors', async () => {

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

78-85: Improve error message clarity for credential status failures.

The error aggregation could be more informative by including which specific credential status failed.

-      throw new Error(
-        `${credentialStatusResult
-          ?.filter((r) => r.error)
-          ?.map((r) => r.error)
-          ?.join(', ')}`,
-      );
+      const failedStatuses = credentialStatusResult
+        ?.filter((r) => r.error)
+        ?.map((r, index) => `Status ${index + 1}: ${r.error}`)
+        ?.join('; ');
+      throw new Error(`Credential status verification failed: ${failedStatuses}`);

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

13-25: Simplify mock setup for better maintainability.

The mock setup is quite verbose and could be streamlined. Consider consolidating the mocks or using more specific mocking patterns.

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

Since you're not extending the original modules in a meaningful way, the simpler approach would be cleaner.

---

152-163: Improve test robustness for signing failure.

The test artificially creates an invalid key pair but the assertion is quite generic. Consider testing more specific failure scenarios.

-    it('should throw error when signing fails', async () => {
-      // Using a key pair that is structurally different to ensure failure
-      const highlyInvalidKeyPair = {
-        ...mockKeyPair,
-        type: 'NonExistentKeyType',
-        privateKeyBase58: 'Invalid',
-      } as any;
-
-      await expect(
-        signCredentialWithKeyPair(mockCredential, highlyInvalidKeyPair),
-      ).rejects.toThrowError();
-    });
+    it('should throw error when signing fails', async () => {
+      // Test with completely missing required properties
+      const invalidKeyPair = {} as any;
+
+      await expect(
+        signCredentialWithKeyPair(mockCredential, invalidKeyPair),
+      ).rejects.toThrowError('Unable to sign credential');
+    });

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

78-85: Redundant keyPair object construction.

The code creates a new keyPair object and conditionally populates it, but then all properties are assigned anyway for the Bls12381G2Key2020 type. This could be simplified.

-  const keyPair: GeneratedKeyPair = {
-    type: keypairData.type,
-  };
-  if (keypairData.type === VerificationType.Bls12381G2Key2020) {
-    keyPair.seedBase58 = keypairData.seedBase58;
-    keyPair.privateKeyBase58 = keypairData.privateKeyBase58;
-    keyPair.publicKeyBase58 = keypairData.publicKeyBase58;
-  }
+  const keyPair: GeneratedKeyPair = {
+    type: keypairData.type,
+    ...(keypairData.type === VerificationType.Bls12381G2Key2020 && {
+      seedBase58: keypairData.seedBase58,
+      privateKeyBase58: keypairData.privateKeyBase58,
+      publicKeyBase58: keypairData.publicKeyBase58,
+    }),
+  };

---

72-76: Improve error message specificity.

The generic "Error generating keypair" message could be more helpful by preserving the original error context.

-    throw new Error('Error generating keypair');
+    throw new Error(`Error generating keypair: ${err instanceof Error ? err.message : String(err)}`);

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

63-66: Remove redundant beforeEach block

This beforeEach block duplicates the cleanup already performed in the parent describe block (lines 57-60).

  describe('w3c-cli sign command', () => {
-    beforeEach(() => {
-      vi.clearAllMocks();
-      vi.resetAllMocks();
-    });
-
    it('should successfully sign a credential and save it', async ({ expect }) => {

---

270-278: Simplify beforeEach block and remove unnecessary type casting

The vi.clearAllMocks() and vi.resetAllMocks() calls duplicate the parent beforeEach. Additionally, the type casting for spies is unnecessary.

    beforeEach(() => {
-      vi.clearAllMocks();
-      vi.resetAllMocks();
      vi.restoreAllMocks();

-      issueDIDSpy = vi.spyOn(w3cIssuer, 'issueDID') as MockedFunction<typeof w3cIssuer.issueDID>;
-      writeFileSpy = vi.spyOn(utils, 'writeFile') as MockedFunction<typeof utils.writeFile>;
-      consoleErrorSpy = vi.spyOn(console, 'error') as MockedFunction<typeof console.error>;
+      issueDIDSpy = vi.spyOn(w3cIssuer, 'issueDID');
+      writeFileSpy = vi.spyOn(utils, 'writeFile');
+      consoleErrorSpy = vi.spyOn(console, 'error');
    });

---

386-389: Remove redundant beforeEach block

This beforeEach block duplicates the cleanup already performed in the parent describe block.

  describe('w3c-cli verify command', () => {
-    beforeEach(() => {
-      vi.clearAllMocks();
-      vi.resetAllMocks();
-    });
-
    it('should successfully verify credential when called with valid input', async ({ expect }) => {

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8380e2d and 15849ef.

⛔ Files ignored due to path filters (1)

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

📒 Files selected for processing (53)

• .gitignore (1 hunks)
• apps/w3c-cli/CHANGELOG.md (1 hunks)
• apps/w3c-cli/package.json (2 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)
• package.json (2 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/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.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 (4 hunks)
• packages/w3c-credential-status/CHANGELOG.md (1 hunks)
• packages/w3c-credential-status/package.json (2 hunks)
• packages/w3c-credential-status/src/lib/index.ts (2 hunks)
• packages/w3c-credential-status/src/lib/utils.ts (1 hunks)
• packages/w3c-issuer/CHANGELOG.md (1 hunks)
• packages/w3c-issuer/package.json (1 hunks)
• packages/w3c-issuer/src/did-web/index.ts (1 hunks)
• packages/w3c-issuer/src/lib/index.ts (1 hunks)
• packages/w3c-vc/CHANGELOG.md (1 hunks)
• packages/w3c-vc/package.json (2 hunks)
• packages/w3c-vc/src/index.ts (1 hunks)
• packages/w3c-vc/src/lib/helper/index.ts (3 hunks)
• packages/w3c-vc/src/lib/sign/credentialStatus/index.ts (2 hunks)
• packages/w3c-vc/src/lib/types.ts (1 hunks)
• packages/w3c-vc/src/lib/w3c-vc.test.ts (2 hunks)
• packages/w3c-vc/src/lib/w3c-vc.ts (1 hunks)
• packages/w3c/CHANGELOG.md (1 hunks)
• packages/w3c/package.json (2 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 (10)

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

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

• isSignedDocument (24-24)

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

• SignedVerifiableCredential (41-55)

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

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

• GeneralCredentialStatus (22-25)

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

• assertCredentialStatusStatusListType (35-41)

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

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/commands/did.ts (3)

• command (7-7)
• handler (10-23)
• promptQuestions (50-98)

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

• command (8-8)
• handler (11-20)
• promptQuestions (22-52)

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

• isDirectoryValid (24-32)

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

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

• VerifiableCredential (39-39)

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

• assertCredentialStatus (73-81)

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

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

• RawVerifiableCredential (57-57)
• SignedVerifiableCredential (41-55)

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

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

• assertCredentialStatuses (21-35)

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

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

• SignedVerifiableCredential (41-55)

scripts/initial_release.js (1)

• chalk (4-4)

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

• GeneralCredentialStatus (22-25)

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

• isCredentialStatusStatusList (96-103)

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

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

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

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

• describe (9-9)
• promptQuestions (22-52)

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

• IssueDidInput (4-8)

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

• IssuedDIDOption (4-6)

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

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

• PrivateKeyPair (51-51)
• DidWellKnownDocument (63-65)

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

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

• isCredentialStatusStatusList (96-103)

🪛 markdownlint-cli2 (0.17.2)

packages/w3c-credential-status/CHANGELOG.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)

🪛 Gitleaks (8.27.2)

apps/w3c-cli/tests/fixtures/mockDidWeb.ts

8-8: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

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

322-322: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

(generic-api-key)

🔇 Additional comments (80)

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

3-3: Version bump looks good

The package.json now advertises 1.2.4, matching the new CHANGELOG entry. No other metadata touched.

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

3-8: Confirm availability & avoid circular import of queryDidDocument

queryDidDocument is re-exported here, but it originates from ./wellKnown/query.
Please double-check that:

1. packages/w3c-issuer/src/did-web/wellKnown/query.ts (or .js) actually exports queryDidDocument by name.
2. No circular dependency is introduced between did-web/index.ts and wellKnown/query.

A quick grep or unit test will surface either issue early.

.gitignore (1)

53-53: Git-ignore rule change – validate generated artefacts

Only public/context/*.json is ignored now. Any non-JSON artefacts (e.g. .jsonld, .html, signatures) produced by the build pipeline under public/context/ will start to be committed. Make sure that is intentional and CI remains green.

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

3-3: Large version jump – ensure changelog & tags are in sync

Jumping from 1.2.3-alpha.2 to 1.2.13 is fine, but remember to publish matching tags and release notes so downstream consumers aren’t surprised.

packages/w3c-issuer/CHANGELOG.md (1)

1-20: Changelog entries align with version bump

Entries for 1.2.2-1.2.4 are present and formatted correctly.

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

3-3: Version bump is coherent with the sibling packages – looks good.
No functional or semantic issues spotted with the move from 1.2.3-alpha.2 to 1.2.13.

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

2-4: export type * from … requires TS ≥ 5.0 – confirm consumer toolchains.

export type * is brilliant for tree-shaking, but projects locked to < TS 5 will fail to compile. If backward compatibility is a concern, consider re-exporting via export { … } from or publishing a major version that documents the new TypeScript baseline.

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

3-3: CLI version bump acknowledged – no issues detected.

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

35-36: LGTM! Dependency versions align with coordinated release.

The dependency version updates are consistent with the package version bump and appear to be part of a coordinated monorepo release.

---

3-3: Coordinated stable release verified – no semantic versioning issues

Changelog entries for version 1.2.17 are present in packages/w3c-vc/CHANGELOG.md and apps/w3c-cli/CHANGELOG.md. The monorepo now has:

• packages/w3c-vc and packages/w3c at version 1.2.17
• packages/w3c-context and packages/w3c-credential-status at 1.2.13
• packages/w3c-issuer at 1.2.4

This confirms the jump from 1.2.7-alpha.3 to 1.2.17 is an intentional, coordinated release from alpha to stable. No further action required.

netlify.toml (1)

6-10: LGTM! Redirect configuration follows best practices.

The redirect from trustvc.io to www.trustvc.io with status = 200 and force = true is properly configured for URL canonicalization while preserving the path structure using :splat.

packages/w3c/package.json (1)

3-3: LGTM! Version updates are consistent with coordinated monorepo release.

The package version and dependency updates align with the coordinated release pattern seen across the monorepo, moving from alpha to stable versions.

Also applies to: 35-38

package.json (3)

14-14: LGTM! Useful script for debugging test caching issues.

The test:skip-cache script is helpful for debugging situations where Nx cache might be causing test issues.

---

16-16: LGTM! Convenient script for automatic linting fixes.

The lint:fix script provides a convenient way to automatically fix linting issues across the monorepo.

---

57-57: LGTM! TypeScript support for UUID usage.

Adding @types/uuid provides proper TypeScript definitions for UUID functionality used in the codebase.

scripts/copy-files.sh (2)

16-16: LGTM! Context files expansion looks good.

The addition of new context files follows the established pattern and naming conventions. The new files support enhanced semantic capabilities for business documents and QR codes.

---

23-26: Consider CORS security implications.

The CORS header Access-Control-Allow-Origin = "*" allows requests from any origin. While this might be intentional for publicly accessible context files, consider if this broad access aligns with your security requirements.

If these context files contain sensitive information or if you want to restrict access to specific domains, consider using a more restrictive CORS policy:

echo "[[headers]]
  for = \"/*\"
  [headers.values]
    Access-Control-Allow-Origin = \"https://yourtrusteddomain.com\"" > ./public/netlify.toml

Otherwise, if public access is intended, the current configuration is appropriate.

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

12-20: LGTM! Import additions are appropriate.

The new imports support the added functionality and follow the existing import patterns in the file.

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

4-11: LGTM! Error handling improvement is consistent.

The change from console error logging to throwing exceptions enables better error handling by upstream callers and aligns with the broader refactoring pattern across the CLI commands.

---

14-21: LGTM! Consistent error handling improvement.

The change to throw descriptive errors instead of logging enables proper error propagation to calling functions. The error message includes helpful context with the file type and path.

---

24-32: LGTM! Appropriate change from error to warning.

Changing from console.error to console.warn with yellow coloring is more appropriate since directory validation failure is handled gracefully by returning false. This provides better UX by not alarming users with red error messages for recoverable validation failures.

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

44-46: Excellent type predicate enhancement!

The change from returning boolean to using a TypeScript type predicate (document is SignedVerifiableCredential) significantly improves type safety. This allows TypeScript to narrow the type of document in conditional blocks, providing better IntelliSense and compile-time type checking for consumers of this function.

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

80-82: Improved error assertion pattern!

Excellent change from console error spying to direct error assertion. This approach is more reliable and tests the actual behavior rather than side effects.

---

156-158: Consistent error testing approach!

Good use of direct error assertion with a specific error message. This ensures the function properly validates input and throws meaningful errors.

---

170-170: Clear error handling test!

The test properly verifies that generic errors are handled appropriately when key pair generation fails.

---

184-186: Comprehensive error coverage!

Good test coverage for file system errors with a descriptive error message that includes the file path.

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

1-76: Comprehensive and well-structured changelog!

Excellent documentation of the version progression from alpha to stable releases. The changelog follows best practices with:

• Proper semantic versioning and GitHub comparison links
• Clear issue references and commit hashes for traceability
• Consistent formatting and categorization
• Detailed descriptions of bug fixes and improvements

This provides excellent visibility into the package's evolution and makes it easy for consumers to understand changes between versions.

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

12-18: Excellent type-only export refinement!

Great improvement in using explicit type-only exports. This ensures:

• Clean separation between types and runtime exports
• Better tree-shaking for consumers
• Prevents accidental runtime usage of type-only imports
• Follows TypeScript best practices for library exports

The explicit export type declarations make the intent clear and improve the package's TypeScript integration.

packages/w3c/CHANGELOG.md (1)

1-77: LGTM! Comprehensive changelog documentation.

The changelog provides excellent documentation of the version progression from 1.2.7-alpha.3 to 1.2.17, with clear categorization of bug fixes and proper semantic versioning. Each entry includes appropriate GitHub issue references and commit hashes for traceability.

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

1-77: LGTM! Well-documented context enhancements.

The changelog effectively documents the progression of context additions and improvements that align with the PR's multikey and data integrity objectives. The incremental version updates show systematic enhancement of the package capabilities.

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

15-27: LGTM! Improved error handling pattern.

The addition of try-catch error handling in the handler function follows a consistent pattern with other CLI commands and provides better user experience by properly logging errors with colored output.

---

10-10: Good refactoring to use utility functions.

The import changes reflect good refactoring by removing direct fs usage and utilizing the centralized isDirectoryValid utility function, which promotes code reuse and consistent error handling across CLI commands.

---

69-69: Consistent error handling with utility function.

The replacement of inline directory validation with the isDirectoryValid utility function and throwing an error instead of early return aligns with the improved error handling pattern where errors are caught at the handler level.

packages/w3c-credential-status/CHANGELOG.md (1)

1-77: LGTM! Comprehensive version documentation.

Despite the heading formatting issues, the changelog content effectively documents the progression of bug fixes and improvements that support the package's evolution and align with the PR's data integrity objectives.

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

1-84: LGTM! Excellent CLI evolution documentation.

The changelog comprehensively documents the CLI's evolution with systematic improvements in error handling, context support, and bug fixes. The version coordination with related packages demonstrates good release management practices.

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

90-110: Excellent refactoring of input validation!

The migration to utility functions (readJsonFile, isDirectoryValid) and throwing errors instead of returning null creates more robust and consistent error handling. The error messages are clear and specific.

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

3-11: Well-structured test fixture with proper immutability.

The mockKeyPair object correctly represents a Bls12381G2Key2020 private key pair with all required fields. The static analysis warning about line 8 is a false positive - the seedBase58 field contains legitimate test fixture data, not an actual API key.

---

13-29: Comprehensive DID well-known document fixture.

The mockWellKnown object provides a complete DID document structure with proper W3C contexts, verification methods, and capability references. The structure aligns well with the mockKeyPair and provides comprehensive test coverage for DID Web scenarios.

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

3-26: Well-structured verifiable credential fixture.

The mockCredential object follows W3C Verifiable Credentials standards with comprehensive contexts, proper credential status implementation using StatusList2021Entry, and realistic subject data. The issuer DID is consistent with other fixtures in the test suite.

---

28-39: Excellent signed credential fixture with consistent proof structure.

The mockSignedCredential properly extends the base credential with a UUID identifier and complete BbsBlsSignature2020 proof. The verificationMethod reference matches the mockKeyPair from the DID Web fixtures, ensuring consistency across the test suite. This provides comprehensive test coverage for credential signing workflows.

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

18-32: Consistent error handling implementation.

The try-catch wrapper follows the same pattern as other refactored commands, providing centralized error handling with consistent formatting. This maintains the existing command flow while improving error management.

---

50-50: Good error handling for invalid URL.

Throwing an error for invalid URLs instead of continuing with invalid data improves the robustness of the command.

---

68-68: Consistent directory validation with utility function.

Using isDirectoryValid with error throwing provides consistent validation behavior across commands.

---

151-156: Improved error handling with proper error preservation.

The updated error handling properly re-throws non-Error exceptions and wraps Error instances with additional context, improving error propagation while maintaining useful debugging information.

---

60-60: readJsonFile always throws on failure—no null return path

I verified in apps/w3c-cli/src/utils.ts (lines 14–21) that readJsonFile either returns the parsed JSON or throws an error in its catch block. There is no code path that returns null, so the calling code’s assumption is safe.

packages/w3c-context/src/context/coo.json (1)

1-196: Comprehensive and well-structured COO JSON-LD context.

The Certificate of Origin context is excellently structured with proper JSON-LD 1.1 compliance, comprehensive vocabulary coverage for supply chain documentation, and appropriate use of nested contexts for complex data relationships. The consistent URI pattern and proper container declarations for arrays demonstrate good JSON-LD practices.

Note that the vocabulary uses https://example.com/terms# URIs, which is appropriate for development/testing but should be replaced with official vocabulary URIs for production use.

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

14-14: Import change aligns with the new consolidated validation approach.

The import of assertCredentialStatuses is consistent with the refactoring to validate multiple credential statuses collectively.

---

226-226: Good refactoring to use the consolidated validation function.

The change to assertCredentialStatuses improves code organization by moving the iteration logic to a dedicated function. This also adds proper validation for TransferableRecords credential status type.

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

54-86: Well-structured tests for credential prompting.

The tests properly cover both success and error cases for credential file reading, with appropriate assertions and error messages.

---

145-147: No change needed: verifyCredentialStatus returns errors via its result object

The implementation of verifyCredentialStatus returns a CredentialStatusResult with an optional error string (see catch block and early returns), rather than throwing. Mocking it with

(verifyCredentialStatus as any).mockResolvedValueOnce({ error: statusError });

is therefore correct. You can disregard the suggestion to throw instead.

Likely an incorrect or invalid review comment.

packages/w3c-context/src/context/status-list-2021-v1.json (1)

1-40: Well-structured JSON-LD context for StatusList2021.

The context properly defines the StatusList2021 vocabulary with appropriate use of @protected to prevent term redefinition and consistent IRI patterns following W3C standards.

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

16-30: Good addition of necessary mocks for enhanced testing.

The async mock setup for isDirectoryValid and issueDID properly maintains type safety while allowing control over their behavior in tests.

---

1-248: Excellent test coverage improvements.

The enhanced tests now properly validate error propagation and include comprehensive edge cases such as invalid JSON content, file vs directory validation, and various error scenarios from the issueDID function.

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

54-56: Good defensive programming with input validation.

The addition of empty string and whitespace validation prevents unnecessary processing and provides clear undefined return for invalid inputs.

---

58-73: Excellent refactor from regex to URL parsing approach.

The new implementation using the URL constructor is more robust and reliable than regex-based validation. The error handling with try-catch appropriately returns undefined for invalid domains, and the hostname validation ensures basic TLD requirements are met.

The logic to prepend "http://" when missing is particularly well thought out for handling various input formats.

packages/w3c-context/src/context/warehouse-receipt.json (1)

43-67: Well-structured nested context for goods array.

The use of @container: "@set" for the goods property is appropriate for handling arrays, and the nested context provides proper semantic mapping for all goods-related properties.

packages/w3c-context/src/context/multikey-v1.json (2)

1-35: Excellent standards-compliant Multikey context implementation.

The JSON-LD context correctly follows W3C security vocabulary standards, using the official https://w3id.org/security# namespace. The type mappings for datetime properties and multibase-encoded keys are properly defined according to W3C specifications.

This implementation aligns well with the PR objective of adding multikey support.

---

24-31: Proper multibase type definitions for cryptographic keys.

The use of https://w3id.org/security#multibase as the @type for both public and secret key properties correctly follows the multibase specification for encoding cryptographic key material.

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

11-23: Excellent centralized error handling pattern.

The addition of try-catch wrapper around the main handler logic provides clean centralized error handling and consistent error messaging. This is a significant improvement over scattered error handling throughout the function.

---

33-37: Good shift from logging to throwing errors.

Changing from console.error to throw new Error allows for proper error propagation and centralized handling. The error messages are descriptive and will help users understand what went wrong.

---

68-68: URL path correction looks appropriate.

The correction to the example URL path in the prompt message improves user guidance. The .well-known/did.json path aligns with DID Web specification requirements.

packages/w3c-context/src/context/bill-of-lading-carrier.json (1)

61-76: Well-structured packages array handling.

The nested context for packages with @container: "@set" properly handles array semantics, and the package properties (description, weight, measurement) cover the essential package information needed for bill of lading documents.

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

31-42: Good error handling pattern implementation.

The centralized error handling with try-catch and consistent error messaging aligns well with the broader CLI improvements mentioned in the summary.

---

53-56: Credential status type compatibility confirmed

The isCredentialStatusStatusList guard narrows each cs to a valid StatusList variant, which is included in the CredentialStatus union exported by @trustvc/w3c-vc. Passing cs to verifyCredentialStatus is therefore type-safe and no changes are required.

packages/w3c-context/src/context/data-integrity-v2.json (2)

1-81: Well-structured JSON-LD context for Data Integrity v2.

The context file follows proper JSON-LD conventions and includes comprehensive mappings for cryptographic proof properties. The structure correctly defines:

• DataIntegrityProof with proper security namespace URIs
• Comprehensive proof purpose mappings with appropriate containers
• Proper type constraints for datetime fields and cryptographic values
• Support for modern cryptosuites as mentioned in the PR objectives

---

66-73: cryptosuite and proofValue type definitions are correct
Both cryptosuite (datatype https://w3id.org/security#cryptosuiteString) and proofValue (datatype https://w3id.org/security#multibase) match the W3C Data Integrity 1.0 specification and the Security Vocabulary context. No changes required.

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

41-62: Excellent test coverage for success path.

The test properly validates the expected structure and uses appropriate matchers for dynamic values like timestamps and IDs.

---

186-197: Good error handling test for file operations.

The test properly simulates file write failures and validates the expected error message format.

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

47-49: Good use of utility function for directory validation.

The replacement of direct fs.readdirSync with the isDirectoryValid utility function improves consistency and error handling across CLI commands.

---

12-20: Consistent error handling implementation.

The centralized try-catch pattern with proper error message formatting aligns well with the broader CLI improvements.

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

58-81: Comprehensive context URL documentation.

The categorized listing of available contexts is very helpful for users. The organization into Core W3C, Cryptographic Suite, and TrustVC Business contexts makes it easy to find relevant contexts.

---

97-120: Excellent modern cryptosuite usage example.

The example clearly demonstrates how to use the Data Integrity context with BBS-2023 and ECDSA-SD-2023, which aligns with the PR objectives for multikey and data integrity support.

---

3-16: Well-structured feature overview.

The feature list clearly communicates the package's capabilities and benefits, making it easy for users to understand the value proposition.

---

27-35: Verified example context URL — the URL in the README (https://w3id.org/security/data-integrity/v2) matches the DATA_INTEGRITY_V2_URL constant in packages/w3c-context/src/lib/index.ts. No changes required.

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

1-1: LGTM! Import changes align with DID resolution consolidation.

The import of queryDidDocument and the new JSON-LD context files follow consistent patterns and support the multikey and data integrity functionality mentioned in the PR objectives.

Also applies to: 8-9, 12-12, 16-18, 20-20, 22-22

---

25-25: LGTM! URL constants follow established patterns.

The new URL constants are properly formatted and align with W3C standards for multikey and data integrity contexts, supporting the PR objectives.

Also applies to: 29-34, 38-39, 41-42, 44-45

---

71-82: LGTM! Context groupings improve organization.

The new qrCodeContexts and templateContexts groupings provide better categorization of related contexts and follow the established pattern used by other context groups.

---

108-109: LGTM! Cache updates align with new context groupings.

The document loader cache correctly includes the new qrCodeContexts and templateContexts groups, ensuring proper caching of the newly added contexts.

---

48-48: Confirm BLS12381 URL context mapping

The new context mappings look correct, but there’s no internal documentation showing that BLS12381_2020_V1_URL should reuse the same bbsV1 context as BBS_V1_URL. Please verify that this reuse is intentional and that no separate BLS12381 context definition is required.

• File: packages/w3c-context/src/lib/index.ts (line 53)

---

123-123: Add error handling around DID resolution

The switch to queryDidDocument is correct, but we should guard against runtime failures and missing data. Wrap the call in a try/catch, validate that wellKnownDid is present, and surface a clear error if not.

File: packages/w3c-context/src/lib/index.ts

   const resolveDid = async (did: string) => {
-    const { wellKnownDid } = await queryDidDocument({ did });
-    const result: DocumentLoaderObject = {
-      contextUrl: null,
-      document: wellKnownDid,
-      documentUrl: did,
-    };
-
-    resultMap.set(did, result);
-    return result;
+    try {
+      const { wellKnownDid } = await queryDidDocument({ did });
+      if (!wellKnownDid) {
+        throw new Error(`No wellKnownDid found for DID: ${did}`);
+      }
+
+      const result: DocumentLoaderObject = {
+        contextUrl: null,
+        document: wellKnownDid,
+        documentUrl: did,
+      };
+
+      resultMap.set(did, result);
+      return result;
+    } catch (e) {
+      const msg = e instanceof Error ? e.message : String(e);
+      throw new Error(`Failed to resolve DID ${did}: ${msg}`);
+    }
   };

• Verify that the queryDidDocument({ did }) call always returns an object with a wellKnownDid property (even if it may be null).
• Ensure downstream logic handles or surfaces any resolution failures appropriately.

[nghaninn]

🎉 This PR is included in version 1.3.0-alpha.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[nghaninn]

🎉 This PR is included in version 1.3.0-alpha.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[nghaninn]

🎉 This PR is included in version 1.3.0-alpha.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[nghaninn]

🎉 This PR is included in version 1.3.0-alpha.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[nghaninn]

🎉 This PR is included in version 1.3.0-alpha.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀

[nghaninn]

🎉 This PR is included in version 1.3.0-alpha.1 🎉

The release is available on:

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

Your semantic-release bot 📦🚀