-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is historical query out of scope of this spec? Is it standardized anywhere else? #61
Comments
The 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. |
I agree, the implementation difficulty in supporting something like this is considerable. Happy to leave it to the DID Resolution Spec / optional extension. |
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... |
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:
@bumblefudge I'd be interested in discussing this with you, as presumably you're interested in the context of the |
Hey @vdods ! I wasn't asking on behalf of a particular implementation ( |
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). |
I would like to bring to your attention this paper:
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. |
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 fromdid: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...
The text was updated successfully, but these errors were encountered: