Re: Implication of building storage around DIDcomm [Was:] DID USER AGENTS

+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/
>