Define fragment processing rules for application/did

[msporny]

The specification currently doesn't define fragment processing rules. We have to define those rules by either reusing the one from application/cid or defining new ones.

[msporny]

... or defining new ones. Was distracted on the DID WG call and trying to create this issue... and clearly, forgot to complete that thought. Original comment fixed so no one else is left wondering. :)

[swcurran]

An interesting issue came up today in the did:webvh (formerly called did:tdw) Work Item Meeting at DIF, going over the spec.

An important feature of did:webvh is providing a resolver and client of a resolver access to the history of the DID (it's in the name vh -- Verifiable History). The DID Method is intended to enable good security practices -- regular rotations of the keys in the DIDDoc, as well as the ability to verify signatures using "old keys" so that things like verifiable credentials can be long lasting. We don't want to have to reissue all the verifiable credentials signed by the key when we simply rotate it to another key. Note that handling the revocation of a key because it has been compromised and known to be used by a malicious actor is different than just rotating away from a key. That's a separate (but related) case to what I'm talking about here.

Given that, if someone comes across, for example, a verifiable credential signed by a DID URL in the form <did>/#frag, should a resolver return the associated DIDDoc (and hence, the fragment) when the fragment is not in the current version of the DIDDoc but is in a prior version of the DIDDoc? Of course, any DID Method supporting this would have to have access to the full history of the DID, but that is exactly what is provided with did:webvh. The DID Controller could choose to keep all #frag values in the current DIDDoc to enable that (and that would work in did:webvh as well), but we really want to avoid that -- did:webvh automagically provides access to "old keys", so bulking up the DIDDoc seems like a bad idea.

Our answer so far is "no -- that should not be supported". However, we thought we should raise the topic on this issue, as if supported, it would be a useful feature in did:webvh.

A DID URL of the form <did>?versionId=<version>#frag would work, and so is likely sufficient.

The key revocation topic is also interesting. In the case of the DID URL above (version and fragment) -- the resolver/client would get the precise key of interest, but would not know if the key had later been explicitly revoked by the DID Controller (vs. just rotated away). We think this should be (somehow -- perhaps via DID Metadata) enabled via the DID Core specification (but not sure how) and are considering how to deal with that.

[peacekeeper]

should a resolver return the associated DIDDoc (and hence, the fragment) when the fragment is not in the current version of the DIDDoc but is in a prior version of the DIDDoc?

As discussed, in my opinion this isn't possible, a fragment can't identify something that's not in the DID document

The DID Controller could choose to keep all #frag values in the current DIDDoc

Yes this would work. Also note the "revoked" property in the CID specification: https://w3c.github.io/cid/#dfn-revoked

A DID URL of the form <did>?versionId=<version>#frag would work

Yes this would also work.