Is historical query out of scope of this spec? Is it standardized anywhere else?

[bumblefudge]

Might/should this spec have opinions about or include an optional behavior for historical query?

As @rhiaro cheekily suggested, you can always query https://web.archive.org/web/20220731132838/https://www.spruceid.com/.well-known/did.json if you want to read [in human-readable, HTML-wrapped form] what did:web:spruceid.com resolved to on 31 July 2022, but some implementers I've heard from would rather configure their web servers to return that historical DID doc from did:web:spruceid.com?dateTime=2022-07-31T19:17:47Z

Where would I send an implementer whose system requires this and would like to propose a standard for interop with other historical-query-supporting did:web hosts? Should they PR an entry into the DID Doc Extension Registry for the benefit of other DID hosting solutions that want to harmonize on query?

NB @dmitrizagidulin @peacekeeper since this is debatably more a DID resolution question than a DID web question...

[gribneau]

The did:web method differs from other methods in that it requires only a simple webserver without complex configuration.

It is certainly possible to establish a deterministic naming convention for historical snapshots and implement logic to return the appropriate snapshot based on some request criteria, and http entity tags could be leveraged to fingerprint versions. The lua module in nginx could handle this nicely as a reference implementation.

With that said, less ambitious extensions have been seen as dangerously complex, and the consensus has been to prefer simplicity.

[dmitrizagidulin]

I agree, the implementation difficulty in supporting something like this is considerable. Happy to leave it to the DID Resolution Spec / optional extension.

[bumblefudge]

Okeydoke. Is it worth PRing in a non-normative sentence simply pointing people to this section of the resolution spec and saying, "servers may choose to implement DID parameters or not, but it's out of scope of this spec"? Sometimes cross-referencing other specs helps newbs to DIDLand find the options they already have...

[vdods]

I'm also interested in historical DID document resolution, in particular for did:web.

The gap in implementation complexity from a simple "get active DID document only" model to a more complex "support historical DID document resolution" model is acknowledged.

In terms of a more complex "support historical DID document resolution" model:

• It seems that query params are the way to go; see https://www.w3.org/TR/did-core/#did-parameters -- however, as far as I'm understanding so far, how to deal with query params within the DID document's "id" fields is not yet resolved. See https://github.com/w3c/did-core/issues/337 (very very long issue thread) and https://github.com/OR13/did-params-and-you
• If the issue with query params in DID doc is resolved, then did:web could provide historical DID documents, though albeit in a way that is "weaker" than other DID methods, as it relies on non-compromise of a specific web server.
• Making did:web a "stronger" DID method could happen through use of the "hl" (hash link) query param. In particular, the hash of the active DID document at time of signing would be set as the "hl" query param value within the "key id" field of signatures, and the hash would be checked during DID doc resolution. However, there's an issue here relating to how query params are dealt with. If query params have to appear exactly as is in the DID doc, then there's no way to include the hash of the DID doc (because of the infeasibility of putting the hash of a document inside the document itself). To get around this, the "hl" param would have to be treated separately (e.g. dropped) before attempting to resolve DID resources, though this approach seems unpalatably complicated.

@bumblefudge I'd be interested in discussing this with you, as presumably you're interested in the context of the ssi implementation.

[bumblefudge]

Hey @vdods ! I wasn't asking on behalf of a particular implementation ( ssi-based or otherwise) but I'd be happy to discuss, ideally on a DIF WG call so that we spray around breadcrumbs for future people to find. I am on vacation this week but maybe we can request a time at a future IDWG call to discuss the lua+nginx solution mentioned above and the nuances of including a hash or hashlink somehow to backstop a web server compromise?

[decentralgabe]

I too am interested in historical resolution. I think it's a mandatory requirement for any "real" DID method. Without it you risk a bunch of verifiable data not being able to be verified, which has serious repercussions.

Could we, at the least, add a section on what to do when you add/remove keys? Perhaps another hosted file? Or a reference to an old key and how to interpret its usage (e.g. not to be trusted for data after a certain date).

[nikosft]

I would like to bring to your attention this paper:

F. Zhang et al. "DECO: Liberating Web Data Using Decentralized Oracles for TLS", in ACM CCS 2020 pdf

The solution, from a high level perspective, creates a bundle that can prove that a file was downloaded from a TLS server at some point in time. I am not saying that this is a solution to the problem, but I can envision some kind of transparence registry, where such bundles are recorded. If there is interest, I can support the design and implementation of such a registry.