Re: DNS -> DIDs

Stephen Curran writes:

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

The writeup includes 1.5 examples: a mostly finished example of a
phone-like contact lists application.  This is a database you'd probably
run this on your device or synchronize with some host server mapping
DIDs bidirectionally to petnames.

Another example that we started to explain was the browser example, but
sadly I think I didn't fully finish that.  Looking at the (unfortunately
bitrotted) Petname Tool extension for Firefox can give some ideas though:

  https://www.w3.org/2005/Security/usability-ws/papers/02-hp-petname/

> 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.

Right... so, any DID in your network that you have a petname for can
itself be a naming hub that provides edge names.  For example, say I
have your DID in my petnames database as "Stephen Curran".  If you
provide an edge name for Markus, I could find Markus like:

  Stephen Curran => Markus Sabadello

Likewise if I have a DNS system set up as a petname, that's also a
naming hub, but it's an *equal player* naming hub.  Let's say that
Markus's DID is also findable through the DNS->DID protocol they
described, in which case I can find:

  DNS => danubetech.com

Which resolves to the same DID.

(Maybe they'd use a different domain, just as an example here.)

> 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.

I agree we don't have an answer to this per edge names, but perhaps you
can help me: you're indicating that two entities want to be able to talk
abou the "same" pairwise DID.  But edge names or otherwise it seems like
"talking about the same entity" is tough to do?  I still don't
understand how you and I might talk about the same entity with a
pairwise DID without unmasking them.

But won't that be true for DNS -> a pairwise DID as well?  Is it
pairwise if it's pointed to by DNS?

Probably the answer is the same thing there, because as I said, we can
interpret DNS as a naming hub which provides edge names.  If it can be
solved in one it can probably be solved in the other.

> 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.

Right... some ways to know and find DIDs and save them in your petnames
database:

 - You already know them and have them in your contacts.  That's the
   "petnames" scenario.
 - You know someone who knows them.  Friend of a friend type deal... and
   that's the "edge names" scenario.
 - You had an interaction with them in the system somewhere, and then
   "bookmarked them" as a petname (aka added to your contacts).
   Eg maybe they were Cc'ed on an email sent to you, or maybe you
   were directed to a project with their information.  We've been
   calling those "intro names".

> 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!
>>
>>

Received on Friday, 10 August 2018 15:19:59 UTC