Add "version-id" and "version-time" DID URL matrix parameters.

[peacekeeper]

This adds two concrete DID URL matrix parameters. See #189.

Description: Identifies a specific version of a DID Document to be resolved.

Example: did:example:1234;version-id=3 or did:example:1234;version-time=1556363673

---

Preview | Diff

[msporny]

This feels like something that should be in the DID Resolution protocol, not in the DID URL itself.

I don't understand the use case that requires this feature? When do you need to do something like this?

[peacekeeper]

@msporny

I don't understand the use case that requires this feature? When do you need to do something like this?

The idea is that you want to be able to know what a certain public key or service endpoint was at a specific point in time. E.g. you want to validate a longer-lived VC that was signed by an issuer 2 years ago, but the issuer's keys in their DID Document have been rotated since then. Or you want a stable reference to a service endpoint as it was in some previous version of a DID Document rather than the current service endpoint.

So you could do things like this:

did:btcr:xz35-jzv2-qqs2-9wjt;version-time=1557005485#keys-1

Or

did:btcr:xz35-jzv2-qqs2-9wjt;version-time=1557005485;service=myprofile/myphoto.jpg

This feels like something that should be in the DID Resolution protocol, not in the DID URL itself.

I agree this parameter could be passed to a DID Resolver separately from the DID URL, as an out-of-band option, but it can also make sense to have it as part of the DID URL in order to essentially make all historic DID Document information part of the URL's addressing space. I think anything that affects WHAT is being identified should be part of the DID URL.

See also #64 and w3c/did-resolution#12.

[msporny]

I agree this parameter could be passed to a DID Resolver separately from the DID URL, as an out-of-band option, but it can also make sense to have it as part of the DID URL in order to essentially make all historic DID Document information part of the URL's addressing space.

Ah, ok, understand the use case now (and it's what I thought it was).

I think this is a layer violation in the architecture and, in general, that the query protocol shouldn't be mixed into the matrix parameters.

To put this another way, we can solve this problem higher up on the stack (in the DID Resolution protocol, which may get very complex over the course of 10 years... which means we shouldn't set a precedent where the matrix parameters carry every possible thing you can pass to the DID Resolution process).

I'd rather we are very conservative w/ features w/ the 1.0 release, put optional things in the DID Resolution layer, and only move them down in the stack if it's clear that there is a pain point here.

[peacekeeper]

@msporny I understand that perspective, and I agree there will be many parameters/options on the DID Resolution layer that will never be expressed with matrix parameters or otherwise in the DID URL. E.g. caching behavior, this should definitely be controlled higher up on the stack. I can also see us treating versioning functionality the same way.

But for the sake of argument, let me try to make a point why it could still make sense to include versioning information in the DID URL: You would basically make previous versions of DID Documents addressable, and you could reference all those previous versions. For example, in a Linked Data Proof, you could explicitly reference a key from a specific version of a DID Document:

{
  "@context": "https://w3id.org/identity/v1",
  "title": "Hello World!",
  "proof": {
    "type": "RsaSignature2018",
    "creator": "did:btcr:xz35-jzv2-qqs2-9wjt;version-time=1557005485#keys-1",
    "proofValue": "eyJ0eXAiOiJK...gFWFOEjXk"
  }
}

I've been thinking of weblogs as an analogy. If you open the front page URL of a blog in your browser, you see the latest article. But all historic articles are also available on the blog. If you want to retrieve those historic articles, you don't just open the same front page URL and pass in a special HTTP header for versioning. That would actually violate web architecture, since the same URL can't identify more than one resource. So instead, all historic articles on that blog have their own URLs (permalinks). With versioning matrix parameters, we'd basically be creating permalinks for all historic DID Documents (and their keys, service endpoints, content references, etc.).

Maybe the analogy is flawed, but this was my thinking; like I said I'd also be happy to specify this as parameters on the DID Resolution layer, similar to caching and others.

We could also decide to not list ANY matrix parameters in the main DID spec and move them all into the DID Resolution spec.

[peacekeeper]

you don't just open the same front page URL and pass in a special HTTP header for versioning.

Actually, it seems there is an HTTP header for that: Accept-Datetime (RFC7089). It says:

The "Accept-Datetime" request header is transmitted by a user agent to indicate it wants to access a past state of an Original Resource.

So I guess that supports your argument.

[cboscolo]

If we do end up enabling a way to resolve DID Documents via a version id, we will need to be careful with how public keys are referenced when used within protocols such as DID Auth.

We don't want to allow an attack where someone can use an old compromised key by referencing a DID Document by the version for which the key would work.

[msporny]

The DID TF agreed to merge this during the 2019-08-01 meeting.