Re: DNS -> DIDs

I think the model that some networks are moving to is for most DID Docs to
be held between the communicating parties, and not pushed out to a public
ledger.  Anyone that needs to resolve the DID -> DIDDoc must be able to in
some local manner (implementation specific), and there must be mechanisms
to push changes from one party to the other. Those same mechanisms are need
for updating the DIDDoc when it is on a public ledger.  So, that does to
some degree help with preventing correlation - there is not an obvious way
to get the list of DIDs in active use for indexing and searching.  In that
model, the DIDs that do go on the public ledger are ones that people want
known - e.g a public DID for an Enterprise to be used to start connections.

Net traffic can be monitored going into and out of a "known endpoint" such
as an Agency (holding many Agents) or a Hub. The plans I have seen on the
HyperLedger Indy side are that data will be encrypted in transit - no
plaintext - and that because the endpoint is shared by all Agents (e.g.
many identities, each with many DIDs), it will be difficult to learn from
just seeing the 'Net traffic.

On Fri, Aug 10, 2018 at 10:29 AM, heather vescent <heathervescent@gmail.com>
wrote:

>
>
> On Fri, Aug 10, 2018 at 9:42 AM, Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> DID Documents are completely public. Is it not safe to assume that most
>> DID docs' contents will be indexed and searchable?
>>
>
> That's an interesting idea I hadn't thought much about. Is this
> functionality that an agent might have?
>
> I can envision a service that is between the ledger (DID, DID Document
> data) and the wallets, hubs/agents that is in the cloud, but is perhaps not
> exactly a hub or agent. If this service monitored the connections between
> the DIDs, do you think it would be possible to correlate them? Or gain
> information about the end points based on the # of DIDs and connections?
>
> My question is asked in the context of monitoring web traffic and making
> assumptions based on network traffic, even while not seeing the specific
> data or connections.
>
> -H
>
>
>
>> 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/
>>
>
>
>
> --
> Heather Vescent <http://www.heathervescent.com/>
> The Purple Tornado, Inc
> ~ The Future in Present Tense ~
>
> @heathervescent <https://twitter.com/heathervescent> | Film Futures
> <https://vimeo.com/heathervescent> | Medium
> <https://medium.com/@heathervescent/> | LinkedIn
> <https://www.linkedin.com/in/heathervescent/> | Future of Security Updates
> <https://app.convertkit.com/landing_pages/325779/>
>



-- 

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