DID WG Topic Call on service endpoints — Minutes

Date: 2020-08-27

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Amy Guy, Dave Longley, Michael Jones, Manu Sporny, Jonathan Holt, Adrian Gropper, Orie Steele, Drummond Reed, Brent Zundel, Markus Sabadello, Daniel Burnett, Daniel Buchner, Dmitri Zagidulin

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Amy Guy

Content:

Brent Zundel: manu sent out an email with some proposals

Manu Sporny: getting a link to the proposals

Manu Sporny: Here’s a link to the proposal – https://lists.w3.org/Archives/Public/public-did-wg/2020Aug/0017.html

Manu Sporny: the proposals are to have discussions around, they start with probably most unpalatable to most palatable towards the end, really only 3 of them
… it’s non exhaustive
… At a high level I’m gonna put the proposals in there and talk to the rationale, and we can open up the discussion
… as people put themselves on the queue
… The first idea is, the one that is not going to go through we expect, is remove service endpoints from the specs

Manu Sporny: IDEA: Remove Service Endpoints from the specification and rely on Verifiable Credentials (e.g., transmitted during DID Auth) to communicate Service Endpoints.

Manu Sporny: we don’t need them, we can use VCs to express them
… daniel hardman had a good resposne to the email which was that how are we going to get the VCs across? We have 3 different did auth mechanism, there’s no consensus on a standard for it
… The counterpoint to that is many of us are moving credentials back and forth today even though we have multiple protocols, it’s demonstrated that we can do it so we could potentially remove service descriptions from the spec and move them across as VCs
… That’s the first idea
… To be clear, the privacy concern is that people will misuse service descriptions in DID documents
… Some developer out there won’t understand the privacy implications, will run a DID ledger that can’t be erased on ethereum or bitcoin, and they will start putting PII into that ledger, tracking identifiers, it’s bad and not GDPR compliant, goes against CCPA
… sad news all around

Manu Sporny: IDEA: Define a Service Endpoint for a GDPR-compliant service that supports Right to be Forgotten and is under the control of the DID controller.

Manu Sporny: Second idea here is people don’t want to remove service endpoints from the spec, but maybe we can define a GDPR compliant service endpoint mechanism
… Maybe we can’t stop people doing bad things, maybe we can define something that says if you’re going to do more discover of information about the DID subject you should probably do it this way because we’ve thought about it in a GDPR compliant, CCPA compliant way, no tracking cookies because of how the protocol works
… we can get together and define a best practice service endpoint that should work for 80%+ of the use cases
… We just define it and people can use it or not use it
… we’re not forcing anyone to use it
… THe third proposal says we can define the right way to do it and strongly recommend it’s the only way to do it

Daniel Buchner: We should not be baking a law into the spec, we should leave it open to use, and work to fix the law that never took all this into account when it was created

Manu Sporny: we can’t think of any use cases it doesn’t work for, we might as well recommend that
… that’s separated because strongly recommending it might feel unpalatable to folks

Manu Sporny: IDEA: Strongly RECOMMEND the use of GDPR-compliant service endpoints.

Manu Sporny: The last one is to strongly recommend a GDPR compliant service endpoint

Manu Sporny: Yes, that’s exactly right, we do know best because this is the group defining it.

Jonathan Holt: I have reservations about saying GDPR-compliant because it implies we know best about interpreting GDPR restrictions. We should say regulations in mind, but without making specific recommendations

Adrian Gropper: +1 to what jonathan just said
… should we be talking about say five specified/recommended service endpoints for whatever reason, or does manu’s proposal literally mean just one?

Manu Sporny: it’s up to the group to have that discussion, it could be one or five
… I suggest we only need one that addresses all the use cases that have been put forth to date
… we say how that one would work and see if anyone has a use case it doesn’t work for

Daniel Buchner: this is a fool’s errand and we shouldn’t be baking jurisdictional legal things into specs
… the law will get modified or interpreted in the years to come, it was created outside of the context of tech
… there will be a GDPR2 and people will get smart
… the spec should stay out of this
… if this is one service endpoint that is an object and i could put a zillion URIs in I’d get around it

Manu Sporny: GDPR is beign used as an example, even if we just remove the law completely it doesn’t remove the fact that what we’re trying to do is create a privacy enhancing ecosystem
… what we have right now, the examples in the spec, dump tracking cookies into the service description fields
… jonathan the question of we should stay out of it we don’t know better - I don’t agree, strongly

Daniel Buchner: services: { serviceEndpoint: { dans_list_of_uris: [1, 2, 3, …, 10] } }

Manu Sporny: we are the global standards setting body for how this technology works
… it is important that we take peoples privacy into account

Orie Steele: we need to remove “http” from the service description?

Manu Sporny: we have to think about GDPR and CCPA and things of that nature and have to do our best job to make sure people don’t accidentally abuse this technology
… what we have in the spec today is a wide open field
… all we need is one or two or three did methods to catastrophically fail to understand how GDPR and CCPA play into the ecosystem it ends up affecting all of us

Brent Zundel: I’d go a step further and we should try to make it so people can’t deliberately abuse this technology

Daniel Buchner: People need to use the spec correctly, we don’t need to police field criteria based on legal filters

Manu Sporny: the suggestion is let’s think about and evaluate what a mechanism could be - I can put forward a proposal in a bit - and see if we can get to something we all agree to
… vs doing nothing
… and leaving the spec as is with tracking cookies in there

Drummond Reed: what do you mean by the spec has tracking cookies?

Manu Sporny: in the spec today all the examples for service endpoints have unique identifiers at the end, which are unique to the individual

Orie Steele: https://w3c.github.io/did-core/#service-endpoints

Drummond Reed: you mean they could be used to track, they’re not actually tracking cookies
… yes, let’s clean that up

Manu Sporny: Here’s what we do in the spec today – https://w3c.github.io/did-core/#example-23-various-service-endpoints

Drummond Reed: what i want to speak to is every time i’ve heard, I’ve spent a lot of time, almost a year, evaluating GDPR and how it could be used specifically with DIDs
… I fully support the idea that in the spec you say if you want to do a GDPR compliant service endpoint do it like this

Daniel Buchner: There are many DID types that have low or no use cases where this is even an issue

Drummond Reed: but there are huge swathes of use cases for fully public did documents for organisations
… and iot, that do not have these privacy considerations
… as soon as I heard let’s get rid of service endpoints, there are all kinds of needs for them in public documents that do not have GDPR considerations

Daniel Buchner: IOT, companies, public benefit orgs, app IDs, package manager IDs

Daniel Buchner: bananas

Drummond Reed: any suggestion that we should get rid of them, evernym will formally object to that

Daniel Buchner: I will formally object too

Daniel Buchner: Imagine the scene from A Few Good Standardistas

Orie Steele: not sure this WG has the skills to interpret GDPR law… we can barely document how mimetypes work :)

Markus Sabadello: it’s a good idea to add some language to talk about these privacy preserving service endpoints that have some kind of proxy function or something but i’d also be against changing the flexibility of having any kind of service endpoint as we have it now
… one reason drummond already explained - public service endpoints for organisations
… privacy is an important objective, but other objectives are sovereignty and control and cryptographic verifiability
… i want to add that some of the guarantees we have for dids and did resolution and did methods apply only to the did document, getting from the did to the did document

Daniel Buchner: https://www.youtube.com/watch?v=bOnRHAyXqYY

Manu Sporny: Orie, some of us have access to lawyers whose job it is to interpret GDPR and CCPA… in the same way that we depend on them to do patent analysis for W3C specs.

Markus Sabadello: as soon as we involve something like a proxy or GDPR compliant service endpoint whatever happens there does not necessarily have the same guarantees as did resolution
… if i have service endpoints for activitystreams, didcomm, openid connect, in my did document i have all of these guarantees of cryptographic verifiability and authentication
… arguments for adding considerations around privacy preserving service endpoints but not changing the ability to have whatever people want

Orie Steele: manu, sounds expensive, but if others are buying :)

Adrian Gropper: service endpoints have both a privacy engineering aspects and an interoperability aspect
… we need to consider both of them together

Adrian Gropper: Service Endpoint Survey: https://docs.google.com/spreadsheets/d/1jNpWDEMvjtgom5O-EDCXfqrIIrlfVnIlXea01igdZaM/edit#gid=872239908

Adrian Gropper: one of the ways to do that was started with this initiative, the service endpoint survey ^

Manu Sporny: Orie, it is expensive, but a number of us have access to those resources (and have already engaged them on the matter)

Daniel Buchner: We are actively working with public sector folks to work this out

Adrian Gropper: we could solve both of these problems by having however many service endpoint types, with an eye not just towards privacy engineering but say also interoperability

Daniel Buchner: the laws knew not what they did

Michael Jones: we’re not experts in GDPR, the California privacy law or the privacy laws in other jurisdictions that may or may not exist
… at most in our spec we should say in a privacy considerations section that implementers and deployers should be aware of locally applicable privacy laws
… and comply with them
… fullstop

Dave Longley: there might be another proposal in the middle ground, for keeping the vocab around in the spec but strongly recommend you use it in VCs instead of DID docs or VDR backed DID docs

Orie Steele: yep +1 to selfissued, i think similar language regarding localized cryptography laws is required.

Dave Longley: the other point, was around questioning the use cases we have for public service endpoints
… a DID on its own is meaningless, it must be bound to some other information to take on meaning
… that could come from a trusted source, a VC, or a peer to peer conversation with another party already
… in both cases the fact you must send additional information means you have the opportunity to send service endpoint information
… it would be more efficient or more security to send it separately
… they don’t have to hit an untrusted endpoint, you hand them the data directly
… also means you don’t have to handle complex authority rules
… I want to make sure it makes sense for the use cases, for people getting dids, where did you get it to begin with? you probably got it from another registry that has more information that in all likelihood is application specific or contextually specific

Manu Sporny: https://w3c.github.io/did-core/#keep-personally-identifiable-information-pii-private

Manu Sporny: couple of points.. mike, we should have language outlining this in the spec, we already do have language about GDPR and PII
… the “we’re not lawyers” true but a number of us have access to legal council and I hope you’re listening to your lawyers when they talk about this stuff and how it impacts you when implementing a DID ledger, it does
… we have access, a number of us have access to lawyers whose job is to interpret where GDPR and CCPA are going and that can influence technology decisions
… I think we can put one of these proposals to rest and I’m going to put it out now, the first one

Daniel Buchner: Let’s let them do their job, and then put out a guide later with more and more detail on how you SHOULD use them

Daniel Buchner: -1

Manu Sporny: my expectation is -1s and we can take it off the table

Dave Longley: notes that we don’t have to talk about law, we can just talk about privacy – that’s really what this is about anyway (which is similar to comments others have made), i think talking about law is a distraction

Manu Sporny: any objections to run that proposal and get it off the table?

Brent Zundel: anyone on the queue planning to speak to anything supporting this proposal?

Proposed resolution: Remove Service Endpoints from the specification and rely on Verifiable Credentials (e.g., transmitted during DID Auth) to communicate Service Endpoints. (Manu Sporny)

Orie Steele: -1

Brent Zundel: -1

Daniel Buchner: -1

Markus Sabadello: -1

Michael Jones: -1

Manu Sporny: +1 (we could do it via VCs)

Drummond Reed: -1 to formal objection level

Adrian Gropper: -1

Dave Longley: -1 for removing from the spec part

Jonathan Holt: -1 unless it is explained more about how to do it with VCs

Manu Sporny: CLEARLY DEAD: Remove Service Endpoints from the specification and rely on Verifiable Credentials (e.g., transmitted during DID Auth) to communicate Service Endpoints.

Drummond Reed: adrian’s point about one of the reason’s I’m a big fan of service endpoints, this is my forth go around on doing identifier and discovery specs, they’ve all had service endpoints
… I understand many of the issues
… one of the things I want to point out is, DIDs and DID docs are such a low level of the infrastructure to imagine that we now can say what people will do with service endpoints and what will or will not have privacy implications

Daniel Buchner: Drummond the Architect of the ID Matrix: I have done this 4 times, and I am getting exceedingly good at it

Drummond Reed: we’re not that smart. keep things simple
… if you want a way to access a service associated with a DID this is how to do it
… the very first version of the spec we recommend any service have an associated spec
… it’s a fantastic idea to have specs to say if you want a GDPR service endpoint, do it this way

Markus Sabadello: dave said service endpoints in a DID doc may not be necessary because you can send it separately however you get the DID
… you could get service endpoints with the same mechanism.. problem with that is it eliminates the function of data portability

Daniel Buchner: I could do a little Clippy riff where he pops up in your DID wallet UI and says: “I see you are crafting a Service Endpoint, would you like me to tell you about GDPR?”

Markus Sabadello: we’ve always said we want DIDs to be persistent identifiers, an abstraction layer on top of services as well as keys. I want to be able to change my services without changing my identifier just like rotating keys

Drummond Reed: There is an entire discovery function represented by service endpoints where there is no capability to “send” anything because the relationship doesn’t even exist yet.

Markus Sabadello: if I get one static set of service endpoints together with the DID I Don’t see how we can have this abstraction layer which is important for data portability

Orie Steele: You could use TOR for serviceEndpoints, 3g2upl4pq6kufc4m.onion ….

Dave Longley: to markus, when you hand over the service endpoint, put an expiration on it and tell them where to refresh the information – then you get portability

Markus Sabadello: another argument for keeping them in the DID doc and preserving the ability to include them in the DID resolution process

Orie Steele: we have to address the data model, the privacy considerations, and the implementation recommendations
… we need to address them each separately and not conflate them all at once

Michael Jones: something manu said a while ago was that we already have sections about GDPR in the body of the spec
… I believe that’s a mistake and I will file an issue to have them removed and move them to privacy considerations
… we should not be including any legal advice
… it’s not our place to give legal advice, MS will formally object if it’s not removed from main body of the spec

Brent Zundel: we need to add an in general if you can send information some other way folks should do that
… encourage the not overloading of the DID doc as an information resource, but not to the point of getting rid of service endpoints
… we keep talking about an implementation guide, we’ve not really had one yet… we’ve got a repo.. if anybody wants to edit the implementation guide let us know!

Daniel Buchner: Without SEs, how will one link to an authorization server?

Adrian Gropper: I want to pile onto what markus just raised about the role of the DID doc as being a means to rotate your private keys and I’m piling on in the sense that the DID doc should also be a means by which I can keep my policies as an individual just as private as I’m keeping my keys as an individual

Orie Steele: The fact that the implementation guide is empty is not a problem, if nobody wants to do that work, that work should not be done :)

Adrian Gropper: I do not want to ever have to put my policies by which authorisation is going to happen when there’s a requesting party at the door that has discovered my DID

Daniel Buchner: (I was just having an aside bit of fun)

Adrian Gropper: and the DID doc as a public document
… in terms of privacy engineering work, in the spec this is one way to look at the role of the DID doc relative to service endpoints
… it’s not the only way, but if we are going to talk about a certain finite number of service endpoints, however they’re specified, this becomes an important consideration

Orie Steele: We should not conflate implementation guide material into the core spec, especially if it implies you should pick one vendor over another….

Manu Sporny: https://w3c.github.io/did-core/#keep-personally-identifiable-information-pii-private

Manu Sporny: mike to save you some time, don’t raise an issue, it’s already in the privacy considerations section
… The next proposal I want to put in front of the gropu is whether the group would oppose a subset of the group defining a service endpoint mechanism that would take into account things like not accidentally exposing tracking tokens, and things like that, things that could be viewed as a best practice

Daniel Buchner: Sounds like a guide

Manu Sporny: it’s an optional field, you don’t have to use it
… one of the things this conversation is suffering from is a concrete example of what a best practice service endpoint might look like
… the proposal is can the group work on that

Daniel Buchner: normatively different in spec text?

Manu Sporny: would anyone object to the group defining an optional service endpoint that takes a number of these concerns into account?

Daniel Buchner: question is the language you use describing that - would this go in a guide? knock yourself out. Is it normative text in the spec that says there’s service endpoints and here’s a special one that infers the others are wrong, would concern me

Manu Sporny: not the one where we prevent everyone from using everything but that one… all we’re doing is.. we need a concrete example of something
… then we can see where the group wants to put it. Could go in best practices, or security considerations, or if the group goes it’s pretty good but optional
… I don’t think we’d get to the point where we said this is the only way to do it

Daniel Buchner: that’s fine

Drummond Reed: manu answered my question. I support figuring how to do it and then where is the content best
… Implementation guide, example under privacy considerations, or service endpoints section. Any of those could work.

Orie Steele: IMO the service endpoint data model should be defined normatively, like we do for verification methods.

Markus Sabadello: this group should write about the idea of having something like this, architectural considerations, the concept of some kind of privacy preserving service endpoint mechanism, but not define any type of concrete service type or protocols but discuss it in a more generic way

Orie Steele: agree with markus, that the concrete, specific example should be avoided, especially in normative text.

Markus Sabadello: if anyone wanted to provide a concrete protocol or service type to enable it it could be a work item elsewhere

Adrian Gropper: I would like to propose at some point we consider at least three types of service endpoints be mentioned in the core proposal
… a mediator (the herd immunity one), a notification one (yesterday we talked about the first contact, the arc between two DIDs) and the authorisation endpoint (because the DID doc covers authentication and leaves open how do we introduce authorization into the sequence)
… I would formally like at some point, maybe not today, to raise those as the minimum three to be mentioned in the core spec

Manu Sporny: I have attempted a proposal ^

Michael Jones: See my comment on the current GDPR text in the specification at https://github.com/w3c/did-core/issues/72#issuecomment-682061148

Manu Sporny: let’s get a concrete example down and decide what to do with it later but not mandate it

Michael Jones: this is very strange
… you could have an appendix with an example service, but I sure don’t want any normative text about it

Drummond Reed: An appendix is one option I was thinking about as well.

Jonathan Holt: the word concrete, we need to be careful about.. setting that in stone

Daniel Buchner: Can we amend the proposal to exclude in-spec normative text?

Jonathan Holt: having a section that describes the privacy concerns and methodologies to mitigate it, but that’s a cat and mouse game

Orie Steele: agree… we need to define an “abstract data model” for service endpoints, and leave concrete stuff to non normative / privacy considerations / implementation guide land.

Jonathan Holt: some solutions in the peer to peer realm, there are ways of elucidating and correlating the IP addresses that are not necessarily in the DID doc but could be inferred from hitting the service endpoints over time
… this would be great to investigate but reservations about the word concrete

Drummond Reed: manu’s proposal has two parts

Markus Sabadello: For reference, this has also come up on the DID Resolution calls in the past: https://w3c-ccg.github.io/did-resolution/#proxy

Drummond Reed: define it then decide where it might go
… it might make a good example for an appendix
… but after we define it it’ll be a lot clearer where it might fit

Manu Sporny: jonathan_holt, you want the word concrete removed?

Jonathan Holt: I think it implies a normative representation of what a service endpoint must be as an example
… I’m all for discussing it more
… adrian and I had serious reservations about this in the security and privacy document we don’t know, there are lot of questions unanswered because we don’t kno wwhat the content tracing capabilities may be in different systems
… but we need to explore it

Daniel Buchner: “Define how to model a service endpoint that does a good job of preserving privacy”

Daniel Buchner: ^ why not this

Jonathan Holt: a concern, be mindful of security considerations such as GDPR and have more ongoing discussion

Manu Sporny: mike, how can we change the proposal?

Michael Jones: the word non normative needs to be there

Manu Sporny: we have that as one of the options

Daniel Buchner: talk about modeling, not about an exact service endpoint

Michael Jones: i’d prefer it be in an appendix
… it’s not clear what this endpoint does
… very strange to define an endpoint with no particular semantics

Adrian Gropper: I would +1 working on whatever it is, even though we are going to end up with at least three, I would +1 this if you can clarify mike’s point about a service endpoint type
… are we going to approach this one as a particular type or in the context of a particular use case? if so fine let’s start

Markus Sabadello: similar question, I would support if it says define the idea or design of such a service endpoint but I would go against defining a concrete service type

Daniel Buchner: what markus said
… I’d be much more comfortable with saying define how you might model service endpoints to preserve privacy, here are some cues. vs producing a service endpoint with characteristics

Manu Sporny: I’m trying to rewrite the proposal

Adrian Gropper: I specified 3 specific types, markus maybe wants to make a proposal around wording

Markus Sabadello: I think the proposal is fine, I would be against defining defining one, and also against three if tha timplies concrete service types and protocols
… we should just talk about designs and functions and how to model and design these

Michael Jones: Discuss in a non-normative appendix how one might model Service Endpoints that preserve privacy

Drummond Reed: to clarify, I’m comfortable with these, I really want to get back to what the spec originally said

Jonathan Holt: suggested Proposal. Document in the implementation guide suggesting best practices for Service Endpoints that preserve privacy in a non-normative way with policies such as GDPR in mind.

Drummond Reed: service endpoint types should have associated specs
… I love the idea that there are specs written for service endpoint types that are around privacy
… you could have many kinds of service endpoint types, it’s turning into a whole section in the implementation guide about how to design privacy perserving service endpoints

Michael Jones: I would be willing to approve the counter-proposal that I wrote above: PROPOSAL: Discuss in a non-normative appendix how one might model Service Endpoints that preserve privacy

Drummond Reed: service endpoint types should have associated specs, as a SHOULD

Michael Jones: uses the word define.. that’s overly normative sounding

Adrian Gropper: +1 drummond types SHOULD

Michael Jones: I’m willing to have us discuss, but w’ere not defining anything
… I sent a counterproposal of wording

Ivan Herman: I’m a bit lost with the types

Daniel Buchner: yes

Ivan Herman: do we end up having yet another section in our registries for service endpoint types?

Drummond Reed: Yes

Manu Sporny: no
… already have it

Drummond Reed: And that’s a GOOD thing.

Jonathan Holt: +1 to mike, drop “define”, document best-practices in a non-normative way

Orie Steele: https://www.w3.org/TR/did-spec-registries/#serviceendpoint

Markus Sabadello: who said we have a registry of service endpoint types?

Manu Sporny: we have a service endpoints section in the registry and we could put types in there

Manu Sporny: https://w3c.github.io/did-spec-registries/#services

Markus Sabadello: I’d be opposed to that
… that defines the serviceEndpoint property but it doesn’t list any service types

Manu Sporny: …yet

Orie Steele: I am not opposed to mike’s proposal, but its not an alternative to mine.

Orie Steele: we define what a verification method is in did core, and terms like type, id, controller
… I’m proposing we do something similar for what a service is
… and use the registry as a way of defining those properties, and if people want to extend, then we do the exact same thing for services as we do for verification methods
… I don’t see how we retain services in the spec without doing that

Daniel Buchner: No one is saying not to normatively define the basic properties of an SE

Orie Steele: where would the definition be for what a service is?

Ivan Herman: I think I agree with Orie on this

Daniel Buchner: we are saying not to define a specific SE type that has all these details baked in

Drummond Reed: +1 to what Orie is saying - and to doing that in the spec text

Manu Sporny: I would presuming we were already going what Orie is saying but we definitely don’t say you can extend it in the spec
… I’m really surprised markus would object to it so clearly we have to talk about that separately
… I’m objecting but not standing the way to mike’s - I don’t think it helps us if we don’t at least get some concrete discussion around concrete service descriptions
… it’s bad to speak in the abstract
… if we pass Orie’s it means some of us can work on concrete service endpoints

Proposed resolution: Discuss in a non-normative appendix how one might model Service Endpoints that preserve privacy. (Manu Sporny)

Orie Steele: +1

Drummond Reed: +1

Dave Longley: -0 i highly suspect the best way to do privacy preserving service endpoints is to express them (however you want) in VCs w/an expiration/refresh mechanism, not in a VDR-sourced DID Doc

Jonathan Holt: +1

Markus Sabadello: +1

Amy Guy: -0 too early to decide where in the spec unwritten text goes or if it’s normative or not

Dmitri Zagidulin: +0

Ivan Herman: +1

Adrian Gropper: +0

Daniel Buchner: +0

Manu Sporny: -0.5 to talk about it purely in non-normative terms… that doesn’t help us make sure we’re designing the ecosystem correctly.

Brent Zundel: +0

Manu Sporny: but I won’t stand in the way.

Brent Zundel: too early to decide where it should go, we don’t have the text yet

Adrian Gropper: +1 too early where it should go

Jonathan Holt: discussion is good before we get to normative text, we need more discussion on security and privacy implications before we make any decisions

Drummond Reed: I did a +1 to the general idea but I also agree it’s too early to decide where the result needs to go

Michael Jones: 0

Orie Steele: agree, but you can’t spread privacy concern over the entire spec….. we have a section for that

Brent Zundel: it feels odd to resolve with so many people being 0s, but your half an objection isn’t stopping it

Resolution #1: Discuss in a non-normative appendix how one might model Service Endpoints that preserve privacy.

Proposed resolution: define an abstract data model for serviceEndpoints in normative text, like we have done with verification methods. (Orie Steele)

Orie Steele: +1

Drummond Reed: +1

Daniel Buchner: +1

Manu Sporny: +1

Dave Longley: +1

Adrian Gropper: 0

Brent Zundel: +1

Dmitri Zagidulin: +1

Manu Sporny: To be clear, I expect us to talk abou tthe registry and how you define new service endpoints

Ivan Herman: +1

Adrian Gropper: My +1 was to drummond’s point only

Jonathan Holt: 0, need more discussion about types

Michael Jones: 0

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

Manu Sporny: any objections to also defining how to do service endpoint extensions using the registry?

Proposed resolution: Define how you do service endpoint extensions using the DID Spec Registry. (Manu Sporny)

Daniel Buchner: +1

Manu Sporny: +1

Orie Steele: +1

Drummond Reed: +1

Dave Longley: +1

Dmitri Zagidulin: +1

Ivan Herman: +1

Markus Sabadello: +0 don’t really understand what that means

Adrian Gropper: 0 Too early to discuss extensions

Michael Jones: 0

Jonathan Holt: 0 , I need more discussion

Resolution #3: Define how you do service endpoint extensions using the DID Spec Registry.

Ivan Herman: we should remember that any resolution taken on this call is not binding, i’ts not the WG call
… the WG call must decide

Brent Zundel: thanks everyone

Adrian Gropper: fantastic scribing by Amy

1. Resolutions