Re: DID WG Special Topic Call (Service Endpoints)

I'm mostly content to move the discussion over to the ticket. However, you
didn't answer my question about what additional education you're proposing
to offer. Will that come through the ticket as well?

I'd like to note that we seem to have a fundamental disagreement about what
constitutes an alternative. Is the goal to communicate an endpoint somehow
(Manu's perspective), or is it to communicate an endpoint such that its
value is versioned with the keys used by that endpoint, and the
communication is known to emanate from the DID controller? If the latter
(which I assert), then I have not yet heard *any* viable alternatives.
That's why I was asking for a preview of the learning you want to offer us.
I don't feel like I need learning about general communication strategies
(they are innumerable); however, I'm *very* interested in communication
strategies that accomplish the more ambitious goal for which I've been
using service endpoints in DID docs. (We can pick up the question of the
goal in the ticket; I made a similar comment at
https://github.com/w3c/did-core/issues/382#issuecomment-683325479).

On Sat, Aug 29, 2020 at 10:42 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 8/28/20 3:38 PM, Daniel Hardman wrote:
> > 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.
>
> Let's move this thread to:
>
> https://github.com/w3c/did-core/issues/382
>
> You're making good points that I'd like to respond to... let's take the
> conversation to the issue tracker.
>
> The rest of my response has more to do with the "why now", and that
> doesn't belong on the issue tracker.
>
> > 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.
>
> Yes, that's what I'm asserting. I'm suggesting that the dissent is
> growing based on how the ecosystem has developed over the past year or
> so and we may want to reconsider before we set this feature in stone. We
> may be able to simplify while supporting everyone's use cases.
>
> > 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?
>
> For at least these reasons:
>
> * I didn't feel as strongly about it back then as I do today...
>   there wasn't as much clarity around alternatives then as
>   there is today. There is new data that is causing me to
>   reconsider not having a strong opinion on the topic.
>
> * I don't find it useful to nitpick every last thing about a
>   solution that I find concerning, especially when attempting
>   to build bridges. There is a certain point I'll stop
>   raising concerns because I can live with a potential
>   solution, even if I disagree with the value or the
>   potential danger posed by the solution. This comes from an
>   assumption that I might be wrong and a diverse ecosystem,
>   as long as there isn't a time bomb in the ecosystem, is a
>   healthy thing.
>
> * I can only argue with folks so much. I don't actually enjoy
>   doing it... it's draining. So, there is pain to gain ratio
>   that needs to be hit for me to engage... which is true for
>   most folks in this group, I imagine.
>
> To be clear, I'm not arguing against Service Endpoints... they're great,
> we should have them! I'm arguing against Service Endpoints *in DID
> Documents*... and am suggesting that it's an anti-pattern. I'm happy to
> lose that argument as long as we came to consensus as a group knowing
> what the alternatives are.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>