W3C home > Mailing lists > Public > public-credentials@w3.org > December 2019

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

From: Adrian Gropper <agropper@healthurl.com>
Date: Wed, 11 Dec 2019 18:09:02 -0500
Message-ID: <CANYRo8hjnsyYUgG2Yn725X2KBsu2e720ek+Ooo0MQCdFZLm3RA@mail.gmail.com>
To: Stephen Curran <swcurran@cloudcompass.ca>
Cc: Orie Steele <orie@transmute.industries>, Daniel Hardman <daniel.hardman@evernym.com>, Oliver Terbu <oliver.terbu@consensys.net>, W3C Credentials Community Group <public-credentials@w3.org>
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?

-Adrian

On Wed, Dec 11, 2019 at 5: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
>>>>>>
>>>>>
>>
Received on Wednesday, 11 December 2019 23:09:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:19:06 UTC