Re: DID WG Special Topic Call (Service Endpoints)

On Fri, Aug 28, 2020 at 12:50 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> 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?
>

Yes. Daniel B has noted Microsoft's investment in them. Your own Veres One
ledger has had service endpoint validation logic since at least late last
year (
https://github.com/veres-one/veres-one-validator/pull/30/files#diff-9f2be51e5e4e2dd1bb6455eef32e4472R115).
The entire Aries and Indy ecosystems also uses service endpoints. The first
production deployment from this ecosystem was of the VON Network in late
2018, IIRC. Evernym has multiple production deployments, and I believe
Trinsic, SecureKey, Kiva, and others may as well. Privacy-preserving,
GDPR-compliant service endpoints are a major design feature of DIDComm and
have been since DIDComm was invented almost three years ago. They largely
avoid the concerns you are raising.

Peer DIDs have supported service endpoints for about 16 months.

> 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 think this may not be a reasonable interpretation of history, Manu,
though I defer to you about the content of specific WG conversations.
Service endpoints have been in the DID spec since forever, including in the
draft of the spec that we used to justify taking the WG effort to the next
level at W3C. I had to deal with service endpoints when I reviewed Mike
Lodder's draft of the did:sov method, the week after we formalized DID
methods at RWOT. Markus built them into universal resolver tech, which
allowed Microsoft to do some cool demos when DIF was launched. The fact
that elsewhere you cited 70+ DID methods that might be using them is not
consistent with a claim that consensus wasn't ever a thing. If consensus
means a clear weight of opinion and expectation, then it has long existed.

If, on the other hand, you want to assert that there has long been dissent,
I think that is a fair point, since consensus != universal agreement. When
you and I did a compare and contrast of did:key and did:peer a year ago, I
remember touching briefly on why did:key's lack of service endpoint support
didn't bother you. You noted then that you were comfortable with that
feature gap, but you didn't propose to take out the feature from the spec.
Nor did you express any of the concerns you are now raising. Why not?

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.
>

See my comments in your ticket (
https://github.com/w3c/did-core/issues/382#issuecomment-683070513) for an
explanation of why I disagree with the antipattern assertion.


> 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.


Your first sample of 2 alternate mechanisms did not yield any "Aha!"
moments for me. Would you be willing to preview the additional education
you'd like to give?