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

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
>>>>>>
>>>>>
>>
>> --
>> *ORIE STEELE*
>> Chief Technical Officer
>> www.transmute.industries
>>
>> <https://www.transmute.industries>
>>
>
>
> --
>
> Stephen Curran
> Principal, Cloud Compass Computing, Inc. (C3I)
> Technical Governance Board Member - Sovrin Foundation (sovrin.org)
>
> *Schedule a Meeting: **https://calendly.com/swcurran
> <https://calendly.com/swcurran>*
>