QUESTION - Resolving other objects than did.json documents

[PatStLouis]

What is the most appropriate way to resolve other documents than did.json?

We are looking to propose a did:web method for the AnonCreds v1.0 Specification. The spec is currently implemented with did:[sov|indy|cheqd|cardano].

There are some json objects which need to be publicly stored. These include:

• schemas
• credential definitions
• revocation registry definitions
• revocation registry entries

These are then referred to as object ID's for external processing, which are did urls.

Would appending a .json at the end suffice to resolve these objects without conflicts? Meaning if the did url ends with .json, do not append /did.json. Examples:

• did:web:<domain>:<checksum>.json
• did:web:<domain>:v1/schema/<checksum>.json
• did:web:schema.<domain>:v1/<checksum>.json
• did:web:<domain>:acme/v1/schema/<checksum>.json

Thoughts, concerns, insults, suggestions and opinions are all welcome!

[gribneau]

The DID core specification does not allow the path component to be used as indicated in your examples.

If, theoretically, the name of a JSON file were allowed, this: did:web:<domain>:v1/schema/<checksum>.json

would need to be represented this way: did:web:<domain>:v1:schema:<checksum>.json

Ultimately, though, it would seem that the identifiers are intended to represent resources other than DID documents, which is likely to draw criticism.

I had a related use case in which I wanted webservers to host human readable content and DID documents on the same HTTPS URL, using content negotiation based on the content type header to select the proper resource to return. I used a dedicated method to support that use case.

[PatStLouis]

Thanks for your input. We can definitly swap the path seperators for colons as specified.

Indeed, we are looking to represent objects specific to the AnonCreds spec using the did:web method. These ojects are currently documented in the did:indy|sov|cardano|cheqd methods thanks to recent work from respective communities and WG.

We are reaching out to see if there is such a concept in the did:web specification currently or if this use case would ultimately need to be documented on the AnonCreds spec for contextual use with did:web URI's. We are also looking to be considerate of existing standards for ease of implementation.

Could you provide more details on how you went about the dedicated method you are referring to? Is there any documentation available?

These objects are not meant for human readability but machine credential lifecycle management.

[PatStLouis]

@gribneau the did core spec does make use of "/' for path representation if I understand correctly (see EXAMPLE 2), could you elaborate why you believe it's wrong in my example?

[gribneau]

The path component is used to locate a resource within a DID document. It is not used in resolving the DID Document itself.

DIDs are resolvable to DID documents.

A DID URL extends the syntax of a basic DID to incorporate other standard URI components such as path, query, and fragment in order to locate a particular resource—for example, a cryptographic public key inside a DID document ...

[gribneau]

Could you provide more details on how you went about the dedicated method you are referring to? Is there any documentation available?

The method is here: https://vpsqr.com/did-method-psqr/v1/

The intended use case is here: https://vpsqr.com/did-psqr/v1/

And the resolver is here: https://github.com/public-square/psqr-did-resolver

[genaris]

The path component is used to locate a resource within a DID document. It is not used in resolving the DID Document itself.

DIDs are resolvable to DID documents.

A DID URL extends the syntax of a basic DID to incorporate other standard URI components such as path, query, and fragment in order to locate a particular resource—for example, a cryptographic public key inside a DID document ...

I think that the example given right after the ellipsis is relevant here:

..., or a resource external to the DID document.

AnonCreds objects are resources associated to the DID and IMHO can apply to this definition. Probably, the initial question (What is the most appropriate way to resolve other documents than did.json?) was not properly formulated or led to confusions.

In these AnonCreds methods @PatStLouis is referring to, there is a single DidDocument associated to the DID (in the case of this did:web method, it would be a JSON file present at host/.well-known/did.json), while a DID URL is used to identify the objects related to that DID (for instance did:web:host/anoncreds/v1/schema/uniqueObjectId or did:web:host/resources/uniqueObjectId). As these AnonCreds objects do have a JSON representation, it might be convenient to threat them in the same way than the DidDocument and maybe that's why the original question referred to them as documents.

If we consider correct using a DID URL and a path (TBD) to identify these resources, I think the main question here is how, in practice, a 'did:web resource resolver' would retrieve them, in a similar fashion it did:web resolvers already do with the DidDocument. We have some ideas for the specific case of AnonCreds, but it would be interesting to know if it could be possible to have a generic way of retrieving resources using did:web so the case can be generalized.

[gribneau]

AnonCreds objects are resources associated to the DID and IMHO can apply to this definition.

That might gain support. DID:WEB does not currently use either path or query. The fragment often refers to an element within the DID document, frequently a public key.

Given the resolution of the DID itself to an https url, including a path, it might be more intuitive to use the query component.

[PatStLouis]

Interesting. Providing a service + endpoint in the did document and use a service + relativeRef query would be the most appropriate then if I understand?

ex: did:web:{domain}?service=anoncreds&relativeRef=/schema/{objectID} or did:web:{domain}?service=ressources&relativeRef=/{objectID}

[gribneau]

That looks plausible to me.

Including the service in the DID document and referencing in the query would be a method-agnostic approach that could easily add value to a variety of future implementations.

[OR13]

Closing this as, asked and answered, but feel free to reopen or raise a new issue if you have more questions.