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

I just wanted to +1 the diagram. Good stuff.

On Fri, Dec 13, 2019 at 9:51 AM Adrian Gropper <agropper@healthurl.com>
wrote:

> Friends and Superfriends,
>
> It seems obvious that protocol work will continue in parallel in W3C,
> IETF, and DIF. I offer the linked document with this diagram as a help in
> coordinating these efforts.
> https://docs.google.com/document/d/1FBfs4shirUAtqD_d_t6F6oi2NZ0Y7400MDoYSm14Yco/edit
>
> I've chosen my words below somewhat carefully, using the Aries definition
> of agent and DIDcomm as well as the generalized idea of authentication and
> delegation that ties this stuff together. That said, *please* improve my
> terminology and the few examples that I give. The doc and diagram are open
> for editing.
>
> [image: Screen Shot 2019-12-13 at 11.43.23 AM.png]
>
> -- Adrian
>
>
> On Fri, Dec 13, 2019 at 7:14 AM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> Here's where things seem to stand in my "contemplation":
>>
>>    - Steve's question about what's being authorized by Alice is
>>    extremely complex (makes our W3C VC standards deliberations look like
>>    childs' play.) The IETF OAuth and Kantara UMA folks have been tinkering
>>    with the myriad of use-cases for a decade. The rate of discussion has risen
>>    recently as IETF considers improvements to OAuth. Start by reading
>>    https://medium.com/oauth-2/rich-oauth-2-0-authorization-requests-87870e263ecb
>>    - AuthN only is a way to cut through the above (what I would call the
>>    scope problem) but it doesn't really solve the problem of delegation even
>>    in the Alice-to-Aliice case because Alice almost never wants to give full
>>    access to cross-copy her assets between one service provider and another.
>>    Would you ever share access to your Facebook account with your Google Docs
>>    account?
>>    - I am going to try and advance the discussion by adopting the Aries
>>    definition of "agent"
>>    https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0004-agents/README.md
>>    It basically makes all four entities in the Alice-to-Bob use case agents
>>    and links to the DIDcomm conversation in a way that reflects our community
>>    discussion, including this thread.
>>    - I will add this thread to the Alice-to-Bob use case document
>>    https://docs.google.com/document/d/1FBfs4shirUAtqD_d_t6F6oi2NZ0Y7400MDoYSm14Yco/edit
>>    because that has been read by a lot of people and seems to be worth keeping
>>    for a while.
>>    - The relationship of capabilities (as in ZCAP-LD) to VCs in the
>>    discussion of scope of authorization and method of delegation remains open.
>>    That maybe should be a separate email thread a bit later on.
>>    - Some have said the Alice-to-Bob use case is 14 separate use-cases.
>>    It depends. If our goal is to structure the protocol stack for adoption
>>    then the actual number hardly matters.
>>    - I will update the Alice-to-Bob use case with a diagram and link it
>>    into this thread so we might try to continue working toward a common
>>    terminology as we discuss the stack.
>>
>> Adrian
>>
>>
>> On Thu, Dec 12, 2019 at 4:59 PM <steve.e.magennis@gmail.com> wrote:
>>
>>> … jumping on this great thread a little late…
>>>
>>>
>>>
>>> @Adrian, as a way to help bootstrap DID* adoption your thought
>>> experiment sounds really intriguing.
>>>
>>>
>>>
>>> Question. Your initial use case states:
>>>
>>> “*…**if successful, Bob gets a capability to access some storage
>>> resource controlled by Alice*.”
>>>
>>> Here are you contemplating:
>>>
>>>    - AuthN only (i.e. all or nothing access to said storage resource)
>>>    - Combining the DIDComm with a VC or access token that defines
>>>    Alice’s intent w/r/t the conditions she wishes to impose on Bob’s access to
>>>    the storage resource?
>>>    - Alice carving out access / usage conditions directly with the
>>>    resource service, but out of band w/r/t the A2A interaction between Alice
>>>    and Bob? (i.e. the resource service manages the AuthZ terms)
>>>    - Something else?
>>>
>>>
>>>
>>> -S
>>>
>>>
>>>
>>> *From:* Daniel Hardman <daniel.hardman@evernym.com>
>>> *Sent:* Wednesday, December 11, 2019 8:12 PM
>>> *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>
>>> *Subject:* 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/
>>>
>>>
>>
>> --
>>
>> 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/
>>
>
>
> --
>
> 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/
>