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

On Thu, Apr 4, 2019 at 10:01 AM Joe Andrieu <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>
> 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
> <https://calendly.com/swcurran>*
>
>
> --
> Joe Andrieu, PMP
> joe@joeandrieu.com
> +1(805)705-8651
> http://blog.joeandrieu.com
>
>