DID WG Telco — Minutes

Date: 2021-08-03

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Justin Richer, Charles Lehner, Brent Zundel, Drummond Reed, Amy Guy, Markus Sabadello, Manu Sporny, Adrian Gropper, Joe Andrieu, Ted Thibodeau Jr., Shigeya Suzuki

Regrets:

Guests:

Chair:

Scribe(s): Amy Guy

Content:

Brent Zundel: agenda review
… talk about the press release we’ve mentioned before
… spend time looking at DID rubric
… presenting it to the group and bringing a resolution to publish as a note
… spend the bulk of the meeting talking about draft for next DID WG charter
… as time permits we will spend some time with DID spec registries
… Any questions or anything to add or change?

1. Announcements

Brent Zundel: DID v 1 is now a PR
… All to ping your AC rep to vote on it
… (hopefully positively)

2. Content for a Press Release

Ivan Herman: See Example for a recent, similar press release

Ivan Herman: See Another Press Release example

Manu Sporny: usually when w3c creates a rec there’s some amount of press involved
… we spoke with some w3c management folks who were interested in seeing a bit more
… this means we need to 1) get in touch with Coralie, the communications director at w3c and let her know that we would like to coordinate on the press release
… typically in a press release what w3c tends to look for are statements of adoption
… good signs that the standard is being picked up by industry
… the larger the pickup and broader deployment better
… the ideal is to show large deployments, signals of deployments using the technology
… government quotes would be good for DIDs
… other things are industries, airline, healthcare, retail
… Those are the big quotes that we’re looking for

Drummond Reed: Industry association quotes, e.g., ToIP Foundation, Decentralized Identity Foundation, Linux Foundation

Manu Sporny: organisations or industries saying they are deploying it into pilot and production settings
… Second tier of support are large orgs or groups of organisations
… DIF, trust over IP foundation
… anything like that
… industry verticals
… member orgs saying they’re deploying it is also good
… The third tier, still important, are member companies themselves are saying it is helping them
… anything you can say about w3c and DIDs and how it’s helping your company is a good thing
… Markus found some good previous press releases, if you’re unsure about what quote to get you can get an idea
… When the press release goes out any of us that have contacts in the broader press ecosystem should try and work with them to do interviews and amplify the w3c press release
… government verticals do press releases, individual companies can do their own and time it with the w3c one
… we’re going to coordinate with Coralie, and ideally each of us is going to work with companies and orgs that we know to get quotes out of them that we can put in the w3c press release
… then we’re going to amplify the w3c press release

Ivan Herman: yes the testimonials are an integral part
… but somebody has to give text to Coralie with the core part of the press release
… I’ve put two recent examples from this year
… somebody must have the pen and I don’t know who that is
… we have to decide
… Also we have to realise that in the old days, when we were young and foolish, every w3c rec was accompanied by a press release. That’s gone, it’s unmanageable. We have to contact Coralie today because she has to plan for it, it’s not automatic at all
… probably Brent is best to do that
… and discuss details
… The schedule - what happens is that the goal is to publish the press release when the recommendation is published
… we can count the end of the PR is at the end of the month, 31 August
… we have to count two weeks to get the recommendation out provided there is no problem with the votes
… there might be small things, editorial things
… two weeks is secure
… means press release is about mid september
… however the press release must be translated
… to chinese, japanese, and french, the four languages of w3c
… and translating such a text is never easy
… we have to be prepared to review it
… usually the comms folks do the translation but looking at it is important
… I presume Shigeya can look at the japanese, I can look at the French, someone needs to look at the Chinese
… and translation takes time

Shigeya Suzuki: Sure.

Ivan Herman: don’t have to translate the testimonials, just the core text
… I would think that having the text ready from our point of view, the core parts ready, we should head for the third week of august, which is not far away
… whoever has the pen has to sit down and use it
… as for the testimonials, they can come in up to the last moment

Drummond Reed: you answered the questions
… Every time I’ve done this (frequently with different foundations) every company and executive needs to know what’s the deadline on the quote
… large companies want several weeks

Ivan Herman: I’d propose to set the quote date, knowing some will be late, to 5th Sept

Drummond Reed: sounds good

Brent Zundel: I can reach out to Coralie
… I’d like to talk to manu and get understanding of conversations already had
… Do we have a volunteer to write the text for the press release?

Manu Sporny: I’m happy to chat, and to help support, perhaps a google doc and people can jump in?
… might be overwhelming for someone to write by themselves, but there needs to be a clear lead

Drummond Reed: +1 to a Google doc. i will help with it too.

Manu Sporny: i can’t be the lead

Ivan Herman: ducks are in a row

3. DID Rubric

Brent Zundel: all of the pubrules checking has been done to create a static version of the rubric?

Joe Andrieu: no

Brent Zundel: what is our status?

Joe Andrieu: we thought we were there. We had that one bit with getting the citation correct took help from Ivan
… In reading it through we realized a bunch of the new criteria in security and privacy have placeholder text
… Daniel is working on getting a first pass at fixing that
… Some were example methods of did:foo etc
… cleaning up this week

Brent Zundel: assuming as those PRs come in we’d like review as soon as we can so we can get the first version of the note published?

Joe Andrieu: yes, still our next goal
… we have a number of other things still trying to get done around putting an option for turning it into a registry on the table for the group to consider
… first we’re going to get a publication
… PRs for that this week

Ivan Herman: What we have to account for is going to /TR/ takes at least a week
… I have to start the procedure to ask for a fpwd publication, get a green light etc, go through admin
… more complicated, we were ‘lucky’ yesterday but usually I don’t work Mondays so if it’s set on Tuesday it needs to all be ready by the friday before, or we settle on Thursday publication

Joe Andrieu: sounds good
… I’ll work with Daniel to get the PR in to address the did:foo kind of problems
… hopefully we’ll get to something we submit for consideration as TR. WG has to vote on that

Ivan Herman: exactly

Brent Zundel: as soon as there is a static version that can go to TR send the group that link for review
… so when we have a meeting we can vote
… to publish as a note

Joe Andrieu: what are the magic incantations to go from respec to static?

Manu Sporny: button on the top right
… then create a directory to put it in, with the date

Ivan Herman: be careful to set the date correctly
… and the publication type
… which is note-fpwd or something, see the respec manual

4. Next DID WG Charter

Brent Zundel: https://w3c.github.io/did-wg-charter/

Brent Zundel: charter repository: https://github.com/w3c/did-wg-charter

Brent Zundel: this is draft text for a proposed charter
… for the WG in maintenance mode
… Set right now to be a 2 year charter with maintenance of the DID spec, editorial changes are in scope and bug fixes are in scope
… the only substantive changes allowed are ‘class 3’ changes which are in response to a bug in the spec, a correction
… because we do not have text in the spec that allows for new features to be added, the maintenance wg cannot put that in scope
… other things in this proposed charter as in scope are
… maintenance of the registries, the rubric and the cbor representation notes
… and also in scope are any other notes that the group may wish to publish
… if the maintenance wg wants to publish an implementation guide that would be in scope
… everything out of scope is everything out of scope for this group plus any new features or substantive additions to the spec

Ivan Herman: for this one I have the pen
… I will need some input because I copy-pasted something from the old charter that may not be relevant any more
… in particular if you look at the section on coordination
… this is on coordination with other groups
… I copy-pasted
… the CCG is okay, the JSON-LD WG I shouldn’t have left there
… the web authn wg I don’t know if we want that
… or if we want with other groups
… and most importantly, for external organisations, we have to have some things there
… manu had a discussion on reaching out to the ietf group
… should be listed
… for section 4 I would really like to get PRs from somebody who is more in the community
… the other part, please get me PRs or issues
… the timing is relatively long
… complex admin of new charters
… we have to submit for review in the strategy team
… this charter is short and simple
… so don’t expect major things, but who knows
… in parallel to that I think it has to be submitted to the AC
… as a preview of a charter
… not as a something to vote
… Then it goes to vote
… I think the charter is usually two months
… I don’t think it can be significantly compressed
… which is end of september
… that’s our current date of the current charter running out
… bottom line, I would like to be positioned to get this to the strategy team at the end of this week or early next week
… they meet every Tuesday
… so by Tuesday with luck they can start their procedure
… so I’m aiming for asap

Manu Sporny: I can try to make a pass over coordination but might find it difficult this week
… The other thing I wanted to make sure I didn’t prevent us from working on is notes on did:key and did:web at a minimum
… right now it’s out of scope to work on specific did methods
… or protocols specs
… I think we should put did key and did web in scope
… for development as notes
… that’s the only thing that jumps out as we should really try and fix that

Drummond Reed: +1 for the maintenance group should be able to work on Notes

Ivan Herman: its good to have a resolution, but process wise the charter is the responsibility of the team. I’d prefer to go ahead if this week I get a green light
… I think the simplest thing is look at out of scope to see if things are still out of scope - there is one which says did method specs or protocols - I would be happy to remove that line but you should look and put it in an issue
… that was there in the original WG charter
… avoiding work which is recommendation track along these lines
… on the other hand the scope says you can produce any wg note as necessary
… so if this is not explicitly out of scope than a note on any did method should be okay
… I realise that the scope, and I got a comment from Dan, that the scope should make a very clear that what is in scope is class 3 changes only
… that would avoid a did method recommendation, but that is out of scope in any case
… is that okay?

Manu Sporny: I think so.. I’ll raise a PR

Joe Andrieu: curious about this mechanism of using a note this way

Justin Richer: +1 to JoeAndrieu

Joe Andrieu: I’m a fan of did:web and did:key and I’d love to see them move to standards. But a note isn’t normative. Shouldn’t we be getting them into standards track? Are we risking anything by publishing a note for something that should be a rec ultimately?

Ivan Herman: this WG decided to go for a maintenance WG
… this meant that we do a very short and quick thing that does not define new recommendations
… now the WG may decide to go beyond that but this charter becomes more complicated because we define rec track document
… which requires more information and background
… I’m not saying I don’t want to do the work, but I went along the lines of what the WG decided

Ted Thibodeau Jr.: on the same thread about a non normative note fo ra normative did method
… I don’t think that the w3c process wants things to go note and then to rec track?

Ivan Herman: that’s perfectly fine
… you define a note when the situation is not yet finished, when you don’t have implementation experience, when technically you are not sure it’s something to become a rec
… later if things are stable you can turn it into a rec, that’s fine

Ted Thibodeau Jr.: then I misread something

Justin Richer: +1 to TallTed

Ted Thibodeau Jr.: it still doesn’t feel right to be doing normative work going into a non-normative document

Manu Sporny: this is one mechanism that we have
… beyond incubation
… if you’re purely incubating something experimental, that’s what CGs do
… but did:key and did:web are beyond that, they’re being deployed
… people want to see this stuff ideally go to rec asap
… but they’re more than experiments, more than incubation

Joe Andrieu: +1 for did:key and did:web being more than incubation stage

Manu Sporny: but not to the place where we want to charter a wg to standardise it
… publishing a note is a perfectly reasonable way to say the wg is headed towards wanting to take this rec track
… without making it a huge lift to recharter the WG to work on those did methods just yet
… we’ve used this mechanism before and it’s worked well
… doesn’t lead to any kind of confusion

Markus Sabadello: I’m in favour of working on did:key and did:web as notes
… wonder if this is something that we want also for additional did methods, and for how many
… we’ve seen the number is growing
… it’s easy for did:key and did:web to argue for them
… but is this something we want for any did methods in future?
… to work on them as notes in the wg?
… could lead to a sense of having two classes of did methods, those done by the WG and those done outsides which may be percieved as less important or usable

Ivan Herman: if we did a WG rec for these two methods, what are the consequences for the whole landscape of did methods?
… I don’t know
… We may end up getting ourselves into a whole series of work on requests coming in to put loads of methods as recs
… I don’t know how many are out there
… double digits
… we have to be careful with what it means
… not sure that we would be prepared to do that long term
… that being said, if we decided to go for a recommendation then that means we have to have a clear way of saying how we would test them
… whole CR period as with the core spec etc
… it’s not just a different document type
… it’s much more than that
… we have seen what it means
… I would be careful about getting into recommendation with these methods right away
… one thing is I set the dates to two years because that’s the usual timing
… but we could without too much problem decide in a year if work is continuing on those two methods that yeah now we are feeling more confident and we want to recharter the wg to get these published to rec
… I think that would be probably more cautious but I would be more cautious about this

Manu Sporny: a simple answer for how we prevent everyone rushing to standardise did methods
… this is a decision the group has to make to work on it
… you need someone to do the work, some people to review
… the only reason I’m suggesting did:key and did:web is they’re broadly useful - not one company, one dlt, one community
… that’s the first thing
… if I were to suggest lets work on did veres one, I’d expect pushback. Understandably.
… the way we deal with each one is case by case

Ted Thibodeau Jr.: Maybe these DID method specs should be CCG Work Items?

Markus Sabadello: Agree, did:key and did:web are broadly useful and “neutral”..

Manu Sporny: right now we’re considering did:web and did:key. If something else comes up we’ll discuss as a wg

Brent Zundel: agree
… as chair of the vc maintenance group, if folks showed up saying they’d written this thing for the wg to review and wanted it published as a note and had done the work I’d be thrilled
… taking this case by case makes sense
… wouldn’t want wording in the charter that limits what we can publish
… all we’re proposing is getting rid of that single line in out of scope that says specific did method specs

Justin Richer: none of this matters because the core document explicitly says that reference to registered did methods and tying those to their defining specs is a non normative action
… the entire registry mechanism is non normative type of thing
… anyway so the only way any of this will ever work at all is if everybody just agrees that’s how it’s going to work anyway
… as much as I think that having a maintenance wg work on intended normative but actually non normative docs is a bad look, but functionally it doesn’t matter

Ivan Herman: +1 to justin_r

Brent Zundel: anything more on this topic?
… new w3c process talks about building and maintaining registries. Do we need something in the charter about that?

Manu Sporny: yes, doesn’t hurt to mention what we’re intending to do

Ivan Herman: not against it
… only problem is how to put it into the document when the process is still not existing
… but it will exist in a few weeks or months
… we can try
… will be handwaving
… “if the new process allows…”
… don’t know if that will fly with internal reviews
… Will I get a bunch of issues and PRs for everything i have to do?
… prefer that..

Brent Zundel: manu has volunteered to do a PR for coordination

Ivan Herman: a todo list in issues is good enough

Brent Zundel: i’ll raise an issue for the registries thing

5. DID Spec Registries

Brent Zundel: https://github.com/w3c/did-spec-registries/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc+-label%3Aneeds-contact-info+

5.1. Explanation on the DID Methods in the registries’ document (issue did-spec-registries#83)

See github issue did-spec-registries#83.

Brent Zundel: explanation on did methods in registries document, raised by ivan

Ivan Herman: more than a year ago
… the last comment is from orie saying i have tried to addressed, I acknowledged it.. seems like this issue should have been closed a long time ago

Manu Sporny: the PR, there was a massive permathread in it and it got closed, never went in

Ivan Herman: vaguely remember when I raised it registration of terms and methods and they looked different from one another but don’t know what happened since then

Brent Zundel: The PR that tried to address the issue was closed rather than merged

Manu Sporny: this was orie and markus going back and forth over normative language in did core…
… my expectation is something got into did core and it was potentially resolved

Markus Sabadello: I can’t check right now but will look later

5.2. Reformat table definitions in DID Spec Registries (issue did-spec-registries#160)

See github issue did-spec-registries#160.

Manu Sporny: this has not been done
… it should be

5.3. Can we add date added/deprecated or version added/deprecated to track addition of properties? (issue did-spec-registries#143)

See github issue did-spec-registries#143.

Brent Zundel: can we add date added / deprecated to track addition of properties
… raised by kyle, some conversation

Manu Sporny: we have an example of this for publicKey
… it wold probably be useful ot have something a bit more blinky to really warn that the thing has been deprecated
… and for ethereumAddress as well
… we should probably have some kind of marker beside the property
… that is the concrete thing

5.4. Management Process for DID Spec Registries after DID WG ends (issue did-spec-registries#149)

See github issue did-spec-registries#149.

Brent Zundel: management process after the WG ends..
… proposals, discussed, resolution
… anything more?

Manu Sporny: can close

Ivan Herman: charter text is along the line of this resolution

5.5. Spec required for resource parameter (issue did-spec-registries#244)

See github issue did-spec-registries#244.

Brent Zundel: spec required for resource parameter

Manu Sporny: we still don’t have a spec, there’s no normative definition, we need to leave this open

5.6. application/did+yaml needs specification URL (issue did-spec-registries#253)

See github issue did-spec-registries#253.

Brent Zundel: application/did+yaml needs a spec

Manu Sporny: we still don’t have one, and we should
… in general we should start removing things that don’t have spec URLs
… they were made at a time when people thought surely we’ll have a spec by the time the wg ends. But we’re at the end here.. we should set a deadline. If there’s no spec by the time the middle of sept rolls around we should remove these from the registries until a spec appears
… we can go through the process to register it then

Joe Andrieu: did we ever state that we need contact information for these entries?
… that should be a req if we’re going to filter out methods that don’t measure up because they don’t have a spec not being able to contact them is pretty important

Manu Sporny: it’s not a part of the process, it’s a good idea though

Joe Andrieu: how do we do that?

Brent Zundel: raise an issue to say in order for someone to register they need contact info

Joe Andrieu: we did that
… I think it didn’t get the attention of the group
… i’ll resurrect that

Manu Sporny: I’d suggest adding something to a PR that changes the first part of the registration process about humana readable description - with contact info for author
… be very explicit and say with an email address

Brent Zundel: I’d like to see that PR as well

Joe Andrieu: I’ll move that forward

Drummond Reed: +1

6. AOB

Brent Zundel: At time. Still quite a bit of work to do on registries
… now we have a proposed rec we’re going to be focussing more and more on this
… familiarise yourselves with the issues as things that need resolving come up
… raise PRs
… thanks for coming

Drummond Reed: Amy, you are awesome!