chore(deps): Bump the patch-updates group across 1 directory with 17 updates

[dependabot]

Bumps the patch-updates group with 17 updates in the / directory:

Package	From	To
@credo-ts/anoncreds	0.7.0	0.7.1
@credo-ts/askar	0.7.0	0.7.1
@credo-ts/core	0.7.0	0.7.1
@credo-ts/didcomm	0.7.0	0.7.1
@credo-ts/indy-vdr	0.7.0	0.7.1
@credo-ts/node	0.7.0	0.7.1
@credo-ts/openid4vc	0.7.0	0.7.1
@credo-ts/question-answer	0.7.0	0.7.1
@credo-ts/tenants	0.7.0	0.7.1
@opentelemetry/api	1.9.0	1.9.1
cors	2.8.5	2.8.6
ws	8.21.0	8.21.3
@types/express-serve-static-core	5.1.0	5.1.3
eslint-import-resolver-typescript	4.4.4	4.4.5
eslint-plugin-prettier	5.5.4	5.5.6
prettier	3.9.6	3.9.8
ts-jest	29.4.6	29.4.12

Updates @credo-ts/anoncreds from 0.7.0 to 0.7.1

Changelog

Sourced from @​credo-ts/anoncreds's changelog.

0.7.1

Patch Changes

• 9f4278b: Add DidDocument.findVerificationMethodsByPurpose and DidDocument.findVerificationMethodsByTypeAndPurpose.

  The relationship-aware methods resolve inline and referenced methods and return them in requested relationship order while preserving entry order within each relationship. The type-filtered method accepts one or more verification-method representations and delegates relationship traversal to the purpose-only method. DIDComm JSON-LD, JWT credentials, presentation selection, DIDComm messaging, AnonCreds data integrity, Cheqd signing, peer DID conversion, and did:webvh signing now use the appropriate shared lookup. AnonCreds credential signing prefers verification methods authorized for assertionMethod, with declared verificationMethod entries as a fallback.

• b75467c: Move the W3C Data Integrity credential attachment format (Aries RFC 0809) out of @credo-ts/anoncreds and into @credo-ts/didcomm, where the rest of the format already lived. The format is not anoncreds specific: binding a credential to an anoncreds link secret is one of its binding methods, next to the didcomm signed attachment method and to not binding the credential at all. Issuing a plain W3C credential over this format no longer requires depending on @credo-ts/anoncreds.

  • Added DidCommDataIntegrityCredentialFormatService to @credo-ts/didcomm. DataIntegrityDidCommCredentialFormatService in @credo-ts/anoncreds is now a deprecated alias for it and will be removed in the next major version.
  • Added the DidCommDataIntegrityLinkSecretBindingProvider interface and its injection token, implementing the anoncreds_link_secret binding method. @credo-ts/anoncreds provides AnonCredsLinkSecretBindingProvider and the AnonCredsModule registers it, so agents using anoncreds keep the binding method with no changes. Using the binding method without the AnonCredsModule registered now fails with an explanatory error rather than an unresolved dependency.
  • Fixed deleteCredentialById deleting every credential of this format through the anoncreds holder service. Credentials that were not bound to a link secret are now removed as the plain W3cCredentialRecord or W3cV2CredentialRecord they are stored as.

• fd5016d: feat: the Cache interface get, set and remove methods now accept a CacheOptions parameter with a scope that is either 'context' (default) or 'global', allowing globally reusable data to be shared across agent contexts. The X.509 CRL summary cache, the Indy VDR pool lookup cache and the AnonCreds registry cache use the global scope, as they only hold publicly anchored data. The DID resolver caches documents of public did methods in the global scope, and documents of other did methods per agent context; the list of public did methods can be configured with the new publicDidMethods option of the dids module (default ['web', 'indy', 'sov', 'cheqd', 'hedera', 'webvh']).

  Behavior changes to be aware of:

  • InMemoryLruCache now namespaces keys by contextCorrelationId by default. This fixes potential cross-context sharing of context-scoped entries (e.g. records cached by CachedStorageService) in multi-tenant setups. Single-context agents are not affected.
  • RedisCache stores global-scope entries under a global: key prefix. Existing context-scoped Redis entries for the caches that moved to the global scope become cache misses after upgrading and expire through their TTL, causing a one-time refetch.

• 907cc54: refactor(vc): rename anoncreds Data Integrity bridge APIs to W3C credential namespace. Replaces Data Integrity-specific symbols and types (IAnonCredsDataIntegrityService, AnonCredsDataIntegrityServiceSymbol, ANONCREDS_DATA_INTEGRITY_CRYPTOSUITE, DataIntegrityProof, dataIntegrityCryptosuites) with W3C credential equivalents. Generic JSON-LD verification now rejects anoncreds-2023 proofs and requires anoncreds W3C credential path. Introduces shouldSignWithAnonCredsW3cService() and shouldVerifyWithAnonCredsW3cService() to clarify service responsibilities.

• cfe86fa: X509 trusted certificates now can be provided in a new format. Previously it was a list of base64/pem/der encoded certificates, but now you can also provide a list of objects in the format [{issuance: string[], status? :string[]}]. This is used for the new status indicator on mdoc. First, it looks for the used issuance trusted certificates and then validates the status, if available, with the status trusted certificates associated with the issuance property.

• b75467c: Support issuing Verifiable Credentials Data Model 2.0 credentials over the W3C Data Integrity credential attachment format (Aries RFC 0809). The format previously advertised data_model_versions_supported: ['1.1'] and rejected a data model 2.0 credential, even though the agent was already able to secure one with a DataIntegrityProof.

  The data model version is negotiated on the wire as the RFC describes: the offer advertises the version of the credential it carries, and the holder echoes its choice as data_model_version on the request. Which cryptosuite secures the credential is not negotiated, as RFC 0809 leaves that choice to the issuer.

  • The base JSON-LD context of the offered credential now determines the advertised data_model_versions_supported, so offering a credential in the https://www.w3.org/ns/credentials/v2 context works without further configuration. Offers for data model 1.1 credentials are unaffected.
  • Added the cryptosuite data integrity credential format option, naming the Data Integrity cryptosuite used to secure a data model 2.0 credential, for example eddsa-jcs-2022. When omitted, the first registered cryptosuite supporting the key type of the issuer verification method is used. It is ignored for data model 1.1, which is secured with a linked data signature suite instead. The anoncreds-2023 cryptosuite is rejected, as it is only produced through the anoncreds link secret binding method.
  • W3cDataIntegrityApi.getSupportedCryptosuites accepts an optional public JWK type, returning only the cryptosuites that support that key type.
  • A received data model 2.0 credential is verified and stored as a W3cV2CredentialRecord. Deleting a credential of this format looks the record up in both the data model 1.1 and 2.0 stores, so the record type on the credential exchange record stays 'w3c' for both versions.
  • The anoncreds link secret binding method is rejected for data model 2.0 credentials, both when creating an offer and when issuing, as that binding method is defined for data model 1.1 and the anoncredsvc-2023 cryptosuite only.
  • Fixed the comparison of the offered and the received credential subject, which rejected any claim with a falsy value: a credential carrying a claim such as 0, false or '' was refused by the holder as not matching the offer. Claims are now compared by presence.

• cfe86fa: TokenStatusList is a new standard module on the agent. It allows you to create/update/fetch token status lists. It is up to the user to host this, this can be easily done with the statusList you receive from the agent.tokenStatusList.createTokenStatusList(...) function. Updating the statuslist allows you to change the status list credential state from valid to invalid, but also update the expiry time, rotate certificates, change signing algorithm, etc. Signatures are the default and mac should only be used if the user is aware of the security implications and has good reason to do so.

• Updated dependencies [9f4278b]

• Updated dependencies [f127ff5]

• Updated dependencies [5cfcadb]

• Updated dependencies [84dfcf4]

• Updated dependencies [b75467c]

• Updated dependencies [e80900a]

• Updated dependencies [8ded8d2]

• Updated dependencies [fd5016d]

• Updated dependencies [d45aec0]

• Updated dependencies [5cfcadb]

... (truncated)

Commits

• fc21fb6 chore(release): new version (#2772)
• fae21ee Merge branch 'main' into feat/signature-suite-registration
• b75467c feat(didcomm): support VCDM 2.0 credentials over RFC0809 (#2898)
• a412444 Merge branch 'main' into feat/signature-suite-registration
• 9f4278b feat(DidDocument): keyType and Purpose-aware Verification Method helpers (#2934)
• 78094a9 don't register signature suite in w3cv2 module
• 7073e76 Merge branch 'main' into feat/signature-suite-registration
• 339f4cc feat(json-ld): abstract json-ld document loader into a module (#2921)
• 3c380a7 Merge branch 'main' into feat/signature-suite-registration
• 907cc54 refactor(vc): anoncreds data integrity namespace change (#2813)
• Additional commits viewable in compare view

Updates @credo-ts/askar from 0.7.0 to 0.7.1

Changelog

Sourced from @​credo-ts/askar's changelog.

0.7.1

Patch Changes

• 8b8690a: Add connectionParameters to the Askar postgres database config. The parameters are added to the postgres connection url and passed to the underlying driver, allowing e.g. ssl options (sslmode, sslrootcert, etc.) to be configured without setting environment variables. See https://docs.rs/sqlx/latest/sqlx/postgres/struct.PgConnectOptions.html#parameters for supported parameters.

• bc4638e: Add support for the ISO/IEC TS 18013-7:2025 Annex C (org-iso-mdoc) Digital Credentials API.

  • KMS: HPKE (RFC 9180) key agreement algorithms HPKE-0, HPKE-3 and HPKE-7, following the naming of draft-ietf-jose-hpke-encrypt. These are integrated-encryption algorithms, so encryption/decryption must be omitted and encrypt returns an encapsulatedKey. Implemented in the askar backend (the recipient private key stays inside askar; only the Diffie-Hellman output leaves it) and in the node backend.
  • Mdoc module: createDcApiVerificationSession / verifyDcApiResponse for verifiers and resolveDcApiRequest / createDcApiResponse for wallets, backed by a new MdocVerificationSessionRecord.
  • verifyDcApiResponse matches the response against the device request of the session and throws a MdocDeviceRequestNotSatisfiedError when a doc request is not satisfied. By default every requested element must be disclosed and issuer signed; in the docRequests passed to createDcApiVerificationSession, pass { intentToRetain, optional, source } instead of the intentToRetain boolean to mark an element as optional or as device signed. The match is returned as deviceRequestMatch, with per doc request the valid and failed documents, and per document the result of the docType and claims checks.
  • resolveDcApiRequest matches the stored mdocs with the same rules and returns the same structure (through Holder.matchDeviceRequest of @owf/mdoc): per doc request the validCredentials and failedCredentials, each with its record and the docType and claims checks, so a wallet can show an mdoc of the requested doctype together with the requested claims it is missing. An age_over_NN request is answered with the age attestation the mdoc has (18013-5 7.2.5). A requested element that is not issuer signed, but that the device key is authorized for in the MSO, is matched as device signed when its value is passed in deviceNameSpaces to resolveDcApiRequest: pass the same value in the deviceNameSpaces of the credential to createDcApiResponse. A credential can also pass elements to disclose only some of the requested elements.
  • Reader authentication on an incoming request is resolved through the same trust layers as credential verification: the certificates passed to resolveDcApiRequest, then the global getTrustedIssuersForVerification callback (with the new mdocReaderAuth verification type, called per doc request), then the deprecated getTrustedCertificatesForVerification callback, then the statically configured trusted certificates. Resolving a reader authenticated request throws when none of these are configured. Return the leaf certificate from the callback to trust a reader on the certificate it presented itself.

• bc4638e: Only pick a response encryption key from client_metadata.jwks that the key management backends of the agent can actually perform the ECDH-ES key agreement with. Previously the first recognized enc key was used, which failed later on if e.g. a verifier included a P-521 key and the configured KMS backend (such as Askar) does not support that curve. The Askar and Node key management backends now also take the curve of the external public key into account in isOperationSupported.

• cfe86fa: X509 trusted certificates now can be provided in a new format. Previously it was a list of base64/pem/der encoded certificates, but now you can also provide a list of objects in the format [{issuance: string[], status? :string[]}]. This is used for the new status indicator on mdoc. First, it looks for the used issuance trusted certificates and then validates the status, if available, with the status trusted certificates associated with the issuance property.

• cfe86fa: TokenStatusList is a new standard module on the agent. It allows you to create/update/fetch token status lists. It is up to the user to host this, this can be easily done with the statusList you receive from the agent.tokenStatusList.createTokenStatusList(...) function. Updating the statuslist allows you to change the status list credential state from valid to invalid, but also update the expiry time, rotate certificates, change signing algorithm, etc. Signatures are the default and mac should only be used if the user is aware of the security implications and has good reason to do so.

• Updated dependencies [9f4278b]

• Updated dependencies [f127ff5]

• Updated dependencies [5cfcadb]

• Updated dependencies [84dfcf4]

• Updated dependencies [e80900a]

• Updated dependencies [8ded8d2]

• Updated dependencies [fd5016d]

• Updated dependencies [d45aec0]

• Updated dependencies [5cfcadb]

• Updated dependencies [097c831]

• Updated dependencies [20d6ab1]

• Updated dependencies [bc4638e]

• Updated dependencies [bc4638e]

• Updated dependencies [bc4638e]

• Updated dependencies [907f12f]

• Updated dependencies [bc4638e]

• Updated dependencies [96dc69b]

• Updated dependencies [7dfafeb]

• Updated dependencies [3a3eb03]

• Updated dependencies [23c354e]

• Updated dependencies [907cc54]

• Updated dependencies [339f4cc]

• Updated dependencies [bc4638e]

• Updated dependencies [5cfcadb]

• Updated dependencies [f127ff5]

• Updated dependencies [cfe86fa]

• Updated dependencies [e97c18b]

• Updated dependencies [121dd14]

• Updated dependencies [b75467c]

• Updated dependencies [cfe86fa]

• Updated dependencies [0a58888]

• Updated dependencies [1e2088f]

  • @​credo-ts/core@​0.7.1

Commits

• fc21fb6 chore(release): new version (#2772)
• bc4638e feat: add support for iso 18013-7 dc api (#2922)
• 8b8690a feat: allow setting postgres connection params in askar (#2931)
• 0bc66a4 fix(askar): only auto-provision at initialization (#2667)
• f127ff5 feat: mdoc revocation for issuance and verification (#2803)
• See full diff in compare view

Updates @credo-ts/core from 0.7.0 to 0.7.1

Changelog

Sourced from @​credo-ts/core's changelog.

0.7.1

Patch Changes

• 9f4278b: Add DidDocument.findVerificationMethodsByPurpose and DidDocument.findVerificationMethodsByTypeAndPurpose.

  The relationship-aware methods resolve inline and referenced methods and return them in requested relationship order while preserving entry order within each relationship. The type-filtered method accepts one or more verification-method representations and delegates relationship traversal to the purpose-only method. DIDComm JSON-LD, JWT credentials, presentation selection, DIDComm messaging, AnonCreds data integrity, Cheqd signing, peer DID conversion, and did:webvh signing now use the appropriate shared lookup. AnonCreds credential signing prefers verification methods authorized for assertionMethod, with declared verificationMethod entries as a fallback.

• f127ff5: Mdoc revocation for issuance and verification

• 5cfcadb: Fail COSE Sign1 and Mac0 signing, and Mac0 verification, when no algorithm is declared instead of falling back to the first supported signature algorithm of the key. The Mac0 authenticate operation now also uses the algorithm provided by the caller. COSE Sign1 verification still falls back to the signature algorithm of the key, as @​owf/mdoc does not forward the alg of the deviceAuth Sign1 structure yet.

• 84dfcf4: sd-jwt vc does not require IAT to be required anymore

• e80900a: Fix selective disclosure of SD-JWT array elements when presenting with DCQL. Array elements that are selectively disclosable on their own were not disclosed, even when requested. They are now disclosed by their position in the array.

  DCQL claim sets of SD-JWT VC and W3C V2 SD-JWT VC credentials now include disclosed_paths: the paths to the claims the presentation discloses, including the claims that are not selectively disclosable. An array element has the position it has in the claims of the credential, where decoy digests don't count. A path stands for the claim and everything below it, so a claim that is disclosed as a whole has a single path. Pass them as the new disclosedPaths in DcqlCredentialsForRequest (done automatically by selectCredentialsForRequest).

  Disclosing an SD-JWT VC or W3C V2 SD-JWT VC based on disclosedPayload is deprecated, as it selects arrays as a whole. disclosedPaths will be required for these formats in the next breaking version.

  For the same reason, applyDisclosuresForPayload on SdJwtVcService and W3cV2SdJwtCredentialService is deprecated in favor of the new applyDisclosuresForPaths.

  IDisclosureFrame now also allows array positions in _sd, and the ClaimPath type is exported.

• 8ded8d2: Fix Ed25519Signature2018 incorrectly accepting Ed25519VerificationKey2020 verification methods (previously converted at runtime from multibase to base58), and register Ed25519Signature2020 with its own required Ed25519VerificationKey2020 verification method type instead of sharing acceptance with Ed25519Signature2018. Each suite now strictly enforces its own verification method type, with error messages identifying both the offending key type and the proof type.

  W3cJsonLdCredentialService#signCredential and #signPresentation now share a single suite-preparation path that resolves and validates the verification method against the suite's required key type before signing, replacing duplicated per-method logic.

  Also fixes missing @type: multibase typing for publicKeyMultibase/proofValue and missing capabilityInvocation, capabilityDelegation, and keyAgreement term definitions in the ed25519-2020 JSON-LD context, which caused JSON-LD framing/expansion failures when dynamically signing and verifying credentials and presentations with Ed25519Signature2020 DIDs.

• fd5016d: feat: the Cache interface get, set and remove methods now accept a CacheOptions parameter with a scope that is either 'context' (default) or 'global', allowing globally reusable data to be shared across agent contexts. The X.509 CRL summary cache, the Indy VDR pool lookup cache and the AnonCreds registry cache use the global scope, as they only hold publicly anchored data. The DID resolver caches documents of public did methods in the global scope, and documents of other did methods per agent context; the list of public did methods can be configured with the new publicDidMethods option of the dids module (default ['web', 'indy', 'sov', 'cheqd', 'hedera', 'webvh']).

  Behavior changes to be aware of:

  • InMemoryLruCache now namespaces keys by contextCorrelationId by default. This fixes potential cross-context sharing of context-scoped entries (e.g. records cached by CachedStorageService) in multi-tenant setups. Single-context agents are not affected.
  • RedisCache stores global-scope entries under a global: key prefix. Existing context-scoped Redis entries for the caches that moved to the global scope become cache misses after upgrading and expire through their TTL, causing a one-time refetch.

• d45aec0: fix(kms): respect the configured defaultBackend when no explicit backend is provided for a key management operation. Previously the first registered backend that supported the operation was always used and the defaultBackend option was silently ignored, which could result in keys being created in a different (e.g. software instead of hardware-backed) backend than configured. If the default backend does not support the requested operation, the first other backend that supports the operation is used and a warning is logged.

• 5cfcadb: Use the alg from the JWS header when verifying linked data proofs, and bind signing to the algorithm declared in the JWS header, instead of using the first supported signature algorithm of the key. Also fixes the JWS header validation for linked data proofs, which could previously be bypassed by adding an extra header parameter.

• 097c831: fix(vc): bind the holder to the credentialSubject when verifying JSON-LD (ldp_vp) presentations

  W3cJsonLdCredentialService.verifyPresentation verified the presentation proof and each embedded credential's issuer proof, but never checked that the presentation signer (holder) controls the credentialSubject.id of the embedded credentials. The underlying @digitalcredentials/vc / jsonld-signatures libraries do not perform this check either. As a result an ldp_vp could be used to present someone else's credential (a data object, not a secret) wrapped in a presentation signed with the attacker's own key. This check is already enforced for jwt_vp and SD-JWT presentations; the JSON-LD path now enforces it too, surfacing the result per credential under

... (truncated)

Commits

• fc21fb6 chore(release): new version (#2772)
• e80900a feat: support array paths and several dcql fixes (#2945)
• bc4638e feat: add support for iso 18013-7 dc api (#2922)
• 8ded8d2 fix(vc): signature suite separation (#2943)
• fae21ee Merge branch 'main' into feat/signature-suite-registration
• b75467c feat(didcomm): support VCDM 2.0 credentials over RFC0809 (#2898)
• a412444 Merge branch 'main' into feat/signature-suite-registration
• 9f4278b feat(DidDocument): keyType and Purpose-aware Verification Method helpers (#2934)
• 78094a9 don't register signature suite in w3cv2 module
• 7073e76 Merge branch 'main' into feat/signature-suite-registration
• Additional commits viewable in compare view

Updates @credo-ts/didcomm from 0.7.0 to 0.7.1

Changelog

Sourced from @​credo-ts/didcomm's changelog.

0.7.1

Patch Changes

• 9f4278b: Add DidDocument.findVerificationMethodsByPurpose and DidDocument.findVerificationMethodsByTypeAndPurpose.

  The relationship-aware methods resolve inline and referenced methods and return them in requested relationship order while preserving entry order within each relationship. The type-filtered method accepts one or more verification-method representations and delegates relationship traversal to the purpose-only method. DIDComm JSON-LD, JWT credentials, presentation selection, DIDComm messaging, AnonCreds data integrity, Cheqd signing, peer DID conversion, and did:webvh signing now use the appropriate shared lookup. AnonCreds credential signing prefers verification methods authorized for assertionMethod, with declared verificationMethod entries as a fallback.

• b75467c: Move the W3C Data Integrity credential attachment format (Aries RFC 0809) out of @credo-ts/anoncreds and into @credo-ts/didcomm, where the rest of the format already lived. The format is not anoncreds specific: binding a credential to an anoncreds link secret is one of its binding methods, next to the didcomm signed attachment method and to not binding the credential at all. Issuing a plain W3C credential over this format no longer requires depending on @credo-ts/anoncreds.

  • Added DidCommDataIntegrityCredentialFormatService to @credo-ts/didcomm. DataIntegrityDidCommCredentialFormatService in @credo-ts/anoncreds is now a deprecated alias for it and will be removed in the next major version.
  • Added the DidCommDataIntegrityLinkSecretBindingProvider interface and its injection token, implementing the anoncreds_link_secret binding method. @credo-ts/anoncreds provides AnonCredsLinkSecretBindingProvider and the AnonCredsModule registers it, so agents using anoncreds keep the binding method with no changes. Using the binding method without the AnonCredsModule registered now fails with an explanatory error rather than an unresolved dependency.
  • Fixed deleteCredentialById deleting every credential of this format through the anoncreds holder service. Credentials that were not bound to a link secret are now removed as the plain W3cCredentialRecord or W3cV2CredentialRecord they are stored as.

• cfe86fa: X509 trusted certificates now can be provided in a new format. Previously it was a list of base64/pem/der encoded certificates, but now you can also provide a list of objects in the format [{issuance: string[], status? :string[]}]. This is used for the new status indicator on mdoc. First, it looks for the used issuance trusted certificates and then validates the status, if available, with the status trusted certificates associated with the issuance property.

• b75467c: Support issuing Verifiable Credentials Data Model 2.0 credentials over the W3C Data Integrity credential attachment format (Aries RFC 0809). The format previously advertised data_model_versions_supported: ['1.1'] and rejected a data model 2.0 credential, even though the agent was already able to secure one with a DataIntegrityProof.

  The data model version is negotiated on the wire as the RFC describes: the offer advertises the version of the credential it carries, and the holder echoes its choice as data_model_version on the request. Which cryptosuite secures the credential is not negotiated, as RFC 0809 leaves that choice to the issuer.

  • The base JSON-LD context of the offered credential now determines the advertised data_model_versions_supported, so offering a credential in the https://www.w3.org/ns/credentials/v2 context works without further configuration. Offers for data model 1.1 credentials are unaffected.
  • Added the cryptosuite data integrity credential format option, naming the Data Integrity cryptosuite used to secure a data model 2.0 credential, for example eddsa-jcs-2022. When omitted, the first registered cryptosuite supporting the key type of the issuer verification method is used. It is ignored for data model 1.1, which is secured with a linked data signature suite instead. The anoncreds-2023 cryptosuite is rejected, as it is only produced through the anoncreds link secret binding method.
  • W3cDataIntegrityApi.getSupportedCryptosuites accepts an optional public JWK type, returning only the cryptosuites that support that key type.
  • A received data model 2.0 credential is verified and stored as a W3cV2CredentialRecord. Deleting a credential of this format looks the record up in both the data model 1.1 and 2.0 stores, so the record type on the credential exchange record stays 'w3c' for both versions.
  • The anoncreds link secret binding method is rejected for data model 2.0 credentials, both when creating an offer and when issuing, as that binding method is defined for data model 1.1 and the anoncredsvc-2023 cryptosuite only.
  • Fixed the comparison of the offered and the received credential subject, which rejected any claim with a falsy value: a credential carrying a claim such as 0, false or '' was refused by the holder as not matching the offer. Claims are now compared by presence.

• cfe86fa: TokenStatusList is a new standard module on the agent. It allows you to create/update/fetch token status lists. It is up to the user to host this, this can be easily done with the statusList you receive from the agent.tokenStatusList.createTokenStatusList(...) function. Updating the statuslist allows you to change the status list credential state from valid to invalid, but also update the expiry time, rotate certificates, change signing algorithm, etc. Signatures are the default and mac should only be used if the user is aware of the security implications and has good reason to do so.

• Updated dependencies [9f4278b]

• Updated dependencies [f127ff5]

• Updated dependencies [5cfcadb]

• Updated dependencies [84dfcf4]

• Updated dependencies [e80900a]

• Updated dependencies [8ded8d2]

• Updated dependencies [fd5016d]

• Updated dependencies [d45aec0]

• Updated dependencies [5cfcadb]

• Updated dependencies [097c831]

• Updated dependencies [20d6ab1]

• Updated dependencies [bc4638e]

• Updated dependencies [bc4638e]

• Updated dependencies [bc4638e]

• Updated dependencies [907f12f]

• Updated dependencies [bc4638e]

• Updated dependencies [96dc69b]

... (truncated)

Commits

• fc21fb6 chore(release): new version (#2772)
• b75467c feat(didcomm): support VCDM 2.0 credentials over RFC0809 (#2898)
• 9f4278b feat(DidDocument): keyType and Purpose-aware Verification Method helpers (#2934)
• 907cc54 refactor(vc): anoncreds data integrity namespace change (#2813)
• 347efbb feat(didDoc): purpose aware key lookup (#2878)
• 040652e chore(proofs): reorganise vc/data-integrity folder structure (#2792)
• b89db13 feat(didcomm): wire jsonld credential record deletion (#2765)
• cfe86fa feat: last changes for mdoc revocation (#2814)
• f127ff5 feat: mdoc revocation for issuance and verification (#2803)
• See full diff in compare view

Updates @credo-ts/indy-vdr from 0.7.0 to 0.7.1

Changelog

Sourced from @​credo-ts/indy-vdr's changelog.

0.7.1

Patch Changes

• Updated dependencies [9f4278b]
• Updated dependencies [f127ff5]
• Updated dependencies [5cfcadb]
• Updated dependencies [84dfcf4]
• Updated dependencies [b75467c]
• Updated dependencies [e80900a]
• Updated dependencies [8ded8d2]
• Updated dependencies [fd5016d]
• Updated dependencies [d45aec0]
• Updated dependencies [5cfcadb]
• Updated dependencies [097c831]
• Updated dependencies [20d6ab1]
• Updated dependencies [bc4638e]
• Updated dependencies [bc4638e]
• Updated dependencies [bc4638e]
• Updated dependencies [907f12f]
• Updated dependencies [bc4638e]
• Updated dependencies [96dc69b]
• Updated dependencies [7dfafeb]
• Updated dependencies [3a3eb03]
• Updated dependencies [23c354e]
• Updated dependencies [907cc54]
• Updated dependencies [339f4cc]
• Updated dependencies [bc4638e]
• Updated dependencies [5cfcadb]
• Updated dependencies [f127ff5]
• Updated dependencies [cfe86fa]
• Updated dependencies [e97c18b]
• Updated dependencies [121dd14]
• Updated dependencies [b75467c]
• Updated dependencies [cfe86fa]
• Updated dependencies [0a58888]
• Updated dependencies [1e2088f]
  • @​credo-ts/core@​0.7.1
  • @​credo-ts/anoncreds@​0.7.1

Commits

• fc21fb6 chore(release): new version (#2772)
• fd5016d feat: allow for per-context and global caching (#2871)
• See full diff in compare view

Updates @credo-ts/node from 0.7.0 to 0.7.1

Changelog

Sourced from @​credo-ts/node's changelog.

0.7.1

Patch Changes

• bc4638e: Add support for the ISO/IEC TS 18013-7:2025 Annex C (org-iso-mdoc) Digital Credentials API.

  • KMS: HPKE (RFC 9180) key agreement algorithms HPKE-0, HPKE-3 and HPKE-7, following the naming of draft-ietf-jose-hpke-encrypt. These are integrated-encryption algorithms, so encryption/decryption must be omitted and encrypt returns an encapsulatedKey. Implemented in the askar backend (the recipient private key stays inside askar; only the Diffie-Hellman output leaves it) and in the node backend.
  • Mdoc module: createDcApiVerificationSession / verifyDcApiResponse for verifiers and resolveDcApiRequest / createDcApiResponse for wallets, backed by a new MdocVerificationSessionRecord.
  • verifyDcApiResponse matches the response against the device request of the session and throws a MdocDeviceRequestNotSatisfiedError when a doc request is not satisfied. By default every requested element must be disclosed and issuer signed; in the docRequests passed to createDcApiVerificationSession, pass { intentToRetain, optional, source } instead of the intentToRetain boolean to mark an element as optional or as device signed. The match is returned as deviceRequestMatch, with per doc request the valid and failed documents, and per document the result of the docType and claims checks.
  • resolveDcApiRequest matches the stored mdocs with the same rules and returns the same structure (through Holder.matchDeviceRequest of @owf/mdoc): per doc request the validCredentials and failedCredentials, each with its record and the docType and claims checks, so a wallet can show an mdoc of the requested doctype together with the requested claims it is missing. An age_over_NN request is answered with the age attestation the mdoc has (18013-5 7.2.5). A requested element that is not issuer signed, but that the device key is authorized for in the MSO, is matched as device signed when its value is passed in deviceNameSpaces to resolveDcApiRequest: pass the same value in the deviceNameSpaces of the credential to createDcApiResponse. A credential can also pass elements to disclose only some of the requested elements.
  • Reader authentication on an incoming request is resolved through the same trust layers as credential verification: the certificates passed to resolveDcApiRequest, then the global getTrustedIssuersForVerification callback (with the new mdocReaderAuth verification type, called per doc request), then the deprecated getTrustedCertificatesForVerification callback, then the statically configured trusted certificates. Resolving a reader authenticated request throws when none of these are configured. Return the leaf certificate from the callback to trust a reader on the certificate it presented itself.

• bc4638e: Only pick a response encryption key from client_metadata.jwks that the key management backends of the agent can actually perform the ECDH-ES key agreement with. Previously the first recognized enc key was used, which failed later on if e.g. a verifier included a P-521 key and the configured KMS backend (such as Askar) does not support that curve. The Askar and Node key management backends now also take the curve of the external public key into account in isOperationSupported.

• Updated dependencies [9f4278b]

• Updated dependencies [f127ff5]

• Updated dependencies [5cfcadb]

• Updated dependencies [84dfcf4]

• Updated dependencies [b75467c]

• Updated dependencies [e80900a]

• Updated dependencies [8ded8d2]

• Updated dependencies [fd5016d]

• Updated dependencies [d45aec0]

• Updated dependencies [5cfcadb]

• Updated dependencies [097c831]

• Updated dependencies [20d6ab1]

• Updated dependencies [bc4638e]

• Updated dependencies [bc4638e]

• Updated dependencies [bc4638e]

• Updated dependencies [907f12f]

• Updated dependencies [bc4638e]

• Updated dependencies [96dc69b]

• Updated dependencies [7dfafeb]

• Updated dependencies [3a3eb03]

• Updated dependencies [23c354e]

• Updated dependencies [907cc54]

• Updated dependencies [339f4cc]

• Updated dependencies [bc4638e]

• Updated dependencies [5cfcadb]

• Updated dependencies [f127ff5]

• Updated dependencies [cfe86fa]

• Updated dependencies [e97c18b]

• Updated dependencies [121dd14]

• Updated dependencies [b75467c]

• Updated dependencies [cfe86fa]

• Updated dependencies [0a58888]

• Updated dependencies [1e2088f]

  • @​credo-ts/core@​0.7.1
  • @​credo-ts/didcomm@​0.7.1

Commits

• fbb6517 feat(node): support host-owned DIDComm HTTP listeners (#2916)
• fc21fb6 chore(release): new version (#2772)
• bc4638e feat: add support for iso 18013-7 dc api (#2922)
• ecfd26f fix: export node file system (#2837)
• See full diff in compare view

Updates @credo-ts/openid4vc from 0.7.0 to 0.7.1

Release notes

Sourced from @​credo-ts/openid4vc's releases.

@​credo-ts/openid4vc@​0.5.5

Patch Changes

• 482a630: - feat: allow serving dids from did record (#1856)
  • fix: set created at for anoncreds records (#1862)
  • feat: add goal to public api for credential and proof (#1867)
  • fix(oob): only reuse connection if enabled (#1868)
  • fix: issuer id query anoncreds w3c (#1870)
  • feat: sd-jwt issuance without holder binding (#1871)
  • chore: update oid4vci deps (#1873)
  • fix: query for qualified/unqualified forms in revocation notification (#1866)
  • fix: wrong schema id is stored for credentials (#1884)
  • fix: process credential or proof problem report message related to connectionless or out of band exchange (#1859)
  • fix: unqualified indy revRegDefId in migration (#1887)
  • feat: verify SD-JWT Token status list and SD-JWT VC fixes (#1872)
  • fix(anoncreds): combine creds into one proof (#1893)
  • fix: AnonCreds proof requests with unqualified dids (#1891)
  • fix: WebSocket priority in Message Pick Up V2 (#1888)
  • fix: anoncreds predicate only proof with unqualified dids (#1907)
  • feat: add pagination params to storage service (#1883)
  • feat: add message handler middleware and fallback (#1894)
• Updated dependencies [3239ef3]
• Updated dependencies [d548fa4]
• Updated dependencies [482a630]
  • @​credo-ts/core@​0.5.5

Changelog

Sourced from @​credo-ts/openid4vc's changelog.

0.7.1

Patch Changes

• d86e941: Allow selecting and persisting the KMS backend used for OpenID4VC issuer access-token signing keys. Key rotation defaults to the issuer's current backend, supports moving to another backend, and deletes the previous key through its owning backend. Existing issuers continue to use the default KMS backend.

• bd17194: fix: do not include c_nonce_expires_in in nonce endpoint response, it was never part of the nonce endpoint response

• 2fa6955: Don't require the DPoP proof to use the client attestation confirmation key at the pushed authorization request and authorization challenge endpoints. Per the attestation-based client authentication draft, the DPoP key and the client instance key only have to be the same for the attest_jwt_client_auth_dpop method (DPoP combined mode), where a single DPoP proof replaces the client attestation PoP JWT. When the dedicated OAuth-Client-Attestation-PoP header is present, the DPoP proof is validated according to RFC 9449 independently, and its public key is not required to match the cnf claim of the client attestation. The issuer wrongly enforced key equality for both methods, rejecting interoperable wallets that use a separate DPoP key. Key equality for the DPoP-bound method at the token endpoint is unaffected.

• e80900a: Fix selective disclosure of SD-JWT array elements when presenting with DCQL. Array elements that are selectively disclosable on their own were not disclosed, even when requested. They are now disclosed by their position in the array.

  DCQL claim sets of SD-JWT VC and W3C V2 SD-JWT VC credentials now include disclosed_paths: the paths to the claims the presentation discloses, including the claims that are not selectively disclosable. An array element has the position it has in the claims of the credential, where decoy digests don't count. A path stands for the claim and everything below it, so a claim that is disclosed as a whole has a single path. Pass them as the new disclosedPaths in DcqlCredentialsForRequest (done automatically by selectCredentialsForRequest).

  Disclosing an SD-JWT VC or W3C V2 SD-JWT VC based on disclosedPayload is deprecated, as it selects arrays as a whole. disclosedPaths will be required for these formats in the next breaking version.

  For the same reason, applyDisclosuresForPayload on SdJwtVcService and W3cV2SdJwtCredentialService is deprecated in favor of the new applyDisclosuresForPaths.

  IDisclosureFrame now also allows array positions in _sd, and the ClaimPath type is exported.

• 5f1c572: Allow the getDynamicIssuanceSession callback to supply the id of the issuance session to create. A dynamic issuance session is created after the callback returns, so the callback could not previously know the id of the session it just authorized. Supplying it lets an external system reference the session before it exists, for example to record it in its own database while handling the same request. When omitted a random id is generated, as before.

• 1d0c05d: Exposed updateIssuer method on OpenId4VcIssuerApi

• 1a6562c: fix(openid4vc): include auth-code scope in credential offer

• 117931c: Updated so that when the holder verifies an incoming credential and it fails, it does not log the entire credential

• a5719ae: Add ignoreWalletAttestationsWhenNotRequired to the OpenID4VC issuer module config. By default, a wallet attestation provided by a client is always verified, even if the issuance session doesn't require it, and an invalid attestation fails the request. When enabled, a wallet attestation that is not required is ignored at the token, pushed authorization request and authorization challenge endpoints, so wallets that send an invalid attestation can still complete issuance sessions that don't require one.

• e18d2cf: feat: interpret key attestation ISO 18045 levels hierarchically on the issuer, so a stronger attested level (e.g. iso_18045_high) satisfies a weaker required level (e.g. iso_18045_moderate). Also adds the OpenId4VciKeyAttestationLevel enum and keyAttestationLevelSatisfies helper.

• 3f2bef1: Restore detailed mdoc verification error.

• 20d6ab1: fix: correctly encode kid in the header of cose signatures, and do not include the kid in oid4vci request to the issuer

• ab90ba7: Support configuring the signed issuer metadata signer when updating an issuer. updateIssuerMetadata and updateIssuer now accept a metadataSigner, which can be omitted to keep the current signer, set to a signer to enable or replace it, or set to null to stop signing the metadata. Previously a signer could only be configured when creating an issuer.

• 0c8138e: Avoid an unnecessary request to the agent's own JWKs endpoint when verifying OpenID4VCI access tokens.

  When an access token issued by the agent's own built-in authorization server is verified, the agent no longer performs an HTTP request to its own jwks_uri to retrieve the access token signing key. The key is already held in the issuer record, and is now resolved locally.

• 60efbe0: feat(openid4vc): support the Client Attestation PoP challenge and DPoP-bound method (draft 09 of OAuth 2.0 Attestation-Based Client Authentication)

  • The issuer can require a fresh, server-issued client attestation PoP challenge (enabled through the new clientAttestationPopChallengeRequired issuer config option). When enabled it advertises a challenge_endpoint and, at the token endpoint, uses the reactive use_attestation_challenge flow (returning the challenge in the OAuth-Client-Attestation-Challenge header) so clients retry automatically. The holder additionally fetches a challenge proactively from the challenge_endpoint for the pushed authorization request and authorization challenge endpoints.
  • Support for the DPoP-bound client attestation method (attest_jwt_client_auth_dpop), where a single DPoP proof signed with the client instance key serves as both the DPoP proof and the client attestation PoP. Used automatically when the authorization server advertises it, in both the pre-authorized code flow and the authorization code flow. For the authorization code flow the whole interaction is bound to th...

    Description has been truncated

[dependabot]

Labels

The following labels could not be found: yarn. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: b5d955ee-f48c-4d82-bd7f-e5669caa2b44

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.