- From: Joe Andrieu <joe@legreq.com>
- Date: Fri, 10 Aug 2018 16:04:57 -0700
- To: public-credentials@w3.org
- Message-Id: <1533942297.75103.1470429344.6D6107ED@webmail.messagingengine.com>
The canonical DID Document is public. That's the point of the DID, to resolve publicly to the DID Document. On ledger (or derivable from the ledger like BTCR) is preferred because it avoids the phone home problem. You *could* also have a composable DID document, as is supported by BTCR, where other parts of the DID Document are resolved elsewhere, e.g., IPFS or even at a http endpoint. The use of a http creates a phone home problem. You could also have what I call a data DID (although there is not yet such a DID method), in which the DID document is embedded in the DID itself, much like a data: URL embeds the resource in the URL itself. This loses the ability to rotate keys and modify endpoints after the DID is initially communicated. These latter two examples are not "canon" in that they aren't how/why we came up with the architecture. HOWEVER, it is my opinion that the ultimate goal is to establish DIDs as widely and broadly as possible. To support that, we'd be better off supporting these DIDs of fewer guarantees than to deny such DID methods as valid. Those developers that need these kinds of DIDs will end up using another approach and we all lose from that bifurcation. IMO, it's better to have a common framework that works even for use cases that don't need the guarantees of the on- ledger DIDs. Also, the DID method registry is managed under a consensus, so legitimate DID methods that used these approaches should, IMO, be recognized. Of course, we could define the requirements for all DID methods to support key rotation and public DID documents, but that will likely either lead to non-compliant implementations or simply the emergence of alternative standards, both would be unfortunate. So, while I'm an advocate of the most censorship-resistant approach as canon, I welcome all the variants that the DID data model reasonably supports. -j On Fri, Aug 10, 2018, at 3:12 PM, heather vescent wrote: > > On Fri, Aug 10, 2018 at 12:21 PM, Stephen Curran > <swcurran@cloudcompass.ca> wrote:>> 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.> > Is this really the case? Which of the ledgers are moving in this > direction? And if so, I'm curious why?> And also if so, can you please point me to documentation. > >> 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.> > But the whole point of putting the DID and DID Doc on the ledger is so > they are always available. It seems counterintuitive to put the DID > but not the DID Doc on the ledger. There is no PII in the DID Doc > (just a #, the public/private key, and any endpoint links)....> >> 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.> > This seems like making this way more complex than is necessary - in > response to my question about the black arts of correlation via > watching data flows vs capturing the actual data. I wasn't saying we > have to solve for that extremely crazy corner case, I was curious if > it maps to that similar problem...> >> >> 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.> > Yeah, but the endpoint is also stored in the DID Doc, and all the PII > data is stored in the wallet, or agent, or hub, or whatever cloud > thing or hardware thing you've decided to use.> > So why/how would it make sense to NOT store the DID Doc on the ledger?> > > >> >> 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[1] >>> The Purple Tornado, Inc >>> ~ The Future in Present Tense ~ >>> @heathervescent[2] | Film Futures[3] | Medium[4] | LinkedIn[5] | >>> Future of Security Updates[6]>>> >> >> >> >> -- >> Stephen Curran Cloud Compass Computing, Inc. (C3I) Technical >> Governance Board Member - Sovrin Foundation (sovrin.org)>> *Cell: (250) 857-109 Schedule a Meeting: ** >> https://calendly.com/swcurran*>> > > > > -- > Heather Vescent[7] > The Purple Tornado, Inc > ~ The Future in Present Tense ~ > @heathervescent[8] | Film Futures[9] | Medium[10] | LinkedIn[11] | > Future of Security Updates[12] -- Joe Andrieu, PMP joe@legreq.comLEGENDARY REQUIREMENTS +1(805)705-8651Do what matters. http://legreq.com[13] Links: 1. http://www.heathervescent.com/ 2. https://twitter.com/heathervescent 3. https://vimeo.com/heathervescent 4. https://medium.com/@heathervescent/ 5. https://www.linkedin.com/in/heathervescent/ 6. https://app.convertkit.com/landing_pages/325779/ 7. http://www.heathervescent.com/ 8. https://twitter.com/heathervescent 9. https://vimeo.com/heathervescent 10. https://medium.com/@heathervescent/ 11. https://www.linkedin.com/in/heathervescent/ 12. https://app.convertkit.com/landing_pages/325779/ 13. http://www.legendaryrequirements.com
Received on Friday, 10 August 2018 23:05:25 UTC