W3C home > Mailing lists > Public > public-credentials@w3.org > August 2019

Re: What’s after DIDs?

From: Markus Sabadello <markus@danubetech.com>
Date: Wed, 14 Aug 2019 00:46:45 +0400
To: Daniel Thompson-Yvetot <drthompsonsmagickindustries@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>
Cc: Dave Longley <dlongley@digitalbazaar.com>, Henry Story <henry.story@gmail.com>, Credentials Community Group <public-credentials@w3.org>
Message-ID: <c5e7977c-e046-887c-1d10-72aacec5ec99@danubetech.com>
Hi Daniel,

The DID itself can't be *did/example/123456*, because that's not a valid
URI (DIDs being valid URIs is one of their central features).

In theory it would be possible to define a DID Resolution binding
<https://w3c-ccg.github.io/did-resolution/#bindings-https> that would
resolve a DID like *did:example:123456* by making an HTTP GET call to
*https://api.service.com/v1/did/example/123456*.

But then again, what's wrong with just concatenating the DID with
colons, i.e. *https://api.service.com/v1/did:example:123456* ?

Markus

On 7/31/19 3:46 AM, Daniel Thompson-Yvetot wrote:
> > Which colon are you referring to?
> *did:example:123456/path
> *
> My question is better phrased as a proposal: 
>
> If this was the id:
>
> *did/example/123456/path
> *
> and this the resolver:
>
> *https://api.service.com/v1/
> *
> with a mere concat this would be simple.
>
> *https://api.service.com/v1/did/example/123456/path*
>
>
>
> On Tue, Jul 30, 2019 at 7:35 PM Manu Sporny <msporny@digitalbazaar.com
> <mailto:msporny@digitalbazaar.com>> wrote:
> >
> > On 7/30/19 12:39 PM, Daniel Thompson-Yvetot wrote:
> > > Is there a real reason why it has to be : delimited instead of /
> > > delimited?
> >
> > Which colon are you referring to?
> >
> > -- manu
> >
> > --
> > Manu Sporny (skype: msporny, twitter: manusporny)
> > Founder/CEO - Digital Bazaar, Inc.
> > blog: Veres One Decentralized Identifier Blockchain Launches
> > https://tinyurl.com/veres-one-launches
Received on Tuesday, 13 August 2019 20:47:14 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:55 UTC