RE: A simpler approach to DID services and content-addressing

RE: resolve the DID Document at a certain timestamp

The OASIS/ISO OData standard defines a extensive collection of time and date functions (and there are existing OData implementations that can be leveraged from an implementation perspective):
http://docs.oasis-open.org/odata/odata/v4.01/cs01/part2-url-conventions/odata-v4.01-cs01-part2-url-conventions.html#_Toc505773257.

These are leveraged using the $filter option.

[cid:image001.jpg@01D4EACA.89F623D0]

Best regards,
Michael Herman (Toronto/Calgary/Seattle)
Independent Blockchain Developer
Hyperonomy Business Blockchain / Parallelspace Corporation

W: http://hyperonomy.com<http://hyperonomy.com/>
C:  +1 416 524-7702


From: Markus Sabadello <markus@danubetech.com>
Sent: April 4, 2019 9:29 AM
To: Manu Sporny <msporny@digitalbazaar.com>; public-credentials@w3.org
Subject: Re: A simpler approach to DID services and content-addressing


Another use case, which I think is hard with the "colon only" syntax, is versioning - resolve the DID Document at a certain timestamp.

With matrix parameters, this could be done as follows:

Agent service endpoint at a certain time:
did:xyz:1234;service=agent;version-time=1554389617/path?query#frag

Content at a certain time:
did:xyz:1234;hashlink=hl:zQmWvQ...;version-time=1554389617

Public key at a certain time:
did:xyz:1234;version-time=1554389617#keys-1

Markus
On 4/4/19 5:11 PM, Manu Sporny wrote:

On 4/4/19 5:43 AM, =Drummond Reed wrote:

1. The issue we saw with Manu's proposal is that there is no

syntactic delimiter between the "naked DID" (that identifies the DID

subject) and the parameters.



The delimiter string between the "naked DID" and the parameters are

":path:" and ":hl:", for the use cases produced thus far.



I did not do one for type because we haven't heard of an example where

that is required, and if that existed, the processing rules would change

to "first search for an identifier, then search by type". So, if that

use case is important to folks, and it's not solved via an array of

service endpoints (which is simpler), then we still have a solution that

works.



The other advantage is that we can still reserve the ";" for matrix

parameters in the future, if we need them, but at this point, we can

solve the use cases without using matrix parameters and thus keep the

syntax for DIDs simpler.



2. The only issue we had with Michael Herman's proposal is that the

syntax seemed heavier-weight (i.e., uses more delimiter characters)

than necessary, particularly for a URL grammar.



I too would like to avoid the heavy use of complex microsyntaxes.



-- manu