Re: DNS -> DIDs

The petnames idea is pretty cool as described but not sure about an
implementation.  Any concrete thoughts on how petnames could be implemented?

Perhaps multiple entities push to some places their petnames for public
DIDs they know and when needed your software (agent, hub) can get the list
for a DID and determine both a consensus and names that are "close" to you
- e.g. from DIDs that you know?  Something like that?  Consensus names
might not be a good idea - we've seen how that can be gamed with Amazon
Reviews.

Another general challenge to petnames is the idea of pairwise DIDs, since
then  there is no sharing of the DIDs - the only instance of the DID is the
one you have for another entity.

Obviously, your own list is easily managed. It's getting help with public
DIDs you don't know that is the challenge.  Note that this same problem
occurs when deciding if you trust a Verifiable Claim issued by a DID you
don't know.

On Thu, Aug 9, 2018 at 7:51 AM, Christopher Lemmer Webber <
cwebber@dustycloud.org> wrote:

> Markus Sabadello writes:
>
> > Hello CCG,
> >
> > I've been working with the Austrian domain registry nic.at on an IETF
> > draft on how to publish a DID for a domain name:
> > https://www.ietf.org/id/draft-mayrhofer-did-dns-00.txt
> >
> > We also posted this to 2 IETF lists:
> > https://mailarchive.ietf.org/arch/browse/din/
> > https://mailarchive.ietf.org/arch/browse/dnsop/
> >
> > Any feedback welcome. Perhaps we put this on the agenda for a future CCG
> > call?
> >
> > Markus
>
> I think it's good that you're looking into this, but...
>
> >   By referring to DIDs from the DNS, those hard to memorize identifiers
> >   can be discovered via well known, human friendly and widely
> >   established names.  This document specifies such a protocol, and
> >   describes how DIDs can be discovered on the basis of host names and
> >   email addresses.
>
> At first glance this seems like a big win: we can bootstrap the system
> quickly off of a naming mechanism that users are already using.  But I
> think we have to be careful here *if we tell users they can just use DNS
> as they currently use it*, for a few reasons:
>
>  - DNS brings centralization back to the system
>
>  - Usually when decentralized systems rely on DNS, they become
>    centralized again.  And since DNS isn't very secure and doesn't carry
>    the information about the cryptographic information of the target
>    along with it, usually it needs to be coupled with a CA.  Now we're
>    back to DNS + CAs again.
>
>  - If we say, "don't worry, you can find my DID from my DNS record", in
>    that case is the DNS record allowed to change?  If that's true then
>    there's a good chance that applications will just rely on DNS, and
>    will in fact have to check it all the time, because users will still
>    be resolving applications via DNS which can change all the time.
>
>  - And if you're going to rely on DNS -> the DID id as your only naming
>    scheme, you probably don't need any of the complexities we're
>    building into DIDs at all.  No need for a blockchain or anything.
>    You already have a way to serve up a JSON document with all that
>    info... just serve it over HTTP.
>
> So I really caution about encouraging users to use DNS to resolve to
> DIDs in the same way we do today.
>
> But... but!  There is a way to include DNS that's much safer I think,
> and could even use the protocol you've described above.  Instead if we
> have a petnames system as described in the sadly incomplete:
>
>   https://github.com/cwebber/rebooting-the-web-of-trust-
> spring2018/blob/petnames/draft-documents/making-dids-
> invisible-with-petnames.md
>
> DNS can become one equal naming hub among many.  It isn't the definitive
> name resolution mechanism to get to an ID... it's just one mechanism
> users can use to find it.
>
> Again, I think the work you put in can be utilized if we take that
> approach.  But I really think we need to be careful and not give users
> the impression that they can use DNS the way they currently do... that
> could accidentally undo all the work we're doing in this group!
>
>


-- 

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


*Cell: (250) 857-109Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*