w3c
PROPOSAL: Define the DID Method Registration Requirements
A first proposal (from @brentzundel): in the DID Spec Registries document, keep one list (the current list) of DID methods where the entire list is labelled as "Provisional". Then, based on the requirements we agree upon, start a separate second list of DID methods that have met those requirements and therefore "graduated" from list 1 to list 2.
Suggestion # 1: +1 this comment if you agree with this basic design decision.
Suggestion # 2: let's separately discuss: a) what should be the requirements to "graduate" to the second list, and b) what should be the "status" values in the second list. (I'll make separate comments to start both of those discussions.)
Proposed requirements for a DID method to graduate from the "Provisional Registration" list to the "Formal Registration" list (see previous proposal). This is a strawman for getting ideas on the table.
- Self-certified conformance to the DID Core 1.0 requirements for a DID method specification. The DID spec editors suggest this be done via a Github issues template that is a checklist of the requirements from section 8 (Methods) of the spec.
- Assertion/confirmation of the URL (or DID) for the authoritative DID method specification and the contact method for the authors/governance authority. This solves the problem of the DID Spec Registries needing to maintain contact info for the DID method spec authors—it puts the burden on them to provide contact method(s) / feedback method(s) in their spec or spec repository.
- Self-asserted status value for the DID method specification listing. See separate proposal in this thread. This of course can change over time as a DID method spec progresses through the proposed statuses.
Proposed status values for Formal Registrations of DID method specifications. This is a strawman proposal for three progressive status values:
- Specification. There is a published DID method specification at a reasonably stable URL that meets the minimum requirements for a Formal Registration (listed above).
- Implementation. There is at least one testable implementation of the DID method specification available at a location specified either directly or indirectly by the DID method specification.
- Production. There is at least one implementation of the DID method specification and the associated verifiable data registry in production at a location specified either directly or indirectly by the DID method specification.
The issue was discussed in a meeting on 2021-03-16
List of resolutions:
- Resolution No. 1: change provisional to "Provisional. + YYYY-MM" so that date of registration can be used to sort
- Resolution No. 2: Update the registration table to include, status, first registered date, last reviewed date
- Resolution No. 3: create a new table for 1.0 conformant methods registered after the spec is published
View the transcript
1.1. Registration process requirements
See github issue did-spec-registries#266.
Orie Steele: Would like to drop some of these issues into meeting minutes
… Today we have term "PROVISIONAL"... what's beyond provisional?
Brent Zundel: Accepted? What goes after Provisional.
Juan Caballero: legit
Charles Lehner: Permanent?
Orie Steele: "Formal Registration" is the term drummond used
Juan Caballero: 2legit
Charles Lehner: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
Manu Sporny: we should talk about the next item... some of the proposals , like testable implementation... there is a perceived thing... we will be putting folks in a bad position....
… some of the language is problematic
… we need to avoid words that create arguments... we need objective criteria for registration
… -1 for the registry maintainers to determine "next status"
Juan Caballero: Conformant-v1 ?
Manu Sporny: smaller words for "confirms to registration 1.0" registration criteria.
… we need something that allows up to deprecate or move things to the bottom of the doc
… lets focus on one word for the next stage
Brent Zundel: What if we just say -- v1.0 as the label?
Manu Sporny: Who watches the watchers?
Brent Zundel: Maybe that means with each version of the DID Spec, DID Methods will need to come and re-register.
Orie Steele: We should motivate people to come and register...
… We could put DID Core TR v1.0 Conformant... instead of provisional... those DID Methods met registration requirements... those registration requirements can change after v1.0 changes...
… Tricky to figure out how to change this in a way that makes everyone happy.
Brent Zundel: +1 to the addition of a date when initially registered
Brent Zundel: or when last registered
Manu Sporny: What if we captured "last updated date"?
… For example, what if we say "the last time the registration was updated was March 2021"? Then we see things fall to the bottom of the list if they're not maintained... and it has the added upside of
… knowing that they passed the registration procedures as of X date, at least.
Brent Zundel: So question on that -- last updated instead of a label?
Orie Steele: We could do provisional as of YYYY-MM....
… We could come up with something later... PROVISIONAL as of YYYY-MM, that would give us a better indication of age, last time registered/reviewed.
Manu Sporny: I like the idea of keeping provisional and sorting by year month date....
… . and we can kick the can on "what comes next" after provisional
Brent Zundel: I like that -- I'd like it more if we could add language that says at any point, maintainers of registry may determine new labels -- provisional with date, but at any point, we can add new labels.
Manu Sporny: +1 to brent
Orie Steele: I don't know if we need to do to get what you're asking for Brent -- registry notes is that we can update this document over time, we could change registration requirements after WG is done, we can change status of provisional, we could do anything, which is dangerous... but we have a tremendous amount of opportunity about changes we could make.
… I don't think we need to set UID higher to privileges than we have... as long as there are enough people that are reviewing proposal changes, registry should be fine.
Brent Zundel: Under current registry setup, I think you're right.
… Formal W3C Registry process defined as part of process 2021 -- might stipulate things otherwise... I think you're right and we're probably good, trying to avoid what's happening with VC Maintenance work... because we didn't specify that we didn't say Maintenance group couldn't add new features... maintenance can't add new features.
Orie Steele: yeah, big +1 to what brent is saying
Manu Sporny: also agree w/ what brent is saying
Brent Zundel: Better safe than sorry and be clear about what we want.
… We could add to your proposal Orie, or add a new proposal
Proposed resolution: change provisional to "Provisional. + YYYY-MM" so that date of registration can be used to sort (Brent Zundel)
Manu Sporny: +1
Orie Steele: +1
Shigeya Suzuki: +1
Brent Zundel: +1
Juan Caballero: +1
Ted Thibodeau Jr.: +1
Resolution #1: change provisional to "Provisional. + YYYY-MM" so that date of registration can be used to sort
Orie Steele: Previously, Manu had mentioned that we could use git blame/praise to figure out when it was originally registered.... concerned about that... having an old date vs. newer date in here -- might be worth thinking out loud about an old date vs. newer date.
… If process of reviewing registry entry is stamp of approval for meeting latest conformance guidelines... if it's about your title to a really short DID Method string, first one is more valuable.
Ted Thibodeau Jr.: Might be better to keep the date out of the "status" and put it somewhere else in the registration of whatever...
Orie Steele: Worth remembering that registration guidelines can change, so if we backdate all of registered entries, we'll backdate to time when it was registered, w/o guidelines we have today -- might make all starting dates today, let them go stale by themselves.
Manu Sporny: what are we trying to do with the registry? we want to see what other have done, it would be nice to see features and health... but thats probably another things job
… the main problem we are trying to solve is staleness
… we don't have contact info for registered methods... some websites are stale / down.... how will we deprecate... etc...
… we don't want registry to be filled with dead stuff
… we should stay away from indicators other than this is fresh / old.... even that gives hints we may not want.
… what problem are we trying to solve?
… we need too push stale stuff to the bottom
… git blame is easy... but we did restructurings...
… -.5 to starting as today... and trying to do an older date
… we need to set a date for CR....
… something far in the past
Ted Thibodeau Jr.: untouched for years doesn't necessarily mean dead... e.g., my business email hasn't changed in 20 years
but squatting remains an issue. failure to contact seems a justification for de-provisionalizing
Orie Steele: When the thing was registered is not an indication of if it's alive or not... best effort of first registration date -- seems like a piece of information that's useful.
… People have said... let's not overload the PROVISIONAL thing... let's just do a registration date -- best effort first registration date... do we want to go beyond that -- best effort most recently updated date.
… That would be something like -- I've registered many DID Methods, maybe I update the spec for them, then ask for another review to make sure latest spec meets conformance requirements... old date for when I registered, then new date for when latest conformance was done.
Manu Sporny: +1 to what Orie just said.
Orie Steele: I think we get the best of both worlds there... staleness vs. very reliable DID Methods registered years ago -- you'll be biased against those entries for most recently updated
Manu Sporny: +1 for two dates
Charles Lehner: Has https://tools.ietf.org/html/rfc7595 "URI Scheme Guidelines" been considered for research and/or inspiration? It includes for Provisional, Historical and Permanent status
Ted Thibodeau Jr.:
last updatedwould let users retrieve new details to replace the old details they had "on file", but what does it mean? contact details of maintainer/registered "owner", vs something material in the method or whatever, vs ???
Orie Steele: First registered date, then last updated date.
Brent Zundel: I wonder if it'd be worthwhile for a new table for new DID Methods registered after the spec becomes a spec... vs. from some time before.
Brent Zundel: This would replace the last proposal -- any changes to language?
… What is the definition of last reviewed?
Ted Thibodeau Jr.: will need clear definition of "last reviewed"
Orie Steele: The process that I follow to review -- look at DID Method registration... look at DID Syntax, supported DID Operations, defines privacy/security -- if it has any reasonable entries, I have to approve it.
… In order to update, date change, review spec, update date -- that's part of the normal process.
Ted Thibodeau Jr.: If I'm registering a thing, and the registration is a pointer to an external place, I'm not going to have any real incentive to change XYZ unless there is some benefit that I get from it -- or non-benefit from not getting it.
Orie Steele: certs expire, we could make did method registration expire too :)
Ted Thibodeau Jr.: For example, a domain name -- first registered 20 years ago doesn't give you much... maybe some cache, first registration, what's the incentive... disincentive of not touching things for a period of time...
Orie Steele: yeah, I agree there will be an incentive to touch your spec regularly
Manu Sporny: we need a graveyard... for things not updated within 5 years, etc...
… people should assume things will get moved to the graveyard
… we need to give editors the ability to interpret the registry....
… maybe the graveyard needs to only support methods
… how do we move things into a category of deprecated
Orie Steele: TallTed would love a proposal form you :)
Orie Steele: we need help :)
Ted Thibodeau Jr.: Here be dragons -- how do we know if people are using things?
Orie Steele: yeah, I agree this is tough
Shigeya Suzuki: I agree with Ted, this is a big issue -- wonder if it's possible to at least -- know if part of spec maintained by someone -- if Apple is trying to make things and not touch the spec, they're fine with it, we may want to know who is maintaining the registered spec... static but maintained.
… We want to know if someone is maintaining the registry -- and if it has no maintainers, it's moved to the graveyard.
Manu Sporny: +1 to what others have said... maybe there is a simple keep alive....
… some automation system for keeping the spec status updated?
… we would need automation...
Ted Thibodeau Jr.: registry maintainer has to ping (email, phone, https URI, ?) the person/company/whatever that registered the whatever every n months? potentially hefty burden on multiple sides
Shigeya Suzuki: Need a definition of "maintaining" but it may include maintenance of documents external to registry.
Orie Steele: Back to the original proposal of two dates and a status -- there is an incentive to update, but that can be managed by people... Editors can ignore people that abuse the process.
… I'm less worried about people gaming the system... I'm more worried about a simple systems that anyone can take over and manage... two dates and a status are about as simple as you get... if we add 1.0 table to the mix, we've got everything... in absence of a better proposal, let's work toward that.
Brent Zundel: no one on the queue, I agree with Orie, avoiding complexity is good.
Ted Thibodeau Jr.: I'm clear enough on it... needs to be written up clearly.
Proposed resolution: Update the registration table to include, status, first registered date, last reviewed date (Brent Zundel)
Orie Steele: +1
Manu Sporny: +1
Charles Lehner: +1
Brent Zundel: +1
Shigeya Suzuki: +1
Ted Thibodeau Jr.: +0.5 I'm still concerned about potential burdens, but won't block
Resolution #2: Update the registration table to include, status, first registered date, last reviewed date
Proposed resolution: create a new table for 1.0 conformant table for methods registered after spec is published (Brent Zundel)
Manu Sporny: +1
Shigeya Suzuki: +1
Proposed resolution: create a new table for 1.0 conformant methods registered after the spec is published (Brent Zundel)
Orie Steele: +1
Shigeya Suzuki: +1
Manu Sporny:
Brent Zundel: +1
Manu Sporny: +1
Ted Thibodeau Jr.: +1
Charles Lehner: +1
Resolution #3: create a new table for 1.0 conformant methods registered after the spec is published
Juan Caballero: And move all pre-registered methods to the new table if they re-register
Juan Caballero: Just to be explicit :)
Orie Steele: yep
Manu Sporny: we should use the checklist for 1.0 and only create that new table once we have an easy process
Brent Zundel: +1 to having a template for DID Method registration
Juan Caballero: Is ccing the ccg list recommended or required to get extra eyes on it ?
Manu Sporny: we need an issue / template for the PR, etc...
Brent Zundel: I don't think it would hurt
Juan Caballero: I guess lots of people watch that repo
Brent Zundel: Depends on how maintenance of registries is set up
Manu Sporny: concerned about too much noise...
Juan Caballero: Fair fair! Was just asking. And +1 to github template
Manu Sporny: there are fairly basic issues with most registrations
Juan Caballero: Did:tk
Orie Steele: We need to have this conversation with larger people -- basic stuff that editors of registry are doing, great to have pool of 10 people and only need 2 people ....
… Big +1 for simple template checklist, registry editors can't be responsible to make sure you put sentences in the right places, not going to scale beyond that -- larger pool of people being able to do it is critical... 2 people doing it is not going to give you same kind of review as 10 people... that one person that says "no, you need to do more" -- having extra eyes reviewing things is good. Don't think having that from CCG list... but we
Manu Sporny: could have CODEOWNERS in there, bigger list, rotate people out that don't do work.
Ted Thibodeau Jr.: -1 to CCs to CCG or any similar list. a role address that bursts to all maintainers of the registry might be useful; probably better to be a ticketing system because 7 people reviewing every registration isn't going to be good, while splitting work over 7 people (or 3 teams of 2, or the like) would be a bonus
Proposed status values for Formal Registrations of DID method specifications. This is a strawman proposal for three progressive status values:
1. **Specification.** There is a published DID method specification at a reasonably stable URL that meets the minimum requirements for a Formal Registration ([listed above](https://github.com/w3c/did-spec-registries/issues/266#issuecomment-797170199)). 2. **Implementation.** There is at least one testable implementation of the DID method specification available at a location specified either directly or indirectly by the DID method specification. 3. **Production.** There is at least one implementation of the DID method specification and the associated verifiable data registry in production at a location specified either directly or indirectly by the DID method specification.
I like the idea that of defining a few statuses like this. Ideally I'd like to continue with saying 2 testable implementations to move to production to remain in line with the WG definition if possible. I think it's fine for something to remain in implementation status until we get 2 in production. The main reason I'm thinking about this because having an implementation in production is different than having interoperable code and ultimately what we want is to end up with interoperable in my opinion. I think it's more concerning to over state that a method in production and then have a second implementation come in and cause breaking changes on the original implementation because not enough eyes were on that first implementation and some bugs were found.
Having this boundary may help us to prevent the common complaint of the ever-growing list of did methods. Thoughts on that slight modification @talltree ?
@kdenhartog I think that's a great idea. Here is an amended list of proposed statuses:
- Specification. There is a published DID method specification at a reasonably stable URL that meets the minimum requirements for a Formal Registration (listed above).
- Implementation. There is at least one testable implementation of the DID method specification available at a location specified either directly or indirectly by the DID method specification.
- Production. There are at least two independent implementations of the DID method specification that interoperate with the associated verifiable data registry in production whose code exists at a location specified either directly or indirectly by the DID method specification.
Please +1 (or thumbs up) if you agree with this list.
@kdenhartog - There are several missing words, and maybe other issues, in your latest comment on this issue (#266). It's difficult to understand what you've written, with these errors in place. Please review your comment and correct the textual errors, so we can better understand what you're saying.
here is an amended list of proposed statuses
I'm concerned about the burden this places on the reviewers. There might be something we can do here wrt. "SPECIFICATION EXISTS" and "IMPLEMENTATION EXISTS"... it gets dicey going beyond that.
here is an amended list of proposed statuses
I'm concerned about the burden this places on the reviewers. There might be something we can do here wrt. "SPECIFICATION EXISTS" and "IMPLEMENTATION EXISTS"... it gets dicey going beyond that.
I've been convinced that the burden on editors/reviewers here would probably end up a bit too high from what @talltree and I originally we're considering. Thinking about how we can ease the burden on editors/reviewers, I'm thinking having a standard template of questions that the registeree has to fill out would be helpful as a part of registration. In order to get the implemented status, the registeree would need to submit a link to a test suite report in that template, or in a follow up template to change the status.
feels like:
editor can see evidence that thing exists is about has prescriptive as we can get.
The issue was discussed in a meeting on 2021-03-30
- no resolutions were taken
View the transcript
3. DID Method Implementations
See github issue did-spec-registries#266.
Brent Zundel: We are nearly ready for DID Method implementors to submit their DID method implementations to the test suite.
… We are not yet ready. So this is a call for DID Method implementations to be prepared: be ready. Very very soon the test suite will be ready.
… Not quite ready yet, so don't submit yet.
… Any quesitons, comments?
Kyle Den Hartog: 2+ for production-ready status - are we in alignment with that in the group?
Brent Zundel: Can you clarify?
Kyle Den Hartog: When we were discussing what are the requirements for different levels - provisional, implementation, production. impl requires only one, but Production requires 2+ independent.
… is what we were thinking
Brent Zundel: Excellent question. Assuming on thread ... in DID Spec Registries?
Markus Sabadello: I don't understand the question. Said to require 2+ implementations of a feature in the DID Core specification, but what does this have to do with Provisional status
Kyle Den Hartog: For reference looking at this issue: https://github.com/w3c/did-spec-registries/issues/266
Manu Sporny: I think you are talking about the did-spec-registries, the Provisional field
… Drummond and Kyle you are proposing we have different words other then provision? Specification, Implementation and Production. That is the proposal?
Kyle Den Hartog: Yeah. Happy to bikeshed the names as well.
Manu Sporny: Not concerned with names but with having the editors have to go out and verify the implementation. Hard enough working on the registry without making a determination on 85 DID methods
… having arguments about what an implementation is.
… "I've got two implementations: my brother and I did one"
… I am wondering if we could go the other way, and remove that field altogether
… I am hesitant about the classifications putting burdens on the people in registry. Would like to hear from Orie
Orie Steele: I agree with the concerns. Registry needs more people in the pool to do these reviews.
… Need to make requirements clear for the reviewers. Not obviously wrong -> Approve.
… Have to be careful about making the burden for registration too high. Need to make it easy.
… I agree with what you are saying, manu. I don't know if the proposal can be beaten into a shape where the pull request template would be enough.
Kyle Den Hartog: I understand your concerns, think they make sense.
… I probably wouldn't go sa far as to say let's completely remove it
… but was thinking what if... when you submit the original spec, we have some sort of template
… where as part of that template, if you have a registered test suite connected with that method, and the test results come back positive, we could change it to "tested". Have effectively two statuses ...
… Concerned we have a bunch of DID methods I've never seen code for.
Brent Zundel: would like to continue. Best place in issues.
Manu Sporny: Agree we should continue to discuss this.
Kyle Den Hartog: +1 thanks, let's discuss over there. Thanks for taking a look at it