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
- Resolution #1: Discuss in a non-normative appendix how one might model Service Endpoints that preserve privacy.
- Resolution #2: Define an abstract data model for serviceEndpoints in normative text, like we have done with verification methods.
- Resolution #3: Define how you do service endpoint extensions using the DID Spec Registry.