- From: Adrian Gropper <agropper@healthurl.com>
- Date: Wed, 11 Dec 2019 18:09:02 -0500
- 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>
- Message-ID: <CANYRo8hjnsyYUgG2Yn725X2KBsu2e720ek+Ooo0MQCdFZLm3RA@mail.gmail.com>
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