This is the old homepage of the DID Working Group. It is not maintained anymore. The new homepage lives at https://www.w3.org/groups/wg/did/.

Decentralized Identifier Working Group — Minutes

Date: 2019-10-22

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Daniel Burnett, Manu Sporny, Ted Thibodeau Jr, Amy Guy, Dave Longley, David Trang, Markus Sabadello, Michael Jones, Dudley Collinson, Adrian Gropper, Kyle Den Hartog, Dmitri Zagidulin, Ganesh Annan, Drummond Reed

Regrets: Ivan Herman

Guests:

Chair: dan burnett

Scribe(s): Ted Thibodeau Jr, Amy Guy

Content:


1. Agenda Review, Introductions, Re-introductions

Michael Jones: potential agenda addition of new issue #85, related to issue #67 (key representation)

Michael Jones: #85 about differentiating between DID and application data is related to #67 - key representation

Grant Noble: technical writer in standards group at Pegasys within Consensys

2. New issue assignment process

Daniel Burnett: Editorial team has a good idea of interest in issues, so has been making initial issue assignments outside of calls
… using github systems. Assignment means “keep discussion moving” not “solve it” or other specifics.
… If things stall, reach out to Chairs or Editors, to get time scheduled on a concall.
… Participation is welcome whether you’re assigned or not; if you want to be assigned, you can request it.

Manu Sporny: https://github.com/w3c/did-spec/issues

Ted Thibodeau Jr: ( manu reviews issue raisers and assignees )

Drummond Reed: Another way to put it: if you raise an issue and you DON’T want it assigned to you, best to say that explicitly when you raise the issue.

3. FPWD

Daniel Burnett: https://github.com/w3c/did-spec/issues/68

Daniel Burnett: key points… No Working Draft is meant to imply consensus, and this is explicitly stated in the Status Of The Document.
… No group agreement is required for most WD publications. FPWD starts some IPR commitment clocks which are important to Rec Track.
… WG could agree that FPWD happens when Editors think it’s ready. WG could agree on a specific date for FPWD.

Michael Jones: thinks the chairs should decide whether FPWD is ready to publish

Daniel Burnett: sure. WG could also decide to publish today, with doc as-is.
… WG members are expected to speak up if Editors make changes that don’t seem to match group decisions, or seriously conflict with their own positions.

Manu Sporny: this doc has been “in process” for months/years, and all low-hanging fruit / easy issues have already been dealt with; the remaining issues are fairly meaty, and may take some time.
… opinion as editor is that doc could easily go out today

Amy Guy: +1 publishing soon, we can release new WDs when things change. FPWDs don’t need to be at all polished

Drummond Reed: today would be fine; end-of-month cutoff would also be fine.

Markus Sabadello: +1 agree with manu and drummond, we can publish now or very soon

Drummond Reed: +1 to giving us one week, then publish after next week’s call

Drummond Reed: I love it—Halloween Edition!

Daniel Burnett: let’s set a one-week deadline for raising anything that someone feels MUST be changed before FPWD
… objections?

Ted Thibodeau Jr: [ crickets ]

Drummond Reed: Let’s sneak in a Boris joke somewhere ;-)

4. Specification shortname

Daniel Burnett: https://github.com/w3c/did-spec/issues/76

Daniel Burnett: Please visit the issue and +1 or -1 on the options listed. These are non-binding, but helpful.

Daniel Buchner: It should though

Daniel Buchner: Much like shitcoin is now on the Congressional record, so too is Didy McDidface on official W3C WG minutes

5. Echidna publishing process

Daniel Burnett: Echidna is an automated tool that makes document publishing faster and easier for Chairs & Editors & W3 staff.
… Can be set up to do things (like publish a new Working Draft) upon given activity (e.g., every PR merge, or every day, or anytime designated people say so)

Manu Sporny: PRs go through stringent process, so live github preview is generally pretty solid. Echidna auto-publish on every PR, or daily, seems a good idea to avoid stall on drafts.

Manu Sporny: I’m fine w/ delaying up to 7 days… publishing every Sunday… but let’s please at least use Echidna.

Daniel Burnett: There are different camps on this, disagreeing on the optimal map between Editors’ Drafts, Working Drafts, etc.

Amy Guy: +1 rapidfire working drafts to minimise group time deciding

Drummond Reed: +1 to rhiaro

Ted Thibodeau Jr: +1 quick WD publication, on whatever basis…

Dave Longley: +1

Daniel Burnett: any objections to fast publications?

Manu Sporny: +1 quick WD publication … let Chairs/Staff/Editors decide on frequency….

Daniel Burnett: I did not ask for fast publication

Dave Longley: +1 for the editors to try something out and we’ll tweak it :)

Amy Guy: +1 letting editors try something and see how it goes

Daniel Burnett: I asked for the working group to let the editors start with a working mode they choose with team contact and chair approval and modify if necessary

Drummond Reed: +1

Manu Sporny: +1 to that!

Dave Longley: +1

Tobias Looker: +1

Ganesh Annan: +1

Grant Noble: +1

Resolution #1: WG will let the editors start with a working mode they choose with team contact and chair approval and modify if necessary

6. Key representation

Daniel Burnett: https://github.com/w3c/did-spec/issues/67

Manu Sporny: https://github.com/w3c/did-spec/issues/85

Manu Sporny: #85 gets into whether data is application data or DID data , or …

Michael Jones: logged #85 based on discussion with dlongley, that application data may be formatted however the app likes, while DID data should be formatted according to the standard(s) we set

Manu Sporny: #85 is a bit of a meta-discussion, which is hard to resolve in a concall, and will make it harder to resolve #67 which is fairly focused
… #85 is still important, just less tangible and harder to grasp

Markus Sabadello: there’s a separate issue for “data about the DID subject” vs “data about the DID document”: https://github.com/w3c/did-spec/issues/65. this is different from issue 85

Michael Jones: focusing on #67 for now is fine. hope is that folks will keep #85 in mind while doing so.

Manu Sporny: https://github.com/w3c/did-spec/issues/67#issuecomment-542480584

Manu Sporny: [ summarizes #67 ] …

Kyle Den Hartog: one concern is that data size will continue to grow, and that may pose a problem

Michael Jones: base* encoding does expand the size of things; that’s a valid concern.
… most important thing is raised as Requirement 11, about future proofing
… secondarily, JWK proponent (and author, so somewhat biased)

Dave Longley: regretful counter is that we have no control over formats used in the wild
… point of expressing your key is to let apps in the wild use your key, and many apps don’t consume JWK, so requiring that all keys are expressed in JWK imposes burden on apps now using openssl or nodejs or others
… would be fantastic if a single representation worked for all, but there are many tools already using multiple representations, so this is hard to force after-that-fact
… forcing JWK would slow adoption of DIDs and DID Methods

Drummond Reed: Mike, what’s your thoughts on Dave’s point?

Kyle Den Hartog: to clarify about size – it’s not about encoding; it’s about the characters required to express the base mathematics

Kyle Den Hartog: yeah, I can add them

Michael Jones: [ citation/example requested ]
… dlongley is right that any chosen format would require translation be implemented (once). idea is that once that translation is written, it’s done

Tobias Looker: DID resolver is going to be required in any case, let this handle the heavy lifting (the representation translation) for the app

Markus Sabadello: remember that we’re separating abstract content from concrete syntax

Manu Sporny: we’ll certainly talk about this again next time. the question is not “JWK or something-else”, it’s “something and JWK” – what is the something, that is capable of handling PEM or PEM in CBOR or ….?

Kyle Den Hartog: @manu thank you for that clarification. In that point, I’m less opinionated about this.

Daniel Burnett: Thanks all. Will continue this discussion next week

Dave Longley: options: 1. support ONLY JWK, 2. support JWK and other popular formats

Manu Sporny: question is whether to support only JWK, or JWK-plus-others

Manu Sporny: +1

Manu Sporny: That’s what the group has to decide.

Ted Thibodeau Jr: fifth time’s the charm!


7. Resolutions