RE: DID WG Special Topic Call (Service Endpoints)

  *   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.
That is just introducing another level of indirection. Also, it feels wrong to try and abolish an existing and working solution without providing an equally-well-worked-out alternative.

The procedural perspective is that if there is no consensus to change something (e.g. deprecate service endpoints), then the spec remains unchanged, correct?

Oskar

From: Adrian Gropper <agropper@healthurl.com>
Sent: 27 August 2020 22:14
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>
Subject: Re: DID WG Special Topic Call (Service Endpoints)

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<mailto: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>
> <mailto: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.
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.