DID WG Topic Call on Service Endpoints — Minutes

Date: 2020-09-24

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Amy Guy, Brent Zundel, Manu Sporny, Daniel Burnett, Dave Longley, Kaliya Young, Jonathan Holt, Adrian Gropper, Dmitri Zagidulin, Daniel Hardman, Joe Andrieu, Orie Steele

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Amy Guy

Content:

all: profound and thoughtful silence

Brent Zundel: to begin, I’m going to make some official chair statements

Brent Zundel: The DID Core spec currently includes a services property.

Brent Zundel: No proposal advocating removal of service endpoints from the specification has become a resolution.

Brent Zundel: Resolutions were made to strengthen the language describing service endpoints:

Brent Zundel: Discuss in a non-normative appendix how one might model Service Endpoints that preserve privacy.

Brent Zundel: Define an abstract data model for serviceEndpoints in normative text, like we have done with verification methods.

Brent Zundel: Define how you do service endpoint extensions using the DID Spec Registry.

Ivan Herman: See minutes for the discussion on those resolutions

Brent Zundel: We are waiting for PRs which act on those resolutions.

Brent Zundel: Group consensus rules spec text changes, not property inclusion. So if there is no consensus around changing the spec text to remove service endpoints, they will not be removed.

Brent Zundel: Inclusion of normative statements and spec features becomes an issue if two or more implementors cannot be found who support each feature. As we transition the spec to CR, if no two independent implementations support service endpoints as a feature, they would need to be removed.

Brent Zundel: If there is a group member who feels strongly enough about service endpoints not being removed that they are considering making a formal objection to the specification, please reach out to the chairs directly.

Brent Zundel: not anticipating a conversation about this statement from the chairs, but q is open

Manu Sporny: https://github.com/w3c/did-core/issues/382

Manu Sporny: we are here to discuss issue 382
… which has a very long set of comments now, 127..
… the initial issue was “service endpoints in the did document might be an anti pattern”
… a lot of healthy debate, numerous points made, not going to try to summarize
… I’d like to try and focus on concrete proposals today
… a couple of things we probably need to do - reaffirm our commitment to the service property
… to address some of what brent just said
… and then talk a bit about some of the language we’d like to put into privacy considerations
… and then talk about some of the alternatives that were put forward
… not trying to summarize everything, just highlights..
… throughout the thread there are times it is reasonable to use service endpoints and other times it is dangerous to do so
… one perfectly reasonable place to put a a service endpoint is in a peer did document as you are exchanging information in a peerwise fashion
… that’s an example of it being perfectly reasonable
… another is putting service descriptions in a public organization’s did doc where you know it’s public
… the other part where service descriptions become a bit dangerous is when the contain personally identifiable information and are placed onto a verifiable data registry for an individual
… clear gdpr concerns.. i’m saying concerns, not that it’s right or wrong to do but people have asserted that doing that is probably inadvisable
… there’s this set of discussions around what kind of guidance we should put around that
… there have been some alternate proposals on how you would transmit service descriptions if not in the DID doc
… I’m suggesting we save that to the end of the call, it’s going to be difficult to come to consensus on that
… I’m going to start with a level setting proposal
… The theory here is everyone should +1 this because it should be consensus, what we already believe

Joe Andrieu: you anchored on some things you thought there was consensus around
… there was a framing around peer dids are suitable.. I guess that’s because you felt it was a private communication anyway
… however they’re already in communication so no need to put it in the did document
… the framing I’d suggest is what needs to be in the did doc to support the fundamental features of dids
… if you’re already exchanging information through did peer I don’t think you need to jam anything else in the DID doc

Adrian Gropper: I hope this is a quick question, I asked in the issue.. can somebody give me a brief example of what an abstract data model would entail for service endpoints if there was one?

Manu Sporny: I don’t think that’s an easy quick thing

Daniel Hardman: I wanted to nuance what Joe just said.. I partly agree
… one of the comments I wrote last night in this thread is that I think there’s an assumption about interactivity that I don’t share
… because you are talking one direction doesn’t mean the other party can talk back
… because of that you can’t assume you have a different way to communicate
… you can’t assume you can’t communicate a piece of information in the opposite direction just because an endpoint is open

Manu Sporny: the first proposal is a level setting exercise.. I’m guessing we all agree to this
… just putting the language out there for now ^
… there are cases where you didn’t want to use it but it can be useful in certain cases
… would anyone like to wordsmith that before we put it to the group? anyone object?

Joe Andrieu: Yes. I think can be useful is not a good litmus. There are lots of things that ‘can be useful’

Manu Sporny: the alternate proposal is that service is never useful

Joe Andrieu: that’s a forced and false dichotomy
… it’s not that they’re never useful, just that some people want them and some people have problems with that

Manu Sporny: how would you change the proposal?

Joe Andrieu: One ay I could support is making it singular. Something along the lines of the value of providing a service endpoint in a DID document is worth the security and privacy risks
… this is about tradeoffs, not if it’s useful. What are the tradeoffs?
… the back and forth about when do you know it’s signed.. some of the different mental models are problematic based on what we need to do with DIDs

Adrian Gropper: this i why the last comment I made n the thread might be useful.. namely allowing at least one service endpoint in the DID doc enhances the control by the did subject.

Joe Andrieu: I like that statement

Manu Sporny: could you write that out as a proposal?

Proposed resolution: The ability for a controller to optionally state at least one service endpoint in the DID Document increases their control and agency (Joe Andrieu)

Manu Sporny: what do we change in the spec based on that? Seems like an assertion of fact

Brent Zundel: as was the level setting one

Joe Andrieu: this is level setting. there was a legitimate argument to not use them at all, but in going back and forth I’ve been convinced there is a reason to have at least one

Adrian Gropper: +1

Brent Zundel: i’d like the group to respond to this proposal

Daniel Hardman: +1

Manu Sporny: -0.5

Brent Zundel: +1

Joe Andrieu: +1

Dave Longley: -0 this is just a fact, it does not mean we should do it

Kaliya Young: +1

Ivan Herman: 0

Jonathan Holt: +1

Brent Zundel: manu more you’d like to say?

Manu Sporny: I think it’s arguable, don’t think we should dwell on it though
… this does establish.. it increases their control and agency but says nothing about the same information expressed through other paths, bu I think we’ll get there

Joe Andrieu: I’m hearing manu is still of the opinion no service endpoints should be under consideration

Manu Sporny: it increases control and agency… there may be better ways to do that without the downsides of the privacy cost you pay for ding that through the DID doc

Adrian Gropper: +

Manu Sporny: this says you have to do one
… it doesn’t say you have the choice to do zero

Joe Andrieu: it is optional. that was important in my framing

Adrian Gropper: to answer manu’s point, that’s why I asked if we could have some idea of what an abstract data model for this one service endpoint might look like
… because it would tend to focus our attention on manu’s claim that there are other ways to do this
… non-normative ways to do this

Manu Sporny: I think we should resolve and go on. Let’s not snatch defeat from the jaws of victory. If we can get a resolution on this..

Resolution #1: The ability for a controller to optionally state at least one service endpoint in the DID Document increases their control and agency

Manu Sporny: the reason I’m struggling with adrian’s question is until we have more resolutions it’s really difficult to know what an abstract data model would look like
… it can change depending on some of the resolutions we may make on the call today
… putting something forward will throw us into arguing about it instead of understanding what the requirements and constraints are
… once we understand the requirements and constraints are it’s much easier to say what the abstract data model wold look like

Adrian Gropper: I can wait

Jonathan Holt: I think also before we constrain it would be helpful to understand the purpose
… a segue into the abstract data model, what is it, what type of thing is it, what is it used for, then we can determine what the data model is and constrain it
… I understand the value of a minimally viable service endpoint in a did doc
… I think if we can talk about it in the abstract, what is it’s purpose, that wil help

Manu Sporny: The next one I’m putting forward, something daniel buchner asked for
… this isn’t specific on exactly what those are, we’ll get to it
… but he said he thinks we need to have some concrete examples to show people what we’re talking about

Brent Zundel: q for specific changes to this proposal before we put it to the group

Proposed resolution: Add concrete examples to the Privacy Considerations section to demonstrate how service endpoints might account for varying levels of privacy requirements. (Manu Sporny)

Manu Sporny: +1

Daniel Hardman: +1

Ivan Herman: +1

Brent Zundel: +1

Adrian Gropper: +1

Dave Longley: +1

Joe Andrieu: +1

Dmitri Zagidulin: +1

Jonathan Holt: I would like to explore the question “why service endpoints?” and “what type of thing it is” before we get to examples.

Jonathan Holt: 0

Resolution #2: Add concrete examples to the Privacy Considerations section to demonstrate how service endpoints might account for varying levels of privacy requirements.

Daniel Hardman: I wanted to clarify in this proposal.. the thing we’re providing examples of considerations, not service endpoints? is that accurate?

Manu Sporny: it was purposefully vague… hopefully we get to that this call
… I expect the language we would write is here is an example of how yo might create a service endpoint, not a concrete one, given these requirements this is what you might do
… or here is a clear example of what you don’t want to do
… eg one for an individual with PII about to be written to a VDR on a DLT, here’s what not to do
… the hope is we can take the concerns of everyone in the group and go through each one and show some concrete thing in the privacy considerations section

Adrian Gropper: I want to suggest jonathan was the only 0 on this resolution that as I put in the issue, spam filtering might be the first example
… that we consider as part of the abstract data model that we might discuss

Manu Sporny: this has to do with items that daniel hardman and dave longley and others brought up
… it’s fine to use service endpoint if you’re a public entity
… the proposal is to speak directly to each one of those things
… there have been people talking about how service descriptions may be helpful for public entities but dangerous for private entities
… this proposal is to enumerate some of these things
… to more fully explore what the group views as safe usages and potentially concerning usages

Adrian Gropper: a brief comment.. I’ve experienced a problem that this might contribute to which is that in general we might not want to fragment the universe of DIDs into private ones and others
… if we encourage in this way.. I’m not saying I’d object.. this fragmentation fo the DID space into public and private, is that really helpful to what we’re trying to achieve overall?

Daniel Hardman: would it be okay if share m y screen?
… I’m feeling uncomfortable with manu’s language because there’s quotes around it
… it perpetuates a distinction that needs subtle nuancing
… public vs private is not the same as.. there’s a visibility dimension and then there is a broader usage dimension which is how many people know it
… by saying there’s a public entity I think we’re encouraging a simplistic view of things
… even businesses that operate in the public like amazon have private conversations with certain people
… I’m not really opposed to the spirit but I’d be more comfortable if we took out the quotes around it and worked on describing in a more nuanced way
… this grid shows that you could have a DID intended to be pairwise but someone ends up publishing
… it’s publicly known but still was intended for a narrow context
… you could have something not intended fo ra public context but still known to many people, like it’s in a company directory
… not public in the sense the world knows it but does have multiple contexts
… I hope you got the drift

Joe Andrieu: echo the sentiments of adrian and daniel… public and private is a false dichotomy
… things you do and can’t do in a public restroom that is private behaviour

Manu Sporny: what can we do to change this

Joe Andrieu: the distinction that came up for me was the desire to publish vs a desire to maintain secrecy

Manu Sporny: publicly published or..?

Daniel Hardman: if we take the quotes off then the proposal is about the general concepts and we can fiddle with the language later
… I would vote as long as the quotes are off

Joe Andrieu: I would still want changes.. public vs private is not a testable feature

Daniel Hardman: what if we acknowledge a spectrum of privacy considerations and publication strategy and where you sit on this spectrum may influence

Joe Andrieu: that’s great

Brent Zundel: I love the conversation, please q before you comment

Joe Andrieu: +1 to queueing

Adrian Gropper: a comment on wordsmithing.. I think it will directly impact the PING analysis, what we do here

Brent Zundel: +1 to agropper’s comment

Manu Sporny: what do you think about the new one?

Joe Andrieu: for readability just commas, but otherwise thumbs up

Manu Sporny: this does not point out specific things that were brought up in the conversation but may be that’s okay and we can put specifics in a PR

Daniel Hardman: maybe add examples of points on privacy spectrum?

Daniel Hardman: but I’ll vote for it

Brent Zundel: I think daniels suggestion would best be reflected in a PR

Daniel Hardman: I agree with brent

Proposed resolution: Add privacy guidance that establishes that there is a privacy spectrum and publication strategies along that privacy spectrum of how service endpoints might be published. (Manu Sporny)

Manu Sporny: +1

Dave Longley: +1

Daniel Hardman: +1

Adrian Gropper: +1

Joe Andrieu: +1

Brent Zundel: +1

Ivan Herman: +1

Kaliya Young: +1

Dmitri Zagidulin: +1

Resolution #3: Add privacy guidance that establishes that there is a privacy spectrum and publication strategies along that privacy spectrum of how service endpoints might be published.

Dave Longley: more specifically about some of the points I’ve been trying to make on the issues
… It’s too challenging for VDR implementers to technically distinguish between what we’re calling ‘public’ ‘private’ ‘personal’ information
… expect it will be very harmful to ecosystems to do anything other that recommend that services not be in DID docs that are published to VDRS
… it will have a centralizing effect on service providers. I don’t want to recreate something with an allowed list for service providers like federated logins today

Brent Zundel: Verifiable Data Registry

Dave Longley: I think we should put off expressing this sort of information to decentralized mutable directories that can either support multiple DID methods or be DID methods agnostic
… Since it is my position that it is harmful to express service endpoints on Verifiable Data Registries it is also a danger that if we allow service endpoints on other implementations the advice for Verifiable Data Registries may not be followed

Joe Andrieu: +1 to supporting innovation at a DID-Method-agnostic directory level

Dave Longley: people can still use the vocabulary and data model in other ways. Our advice should be it is best to put this information somewhere else

Manu Sporny: that is the next part of the discussion

Jonathan Holt: +1 to paraphrase one of my favorite quotes that seems relevant: “When you are young it seems easy to distinguish between ‘right and wrong’ and ‘public vs private’, but as one gets older it becomes more difficult. The heroes and the villains get all mixed up.”

Manu Sporny: one of the other things raise din this thread was whether or not it was a good idea in general to put services in DID documents
… you could argue that it’s never a good idea to do that for DID docs that are going onto a DLT type thing
… from a technical perspective it’s difficult to determine for a VDR where on the privacy spectrum the person requesting storage on the VDR is
… note that tihs doesn’t mean you can’t do it anyway, but has to do with the guidance the group is attempting to give in general

Daniel Hardman: I’d like to note that implicit in dave’s concern is an assumption that a VDR is immutable
… I don’t think that’s a required characteristic, it’s a common one if we’re talking about DLTs, but it’s not just peer DID documents that could get around gdpr problems, it’s any data registry that doesn’t have blockchain type characteristics

Dave Longley: that is true what daniel said. the other part of my comment is being too nuanced in our guidance
… where we’re saying if your’e using a VDR and it’s immutable, do x, y, and z, otherwise do this other thing
… that is going to be lost on most implementers
… people will end up putting things in places where they’re going to be harmful to the ecosystem and to privacy so our advice should be more broad
… we could mention you could get away with x, y, and z but this guidance is too nuanced so we recommend don’t do it this way

Daniel Hardman: practical consideration here for me is that i’ve recognised for 4 years the privacy issues that are being raised and have wrestled with them. i get it, they’re hard, I don’t want to diminish these concerns
… after investing millions of dollars and many person years of effort we have a solution for them
… by putting advice in a spec that says it’s a bad idea without acknowledging that there are ways to solve it well it’s against a whole ecosystem that has already solved the problem

Dave Longley: to be clear, i am not against people putting “service” in a DID peer DID document, so perhaps “see the specific DID method for solutions to this problem”

Manu Sporny: could you be more specific? if we put in the immutable in front of verifiable data registries would that address your concern?

Daniel Hardman: no because indy ledgers are immutable but have a solution

Dave Longley: perhaps we could say something like see particular DID method advice for specific solutions to this problem
… so we can differentiate the general advice given but allow space for DID method creators to say we’ve got a special solution to this problem that we think works, look at our DID method spec for it

Daniel Hardman: i won’t vote for any proposal that says we advise you not to build an ecosystem like the indy one

Jonathan Holt: I’d be in favour of the wording dave just suggested

Orie Steele: +1 to noting that DID Method specs may have better guidance on the user of services

Adrian Gropper: Separation of Concerns is a good thing

Jonathan Holt: a pragmatic approach to add privacy guidance that discourage services from expressing identifying information, but i’d leave off the part about VCs
… that points to the issue that is putting identifying sensitive information in the DID doc
… there are ways of doing it through method specific use cases or service endpoints that are privacy preserving
… I think we are spending too much time on the nuances of this

Manu Sporny: I don’t expect this to pass, I’m trying to address what jonathan just raised and the other thing that dave said how we can modify this.. doesn’t go far enough for daniel, understood, but simplifies

Daniel Hardman: +1 to burn’s suggestion

Jonathan Holt: suggested PROPOSAL: Add privacy guidance that discourages services from adding potentially private identifying information in DID Documents.

Daniel Hardman: I would also support Jonathan’s variant

Joe Andrieu: what jonathan’s proposal doesn’t address is the fact that service endpoints, even with no PII in the endpoint, themselves correlate to external services
… I would like to find other language that includes the fact that even if the service endpoint doesn’t have PII they can be privacy impacting

Brent Zundel: let’s focus on one of these first

Proposed resolution: Add privacy guidance that discourages services from being expressed in DID Documents that are published to Verifiable Data Registries unless a DID Method specification have given specific guidance about how privacy concerns are addressed. (Manu Sporny)

Orie Steele: +1

Dave Longley: +1

Jonathan Holt:

Manu Sporny: +1

Adrian Gropper: +1

Daniel Hardman: +1

Brent Zundel: +1

Dmitri Zagidulin: +1

Ivan Herman: +1

Joe Andrieu: +1

Jonathan Holt: 0

Kaliya Young: +1

Resolution #4: Add privacy guidance that discourages services from being expressed in DID Documents that are published to Verifiable Data Registries unless a DID Method specification have given specific guidance about how privacy concerns are addressed.

Proposed resolution: Add privacy guidance that discourages services from adding potentially correlatable identifying information in DID Documents. (Manu Sporny)

Ivan Herman: +1

Orie Steele: +1

Manu Sporny: +1

Daniel Hardman: +1

Kaliya Young: +1

Dave Longley: +1

Jonathan Holt: +1

Adrian Gropper: I think this is too vague to be useful

Dmitri Zagidulin: +0 (agree that too vague)

Manu Sporny: if the PR is too vague it won’t get into the spec… I agree but I tihnk we can deal with it in a PR

Joe Andrieu: I agree with the general intent but the way it reads is that services can add information to DID docs which isn’t the case
… so something about adding service endpoints that have potentially correlatable information. The services aren’t the ones adding stuff

Jonathan Holt: fine to update to be more correct and to adrian’s point, it is vague, I apologies but it has to do with what is correlation and how is that performed
… those are unanswered security questions we had
… we haven’t explored that sufficiently to understand the threat model so we can have spec text that explains this in more detail

Brent Zundel: if you have concerns please -1 so we can jump to a new version of it more formally

Joe Andrieu: -1

Jonathan Holt: suggested PROPOSAL: Add privacy guidance that discourages services from adding correlatable identifying information in DID Documents.

Manu Sporny: there are two more important ones where we decide what we’re going to do with service..
… because it is linked data you can always do either one, but this is about what the group’s guidance around this is. do we want to tell people they can use services in VCs or do we want to say you must only use services in did docs
… but we’re not going to get to that. let’s rerun jonathan’s proposal

Daniel Hardman: For the record: I would vote 0 to both of Manu’s proposal. No opinion.

Joe Andrieu: it’s interesting that you tie that back to jonathan’s… the two options you just presented seems to say you can’t specify a service outside a DID doc or a VC… seems like we should just be talking about what is appropriate to put in a DID doc, nt where else you might publish information

Proposed resolution: Add privacy guidance that discourages services from adding correlatable identifying information in DID Documents. (Manu Sporny)

Manu Sporny: +1

Orie Steele: +1

Ivan Herman: +1

Adrian Gropper: -1

Daniel Hardman: 0

Joe Andrieu: I updated based on my comments but now we’re not using it

Daniel Hardman: +1 to Joe’s proposal, even though we’re not voting on it…

Joe Andrieu: -1 for that last proposal

Brent Zundel: we’re at time. I love that people are so excited about proposals

Kaliya Young: star hands

Brent Zundel: we made excellent progress today

Daniel Burnett: Yes, +1 to everyone’s enthusiasm to find an agreement!

Brent Zundel: we still have some proposals to look at but hopefully not so many that we need a special topic call.. maybe the main call
… thanks everyone for coming

Joe Andrieu: thanks, Amy!

Orie Steele: lets do it in the main call!

Amy Guy: Reminder - next main call is an Asia/Europe friendly time, US unfriendly time

1. Resolutions