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

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/