- From: Adrian Gropper <agropper@healthurl.com>
- Date: Thu, 27 Aug 2020 16:13:33 -0400
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: Daniel Hardman <daniel.hardman@evernym.com>, Manu Sporny <msporny@digitalbazaar.com>, W3C DID Working Group <public-did-wg@w3.org>
- Message-ID: <CANYRo8im+CC+fBKobjnSsE6nu1ZGnA0GqsdvrMN_LBMLb-6s5g@mail.gmail.com>
Of the three service endpoint types that I consider a priority (mediator, notification, authorization), it seems we have interest in working on notification first. The mediator type is just designed to provide herd immunity for the other types so might consider notification first. I see Notification as an adjunct to an authorization service endpoint for handling "first contact" between the data subject and a requesting party and also for dealing with warning or exceptions in the authorization flow. - Adrian On Thu, Aug 27, 2020 at 3:54 PM Dave Longley <dlongley@digitalbazaar.com> wrote: > > On 8/27/20 3:26 PM, Daniel Hardman wrote: > > This answer assumes that learning of B's existence and learning how to > > talk to B are the same thing. They may coincide sometimes, but there is > > no guarantee that they always will. We know they do not, sometimes. > > Similarly, there could be registries of information about B that do not > need to be DID method specific registries. > > What we do know is that B on its own is meaningless. There must be other > information associated with B to give it meaning. It is this other > information that A seeks and often (should always?) requires as a > prerequisite to establish a useful relationship with B. > > > This answer also assumes that the channel over which you engage with B > > is duplex, such that the channel to reply is the channel to receive. > > Again, another assumption that's not always true. > > The answer doesn't make this second assumption. The endpoint for talking > with B, for example, could be put in a registry along with the other > information about B for which A might search. Such a registry need not > be associated with a particular DID method and could be contextualized > in some important way for its human and software users. And, of course, > it need not be a duplex. > > > > > On Thu, Aug 27, 2020 at 1:13 PM Dave Longley <dlongley@digitalbazaar.com > > <mailto:dlongley@digitalbazaar.com>> wrote: > > > > > > On 8/27/20 12:08 PM, Daniel Hardman wrote: > > > Yes, agreed, I expect this will be the most undesirable option > > to most. > > > The counter-point is that everyone *is* doing some form of DID > > Auth now, > > > and even if it's not officially standardized, we are able to > > get VCs > > > from point A to point B today. > > > > > > > > > How do you get VCs from A to B if you don't know how to contact B? > > > > This is a good question and, if we go even further back, we might > find > > an answer: > > > > How do you even know B to begin with? > > > > One option for getting VCs from A to B is to reuse the same channel > from > > which you learned B in the first place. > > > > > -- > Dave Longley > CTO > Digital Bazaar, Inc. > >
Received on Thursday, 27 August 2020 20:13:57 UTC