DID WG Topic Call on did spec registries — Minutes

Date: 2021-03-16

See also the Agenda and the IRC Log

Attendees

Present: Kelsey Rhoda, Orie Steele, Shigeya Suzuki, Charles Lehner, Brent Zundel, Juan Caballero, Adrian Gropper, Ted Thibodeau Jr., Manu Sporny

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Manu Sporny, Orie Steele

Content:

Brent Zundel: Welcome everyone, DID Special Topic Call – I will be chairing
… Rough agenda – DID Spec Registries – DID Method Registration
… Add yourselves to the queue – let’s get going.

1. DID Spec Registries

Orie Steele: Last time we talked, covered a couple of items… remove the schema requirements from registration process, talked about process of registering incredibly short DID Methods on first-come-first-served basis
… What we need to talk about today is the process of managing the registry entries and their conformance to the requirements as they are now.
… The requirements have changed, so we’re in the process where we need to clean up the registry and a clear list on meeting latest registration conformance requirements and people that have registered previously… that and registry governance are primary areas for discussion today.

Brent Zundel: Ok, primary topics – previously registered and registered w/ updated items – let’s jump into those topics - propose and agree to some resolutions.
… Recommendation to Orie – as Editor of NOTE, lay out how you’d like things to proceed as a proposal, and we’ll get feedback from the group.

Orie Steele: I will do my best – first proposal is that we establish a new category of registered DID Methods to correspond to meaning of latest registration requirements.
… We had talked about possible words before… some issues open

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 updated would 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

2. AOB

Brent Zundel: Anything else we want to cover today?
… We’ve been able to establish some common ground on a number of things.

Orie Steele: This is a special topic call, our resolutions are non-binding – need to run proposals by bigger WG.

Brent Zundel: If they were controversial things… informing the group that these resolutions happened and then letting group members see and object is the process… so, technically, no, we don’t need to run these again
… We should present these things on the calls.

Orie Steele: At some point, we do need to lasso out a few more folks to do reviews.

Brent Zundel: Ok, can get that on the agenda for the next call.

Juan Caballero: Yeehaw! Feel free to tag me for review on that github template

Brent Zundel: Do we need to redefine registration process itself?

Manu Sporny: I think we’re good with process in document.

Orie Steele: We need to remove stuff about schemas, might update process in future, the sooner we can get PRs in, the better.
… Worst case scenarios, the Editors will do it.

Juan Caballero: Thanks all! Sorry for text only

Orie Steele: thanks all!

Brent Zundel: Thanks for coming, participating, thanks Orie and Manu for scribing, looking forward to seeing all folks on call next week.
… We are official now, we are in Candidate Recommendation!

3. Resolutions