Skip to content

Update all non-major dependencies (patch) - #1190

Open
renovate[bot] wants to merge 2 commits into
mainfrom
renovate/patch-all-minor-patch
Open

Update all non-major dependencies (patch)#1190
renovate[bot] wants to merge 2 commits into
mainfrom
renovate/patch-all-minor-patch

Conversation

@renovate

@renovate renovate Bot commented Sep 23, 2026

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@credo-ts/core (source) 0.7.0 → 0.7.1 age confidence
@credo-ts/openid4vc (source) 0.7.0 → 0.7.1 age confidence
@js-soft/docdb-access-abstractions (source) 1.4.3 → 1.4.5 age confidence
@js-soft/docdb-access-loki (source) 1.4.3 → 1.4.5 age confidence
@js-soft/docdb-access-mongo (source) 1.4.3 → 1.4.5 age confidence
@js-soft/eslint-config-ts 2.0.10 → 2.0.11 age confidence
@js-soft/node-logger (source) 1.2.14 → 1.2.15 age confidence
@js-soft/ts-utils (source) 2.3.7 → 2.3.9 age confidence
@nmshd/connector-sdk (source) 7.4.10 → 7.4.12 age confidence
@nmshd/crypto (source) 3.0.8 → 3.0.9 age confidence
@types/node (source) 24.13.4 → 24.13.6 age confidence
enhanced-publish 1.1.12 → 1.1.13 age confidence
expect (source) 30.5.1 → 30.5.2 age confidence
jest (source) 30.5.1 → 30.5.2 age confidence
prettier (source) 3.9.6 → 3.9.8 age confidence

Release Notes

openwallet-foundation/credo-ts (@​credo-ts/core)

v0.7.1

Compare Source

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

  • bc4638e: Update @owf/mdoc, @owf/cose and @owf/token-status-list, which add ISO/IEC 18013-5 conformance checks to mdoc verification:

    • Device signed elements must be authorized by the keyAuthorizations in the MSO (9.1.3.4). When creating a device response, deviceNameSpaces values are only disclosed when they are requested and the mdoc authorizes them; other values are left out. Mdoc.sign accepts a new keyAuthorizations option to authorize namespaces or individual data elements.
    • A CWT status list referenced by an mdoc must have an expiration time (12.3.6.3), and its sub must equal the URI it is referenced by. Pass expiresAt when creating a CWT token status list for mdocs.
    • A device response with a status other than 0 must not contain documents, and a document must not contain the same element identifier twice in a namespace.
    • The docType in the MSO must match the docType of the document, for every document in a device response (9.3.1).
    • issuing_country and issuing_jurisdiction are checked against the countryName and stateOrProvinceName in the subject of the document signer certificate, instead of in its issuer (9.3.1). issuing_jurisdiction is only checked when the certificate has a stateOrProvinceName.
    • Mdoc.sign throws when validityInfo.validFrom is before signed, which defaults to now, or when validUntil is not later than validFrom (9.1.2.4).

  • 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: chore(mdoc): deprecate MdocDeviceResponse.createDeviceResponseWithDcqlQuery and MdocService.createDcqlQueryDeviceResponse

    Credo does not use these methods itself, and they only support part of DCQL: every claim of every mso_mdoc credential query is requested, credential_sets, claim_sets and values are ignored, and a claim missing from the mdoc throws instead of being treated as optional. Use DcqlService.createPresentation to present mdocs for a DCQL query, or createDeviceResponse with explicit documentRequests.

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

  • bc4638e: Support treating the doc requests of an mdoc device request as alternatives, of which only one has to be satisfied. A device request with more than one doc request does not say whether it asks for all of them or for any one of them, so both sides opt in with treatAmbiguousMultipleDocRequestsAsAlternatives: on createDcApiVerificationSession for the verifier, which stores it on the session and applies it when the response is verified, and on resolveDcApiRequest for the wallet. The resolved request and the device request match now carry docRequestsAsAlternatives, which is only true when the option is set and the request has more than one doc request. A resolved request that succeeds this way keeps the doc requests that could not be answered, so only create a response for the ones that succeeded.

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

  • 339f4cc: Add a standalone JsonLdModule and shared JsonLdModuleConfig for configuring document loaders across JSON-LD consumers. W3cCredentialsModule continues to support its existing documentLoader configuration API.

  • bc4638e: Update to stable releases of @owf/mdoc (0.8.0), @owf/cose (0.4.0) and @owf/token-status-list (0.4.0), to @sd-jwt/core and @sd-jwt/sd-jwt-vc 0.21.0, and to @openid4vc/* 0.5.6. SD-JWT processing is now stricter: a compact SD-JWT must end with the ~ separator, disclosure salts must be unique within an SD-JWT, and the sub claim of a status list token must equal the uri that references it.

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

  • 121dd14: feat(vc2): implement W3C Verifiable Credentials 2.0 support including JWT, SD-JWT, and Data Integrity proof formats

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

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

openwallet-foundation/credo-ts (@​credo-ts/openid4vc)

v0.7.1

Compare Source

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

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

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

  • bc4638e: Update to stable releases of @owf/mdoc (0.8.0), @owf/cose (0.4.0) and @owf/token-status-list (0.4.0), to @sd-jwt/core and @sd-jwt/sd-jwt-vc 0.21.0, and to @openid4vc/* 0.5.6. SD-JWT processing is now stricter: a compact SD-JWT must end with the ~ separator, disclosure salts must be unique within an SD-JWT, and the sub claim of a status list token must equal the uri that references it.

  • 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

  • 121dd14: feat(vc2): implement W3C Verifiable Credentials 2.0 support including JWT, SD-JWT, and Data Integrity proof formats

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

js-soft/ts-documentdb-access (@​js-soft/docdb-access-abstractions)

v1.4.5

Compare Source

What's Changed
Dependency Updates

Full Changelog: js-soft/ts-documentdb-access@1.4.4...1.4.5

js-soft/ts-linting (@​js-soft/eslint-config-ts)

v2.0.11

Compare Source

What's Changed

Dependency Updates

New Contributors

Full Changelog: js-soft/ts-linting@2.0.10...2.0.11

js-soft/ts-logging (@​js-soft/node-logger)

v1.2.15

Compare Source

What's Changed
Dependency Updates

Full Changelog: js-soft/ts-logging@1.2.14...1.2.15

js-soft/ts-utils (@​js-soft/ts-utils)

v2.3.9

Compare Source

What's Changed
Dependency Updates

Full Changelog: js-soft/ts-utils@2.3.8...2.3.9

nmshd/connector (@​nmshd/connector-sdk)

v7.4.12

Compare Source

What's Changed

New Features
  • Remove mimetype parameter from UploadOwnFile and rename filename to filenameOverride by @​tnotheis in #​1074
Dependency Updates

Full Changelog: nmshd/connector@7.4.11...7.4.12

v7.4.11

Compare Source

What's Changed

New Features
  • Allow filename and mimetype to be passed outside of file during file upload by @​tnotheis in #​1064
Dependency Updates

❗ Important

✂ PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • Between 12:00 AM and 06:59 AM, only on Wednesday (* 0-6 * * 3)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the dependencies Pull requests that update dependencies label Sep 23, 2026
@renovate
renovate Bot enabled auto-merge (squash) September 23, 2026 03:50
@renovate
renovate Bot force-pushed the renovate/patch-all-minor-patch branch from ed4b1d1 to 53b13a4 Compare September 23, 2026 05:49
@renovate

renovate Bot commented Sep 23, 2026

Copy link
Copy Markdown
Contributor Author

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@renovate-approve renovate-approve[bot] renovate-approve[bot] approved these changes

Assignees

No one assigned

Labels

dependencies Pull requests that update dependencies

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@tnotheis