Prefix AnonCred object identifiers for cross-ledger compat

[dbluhm]

On a recent Indy Contributors call, it was briefly discussed that instead of <did>/<object-type>/<object-type-identifier>, something like <did>/anoncreds/v1/<object-type>/<object-type-identifier> would be more compatible with anchoring AnonCreds objects on ledgers not based on Indy. I agree that this format would indeed be helpful as we look forward to AnonCreds as an independent standard.

From what I recall, there were not any dissenting views expressed on the call on this but figured it would be appropriate to open an issue to allow anyone who wasn't on the call to share their thoughts.

[swcurran]

For homework between now and this Tuesday's Indy Contributors call (8AM Pacific, 5PM CET), it would be good to look into the more general question from three angles:

• Is this the best approach from a DID Resolution perspective? I think it is, but confirming this with a read of the DID Resolution perspective would be a good idea or if there any other ideas.
• What object would we expect to get back from this? Presumably an object of the desired type, but should it be a DIDDoc with the object embedded?
• Would common DID Methods be able to support this? What DID Methods are important and how could they support this?

@peacekeeper, @talltree and other DID gurus -- it would be great to get your perspectives on this.

[peacekeeper]

<did>/anoncreds/v1/<object-type>/<object-type-identifier> looks good to me!

should it be a DIDDoc with the object embedded?

While you could do that, I don't think it's a good idea. You should just return the object itself, with an appropriate media type. What you're doing is strictly speaking not DID Resolution, but DID URL Dereferencing, which can return anything you want: https://www.w3.org/TR/did-core/#did-url-dereferencing

Would common DID Methods be able to support this?

Each DID Method would have to define separately how they can support dereferencing of such DID URLs. For some DID methods it would probably be easy to define that (e.g. for did:web), while for others it would be harder (e.g. for did:btcr).

[talltree]

I agree with @peacekeeper that if the DID URL uses a path in order to reference a digital object, then it should just return the native digital object with an appropriate media type.

If you want 100% interoperability across DID methods, i.e., the same behavior across all of them, I'd recommend using the resource parameter as defined by the DID URL Resource Parameter Specification. If you specify that, each DID method that wants to support the functionality of returning a native digital object directly can internally implement that functionality its own way, and the result will always be the same (direct return of a file with the requested media type) just as the resolution of a plain DID will always return a DID doc.

[swcurran]

This was discussed at the Indy Contributors call on 2022.02.01. Agreements:

• @dbluhm suggestion of putting the object family and object family version was the right thing to do. A PR is in that will address that when merged.

• From the discussion we expect to get back the object itself, not a DIDDoc or reference to the object. We do need to look at other DID Methods to see how this might be handled. did:web would seem to be easy, but it would be nice if others could be used. It would be interesting to look at the sidetree DID method to see if it could be used.

• We talked about the resource query parameter, but agreed that it is likely not relevant in this case. A resource (we think) is intended to be used when a DID is an identifier for a specific object. In this case, the DID identifies the "owner" or "controller" of a bunch of objects. For example, a single issuer, identified by a single DID may have many instances of these objects. The object identifiers will NOT be represented inside the DIDDoc of the DID, and so cannot be dereferenced based on the DIDDoc.