Skip to content

chore(release): new version - #2772

Open
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main
Open

chore(release): new version#2772
github-actions[bot] wants to merge 1 commit into
mainfrom
changeset-release/main

Conversation

@github-actions

@github-actions github-actions Bot commented Apr 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@credo-ts/action-menu@0.7.1

Patch Changes

  • 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 [f127ff5]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [84dfcf4]
  • Updated dependencies [fd5016d]
  • Updated dependencies [d45aec0]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [097c831]
  • Updated dependencies [20d6ab1]
  • Updated dependencies [907f12f]
  • Updated dependencies [96dc69b]
  • Updated dependencies [7dfafeb]
  • Updated dependencies [3a3eb03]
  • Updated dependencies [23c354e]
  • Updated dependencies [907cc54]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [f127ff5]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [e97c18b]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [0a58888]
  • Updated dependencies [1e2088f]
    • @credo-ts/core@0.7.1
    • @credo-ts/didcomm@0.7.1

@credo-ts/anoncreds@0.7.1

Patch Changes

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

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

  • Updated dependencies [5cfcadb]

  • Updated dependencies [84dfcf4]

  • Updated dependencies [fd5016d]

  • Updated dependencies [d45aec0]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [097c831]

  • Updated dependencies [20d6ab1]

  • Updated dependencies [907f12f]

  • Updated dependencies [96dc69b]

  • Updated dependencies [7dfafeb]

  • Updated dependencies [3a3eb03]

  • Updated dependencies [23c354e]

  • Updated dependencies [907cc54]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [f127ff5]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [e97c18b]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [0a58888]

  • Updated dependencies [1e2088f]

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

@credo-ts/askar@0.7.1

Patch Changes

  • 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 [f127ff5]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [84dfcf4]
  • Updated dependencies [fd5016d]
  • Updated dependencies [d45aec0]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [097c831]
  • Updated dependencies [20d6ab1]
  • Updated dependencies [907f12f]
  • Updated dependencies [96dc69b]
  • Updated dependencies [7dfafeb]
  • Updated dependencies [3a3eb03]
  • Updated dependencies [23c354e]
  • Updated dependencies [907cc54]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [f127ff5]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [e97c18b]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [0a58888]
  • Updated dependencies [1e2088f]
    • @credo-ts/core@0.7.1

@credo-ts/askar-to-drizzle-storage-migration@0.7.1

Patch Changes

  • Updated dependencies [f127ff5]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [84dfcf4]
  • Updated dependencies [fd5016d]
  • Updated dependencies [d45aec0]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [097c831]
  • Updated dependencies [20d6ab1]
  • Updated dependencies [907f12f]
  • Updated dependencies [96dc69b]
  • Updated dependencies [7dfafeb]
  • Updated dependencies [60efbe0]
  • Updated dependencies [3a3eb03]
  • Updated dependencies [23c354e]
  • Updated dependencies [907cc54]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [f127ff5]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [e97c18b]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [0a58888]
  • Updated dependencies [1e2088f]
    • @credo-ts/core@0.7.1
    • @credo-ts/drizzle-storage@0.7.1
    • @credo-ts/askar@0.7.1
    • @credo-ts/tenants@0.7.1

@credo-ts/cheqd@0.7.1

Patch Changes

@credo-ts/core@0.7.1

Patch Changes

  • 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

  • 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
    credentials[].credentialSubjectAuthentication to match the jwt_vp result shape.

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

  • 907f12f: fix(mdoc): guard unsupported device MAC authentication in the mdoc context

    The hdkf callback in the mdoc context previously derived an ECDH shared secret using raw curve math over the raw device private key bytes passed to it as a callback argument. This code path is only reached for mdoc device MAC authentication (ISO/IEC 18013-5), which Credo does not currently implement (only device signature authentication is supported), so it was never exercised. It is now replaced with an explicit error. A future device MAC implementation must derive the shared secret from the wallet-managed key inside the KMS, since the previous callback contract is incompatible with a non-exportable, KMS-held device key.

  • 96dc69b: fix(mdoc): accept status lists signed by the credential's issuance chain during presentation (device response) verification

    The mdoc presentation verification path (MdocDeviceResponse.verify, used by OpenID4VP) did not fall back to the issuance certificates when a trusted issuer was configured without dedicated status certificates (status: undefined). As a result, an mdoc carrying a token status list signed by the same certificate as the credential failed presentation verification, while the equivalent SD-JWT VC and standalone Mdoc.verify cases succeeded. The fallback (and the chain-equality safeguard that prevents it from widening the trust set) is now shared between Mdoc.verify and MdocDeviceResponse.verify.

  • 7dfafeb: Support certificate chain in mdoc signing.

  • 3a3eb03: Use the JWT header alg for SD-JWT VC signing and verification instead of always falling back to the first supported signature algorithm of the key. The alg can now be set on a PublicJwk instance, restricting the key to that algorithm.

  • 23c354e: Add a new W3C Data Integrity module to core with proof models, validation helpers, processing utilities, and structured create/verify result handling.

    The module introduces a cryptosuite registry and Data Integrity proof service/API for proof creation, single-proof verification, and proof-set/chain verification flows, plus an initial eddsa-jcs-2022 cryptosuite implementation.

    It also adds public/internal Data Integrity exports and registers the Data Integrity module in the default agent module set, making Data Integrity APIs available by default.

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

  • 5cfcadb: Use the alg from the provided options when updating a JWT token status list, instead of the alg of the signing key jwk (which is usually not defined).

  • f127ff5: Added token-status-list module which allows you to fetch/update/create token-status-list instances for sd-jwt and mdoc

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

  • e97c18b: Add a global getTrustedIssuersForVerification agent callback for resolving trusted issuers during verification. Unlike the now-deprecated X.509-module getTrustedCertificatesForVerification callback (which it takes precedence over), it supports both X.509 certificate chains and DIDs and is extensible to other trust mechanisms. It is wired into SD-JWT VC, mdoc, W3C V1 JWT and LD-JSON, W3C V2 JWT and SD-JWT, and OpenID4VP verification.

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

  • 0a58888: Normalize DID identifiers when authenticating the credential subject of a verifiable presentation. A credential subject id that references a specific verification method (e.g. did:example:123#0) now matches the bare DID controller (did:example:123), as both refer to the same DID subject. Non-DID identifiers are still compared as-is.

  • 1e2088f: Add X.509 CRL (Certificate Revocation List) verification. Certificate chain validation can now check certificate revocation status against the CRLs referenced in each certificate's CRL Distribution Points extension, with configurable SoftFail/Require/Disabled modes, reason partitioning (RFC 5280 §5.2.5), optional caching (verified CRLs are cached until their nextUpdate and, after a configurable freshness period, revalidated against the freshly fetched bytes so unchanged CRLs skip re-parsing and re-verification) and full-chain checking. Revocation checking now also honours the CRL's own extensions: delta CRLs, indirect CRLs, CRLs whose Issuing Distribution Point scope does not cover the certificate being checked, and CRLs bearing an unrecognized critical extension are rejected rather than treated as authoritative proof that the certificate is unrevoked. Key usage is now enforced where RFC 5280 requires it: issuing CA certificates must assert keyCertSign and CRL issuers must assert cRLSign when they carry a Key Usage extension. The certificate creation API also gained support for revocation reasons on CRL distribution points, and a new createCertificateRevocationList API (X509Api/X509Service) for creating and signing CRLs, including the CRL Number, Delta CRL Indicator, Authority Key Identifier and Issuing Distribution Point extensions.

@credo-ts/didcomm@0.7.1

Patch Changes

  • 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 [f127ff5]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [84dfcf4]
  • Updated dependencies [fd5016d]
  • Updated dependencies [d45aec0]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [097c831]
  • Updated dependencies [20d6ab1]
  • Updated dependencies [907f12f]
  • Updated dependencies [96dc69b]
  • Updated dependencies [7dfafeb]
  • Updated dependencies [3a3eb03]
  • Updated dependencies [23c354e]
  • Updated dependencies [907cc54]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [f127ff5]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [e97c18b]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [0a58888]
  • Updated dependencies [1e2088f]
    • @credo-ts/core@0.7.1

@credo-ts/drizzle-storage@0.7.1

Patch Changes

  • 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 the client instance key: the authorization request commits the instance key as the DPoP key (dpop_jkt, with the issuer enforcing that the client attestation confirmation key matches the DPoP key), and the token endpoint uses the combined DPoP proof with that same key.
    • The issuer now advertises the new client_attestation_signing_alg_values_supported / client_attestation_pop_signing_alg_values_supported metadata (configurable per issuer, stored as two nullable columns on the issuer record). Client attestation client authentication is advertised in token_endpoint_auth_methods_supported based on those signing algorithms being configured (matching how DPoP support is enabled via dpop_signing_alg_values_supported): attest_jwt_client_auth when the client attestation and pop signing algs are set, and the DPoP-bound attest_jwt_client_auth_dpop when the client attestation and DPoP signing algs are set.

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

  • Updated dependencies [2fa6955]

  • Updated dependencies [f127ff5]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [84dfcf4]

  • Updated dependencies [5f1c572]

  • Updated dependencies [fd5016d]

  • Updated dependencies [1d0c05d]

  • Updated dependencies [1a6562c]

  • Updated dependencies [117931c]

  • Updated dependencies [e18d2cf]

  • Updated dependencies [d45aec0]

  • Updated dependencies [3f2bef1]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [097c831]

  • Updated dependencies [20d6ab1]

  • Updated dependencies [ab90ba7]

  • Updated dependencies [907f12f]

  • Updated dependencies [96dc69b]

  • Updated dependencies [7dfafeb]

  • Updated dependencies [0c8138e]

  • Updated dependencies [60efbe0]

  • Updated dependencies [4f8bc6f]

  • Updated dependencies [3a3eb03]

  • Updated dependencies [23c354e]

  • Updated dependencies [907cc54]

  • Updated dependencies [9b64ef6]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [f127ff5]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [e1ddb2e]

  • Updated dependencies [e97c18b]

  • Updated dependencies [9b64ef6]

  • Updated dependencies [e2871bb]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [0a58888]

  • Updated dependencies [1e2088f]

    • @credo-ts/openid4vc@0.7.1
    • @credo-ts/core@0.7.1
    • @credo-ts/anoncreds@0.7.1
    • @credo-ts/question-answer@0.7.1
    • @credo-ts/action-menu@0.7.1
    • @credo-ts/didcomm@0.7.1
    • @credo-ts/drpc@0.7.1
    • @credo-ts/tenants@0.7.1

@credo-ts/drpc@0.7.1

Patch Changes

  • 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 [f127ff5]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [84dfcf4]
  • Updated dependencies [fd5016d]
  • Updated dependencies [d45aec0]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [097c831]
  • Updated dependencies [20d6ab1]
  • Updated dependencies [907f12f]
  • Updated dependencies [96dc69b]
  • Updated dependencies [7dfafeb]
  • Updated dependencies [3a3eb03]
  • Updated dependencies [23c354e]
  • Updated dependencies [907cc54]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [f127ff5]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [e97c18b]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [0a58888]
  • Updated dependencies [1e2088f]
    • @credo-ts/core@0.7.1
    • @credo-ts/didcomm@0.7.1

@credo-ts/hedera@0.7.1

Patch Changes

@credo-ts/indy-vdr@0.7.1

Patch Changes

@credo-ts/node@0.7.1

Patch Changes

@credo-ts/openid4vc@0.7.1

Patch Changes

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

  • 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

  • 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 the client instance key: the authorization request commits the instance key as the DPoP key (dpop_jkt, with the issuer enforcing that the client attestation confirmation key matches the DPoP key), and the token endpoint uses the combined DPoP proof with that same key.
    • The issuer now advertises the new client_attestation_signing_alg_values_supported / client_attestation_pop_signing_alg_values_supported metadata (configurable per issuer, stored as two nullable columns on the issuer record). Client attestation client authentication is advertised in token_endpoint_auth_methods_supported based on those signing algorithms being configured (matching how DPoP support is enabled via dpop_signing_alg_values_supported): attest_jwt_client_auth when the client attestation and pop signing algs are set, and the DPoP-bound attest_jwt_client_auth_dpop when the client attestation and DPoP signing algs are set.

  • 4f8bc6f: feat: add deleteIssuanceSessionById and deleteVerificationSessionById public APIs to allow cleanup of stored OpenID4VC session records.

  • 9b64ef6: feat: increase the max request payload size for oid4vci to 1mb and openid4vp to 5mb to be able to handle payloads containing images

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

  • e1ddb2e: Consult the getTrustedIssuersForVerification callback for did signed OpenID4VC JWTs. Previously only x5c signed JWTs were checked against a trust list, meaning a signed authorization request (JAR), an OpenID4VCI key attestation, an OAuth2 client (wallet) attestation, or signed credential issuer metadata signed by any DID was accepted. Semantics now match did signed credentials in core: allowed when no callback is registered or it returns undefined, rejected when the signer DID is not in the returned list. Behavior for x5c signed JWTs is unchanged.

  • e97c18b: Add a global getTrustedIssuersForVerification agent callback for resolving trusted issuers during verification. Unlike the now-deprecated X.509-module getTrustedCertificatesForVerification callback (which it takes precedence over), it supports both X.509 certificate chains and DIDs and is extensible to other trust mechanisms. It is wired into SD-JWT VC, mdoc, W3C V1 JWT and LD-JSON, W3C V2 JWT and SD-JWT, and OpenID4VP verification.

  • 9b64ef6: chore: update to oid4vc-ts 0.5 stable

  • e2871bb: feat(openid4vc): add a getDynamicIssuanceSession callback for dynamic (wallet-initiated) issuance that is not bound to a credential offer.

    The callback is the single decision point and application-level abuse-prevention gate for dynamic issuance. It is invoked when:

    • a Pushed Authorization Request or Authorization Challenge request is received by the internal authorization server without an issuer_state (the chained and presentation flows), or
    • the credential endpoint receives an access token issued by an external authorization server that is not bound to a credential offer (the external flow).

    The callback input is typed based on the endpoint that received the request (discriminated by origin: pushedAuthorizationRequest, authorizationChallengeRequest, or credentialRequest). For the authorization-server origins the parsed (not yet verified) wallet attestation, DPoP and raw request are available; for the credential-request origin the verified access token payload is available.

    The callback returns options describing the issuance session to create (or throws / returns undefined to deny). The returned options are typed based on the chosen authorizationFlow:

    • chained - authorization is delegated to a chained (internal) authorization server.
    • presentation - authorization is completed using an OpenID4VP presentation during issuance (requires getVerificationSession).
    • external - authorization has already been completed at an external authorization server (DPoP/wallet attestation requirements and refresh tokens are not configurable, as these are handled by the external authorization server).

    This enables wallet-initiated issuance for the chained authorization server and presentation during issuance flows, and unifies the existing external authorization server dynamic issuance under the same callback.

    The allowDynamicIssuanceSessions configuration option is deprecated, and the getDynamicIssuanceSession callback takes precedence.

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

  • Updated dependencies [5cfcadb]

  • Updated dependencies [84dfcf4]

  • Updated dependencies [fd5016d]

  • Updated dependencies [d45aec0]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [097c831]

  • Updated dependencies [20d6ab1]

  • Updated dependencies [907f12f]

  • Updated dependencies [96dc69b]

  • Updated dependencies [7dfafeb]

  • Updated dependencies [3a3eb03]

  • Updated dependencies [23c354e]

  • Updated dependencies [907cc54]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [f127ff5]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [e97c18b]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [0a58888]

  • Updated dependencies [1e2088f]

    • @credo-ts/core@0.7.1

@credo-ts/question-answer@0.7.1

Patch Changes

  • 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 [f127ff5]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [84dfcf4]
  • Updated dependencies [fd5016d]
  • Updated dependencies [d45aec0]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [097c831]
  • Updated dependencies [20d6ab1]
  • Updated dependencies [907f12f]
  • Updated dependencies [96dc69b]
  • Updated dependencies [7dfafeb]
  • Updated dependencies [3a3eb03]
  • Updated dependencies [23c354e]
  • Updated dependencies [907cc54]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [f127ff5]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [e97c18b]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [0a58888]
  • Updated dependencies [1e2088f]
    • @credo-ts/core@0.7.1
    • @credo-ts/didcomm@0.7.1

@credo-ts/react-native@0.7.1

Patch Changes

@credo-ts/redis-cache@0.7.1

Patch Changes

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

  • Updated dependencies [f127ff5]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [84dfcf4]

  • Updated dependencies [fd5016d]

  • Updated dependencies [d45aec0]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [097c831]

  • Updated dependencies [20d6ab1]

  • Updated dependencies [907f12f]

  • Updated dependencies [96dc69b]

  • Updated dependencies [7dfafeb]

  • Updated dependencies [3a3eb03]

  • Updated dependencies [23c354e]

  • Updated dependencies [907cc54]

  • Updated dependencies [5cfcadb]

  • Updated dependencies [f127ff5]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [e97c18b]

  • Updated dependencies [cfe86fa]

  • Updated dependencies [0a58888]

  • Updated dependencies [1e2088f]

    • @credo-ts/core@0.7.1

@credo-ts/tenants@0.7.1

Patch Changes

@credo-ts/webvh@0.7.1

Patch Changes

  • 5840d28: fix(webvh): use a verification method URL in DID log proofs
  • eb4aa3c: fix(webvh): bump didwebvh-ts version to 2.8.0. This solves a hash calculation bug that makes previous DIDs created with this library incompatible with the spec. As a result, DIDs created with previous versions of Credo will fail to resolve. See entryHash uses "{SCID}" placeholder for all entries, violating spec for entries after the first decentralized-identity/didwebvh-ts#93.
  • 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 [f127ff5]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [84dfcf4]
  • Updated dependencies [fd5016d]
  • Updated dependencies [d45aec0]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [097c831]
  • Updated dependencies [20d6ab1]
  • Updated dependencies [907f12f]
  • Updated dependencies [96dc69b]
  • Updated dependencies [7dfafeb]
  • Updated dependencies [3a3eb03]
  • Updated dependencies [23c354e]
  • Updated dependencies [907cc54]
  • Updated dependencies [5cfcadb]
  • Updated dependencies [f127ff5]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [e97c18b]
  • Updated dependencies [cfe86fa]
  • Updated dependencies [0a58888]
  • Updated dependencies [1e2088f]
    • @credo-ts/core@0.7.1
    • @credo-ts/anoncreds@0.7.1

@github-actions
github-actions Bot requested a review from a team as a code owner April 29, 2026 15:36
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 6 times, most recently from dd26da5 to cdadc63 Compare May 6, 2026 17:46
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 4 times, most recently from 63201ad to 0ee029a Compare May 13, 2026 12:01
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 4 times, most recently from a3e9693 to 9606caa Compare May 20, 2026 14:24
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 2 times, most recently from 412f6ef to a40c92c Compare May 28, 2026 14:11
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 11 times, most recently from d941854 to f384f10 Compare June 12, 2026 10:33
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 2 times, most recently from 872a86e to 8a8cc63 Compare June 17, 2026 10:01
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 7 times, most recently from 405bb46 to 5f7bb50 Compare July 7, 2026 09:35
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 4 times, most recently from 74bb6f1 to 8642253 Compare July 13, 2026 10:48
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 9 times, most recently from 4d59ca2 to bb123b2 Compare July 23, 2026 12:17
@github-actions
github-actions Bot force-pushed the changeset-release/main branch 9 times, most recently from 60c455f to 8e0359e Compare July 28, 2026 14:13
@github-actions
chore(release): version 0.7.1
665d2e6 
Signed-off-by: "github-actions[bot]" <"41898282+github-actions[bot]@users.noreply.github.com">
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants