DID WG Telco — Minutes

Date: 2020-09-15

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Ivan Herman, Justin Richer, Dmitri Zagidulin, Dave Longley, Brent Zundel, Chris Winczewski, James Qu, Markus Sabadello, Wayne Chang, Orie Steele, Jonathan Holt, David Ezell, Adrian Gropper, Eugeniu Rusu, Drummond Reed, Daniel Buchner, Kaliya Young, Manu Sporny, Phil Archer

Regrets: Amy Guy

Guests:

Chair: Daniel Burnett

Scribe(s): Dmitri Zagidulin

Content:

1. Agenda Review, Introductions, Re-introductions

Daniel Burnett: we have an interesting agenda today, a number of reminders, and then the typical Next Special Topic call reminder, then a discussion of Service Endpoints (explanation of what’s next)
… and then a recap of the CBOR and Registry conversation
… that is an important discussion to the group
… if time remains, we’ll go back to usual core issue status check
… do we have anyone joining us for the first time? doesn’t look like it
… anyone want anything else on the agenda?

2. Normative Statements homework reminder

Daniel Burnett: https://docs.google.com/spreadsheets/d/1oVFYZdK65C6f4ErF5zfoGv1c57M5Em75YKCtRdAF-yg/edit#gid=0

Daniel Burnett: this is a document sent out to the group
… in it, there’s a list of all of the normative statements in the DID spec
… in preparation for doing the test suite work
… please take a look at the list. Make sure the normative statements match your understanding. If something doesn’t strike you as right, suggest changes
… this is what will be required for your implementations.

3. Reminder WoT joint meeting poll

Daniel Burnett: next is a reminder - the Web of Things WG has requested to meet with us around TPAC time

Daniel Burnett: https://doodle.com/poll/b9hvv66nxqsfnbzc

Daniel Burnett: Brent put together a Doodle poll ^
… re normative statements list - that’s going to remain open for another week or so. So please do review it soon.
… with respect to WoT meeting poll - that’ll remain open till Thursday, and we’ll select a time to meet with them

4. Next special topic call

Daniel Burnett: next Special Topic call is going to be on Unknown Properties in did docs

Daniel Burnett: https://lists.w3.org/Archives/Public/public-did-wg/2020Sep/0014.html

Daniel Burnett: here’s a link to the relevant topic.
… it’s about Unknown Properties. I believe Markus has a slide to share with us…
… ah, maybe it’s just a reminder for unknown properties. It’ll make more sense to share it on the special topic call

5. Service Endpoints - next steps

Daniel Burnett: next item is : Service Endpoints
… I believe one of the Editors is going to lead this summary of where we are, and the next steps

Daniel Burnett: https://github.com/w3c/did-core/issues/382

Daniel Burnett: I’ll drop a link to the relevant issue. Who wants to handle this summary?

Drummond Reed: I will

Ivan Herman: See Minutes of the topic all on service endpoints

Drummond Reed: there has been an awful lot of discussion around this topic,
… and it doesn’t seem like it’s converging. Our goal of the Special Topic call is to say - ok, we have dramatically different points of view, and we have to decide what is going into DID Core, what will go into the Implementation Guide, extensions, etc.
… We had the topic call. There was a lot of discussion, but no consensus or convergence.
… We have to make a practical decision now, on what to do in DID Core.
… so, we had an earlier call, we had discussion, now let’s focus on what we can agree to do, with service endpoints.

Markus Sabadello: We’ve had a number of resolutions on Service Endpoints

Orie Steele: One point we might get clarity on would be the use of the registries for managing “service types”.

Markus Sabadello: Resolutions from last Topic Call on service endpoints: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-08-27-did-topic#res

Markus Sabadello: We wanted to model in a non-normative Appendix about service endpoints and privacy

Drummond Reed: we didn’t come to any conclusions, though. The proposals are fairly general.

Adrian Gropper: also, service endpoints are blocking the PING work

Drummond Reed: now, let’s have a call that focuses on the decisions / what goes where.

Daniel Burnett: reminder, this next call is Unknown Properties, not service endpoints (though we’ll talk about those again)
… that’s today, in just under 7 hours if I recall correctly
… editors, anything else about service endpoints?

Drummond Reed: no

6. Recap - CBOR and the Registry

Daniel Burnett: let’s move on to our topic of the day - CBOR and Registry
… I believe, Brent, you were going to take us through this

Ivan Herman: See Minutes of the topic call on CBOR

Brent Zundel: first recap of the meeting - there was very strong consensus around interest in a CBOR representation
… following that, the next 45 mins of discussion brought absolutely no consensus regarding which particular flavor of CBOR to include in the spec. or anything else.
… so, go ahead and queue up if anyone wants to add to brief recap
… not really intending to make it a massive discussion

Jonathan Holt: can I share screen?

Brent Zundel: is this about recap of meeting?

Jonathan Holt: yes

Brent Zundel: maybe what you want to present is not in recap, but in the next section (on next steps)

Jonathan Holt: one small point.
… (sharing screen to section 6.3 CBOR of did-core)
… (quotes from second sentence of that section)

Brent Zundel: the next steps that need to happen, in order for the CBOR representation to thrive, as part of the data model,
… is we need to come to consensus on the particular flavor we want to include
… that includes a stable normative specification for that flavor

Jonathan Holt: please clarify “flavor”

Brent Zundel: we need to have Translation to CBOR added to the registry for all existing properties
… we need to have clear guidance on how to add CBOR to the registry for all new properties
… and we need a clear specification in the DID Core, for producing and consuming CBOR,
… so that it can be losslessly converted to and from other specifications
… and this needs to be done by the end of September
… those are the next steps.
… are there any other steps that seem necessary, or other clarifications?

Jonathan Holt: the wording and constraints I made in the current CBOR section, was to get the semantic alignment with a core data model that can be converted to different representations, including JSON and JSON-LD
… the beauty of that is / the challenge we’re having is - the DID Document has a potentially mixed data type
… we have a potentially binary representation in CBOR, and then (potentially) hex encoding in JSON/JSON-LD. (encoding of binary fields?)
… encoding of public key material
… (my thoughts on this were interrupted by motorcycle accident this weekend! :( )
… (screenshare example. CBOR representation is 10-20% smaller than equivalent JSON repr.)
… the issue is really about the semantics of the properties in the core data model
… so that there’s clear semantic interop
… that’s what I attempted to do with the CBOR section. So that the representations can be translated, back and forth, including JSON to YAML , etc.
… I provided a sample algorithm (that provides an ordering to the properties, for translation)
… so, in short, there is lossless transformation between JSON <-> CBOR <-> YAML <-> JSON-LD
… we can have our cake and eat it too

Brent Zundel: thank you Jonathan!

Brent Zundel: Steps that need to be made:

Brent Zundel: 1. consensus around the flavor of CBOR to include in the spec

Brent Zundel: 2. stable normative reference to a spec for that flavor

Brent Zundel: 3. CBOR added to the registry for all existing properties

Brent Zundel: 4. Clear guidance on how to add CBOR to the registry for any new properties

Brent Zundel: 5. Clear specification in DID Core for producing and consuming CBOR such that it can be “losslessly converted” (via the abstract data model) to the other representations

Justin Richer: two quick things
… one, when we’re adding this section, please keep in mind that this is not a commercial for how great CBOR is.
… two, when dealing with property types, it’s my understanding that the group’s current direction is to define JSON/CBOR/etc encoding for each individual property
… I’d like to invite the group to define things in general data types
… such as - URIs, binary key material value, etc
… so, intermediate types
… which is the direction that I took with the JSON representation in the core doc

Drummond Reed: +1 to Justin’s suggestion

Justin Richer: more like “semantic types” more than “intermediate types” but yes

Ivan Herman: I’m not a CBOR expert. looking at the doc right now,
… the problem I have is - the separate section which is 6.3.3.1 on DAG-CBOR
… what is DAG-CBOR, where is it defined, is there a way to normatively refer to the spec?
… the rest of the CBOR section is no problem, but we have to be careful with linking to specs

Jonathan Holt: iana tag 42

Justin Richer: to be clear, my concerns are all very addressable :)

Brent Zundel: jonathan has linked us to the possible spec
… I have outlined 5 steps in the IRC notes,
… regarding what we need to do for CBOR to be a valid addition to our spec
… are there any feedback items, on those 5 steps?

Jonathan Holt: DAG-CBOR is basically CBOR, with the constraint that it’s just IANA tag 42

Brent Zundel: 1. consensus around the flavor of CBOR to include in the spec

Brent Zundel: 2. stable normative reference to a spec for that flavor

Brent Zundel: 3. CBOR added to the registry for all existing properties

Brent Zundel: 4. Clear guidance on how to add CBOR to the registry for any new properties

Brent Zundel: 5. Clear specification in DID Core for producing and consuming CBOR such that it can be “losslessly converted” (via the abstract data model) to the other representations

Jonathan Holt: with regard to the 5 steps – the clearest path for semantic interop is to make the registry of properties in the DID Registries is to have a symbol representing a concept
… the symbol is a Byte String, which can be represented in all the various representations
… (also incidentally, I’m supporting DAG-CBOR <-> JSON-LD interop, in that section)
… advanced topics in CBOR, and the kind of compression you get with CBOR-LD, I think that should be topic for later discussion

Drummond Reed: +1 to the five steps

Manu Sporny: I wanted to +1 the 5 steps from Brent
… those are fairly typical of anything that needs to go into the spec
… so, +1.

Justin Richer: in general, a +1 to the steps. I wanted to clarify that my second point about abstract property types is directly related to steps 3 & 4

Brent Zundel: I agree
… I’m hearing no alteration requests (to the steps)
… I’m going to make a proposal to the group

Proposed resolution: if all of these 5 steps are not done by the end of September, the CBOR representation will be removed from DID core and made its own note. (Brent Zundel)

Daniel Burnett: +1

Orie Steele: +1

Ivan Herman: +1

Dmitri Zagidulin: +1

Drummond Reed: +1

Dave Longley: +1

Markus Sabadello: +1

Phil Archer: +1

Manu Sporny: +0.8 – would rather state something about “Alternate Representations” in the spec, but that doesn’t preclude this item.

Adrian Gropper: +1

Jonathan Holt: can you clarify what ‘flavor’ of CBOR is?

Brent Zundel: DAG-CBOR vs CBOR-LD vs “vanilla CBOR” (conversion of JSON to CBOR without specific tags)

Phil Archer: I was thinking about the implications on your proposal
… my question is - does this mean that any implementation that uses DIDs now has to process CBOR? Or is support optional?

Brent Zundel: step 5 describes what a conforming producer or consumer of a CBOR representation must do
… so if a DID method chooses to be a producer or consumer of it, those are the reqs
… but there is no requirement for any DID method to do so

Phil Archer: do we know of 2 independent CBOR implementations, to get us out of CR?

Ivan Herman: if not, it’ll be taken out of document

Dmitri Zagidulin: One of the items we’re discussing is coming to consensus – what’s the mechanism for that consensus?

Justin Richer: Manu the spec should say more about defining representations anyway

Brent Zundel: the ideal mechanism is the same one outlined in our charter
… which is - someone raises a PR, and group approves
… alternate method is - somebody makes a proposal during a call, and group comes to resolution that way

Manu Sporny: justin_r, agreed.

Manu Sporny: it doesn’t say enough right now.

Brent Zundel: I’m seeing

Daniel Burnett: Phil, this is why step 1 is important. Without consensus on the flavor we cannot be sure there are implementations.

Resolution #1: if all of these 5 steps are not done by the end of September, the CBOR representation will be removed from DID core and made its own note.

Brent Zundel: no opposition to my proposal. Resolved.

Manu Sporny: justin_r – something like “Guidelines for Creating Representation Specifications”… or something roughly equivalent.

Brent Zundel: secondary proposal

Proposed resolution: If CBOR is removed, we will add an ‘additional representations’ section which includes: the efforts we made for a CBOR representation and our belief that such a representation would be very good for the DID ecosystem; that additional representations of the abstract data model could and should be specified, either in a separate specification, or in a future version of the DID Spec. (Brent Zundel)

Drummond Reed: +1

Ivan Herman: +1

Justin Richer: -1 we should have that section anyway

Dmitri Zagidulin: +1

Orie Steele: +1

Phil Archer: +1

Daniel Burnett: +1

Manu Sporny: +0.8 – we should have that section anyway.

Dave Longley: +1

Justin Richer: when I first wrote the text for the Representations section, that’s what I wanted to capture there (what’s in the proposal)
… this should not be contingent on what we do with CBOR, we should have this section anyway
… cause you never know when DID-PDF and DID-S-Expressions may strike

Drummond Reed: +1

Brent Zundel: manu has drafted an alternate version of the proposal

Orie Steele: +1

Drummond Reed: giant +1

Dmitri Zagidulin: +1

Manu Sporny: (forgot to put the proposal to the record. so those previous +1s are just acausal quantum pilot waves)

Drummond Reed: +1

Proposed resolution: Language should be added to the DID Core specification that provides guidelines to Representation specification writers. (Manu Sporny)

Orie Steele: +1

Ivan Herman: +1

Dmitri Zagidulin: +1

Drummond Reed: +1

Dave Longley: +1

Justin Richer: +1

Manu Sporny: +1

Phil Archer: +1

Adrian Gropper: +1

Markus Sabadello: +1

Daniel Burnett: +1

Brent Zundel: +1

Brent Zundel: seeing no opposition, resolved.

Resolution #2: Language should be added to the DID Core specification that provides guidelines to Representation specification writers.

Brent Zundel: that was everything I was hoping to cover, during this section!

Daniel Burnett: ok
… is there any other comments on this topic before we move on?

7. Core issue status check

Daniel Burnett: last topic for today, issue status check
… we’ll do something a little different.
… first - do the Editors have anything in particular they’d like to bring up?

Manu Sporny: in general, we’ve been hovering at around the same number of issues
… in some cases, it’s understandable (they’re hard issues), in other cases, just lack of PRs

Daniel Burnett: yes, we are at the magic “around 50”.

Daniel Burnett: Magic as in “groups get stuck here, and when you make progress past this point it means you’re about done”

Manu Sporny: so as a general comment, if you’re assigned an issue, we are definitely in the home stretch of having to get these resolved
… you don’t have to write the PR, but.. you should start considering it

Brent Zundel: +1

Manu Sporny: usually allocating 4 hrs during the week
… the failure case is, if we don’t do that, the issues will be closed due to no progress
… so, now is the time to submit PRs!

Wayne Chang: curious - how do I identify the most important issues to the community?
… aside from our usual ‘least recently updated’?

Brent Zundel: rather than concerning about what the community cares about, find what you care about

Drummond Reed: I like brent’s answer a lot
… as editors, we’ll start to curate issues

Ivan Herman: just reminder re W3C background. When we go to CR, most of these issues must be closed
… in other words, once in CR, no major tech changes to the spec, or else a more complex republication is to be done.

Wayne Chang: I do love Choose-Your-Own-Adventure, but my interest here is specifically getting the DID Spec out the door
… so my question is more - what are the blockers

Daniel Burnett: just to be clear, we don’t go to CR until we’ve addressed the issue
… what Manu is stating is – there will come a time when the remaining issues either need a PR or they’ll be closed
… and we’re almost at that stage
… so, if you care about something, now’s your last opportunity before the editors take action

Manu Sporny: +1 to that.
… regarding what are the blockers - we’re actually in a pretty good place
… for those of you who have gone through this process – the things that remain in the spec are not that contentious
… sure, there’s things like Service Endpoints and the CBOR stuff, but that pales in comparison with what other groups go through around this time
… so, there’s some significant language to change, but the group is demonstrating strong amount of cohesion
… so, the remaining issues - most of them are low-key, just need PRs
… so, people, roll up your sleeves and we’ll move into CR
… take a look at what’s happening in the Normative Statements spreadsheet
… take a look at the comments in the margin

Drummond Reed: +1 to doing the attempt on the PR.

Jonathan Holt: after reading this over the weekend / normative statements,
… there’s several I’m having a hard time with. What happened to the ‘proofs’ property, for example?
… it has disappeared off my radar

Manu Sporny: proofs were removed in a PR, by consensus
… folks didn’t feel like it was appropriate to have proof in the spec

Jonathan Holt: because there was no consensus?

Manu Sporny: I don’t think so. and anyway, that’s a perfectly reasonable method for removing something

Jonathan Holt: certain things about the data model surprised me

Manu Sporny: Jonathan - spec surprising you is good feedback (thorough review of the spec)
… we always need as many eyes as possible on the whole spec

Markus Sabadello: I also don’t remember exactly when proofs were removed,
… but I’m pretty sure it was in the context of metadata
… so proofs (and timestamps etc) are considered metadata, not data about the subject

Manu Sporny: Here’s where we removed Proofs – https://github.com/w3c/did-core/pull/305

Daniel Burnett: the reason I asked if the Editors wanted to highlight any issues
… I was going to offer for us to end early-ish
… so, everyone, go work on issues and PRs!

8. Resolutions