- From: Daniel Hardman <daniel.hardman@evernym.com>
- Date: Wed, 11 Dec 2019 21:11:40 -0700
- To: Adrian Gropper <agropper@healthurl.com>
- Cc: Stephen Curran <swcurran@cloudcompass.ca>, Orie Steele <orie@transmute.industries>, Oliver Terbu <oliver.terbu@consensys.net>, W3C Credentials Community Group <public-credentials@w3.org>
- Message-ID: <CAFBYrUpOgOqTVYkWDCjPK9Li=NqJoCn_Aq=Xw-KFRsCk6LjwuA@mail.gmail.com>
+1 to all of this. Sounds smart to me. On Wed, Dec 11, 2019 at 9:07 PM Adrian Gropper <agropper@healthurl.com> wrote: > Daniel, > > Once again, I think we fundamentally agree. > > - Neither of us wants to exclude either HTTPS or DIDcomm. > - I think any protocols that preference federated identity or trust, > including CAs, are DOA. I have seen federated ID fail completely in > healthcare and to large extent elsewhere. > - I'm not after making a better GoogleDrive/Dropbox/iCLoud data store. > Any protocol that puts P2P interactions at a disadvantage is DOA on my > roadmap as well. > - I agree that asynchronous multiparty interactions are key. Hence, I > use the UMA transaction model (registration precedes authorization) for > Alice to Bob and capabilities (async by design) as much as we can. > > I also agree that the set of addressable use cases is larger for DIDcomm > than HTTPS, but that brings with it a potential adoption problem that we > can mitigate by careful design. That's my goal here. I don't care about > server platforms Google Drive / Dropbox / iCloud one way or another. > They're just data brokers with a (proprietary) layer of consent as far as > I'm concerned. > > What I care about in terms of adoption is the millions of server entities > like vehicles, labs, hospitals, banks, and schools that have *original* > data about me exposed via some API, and they also, as you point out, > typically have useful CA certificates. In these millions of cases, the > adoption of SSI could be at risk if we insist on DIDcomm. Do we call these > millions of service providers "storage"? I don't care. I call them resource > servers but that's unimportant. > > Here's one thought experiment that I might call Uauth (as opposed to > DIDauth or OpenID). > > - A service exposes an authentication endpoint like a userID on a web > page or the equivalent in some other protocol > - The endpoint accepts any identifier that might be resolved to a > proof of control by Alice: > - a DID > - an email that WebFinger resolves to a DID > - an email that WebFinger resolves to an UMA Authorization Server > - an OpenID Connect IDP > - a password challenge > - The service does its best to establish a secure connection with > Alice. If it succeeds, the transaction continues and a message passes. > > From my perspective, Uauth is the best path to SSI because every one of > the millions of current services can choose to offer this Uauth input field > as an identifier and simply add an SSI logo if DIDauth and/or DIDcomm might > work. As a user, Alice might prefer to get a DID to get passwordless SSO > and many privacy benefits depending on the method. The decisions to adopt > SSI would be independent by Alice, Bob, and the service enterprise . SSI > adoption would proceed incrementally. > > Given Uauth, other aspects of the messaging protocol such as scopes and > capabilities would also need to be standardized. But that is a separable > concern in my model. > > Adrian > > On Wed, Dec 11, 2019 at 8:15 PM Daniel Hardman <daniel.hardman@evernym.com> > wrote: > >> Adrian: >> >> I am mostly content to let the conversation focus on the question you >> posed ("applied separately") --but I feel compelled to note a false mental >> model that might grow up around your framing. To be clear, this is a >> tangent to your main question, though. >> >> HTTPS and DIDComm may represent opposite choices with respect to root of >> trust, but treating them as direct equivalents is a misleading >> simplification. DIDComm can (and in most impls, does) run over HTTP or >> HTTPS (1.0, 1.1, or 2.0); deciding that you want these transports doesn't >> mean you've decided that DIDComm is irrelevant. DIDComm over HTTP(s) just >> means that the payloads of your POSTs are DIDComm JSON messages instead of >> some other JSON envelope, custom-invented for a particular problem domain. >> So a more insightful framing might be certs-and-sessions vs. DIDComm, with >> HTTP being orthogonal. >> >> The set of addressable use cases with DIDComm is bigger than the set >> addressable with HTTPS, because it solve additional problems. With HTTPS, >> the security is an attribute of the transport; configure the transport >> badly, and the security vanishes. (As we all know to our chagrin, this >> frequently happens with self-signed and expired certs.) With DIDComm, >> security is an attribute of the messages, and transports are incidental. >> Also, HTTP(s) is inherently client/server and request/response and 2-party >> and more-or-less synchronous. DIDComm is peer-to-peer and not necessarily >> request/response (though it supports that style of interaction) and not >> necessarily 2-party, and not particularly synchronous. Thus: >> >> - If you want to support interactions over sneakernet (thumb drives, >> plain old files) and BlueTooth and SMTP and FTP and WebSockets and SSE and >> XMPP and AMQP--or if you want mixed transports (Alice sends to Bob over >> HTTP, and an intermediary translates to the BlueTooth on Bob's phone for >> the last leg), you need DIDComm or something like it. (Or you can use HTTPS >> when the transport is HTTP, and invent entirely different protocols for the >> other transports.) >> - If you want a request or response for data to be processable at a >> time far removed from the other half of the interaction (you request data >> in June, and the data is emitted to you then, but you are vacationing >> offline; you come back in July but the website is down, yet you can open >> the response and process the data you asked for--how email works), you need >> DIDComm or something like it. >> - If you want to support more than 2 parties without centralizing in >> a web server (or replicated pool thereof) that all the other parties must >> use as a rendezvous point, you need DIDComm or something like it. >> >> There is no doubt in my mind that we could build secure data hubs using >> just HTTPS. I think the result would be a modest improvement on today's >> Google Drive/DropBox/iCloud. It would still depend on large institutions to >> broker access (because they're the ones with always-on web servers and high >> reputation from CAs)--and because of this, its observability would be high, >> and its privacy guarantees would be weaker than I'd like. Encryption on the >> wire and at rest doesn't change this. Because the security of such an >> approach wouldn't be strongly tied to DID control, I don't see it bringing >> about much change in the trust dynamic or the self-sovereignty outcome over >> today's status quo. It would only work online, not peer-to-peer in offline >> mode. But it would work just fine within its narrow mandate, and it would >> be relatively easy to build. >> >> I will cheerfully nod to people who head off down that path, but a spec >> that forces me there is DOA with respect to my roadmap. >> >> >> >> On Wed, Dec 11, 2019 at 4:48 PM Adrian Gropper <agropper@healthurl.com> >> wrote: >> >>> I might agree with Daniel on all counts. Specifically, if: "HTTPS trust >>> on one side is rooted in CAs. On the other, it's rooted in sessions that >>> follow from login. DIDComm trust is rooted in control of DIDs." then my >>> question becomes: >>> >>> Should the choice of HTTPS or DIDcomm be applied *separately* to each of >>> the four edges of the general storage use-case: >>> 1 - Alice to Storage Enterprise >>> 2 - Bob to Alice >>> 3 - Bob to Bob's Enterprise >>> 4 - Bob's Enterprise to Storage Enterprise >>> >>> If the overall storage protocol use-case applies either one or the other >>> secure messaging method for each edge, then HTTPS / DIDcomm are equivalent >>> from my perspective and we can move on to explaining what else is going on. >>> >>> Adrian >>> >>> On Wed, Dec 11, 2019 at 6:14 PM Daniel Hardman < >>> daniel.hardman@evernym.com> wrote: >>> >>>> You guys are commenting so fast that I can't respond individually, so >>>> here's an omnibus response... >>>> >>>> Orie: >>>> >>>> >1. Can DIDComm be used without an agent? I think the answer is yes. >>>> Can it be used without things that have a DID? sorta, since any key >>>> material can be used to construct a DID via did:peer, did:key, etc... >>>> >>>> >>>> Stephen: >>>> >>>> >DIDComm is a communications/messaging protocol and other than just >>>> calling the "message processing thingy" something other than "agent", it >>>> requires agents. >>>> >>>> >>>> Daniel: >>>> >>>> I want to split hairs between Orie and Stephen. :-) >>>> >>>> Agents use DIDComm--but that doesn't mean that *only* agents use >>>> DIDComm. The "fiduciary" quality that Adrian highlighted is a requirement >>>> for *agents*; its extension to *DIDComm* makes some philosophical >>>> sense but is not articulated anywhere that I consider official, and is not >>>> an assertion I advocate. In fact, there is a whole section of the >>>> Aries "agents" RFC that discusses the relevance of the paradigm to >>>> not-pure-agenty things that could speak DIDComm >>>> <https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents#the-agent-ness-continuum>. >>>> If you intend to communicate+encrypt or sign using keys that are rooted in >>>> DIDs, you need DIDComm--no matter whether the thingy that uses it is called >>>> an agent or not. DIDComm's just a standard[1] recipe for how to do that. >>>> >>>> >>>> Orie: >>>> >>>> >2. Can DIDComm be used with things like ZCaps? I think the answer is >>>> yes. Consider the case where 2 agents use DIDComm to agree to an >>>> authorization capability that when invoked grants access to some data >>>> stored in an encrypted data vault. >>>> >>>> >>>> Daniel: >>>> >>>> Yes. >>>> >>>> I note in passing, however, that I do not believe in ZCaps. I think >>>> they have some serious design flaws and that there is a better answer based >>>> on VCs-as-capabilities. I haven't said much about this (other than a >>>> session that touched on it in the last IIW) because the time/circumstances >>>> haven't been right, and I'm not hoping to argue it here. I just want to put >>>> a bookmark in the fact that object capabilities and zcaps are not >>>> necessarily foregone synonyms; can we discuss at some point in the future? >>>> >>>> >>>> Adrian: >>>> >>>> >If every entity (Alice, Bob, Bob's Enterprise, Storage Enterprise) >>>> that communicates securely has an agent regardless of what the entity is or >>>> what else it does, then isn't DIDcomm just a new alternative to HTTPS? >>>> >>>> >>>> Daniel: >>>> >>>> No. HTTPS trust on one side is rooted in CAs. On the other, it's rooted >>>> in sessions that follow from login. DIDComm trust is rooted in control of >>>> DIDs. To Adrian's related question about whether we can reduce the reliance >>>> on DIDComm, my response is: Yes. We can reduce the reliance on DIDComm >>>> exactly in the degree to which we reduce our reliance on DID-associated >>>> keys for security properties. And the amount of that reduction is >>>> something we can pick. >>>> >>>> >>>> So, how much reduction do we want to pick? >>>> >>>> Here is what Adrian proposed: >>>> >>>> >Bob will access the storage resource using a client that is different >>>> from the agent Bob used in the A2A / DIDcomm transaction because, in the >>>> typical case, Bob’s client is not a fiduciary of Bob and therefore does not >>>> fit the Aries definition of agent. >>>> >>>> It doesn't matter whether Bob's client for accessing storage fits the >>>> Aries definition of agent; it only matters whether Bob's client wants to >>>> use DIDs to authenticate and encrypt. If the capability Adrian wants will >>>> communicate in secure ways, *and root the security in DID keys*, then >>>> it should use DIDComm. If it wants to get its security without DIDs, then >>>> other answers (e.g., HTTPS) are perfectly reasonable. >>>> >>>> >>>> ----- >>>> [1] DIDComm today is only a de facto standard with a dozen or so >>>> implementations and a bunch of documentation. However, it is likely to turn >>>> into IETF RFCs (that is part of DIF's goal in sponsoring it, I believe). So >>>> "standard" should be read as a claim about a work in progress. >>>> >>>> On Wed, Dec 11, 2019 at 3:12 PM Stephen Curran < >>>> swcurran@cloudcompass.ca> wrote: >>>> >>>>> I find these answers odd: >>>>> >>>>> > 1. Can DIDComm be used without an agent? >>>>> > >>>>> > I think the answer is yes. Can it be used without things that have a >>>>> DID? sorta, since any key material can be used to construct a DID via >>>>> did:peer, did:key, etc... >>>>> >>>>> DIDComm is a communications/messaging protocol and other than just >>>>> calling the "message processing thingy" something other than "agent", it >>>>> requires agents. >>>>> >>>>> DIDComm is intended to use did:peer (which is a DID) so there is not a >>>>> "sorta" there. I would not call "did:key" a DID, as it is really just a >>>>> public key with a transformation to generate an opinionated DIDDoc (which >>>>> is a very helpful - it's just not a DID, or at least an extremely >>>>> constrained one). DIDComm will likely make use of the did:key method as a >>>>> replacement for the conveyance of naked public keys, but I don't think the >>>>> DIDComm protocol should ever be implemented based on did:key. As has been >>>>> stated before (but bears repeating) did:peer and did:key are two very >>>>> different mechanisms. >>>>> >>>>> DIDComm can use public DIDs and that will be done for certain use >>>>> cases (likely on the enterprise side), but will not be the default. That >>>>> will be did:peer. >>>>> >>>>> On Wed, Dec 11, 2019 at 1:56 PM Orie Steele <orie@transmute.industries> >>>>> wrote: >>>>> >>>>>> There are a couple questions in here: >>>>>> >>>>>> 1. Can DIDComm be used without an agent? >>>>>> >>>>>> I think the answer is yes. Can it be used without things that have a >>>>>> DID? sorta, since any key material can be used to construct a DID via >>>>>> did:peer, did:key, etc... >>>>>> >>>>>> 2. Can DIDComm be used with things like ZCaps? >>>>>> >>>>>> I think the answer is yes. Consider the case where 2 agents use >>>>>> DIDComm to agree to an authorization capability that when invoked grants >>>>>> access to some data stored in an encrypted data vault. >>>>>> >>>>>> OS >>>>>> >>>>>> ᐧ >>>>>> >>>>>> On Wed, Dec 11, 2019 at 3:05 PM Adrian Gropper < >>>>>> agropper@healthurl.com> wrote: >>>>>> >>>>>>> I just read the Aries Agents paper [1] and am trying to process it >>>>>>> in the Alice-to-Bob storage context that I work with. [2] >>>>>>> >>>>>>> Let’s say that the A2A interaction between Alice and Bob is DIDcomm >>>>>>> and, if successful, Bob gets a capability to access some storage resource >>>>>>> controlled by Alice (that is operated by a different entity than Alice’s >>>>>>> agent that issued the capability to Bob). >>>>>>> >>>>>>> Bob will access the storage resource using a client that is >>>>>>> different from the agent Bob used in the A2A / DIDcomm transaction because, >>>>>>> in the typical case, Bob’s client is not a fiduciary of Bob and therefore >>>>>>> does not fit the Aries definition of agent. >>>>>>> >>>>>>> The protocol that transfers the capability from Bob’s agent to Bob’s >>>>>>> client could be an A2A / DIDcomm transaction. Separately, the protocol that >>>>>>> presents the capability to the storage resource could also be an A2A / >>>>>>> DIDcomm transaction. >>>>>>> >>>>>>> Finally, the storage resource then has to verify the capability as >>>>>>> being signed by Alice’s agent. If Alice has a DID, then that's probably >>>>>>> obvious and DIDcomm would not be involved. >>>>>>> >>>>>>> The implication of building around the Aries agent definition is >>>>>>> that the agents of all four parties (Alice, Bob, Bob's Employer, Storage) >>>>>>> would need to deploy DIDcomm. >>>>>>> >>>>>>> Would this become an adoption problem for SSI? How can we reduce it? >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents/README.md >>>>>>> [2] >>>>>>> https://docs.google.com/document/d/1FBfs4shirUAtqD_d_t6F6oi2NZ0Y7400MDoYSm14Yco/edit >>>>>>> >>>>>>> On Wed, Dec 11, 2019 at 7:18 AM Oliver Terbu < >>>>>>> oliver.terbu@consensys.net> wrote: >>>>>>> >>>>>>>> IMO, a DID user agent is not a well-defined term. The community >>>>>>>> distinguishes between different types of agents. These agents are either >>>>>>>> controlled by an entity, or act on behalf of the entity, run in different >>>>>>>> locations and have certain capabilities, e.g., routing messages between >>>>>>>> entities, answering to credentials presentation requests on behalf of >>>>>>>> entities. I assume you are referring to an agent that runs on a mobile >>>>>>>> phone or in the browser (e.g., plugin/extension) that is controlled by an >>>>>>>> entity. >>>>>>>> >>>>>>>> In general, there are a lot of companies working in this area and >>>>>>>> they have their own agent implementations. The community has agreed so far >>>>>>>> on the W3C Verifiable Credentials Data Model (W3C REC) and on the W3C CCG >>>>>>>> DID Spec (Community Draft) so far. The DID spec is now being formalized in >>>>>>>> a dedicated W3C DID WG. HL Aries/DIF is working on protocols that allows >>>>>>>> them to interoperate on the messaging level. The following is a >>>>>>>> non-exhaustive list of public edge agents available on Android/ iOS: >>>>>>>> - uPort -> https://www.uport.me/ >>>>>>>> - Evernym/ connect.me -> https://www.evernym.com/products/ >>>>>>>> - Jolocom -> https://jolocom.io/ >>>>>>>> - Civic -> https://www.civic.com/ >>>>>>>> - ... >>>>>>>> >>>>>>>> Oliver >>>>>>>> >>>>>>>> On Tue, Dec 10, 2019 at 5:05 PM Daniel Hardman < >>>>>>>> daniel.hardman@evernym.com> wrote: >>>>>>>> >>>>>>>>> If this topic is of interest to you, you may want to read this doc >>>>>>>>> <https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents/README.md>, >>>>>>>>> and look at the list of implementations at the bottom >>>>>>>>> <https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents#implementations>. >>>>>>>>> This is NOT an exhaustive list of agent technologies; others on the the >>>>>>>>> list should chime in with other things, too. >>>>>>>>> >>>>>>>>> On Tue, Dec 10, 2019 at 2:49 AM Kenneth Anshewitz < >>>>>>>>> kja10@my.fsu.edu> wrote: >>>>>>>>> >>>>>>>>>> Hey guys, >>>>>>>>>> >>>>>>>>>> I'm trying to learn about DIDs and came across your org. I'm >>>>>>>>>> interested to know of any emerging DID User agents out there besides >>>>>>>>>> potentially Microsoft and BCDiploma. Would Civic be considered a DID user >>>>>>>>>> agent? >>>>>>>>>> >>>>>>>>>> Kenny >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>>> > > -- > > 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/ >
Received on Thursday, 12 December 2019 04:11:58 UTC