Cardano Updates

Signed-off-by: A-Chronicle <[email protected]>

The onlyOne() method in Pluto threw a generic Error("something wrong") with no context about what was being looked up or why it failed.

Changes:
- Accept optional context string to identify the caller and query
- Distinguish between empty results (arr.length === 0) and null item
- Report the actual count when multiple results found
- Pass context from getPairByDID() and getPairByName() callers

Fixes #648

Signed-off-by: A-Chronicle <[email protected]>

The validateField method in PresentationVerify passes the filter.pattern
from the presentation definition directly to new RegExp() without any
safety checks. An attacker can craft a presentation request with a regex
pattern that causes catastrophic backtracking (e.g. (a|aa)+b), blocking
the JavaScript event loop indefinitely.

This is an unauthenticated attack vector since the presentation definition
originates from an external verifier.

Add a safeRegex utility that:
- Validates the pattern is a non-empty string
- Enforces a maximum pattern length of 256 characters
- Verifies the pattern compiles as a valid regex
- Detects and rejects patterns with nested quantifiers (ReDoS vectors)
- Detects and rejects patterns with alternation inside quantified groups

Fixes #646

Signed-off-by: A-Chronicle <[email protected]>

The validateField method in PresentationVerify passes the filter.pattern
from the presentation definition directly to new RegExp() without any
safety checks. An attacker can craft a presentation request with a regex
pattern that causes catastrophic backtracking (e.g. (a|aa)+b), blocking
the JavaScript event loop indefinitely.

This is an unauthenticated attack vector since the presentation definition
originates from an external verifier.

Add a safeRegex utility that:
- Validates the pattern is a non-empty string
- Enforces a maximum pattern length of 256 characters
- Verifies the pattern compiles as a valid regex
- Detects and rejects patterns with nested quantifiers (ReDoS vectors)
- Detects and rejects patterns with alternation inside quantified groups

Fixes #646

Signed-off-by: A-Chronicle <[email protected]>

Remove unsafe `as any` casts when accessing `x` and `kid` fields on
publicKeyJwk. Use the SDKs existing `expect()` utility and explicit
type guards to validate that JWK coordinates are present before
passing them to cryptographic operations.

- DIDCommDIDResolver: use `expect()` instead of `as any` for `x`, drop
  unnecessary `as any` for `kid` (already typed on JWK.Base)
- prism/index.ts: replace `as any` on `x` with typeof guard throwing
  InvalidKeyError when x is missing or not a string
- Add test: missing JWK x coordinate in DIDDoc throws InvalidKeyError

Fixes #625

Signed-off-by: A-Chronicle <[email protected]>

When backing up SD+JWT credentials, only the JWT ID field was being
stored instead of the full SDJWT JWS. This caused restore to fail
because SDJWTCredential.fromJWS() expects the complete JWS including
disclosures.

Changes:
- Modified Backup.ts to reconstruct full SDJWT JWS from JWT + disclosures
- Updated tests to use correct data format for SDJWT restore
- Added SDJWT to round-trip backup/restore test
- Exported credential JWS strings from fixtures for test use

Fixes #458

Signed-off-by: A-Chronicle <[email protected]>

The import path was incorrect - ../../../ only goes back to pluto/,
but we need ../../../../ to reach src/ and then access pollux/.

Signed-off-by: A-Chronicle <[email protected]>

- Add proper type assertions and validation for credential data
- Handle disclosure objects with _encoded property format
- Improve SDJWT JWS reconstruction logic
- Add SDJWT with disclosures test fixture and test coverage
- Replace import type with runtime import for Domain error classes

Signed-off-by: A-Chronicle <[email protected]>

- Add module-level documentation to FindDIDSigningKeys explaining:
  * DID verification relationships concept
  * ISSUING_KEY ↔ assertionMethod mapping (for credential issuance)
  * AUTHENTICATION_KEY ↔ authentication mapping (for DID ownership proofs)
  * Why multiple keys exist (key rotation, security, scalability)
  * Reference to W3C DID Core Specification
  * Other verification relationships: keyAgreement, capabilityInvocation, capabilityDelegation

- Enhance CreateJwt documentation:
  * Explain SSI JWT use cases
  * Clarify why ISSUING_KEY is default for credential issuance
  * Document when to use AUTHENTICATION_KEY for authentication flows
  * Add complete JSDoc parameter descriptions

- Add CreateSDJWT documentation:
  * Explain Selective Disclosure JWT (SD-JWT) concept
  * Document privacy-preserving credential sharing use case
  * Reference RFC 9052 specification
  * Explain verification process
  * Confirm SD-JWT also defaults to ISSUING_KEY

- Add matchKeys() documentation:
  * Explain key matching algorithm
  * Clarify multibase and JWK encoding support
  * Ensure keys are authorized for requested purpose

- Provide complete DID document structure example with all verification relationships
- Clarify that SDK currently supports ISSUING_KEY and AUTHENTICATION_KEY

Addresses issue #598: Makes it easier for new contributors to understand
DID verification relationships, key purposes, and SSI concepts.

Signed-off-by: A-Chronicle <[email protected]>

- Add module-level documentation to FindDIDSigningKeys explaining:
  * DID verification relationships concept
  * ISSUING_KEY ↔ assertionMethod mapping (for credential issuance)
  * AUTHENTICATION_KEY ↔ authentication mapping (for DID ownership proofs)
  * Why multiple keys exist (key rotation, security, scalability)
  * Reference to W3C DID Core Specification
  * Other verification relationships: keyAgreement, capabilityInvocation, capabilityDelegation

- Enhance CreateJwt documentation:
  * Explain SSI JWT use cases
  * Clarify why ISSUING_KEY is default for credential issuance
  * Document when to use AUTHENTICATION_KEY for authentication flows
  * Add complete JSDoc parameter descriptions

- Add CreateSDJWT documentation:
  * Explain Selective Disclosure JWT (SD-JWT) concept
  * Document privacy-preserving credential sharing use case
  * Reference RFC 9052 specification
  * Explain verification process
  * Confirm SD-JWT also defaults to ISSUING_KEY

- Add matchKeys() documentation:
  * Explain key matching algorithm
  * Clarify multibase and JWK encoding support
  * Ensure keys are authorized for requested purpose

- Provide complete DID document structure example with all verification relationships
- Clarify that SDK currently supports ISSUING_KEY and AUTHENTICATION_KEY

Addresses issue #598: Makes it easier for new contributors to understand
DID verification relationships, key purposes, and SSI concepts.

Signed-off-by: A-Chronicle <[email protected]>

Addresses review feedback on #566: the mediator may answer a
keylist-update either inline in the same HTTP reply or asynchronously
as a separate inbound message, and the SDK should handle both.

updateKeyListWithDID now registers a MESSAGE listener before sending.
When Send resolves with a matching inline response that response is
used directly (path A); otherwise the method waits for the response to
arrive on the MESSAGE event (path B), racing against the existing 60 s
timeout. The response is matched by piuri and by a thread id equal to
either the outgoing message id or the registered peer DID.

Tests cover the async success path, a response threaded on the peer
DID, an async failure result, and a non-matching thid timing out.

Signed-off-by: Seydi Charyyev <[email protected]>

Extract required claim keys from the presentation request's
input_descriptors.constraints.fields and forward them to
SDJWT.verify() during presentation verification. Previously
hardcoded to [], which meant @sd-jwt/core never enforced that
required claims were actually disclosed by the holder.

Fixes #366

Signed-off-by: Abhigyan Singh <[email protected]>

The previous flow assumed Send.run would resolve to the mediator's
keylist-update-response. In practice it always resolved to undefined:
DIDCommConnection.send returned the registered handler's result rather
than the parsed message, and the SDK never asked the mediator for an
inline reply. Per coordinate-mediation 2.0 the mediator only answers
synchronously when the request carries `return_route: "all"`, and
Mercury auto-attaches that header for the piuris in ReturnRouteProtocols
(packages/wasm/didcomm/src/Wrapper.ts) -- but keylist-update was never
on that list. So every keylist-update went out without return_route, the
mediator dispatched the response asynchronously, and the client never
observed it.

Add keylist-update to ReturnRouteProtocols, make DIDCommConnection.send
return the inline response, and rewrite updateKeyListWithDID to send the
message, race the call against a 60 s timeout, assert the response is a
Message with the expected piuri and a thid matching the outgoing id, and
validate the body via MediationKeysUpdateResponse (throws on any
non-success / non-no_change result).

Tests cover success, no_change, client_error, server_error, malformed
body, timeout, wrong piuri, wrong thid and a missing response. A guard
on ReturnRouteProtocols prevents the same kind of regression that
originally introduced this bug (PR #85).

Closes #391

Signed-off-by: Seydi Charyyev <[email protected]>

Signed-off-by: Yummy-Yums <[email protected]>

Signed-off-by: Yummy-Yums <[email protected]>

Signed-off-by: Yummy-Yums <[email protected]>

Signed-off-by: Yummy-Yums <[email protected]>

Signed-off-by: Abhayraj Jaiswal <[email protected]>

Signed-off-by: Abhayraj Jaiswal <[email protected]>

Signed-off-by: iammdzaidalam <[email protected]>

Signed-off-by: Abhigyan Singh <[email protected]>

Signed-off-by: Pat Losoponkul <[email protected]>

Signed-off-by: Pat Losoponkul <[email protected]>