Re: DNS -> DIDs

DID Documents are completely public. Is it not safe to assume that most DID
docs' contents will be indexed and searchable?

Adrian

On Fri, Aug 10, 2018 at 11:19 AM, Christopher Lemmer Webber <
cwebber@dustycloud.org> wrote:

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


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/