W3C home > Mailing lists > Public > public-did-wg@w3.org > August 2020

RE: DID WG Special Topic Call (Service Endpoints)

From: Daniel Buchner <Daniel.Buchner@microsoft.com>
Date: Fri, 28 Aug 2020 19:11:45 +0000
To: Manu Sporny <msporny@digitalbazaar.com>, "public-did-wg@w3.org" <public-did-wg@w3.org>
Message-ID: <CH2PR00MB0811B8AA40704310981D262281521@CH2PR00MB0811.namprd00.prod.outlook.com>
Yep, we just started work a couple weeks ago on moving Linked Domains service endpoints and the integration of Well Known DID Configuration files into production code.

-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com> 
Sent: Friday, August 28, 2020 11:50 AM
To: public-did-wg@w3.org
Subject: Re: DID WG Special Topic Call (Service Endpoints)

On 8/28/20 4:00 AM, Deventer, M.O. (Oskar) van wrote:
> 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.

Are there DID Methods that use service endpoints today in their implementations? Are these in production?

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

In this case, we haven't really discussed service endpoints in this group in detail. It could still come out of the specification... btw (Orie), this is an example of why I really don't like merging things before there is broad consensus.

There was never consensus in this WG to have service endpoints; folks felt it was useful so we put it in there in the CG because we wanted people to experiment... but the argument now is "Oh, well, it's in the spec, so we need consensus to remove it, right?!" -- so the burden of proof is really on people to prove that we actually need service endpoints in DID Documents.

I'm certainly not going to stand in the way on this particular item, even though I think it's probably an anti-pattern. It'll just get everyone fired up and drawing lines again right before CR, which we want to avoid as a group.

What I would like the group to do, instead, is understand the alternative options... and I'm positive that there are folks in the group that do not understand all of the alternative options for communicating service endpoints. I'd like us to take the opportunity to educate the group rather than just assuming that service endpoints are a foregone conclusion.

-- manu

--
Manu Sporny - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&amp;data=02%7C01%7Cdaniel.buchner%40microsoft.com%7Cfa25eed5401d4fb8223108d84b834b61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637342374576597828&amp;sdata=MxW1J2H6V2nhJWWmNjOVDFHDW49DYWoOMxxzjtgw%2B%2FY%3D&amp;reserved=0
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&amp;data=02%7C01%7Cdaniel.buchner%40microsoft.com%7Cfa25eed5401d4fb8223108d84b834b61%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637342374576597828&amp;sdata=6N%2FZy7A4oup%2Byj3Y1NVoqkh53riW8NXllvFufGi9lMQ%3D&amp;reserved=0

Received on Friday, 28 August 2020 19:12:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 28 August 2020 19:12:02 UTC