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

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.

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 <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 <http://mystodon.andrieu.net/?user=joe>/mypicture.png 

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

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> 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
+1(805)705-8651
http://blog.joeandrieu.com