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

This is definitely a topic that will have to be covered in the DID
Resolution, but I don't think it's a problem, we just need to set some
"appending rules" instead of doing "blanket appending", e.g.

Assume A is the DID URL to be dereferenced, and B is the service
endpoint in the DID Document, then we could say e.g.:

- Result URL's scheme and authority = B's scheme and authority
- Result URL's path = B's path + A's path
- Result URL's query string (if neither A nor B has a query string) = null
- Result URL's query string (if only A has a query string) = A's query
string
- Result URL's query string (if only B has a query string) = B's query
string
- Result URL's query string (if both A and B have query strings, and
both query strings are in the form of &key=value pairs) = merge A's and
B's query strings
- Result URL's query string (otherwise) = [resolution error]
- Result URL's fragment (if neither A nor B has a fragment) = null
- Result URL's fragment (if only A has a fragment) = A's fragment
- Result URL's fragment (if only B has a fragment) = B's fragment
- Result URL's fragment (if both A and B have fragments) = [resolution
error]

In fact, we may even be able to re-use some standard rules for relative
URI references instead of the above list.

Markus

On 4/4/19 7:00 PM, Joe Andrieu 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.
>
> 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.
>
> 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
>