build: Bump cheqd driver to v3.7.0

[ankurdotb]

Key changes

This release addresses feedback regarding the current state that dealing with DID-Linked Resources (DLR) typically requires two API calls:

1. One to resolve the DID Document and its metadata, which contains the DLR metadata too
2. One to fetch the resource itself
3. If just fetching a DLR, the DLR and DLR metadata need to be fetched separately

This release allows, for certain Accept header profiles, for both the DLR and its metadata to be fetched in a single call. We've also maintained backwards compatibility with current behaviour when no specific header is provided or DID Documents/DLRs fetched in the browser.

Supporting more granular ways of fetching DID Documents and DID-Linked Resources will offer developers greater control when fetching resolution/dereferencing results.

For DID Resolution

1. Accept: application/ld+json;profile="https://w3id.org/did-resolution": Returns DID Document + DID Document metadata with DID-Linked Resource metadata
2. Accept: application/did+json, application/did, or application/did+ld+json: Returns DID Document only, no DID Document metadata
3. Accept: */* or accessing via browser: → Returns DID Document + DID Document metadata with DID-Linked Resource metadata
4. Query parameter resourceMetadata=false: Returns DID Document + DID Document metadata without DID-Linked Resource metadata

For DID URL Dereferencing

1. Accept: application/ld+json;profile="https://w3id.org/did-url-dereferencing": Returns DID-Linked Resource (Base64-encoded) and its metadata in a single response
2. Accept: */*, specific Accept header (e.g., Accept: application/json), or accessing via browser: Keeps existing behaviour, returning only the DID-Linked Resource

General improvements

1. When specifying multiple acceptable values in Accept header, you can now use q values to prioritise preferred IANA media types in response and this will be respected.
2. If DID-Linked Resource queries are ambiguous, an invalidDidUrl error is now thrown instead of attempting to resolve to first matching DID-Linked Resource
3. DID-Linked Resource metadata is now consistently returned in contentMetadata rather than contentStream. Only the actual DID-Linked Resource, if requested in body in Base64-encoding, is returned in contentStream

Full changelog

https://github.com/cheqd/did-resolver/releases/tag/v3.7.0

[BernhardFuchs]

@ankurdotb @peacekeeper Version 3.7.0 of the cheqd driver with latest tag of uni-resolver-web return following error:

[internalError] Driver cannot retrieve resolve result for did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47 from http://cheqd-did-driver:8080/1.0/identifiers/did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47: No DID document consumer for media type: application/ld+json

[peacekeeper]

This may be a bug in the Universal Resolver itself, I will take a look..

[ankurdotb]

A bit confused indeed, so do let me know. I tried it with that Accept header on Postman and seemed to work 🤔