DID WG Telco — Minutes

Date: 2021-11-30

Attendees

Present: Brent Zundel, Shigeya Suzuki, Ted Thibodeau Jr., Logan Porter, Charles Lehner, Adrian Gropper, Drummond Reed, Markus Sabadello, Dmitri Zagidulin, Orie Steele, Daniel Burnett, Ryan Grant, Joe Andrieu, Kyle Den Hartog, Kristina Yasuda, Pamela Dingle, Yoshifumi Takeuchi

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Charles Lehner, Brent Zundel

Brent Zundel: Let’s go ahead and get started, fairly straightforward agenda, bulk of our meeting will be on DID Method registration limitations… what are existing limitations, what should those limitations be moving forward, as time permits after that, we’ll look at did-spec-registries issues..
… Any questions about the agenda? Anything else we want to talk about today?.

Manu Sporny: Can we talk about DID Core objections for a bit?.

Brent Zundel: Yes, we can – let’s do that now..

1. DID Core Spec update.

Manu Sporny: Just an update: we specifically requested a timeline before Thanksgiving, two weeks ago, to the Advisory Board..
… They were talking about timeline and things of that nature. We haven’t gotten a response yet..
… It’s been 80+ days. Really long time for a FO..
… Haven’t published minutes - meeting every other week. Expecting minutes this Thursday and then to find if there is a timeline or not..
… We’re being guinea-pigged… don’t know what to expect… don’t know what to do about that, other than multiple of us asking for a timeline..
… Two things we can do… We’ve talked with Google, wrote it up. Also talked with Mozilla… they are writing it up for distributing to the AC..
… We have a pretty good idea of their concerns at a high level. Probably need to write that up and circulate it among the AC..
… I’ve taken a shot at that, here:.

Manu Sporny: See Letter to the AC on DID Core FO Status.

Manu Sporny: That’s a link that has comment rights. I’d like this group to maybe review that, modify language, see if anything was missed..
… The purpose of the letter is to try to summarize where we are, not to say what is right or wrong, just to say what seem to be the points of contention, and where the WG is right now..
… We know what is request, and that is problematic….
… We are trying to say we understand the concerns at a high level and ask what you suggest we do about it concretely.

Manu Sporny: See Write up of status of formal objections.

Manu Sporny: Second item: a request to the group - I think I’ve circulated this to the group before ^.
… I’d like to propose the WG adopt the write-up I did - specifically to fix it up and make it a position, so that we can go into the FO council with a writeup and all the QA that’s happened over the past few months..
… Suggestion is to transfer it to the WG.
… To summarize, two requests to the group: 1. review that letter; if objections, I’ll send it as a personal letter. 2. review transferring that repo to WG.
… Goal is to make it easy to summarize the WG’s position on all points.

Brent Zundel: Thanks, we’ll take questions now..

Drummond Reed: First of all, thanks Manu for all the work to help us through this process. We’re being guinea pigged, we don’t even know what this process looks like, helpful. Question around AC letter – is that letter you like to send from the WG? What’s our process for approving it?.

Manu Sporny: It’s a good question….
… I don’t think we need to get it approved by the WG, I’m just going to send it out there, to say here’s where we are - just don’t want anyone to say “no, that’s not all right”.
… Letter doesn’t need to be formal - just a once-over by the WG for any objections.
… The repo, it would probably be better to have it in the WG, and be reviewed for any errors.
… Both are important for the Formal Objection council to take a look at and know that the WG has reviewed it and there are no objections, etc..

Brent Zundel: Any other questions from folks?.

Ryan Grant: I would like to rewrite the sustainability section to reference the conflict with human rights and inability to rank one above the other given the current ethical web principles..

Manu Sporny: My hope is to not get in an argument about that with anybody, and just say, sustainability is important to everyone, let’s make another group..
… The W3C cares about sustainability - there needs to be a sustainability group..
… My concern about what you would do is that there would be an argument - It’s totally valid, but if we get into that argument in this group with the FO council, it could slow the process down..

Ryan Grant: I can’t accept it as is.

Manu Sporny: Please suggest concrete changes.

Ryan Grant: Will do.

Manu Sporny: ok, please suggest changes and we’ll go from there..

Drummond Reed: Were you commenting on the last section of letter or the FAQ?.

Ryan Grant: On the letter?.
… I don’t want to allow the current framing to persist..

Drummond Reed: Having looked at the letter, it would be helpful to send to the AC list this letter. We don’t have to approve as WG – would favor doing that, modulo changes/objections such as the one ryan just raised, it does help make a strong case for moving forward… put ball in FO Council’s court..

Brent Zundel: We’re going to move forward with Agenda, thanks for bringing those things to groups attention. Going to talk about DID Method registration limitations..

2. DID Method Registration Limitations.

See github pull request did-spec-registries#369.

Brent Zundel: Let’s start by looking at PR.
… markus, can you walk us through this PR?.

Markus Sabadello: yes, I can.
… a new requirement added to registration process – DID Method names must be indicative of their function or underlying nature of Verifiable Data Registry, motivation, other PR – addition of did:id method..
… Could be a useful role, names should indicate what they do – ‘myProperty’, ‘foo’, ‘abc’, or ‘firstName’, but it has nothing to do with first name… registry, method – do we have any rules around that/.
… Feedback in PR so far, sounds like that could be useful, might be difficult to make judgement in some cases, one proposal was to change MUST to SHOULD … after reflecting, I would be fine w/ that change. Would be fine with that change, to remove burden for Editors and additional value judgement..

Drummond Reed: +1 to making it a “SHOULD”.

Drummond Reed: +1 to it being a “MUST” if the PR is limited to properties.

Markus Sabadello: That’s current status of PR..

Joe Andrieu: What’s the definition of extension? property names or method names?.

Markus Sabadello: All of it.

Joe Andrieu: It seems inappropriate that a method name has to be indicative..

Manu Sporny: If this is about properties, I don’t have a problem with that, even with a MUST. Applying this to DID Methods is more difficult.

Kyle Den Hartog: +1 to property only and it seems much easier to scope the subjectiveness.

Kyle Den Hartog: I agree with manu about property aspects, but also recognize that this was raised because of method names – in that regard, do we not apply this to method names? Or just split it out wrt. procedure, deal w/ method names later..

Markus Sabadello: Kyle is right, original motivation had to do with method name – felt that particular method was misnamed – with regard to this PR, lets make it MUST for property names and parameter names, SHOULD for method names..

Joe Andrieu: I think we’re doing too much for methods, long term, we should not have a registry for DID Methods here – we took what we needed to have an interoperable properties registry, and started listed DID Methods… feature creep, started an avalanche, not right place to do it, DID Methods don’t have to be registered to be conformant..
… I’d like to plan that seed… don’t have a solution that’s better right now, whole world of conversations because we bit off what we can chew..

Ryan Grant: +1 to less registry and more directory.

Drummond Reed: There was a lot of pressure to establish unique DID method names, at least in one context (the W3C context).

Orie Steele: +1 … I think folks should not think of the registry as useful for discovery or directory…..

Manu Sporny: +1 to that. That solves a bunch of problems we’re having now. And it incentivizes Method implementers to pass the test suite or go through the rubric. I’d like to split this in two..
… property names should mean what they indicate, DID Method names should be kicked down the road..
… then we can talk about DID Method names.

Adrian Gropper: +1 to Joe’s point, curious – why wouldn’t we focus entirely on Rubrics?.

Kyle Den Hartog: Is it ok if we continue down path of responding or do this later?.
… +1 to that, Joe’s advocated that point… W3C from a founding, doesn’t have things in place to deal w/ trademarks other difficult aspects, we’re likely to run into that, only concern I have… what do we do about interop case where resolvers treat methods in different ways? BBS+ keys inside Sovrin DID method, but wasn’t compliant w/ sovrin did method… breaking change, should’ve been renaming method, didn’t do that – implication on interop by allowing people to reuse same namespace in different ways for different methods..

Drummond Reed: The very first version of DID spec, we said: there shall not be a registry of DID Methods… but here we are with a registry – reason we have registry was because of unique namespace consideration, he was one of the strong proponents on “how do I know if I’m using authoritative method”, that’s why we’re doing it. If we’re doing it, that’s why we need baseline requirements so we don’t get it filled with junk… in terms of not real/legitimate methods… way to get around it, ignore it? Namespace uniqueness was the reason we did it..

Ted Thibodeau Jr.: A few things – the registry, as I recall it, one of the first thing that went into registry was DID Methods, namespaces wasn’t solved in another way, if we undo it here, needs to be addressed..

Orie Steele: Maybe we can move the did method registry to IANA?.

Ted Thibodeau Jr.: Not everyone in the world speaks english, if we have to name things to what they’re doing, we need to declare a language… english would suit people on this call, but perhaps it should be cantonese or something w/ a larger population?.
… In a lot of ways, what we were should’ve thought about two years ago we’re thinking about now… unfortunate due to current FOs… but perhaps we do this again w/ some of these considerations higher in mind..

Kristina Yasuda: A big -1 to killing DID Method registry entirely. Did I understand that correctly?.

Brent Zundel: My understanding is properties and parameters would stay, but DID Methods would be removed..
… This is about removal for DID Methods.

Kristina Yasuda: A big -1 to that, even though it’s been criticized, it helps interop. We need to understand which client supports which DID Method, here’s a registry, this is a common way on what to include in metadata without any judgement. This is why we’re separating Rubric from DID Method registry, we need that..
… I’d like Mike Jones to be on this call if that decision were to be made..

Joe Andrieu: There is a misconception about what’s currently functionally specified. There is no requirement that property names be unique, DID Methods names are unique, this is exactly parallel to the question: Which blockchain deserves the BTC ticker symbol… a centralized registry to delineate that space is not the right way to solve a decentralized identity problem. We need a healthy mechanism where people can discover DID Methods..
… Centralizing a control system is exactly what W3C does not have the institutional processes to handle… who owns any of these entries? Who gets to choose entries?.
… For IANA, there is process and case law… we should take some time over holidays wrt. how we do this better. Main reason we had registry is interop for JSON / JSON-LD… then we added Methods..

Markus Sabadello: Don’t have a strong opinion either way, there is a trade-off – on one hand it’s useful to have registry of method names, on the other hand it introduces a central authority which controls a namespace… middle ground we ended up with was method registry is informal guidance, a way of discovering..

Joe Andrieu: +1 method registration was always considered informal and optional.

Drummond Reed: +1 to the method registry being to provide informal guidance.

Markus Sabadello: informal, non-normative listing, not a requirement for anything to work… they should still work for OpenID connect and other things, difficult topic – maybe we should have method numbers instead of method names…. did:46.
… Removing it at this point would go too far..

Joe Andrieu: +1 to say anyone should be able to create a method, without censorship.

Kristina Yasuda: A couple of points – first introducing centralization into decentralizing space… we’re decentralizing identifiers, we’re decentralizing keys… let’s decentralize that first. Decentralized PKI identifier problem first… then let’s solve discovery next… simplest way is to have a registry right now..

Drummond Reed: +1 to Kristina’s point that our first goal is solving decentralized identifiers and PKI first.

Kristina Yasuda: There are legal issues related to registries… there is a misconception there, doesn’t mean system doesn’t work… IANA has a registry, W3C is undergoing some transformation, but introducing a good mechanism… worth the effort to try and install it..
… You need to discover each DID Method… inside DID Documents, you can use another mechanism..

Orie Steele: There was a CCG work item that managed a registry of DID Methods and eventually we imported that work item into DID Spec registries as a section, and I kinda agree w/ everything everyone’s been saying – need a way to say “here’s the namespace registry”, then you need other places to pass judgement on those registrations. It’s basically first come first serve unless you violate a legal/security issue that would put things at risk… we approve by.

Manu Sporny: default if you follow the rules..

Joe Andrieu: +1 to say we don’t need discovery. it’s a nice to have..

Orie Steele: I don’t know how IANA handles this – DID Method registry may belong at IANA, not at W3C – not a place to put all these value judgement, customization, just a place to solve for global interop, that’s it’s purpose, based on centralized tech– first version is going to be… IANA is totally centralized, it’s what works – centralized registries, you can’t there is not way to solve that problem better than how IANA has solved it… DID Method registries is how it’s supposed to be, not filled w/ value judgement, you discover that information in other places..

Joe Andrieu: +1 to returning to PR.
and W3C != IANA.

Manu Sporny: I feel like we are spiraling away from the PR we were discussing. I want to remind folks that IANA is still people and they still have these discussions..
… we should keep what we have now. The value of IANA is that they don’t make value judgement. I think we may have people in the WG who want to make value judgement. I’d like to go back to the PR itself. How can we pull it in. If we can make it about properties and not methods..

Orie Steele: clearly… IANA has registries that work..

Brent Zundel: Let’s talk about the PR – quickly, drummond..

Kristina Yasuda: not making a value judgement does not mean not making any judgement at all.

Drummond Reed: If we’re keeping method registry, we need baseline compliance value judgement/decision – at one end, it’s no judgement at all – even IANA, baseline IANA – do you have a spec, baseline judgement about compliance so we don’t get complete junk..

Ted Thibodeau Jr.: Are we declaring English to be the lingua registrata?.
Got to make English requirement explicit in the docs, if that’s consensus. Or make something explicit about handling Unicode values, non-EN langs, etc..

Kyle Den Hartog: Regarding the “DID spec compliance value judgement” we should take a look at [RFC6838], [RFC4289], and [RFC6657] which is how mime-types handle registration.

Markus Sabadello: regarding the PR, I’ll split it up into two PRs… one about property names, I don’t think language concern is an issue… don’t have to have things be in english, that’s what I will do – split it up into method names with SHOULD – things can be said separately..

Orie Steele: +1 to splitting the PR.

Kristina Yasuda: Not making value judgement doesn’t mean not making any judgement at all..

Manu Sporny: +1 to kristina..

Drummond Reed: I would agree, value judgement or legitimacy discussion, not trying to say it’s more than a baseline….

Kristina Yasuda: Checking that method name exists, method name is harmful, etc..

Drummond Reed: Specific proposal, is the method spec compliant at a base level, we have a set of requirements that would prevent rogue registrations that wouldn’t have legitimate spec..

Brent Zundel: First, thanks, this is a good conversation, agree, glad we were able to come to agreement on PR – continue this conversation, going to ask question, purpose of question is to stir things up a bit? Why do we care if people register junk?.

Orie Steele: The only reason we would care, is that they’re taking valuable words and destroying their value so they’re not useful..

Kristina Yasuda: DDoS attack on a DID method registry by registering a lot of junk method names?.

Drummond Reed: Exactly.

Ted Thibodeau Jr.: ^^^^^^^ yup.

Orie Steele: if I name squat, namespace is shrinking, value in strings people have affinity for. So, we need registries that have Editors that are capable of handling those sorts of scenarios, whole bunch of people that are spinning up GPT3 crafted DID Specifications… according to rules, I have to approve them… not that great to do that sort of thing, squatting on whole namespace, assign them, handle mapping,.
… managing a registry is an annoying process and it’s even more annoying when registry does more than checking a few minimum criteria..
… Obsolete, probably going to happen..

Drummond Reed: I’m hoping that DID method names have minimal value because 99.99999% of humanity will never see one. But they still have some value to the developers, which is why we still need to avoid garbage DID methods..

Dmitri Zagidulin: +100, drummond. Devs are our main audience.

Orie Steele: We care deeply if name squatting / damaging registrations happens, harm existing DID Methods, make registration process really frustrating,.

Kyle Den Hartog: Primary reason we care, spam attack on maintainers of registry. Takes me 40 minutes to do an evaluation of method, I’m looking for “can I implement this myself?” – maintainers have to spent time on this..

Orie Steele: almost like IANA already knows how to solve this…..

Kyle Den Hartog: DID Methods are TLDs, some sold for $150K, we need to recognize cash value here..

Dmitri Zagidulin: ok, but they ARE TLDs for developers.

Kyle Den Hartog: We’ve already seen it in indy space. People are using the indy did method and renaming to fit their network.

Brent Zundel: is a DID method equivalent to a tld? an http URL? an IP address?.

Drummond Reed: Allergic reaction of DID Method name to TLD, just got done entering a comment about vast majority of humanity will never see DID and Method name… could be completely wrong about that… they are TLDs for a developer, write code… still some value … that’s why we have 114 registrations, in my view, it’s the quality of the registry, even if it’s informal, being able to discover information, find spec associated w/ method. What we end up, method name in spec, rubric, test reports, implementations, useful tool… quality of that tool – that’s what we should care about..

Orie Steele: +100000 stop trying to use the registry to discover “value”….

Joe Andrieu: I don’t think the registry is the sort of place to do that additional discovery… hoping to propose something next quarter on that… explcit question– junk methods will make DIDs look like junk. People will pick one, and if it looks bad, they think it’s malarkey/scam….

Shigeya Suzuki: +1 to Orie.

Brent Zundel: maybe some folk shave already done that..

Drummond Reed: “a bunch of junk DID methods” will make DID look like junk <== totally agree with Joe on that.

Orie Steele: I tend to think the web is bad, because Manu web sites are bad..

Dmitri Zagidulin: orie: lol.

Drummond Reed: +1 to encouraging re-use of DID methods.

Logan Porter: A DID Method should be a means to access data rather than a brand, we want to encourage people to reuse methods and interop better… I hope it’ll push implementers to use existing method rather than fulfill requirements to make high quality method..