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

I agree with Drummond on this. At the DID grammar (i.e. syntax structure) level, the grammar needs to be inclusive. The intent of a grammar is to say: a generic compliant did-uri looks like "this" where "this" is the syntax structures defined using ABNF notation ...like a template.

Michael

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: =Drummond Reed <drummond.reed@evernym.com>
Sent: Thursday, April 4, 2019 12:54:49 PM
To: Joe Andrieu
Cc: Credentials Community Group
Subject: Re: A simpler approach to DID services and content-addressing

On Thu, Apr 4, 2019 at 10:01 AM Joe Andrieu <joe@joeandrieu.com<mailto:joe@joeandrieu.com>> wrote:
Stephen,

This isn't quite accurate. For URLs, the fragment is the only part that is handled by clients post dereferencing.

We do not currently have semantics for path and query parts for DIDs.

Agreed.


For non-service pointing DIDs, there is literally no consensus on what to do with path and query parts.

For service point DIDs, there is a use case for "file folder" applications where you have a large set of assets you wish to have portable, consistent access to, such as you might build a web page with local references and move it to a different domain and it all still works. The goal here is to do that WITHOUT changing the DID, but rather just the service endpoint.

The blanket appending of path & query parts to service endpoints is problematic because the service endpoint itself could have path & query parts. So how do you amalgamate?

did:ex:123;me/mypicture.png

When I move from one service to another, e.g.,
from http://twitter.com/JoeAndrieu to http://mystodon.andrieu.net?user=joe

The append DID may have been valid at twitter http://twitter.com/JoeAndrieu/mypicture.png but is almost certainly NOT at mystodon: http://mystodon.andrieu.net?user=joe/mypicture.png

So, for some use cases, appending will break the urls.

Joe, you are absolutely right. However I propose that we look at this different: if in the DID spec we specify a simple standard uniform transform rule (which I think should be exactly what you call "blanket appending" with no other logic applied), then we enable service providers anywhere on the Web to begin competing on offering DID service URL portability to users. All the service provider has to do is configure their own service offerings to support portability—which is as simple as designed the URLs for their base services to accept "blanket appending" of DID service URL payloads.

In other words, this does NOT mean that DID service URLs will automatically make everything that is URL addressable portable everywhere. However it DOES mean that there would now be a way for any service provider to offer DID service URL portability to its customers.

For example, I personally would choose a blog hosting company who guarantees that they will support DID service URL portability—and eliminate any who do not.

So we would be enabling a new market more so than fixing all the problems in an old one.

=D



On Thu, Apr 4, 2019, at 8:47 AM, Stephen Curran wrote:
Daniel, that is available for the developer to use as the DID URL. However, it is to be processed by the client - post resolution.  The matrix syntax parameters enables information to be passed to the resolver, so that it can handled at resolution time.  So it is good for interacting with the ledger. In the Indy case - getting non-pure-DID-type data off the ledger (schema, creddef, rev reg) by the resolver with DID syntax.  Query params can be used after the data is back to the client.



On Thu, Apr 4, 2019 at 8:39 AM Daniel Hardman <daniel.hardman@evernym.com<mailto:daniel.hardman@evernym.com>> wrote:
Please forgive me if this question triggers remedial tutoring.

Is there some important reason why we can't repurpose an existing convention? For example, could we just adopt the familiar syntax for query strings?

did:example:1234abcd?a=b&c=d&e=f

This has the advantage that every software stack on the planet probably already has code that can parse it, and every developer already knows it.




--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Technical Governance Board Member - Sovrin Foundation (sovrin.org)

Schedule a Meeting: https://calendly.com/swcurran

--
Joe Andrieu, PMP
joe@joeandrieu.com<mailto:joe@joeandrieu.com>
+1(805)705-8651
http://blog.joeandrieu.com