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

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