DID WG Telco — Minutes

Date: 2021-02-02

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Ivan Herman, Adrian Gropper, Ted Thibodeau Jr., Dave Longley, Brent Zundel, Shigeya Suzuki, Manu Sporny, Jonathan Holt, Joe Andrieu, Markus Sabadello, Amy Guy, Drummond Reed, Wayne Chang, Orie Steele, Justin Richer, Dmitri Zagidulin, Daniel Buchner

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Dave Longley

Content:

Amy Guy: may be irc only, network issues

Brent Zundel: We’ll start with agenda review. We’re going to remind everyone of the PR deadline and the special topic call. We’ll have a brief conversation about WG scope followed by a reminder about normative references in the spec and we’ll move what we expect to be a lively conversation about CBOR.
… As time permits we’ll talk about CR exit criteria.
… Anything to add to the agenda?

Manu Sporny: Somewhat on the fence, chair discretion if you want to pick this up, maybe talk a bit about the expectations over Feb and March and what the editors will try to be doing, what will happen at Feb 9th deadline, that kind of stuff.

Brent Zundel: I’ll incorporate that into the PR deadline topic and give you some time for that

Manu Sporny: Thanks.

Brent Zundel: We’re going to skip intros and reintros today. Next topic is PR deadline.

1. CR Timeline

Brent Zundel: We sent out an email (the chairs did) letting people know the PR deadline is Feb 9th.
… What this means is – any issues that are not addressed by PRs submitted by Feb 9th will need to be deferred to a future version of the spec. We’ve been working hard for a long time and if we want to actually produce a spec we have to move forward so that the process has time to complete.

Manu Sporny: Right, so the thing that we kind of want to make sure that the whole group is on board with. What the process is/expectations are. We expect all PRs in by Feb 9. At that point, that doesn’t mean all PRs have been committed, it means they are in. We will have a flurry of activity to get those PRs merged down. Dealing with objections, editorial things. Ideally they’d all be in by the 9th but there are always some last minute ones that come in overnight. During that week we will try to get them all in.

Manu Sporny: The week of the 9th, the editors and others will make multiple passes over the entire document and a huge flurry of activity, to make editorial passes, tightening up terminology, doing all of the last things we need to do before CR.
… There’s a request here from at least one editor, me, that we go into a mode of operation where we do 24 hr reviews. We will put all the PRs through the process, all expected to be editorial, if they do have to make normative changes it will be a 7 day period. But for editorial ones, we want to do 24 hr review cycles.
… These are editorial changes and we can always undo them because they are.
… Feb 9th hits, we get remaining PRs to get them in, then flurry of editors with editorial PRs with 24 hr review periods. Once that’s done, we hope the transition period goes through, the chairs/staff contact will handle that. Then a call thereafter.
… Any questions?

Justin Richer: Yeah, I agree with the sentiment that’s every thing that’s stated. I’m a little concerned about things being declared as editorial that make more than just editorial changes. There isn’t always agreement on equivalence of text. I know there’s one right now being discussed with that very nature.
… So I’m not sure what I’m asking of the group other than to be aware of that and try not to do that.

Manu Sporny: +1 to being aware of that and trying not to do it. It will happen. It’s the nature of this stage and when it does happen and people can ask for the change to be backed out. If any asserted editorial change is objected to as actually normative, people should object in the PR and the PR won’t go in. Even if it gets missed then the editors will default to backing out such changes if they have hit the spec.
… Hopefully that puts everyone’s minds at ease. That we won’t make any massive breaking change, etc.
… When we say “editorial change” that typically means it won’t change what implementers will do. Usually during the CR stage, we tend to say that a normative change that will – that will change an implementation.
… A substantive change is something that will change the implementations.
… We hear you Justin, we’re trying to do the right thing and stick to the aggressive schedule.

Justin Richer: +1 thank you, it’s not easy to balance a timeline like this with not surprising people

Brent Zundel: Thank you, Manu. We have full confidence in our editors and in their impartiality as they do editorial things. We recognize that everyone is human and look to the group that – no one will try to sneak things in or railroad, this is just the process and you can say “I’m not sure I agree with that” and we can continue the conversation.

Justin Richer: and +1 to a clear redress process

2. special topic call

Brent Zundel: Our special topic call is today at 6pm ET. The goal of the call is to provide folks with feedback on PRs. If you’re working on a PR or want to write one, this meeting is to give you feedback on PRs.
… Please come to the special topic call.

3. WG Scope

Brent Zundel: WG scope – the chairs met with our staff contact, had a very in depth conversation on our charter and what our scope entails. We would like to make the following statement: Defining canonicalization algorithms for any representation is outside of the scope of our WG charter.
… If you have a question about what that means we might be able to take it now, but we also have time set aside in the agenda in detail for something it definitely affects.

4. Normative References Reminder

Brent Zundel: All normative references in the DID core spec must point to a reference of equal standing. This is W3C policy. What this means is, while our spec is in the working draft stage, then it’s appropriate to point to other specs in a working draft stage. But once we move to CR and PR, those references, the standards to which those references point must be of equal or greater maturity standing.
… They need to essentially be W3C/IETF standards.
… If there’s a normative reference to something that is not going to be an equally (or greater) standard at the time we wish to publish, then that reference must be removed.
… Any questions on this topic?

Ted Thibodeau Jr.: CR -> CR would be acceptable … but timelines don’t usually line up that well

Daniel Burnett: TallTed, agreed. Equal or greater maturity

Drummond Reed: Do we know – I understand the blanket thing. Is there a specific reference that we need to address? Is that a general warning?

Brent Zundel: It is a reminder and it does affect CBOR or possibly affect DagCBOR which we’ll talk about next.

Daniel Buchner: “Thou shalt only point to other carved ivory artifacts of antiquity within the Ivory Tower”

5. Conversation about CBOR

Brent Zundel: To start off, the chairs have pushed from the beginning and hoped from the beginning that we’d have multiple representations. Once we had an ADM the chairs hoped to see JSON, JSON-LD, but also CBOR. We have been rooting from the sidelines hoping for it to proceed.
… We will need to see some changes to the CBOR section based on what was just highlighted and this is an opportunity to have this conversation. I’d much prefer that folks jump on the queue to talk about what they see as the ramifications of these determinations.

Manu Sporny: I’ve very interested to hear Jonathan’s thoughts on all this. The CBOR section currently has a section about canonicalization. My expectation is that based on the chairs and the staff finding that that part would come out, the canonicalization algorithm in the CBOR section. We could still refer to the things you should keep into account when defining a canonicalization algorithm by referencing the CBOR RFC.
… Now there would be potentially a PR to remove that canonicalization language. The other ramification would be for the DagCBOR section. We would need to reference something normatively that has clear canonical rules for DagCBOR or that section wouldn’t say anything about canonicalization.
… The discussion during the special topic call last week that if we moved DagCBOR into its own spec and registered it in the DID spec registries it would allow that spec to define canonicalization rules and continue to improve and mature at its own pace instead of being tightly coupled to DID core.
… Is that interpretation correct?

Jonathan Holt: I think there’s room for a compromise. It was my hope in the 4+ months that I wrote the section and I hoped it would mature and wanted it to be to a level we could point to normatively. The IPFS community is a bit slow to formalize – that’s the challenge. Despite my best efforts it didn’t happen in the timeframe expected.
… ipfs: is now a registered scheme, many users now have access to ipfs in the browser, which is a good thing.
… I think we reached a compromise to move the DagCBOR spec into its own spec and put it in the DID spec registries.

Manu Sporny: hoooray wrt. DagCBOR -> separate specification and put it in DID Spec Registries.

Jonathan Holt: My goal was to have a DAG data model in the spec and I think that would be worthy to be represented. The other compromise side of that is that there is normative language for the core deterministic requirements that’s in the new RFC 8949, which replaces RFC 7049. I’m arguing that the deterministic representation is important in our work and I was hoping to inherit those constraints.
… To the DagCBOR section. That was my attempt 4 months ago to have the text in the CBOR section, not the DagCBOR section.
… But I realize I wrote that text 4 months ago while recouping from a motorcycle accident on narcotics and it wasn’t perfect.
… Now we have core requirements.
… Just as we’ve been building an ADM if we have a canonical representation and that can live in RFC 8949 and the rest of CBOR can play out in other standards including the DID spec registries.

Orie Steele: I agree with the chairs. We should have nothing to do with canonicalization. I’d prefer to not have that discussion. I would propose we do the same thing that we’ve agreed to do with DagCBOR to also do with CBOR. Implementers haven’t had enough time to work with CBOR. There’s been even less contribution to CBOR than DagCBOR.
… It would be prudent to move CBOR to the DID spec registries and not commit the WG to production and consumption rules for something no one has done implementations for. I think we should defend CBOR from a sloppy rushed approach. The DID spec registries allow us to rapidly iterate and it’s necessary for those representations to survive and be useful.
… I think it’s dangerous to keep it in DID core when no one is doing anything with it. I propose both CBOR and DagCBOR move to other specs and be registered in the DID spec registries.

Orie Steele: I think did core should reserve the mime types for cbor, and point to the registry

Ivan Herman: My original only comment was that if we take out DagCBOR from the current document, we should publish it separately as a NOTE and don’t lose it. It’s not mature enough to become a recommendation but it may become one in a later iteration of the WG and we keep that up.
… I can’t comment on the technical content of the CBOR section. But to move the basic CBOR out of the spec because there haven’t been any implementations … moving it into a NOTE is a possibility. The fact of keeping CBOR in the doc is that it conveys a message that representations that are fairly different are also there and possible.
… Perhaps marking the CBOR at-risk would be a compromise to give it a chance.

Manu Sporny: Unfortunately, the CBOR thing isn’t different from JSON and JSON-LD – it’s a straight translation.

Orie Steele: CBOR as currently defined is 100% equivalent to JSON / JSON-LD … making it actually the opposite of what ivan wants.

Justin Richer: So I agree with Ivan’s statement of not only the messaging that inclusion of CBOR sends outside of the group, but as a reminder inside the group that we have always claimed to be creating a specification that could be represented in a number of different ways. I fully understand that a lot of implementers will only be doing a single representation themselves.
… That does not mean that we should only be defining one because abstraction from a single point leads to laziness and a brittle architecture.

Orie Steele: justin_r you know that CBOR representation is just CBOR(JSON) right now?

Justin Richer: I disagree with the statements in the chat just now that it was a direct translation. Then there would be zero argument to remove it. Because it would be a simple set of statements of “see this field do this”. I don’t have strong opinions with DagCBOR but the CBOR section can be included at the same level as the JSON/JSON-LD sections because the focus is getting things into and out of the representation.
… You’ve got the ADM and the representation and tell me how to go into/out of. Don’t tell me anything else. If it includes field order, great, those are serialization rules, if we stay in those lines I think we’ll be fine.

Markus Sabadello: +1 to justin_r

Orie Steele: justin_r you are not correct. the transformation through the ADM is equivalent to what manu is saying

Orie Steele: its not the only way to do it though

Manu Sporny: I put some proposals in the IRC channel to look at and modify before we potentially run them.
… I would prefer to move the CBOR section out as a NOTE at this point. I don’t feel very strongly about it. Just to highlight my statement in IRC. You can basically do CBOR by taking the JSON or JSON-LD and spinning it through a CBOR<=>JSON translator. It’s effectively the same thing. Yes, some of the binary encoding is different, but, in my opinion, it doesn’t utilize CBOR in a way I’d expect.
… It’s lossless, it goes to/from ADM and for those reasons I can go along with keeping it in the spec, but I’d be surprised if implementers would choose it as their CBOR encoding. I’d expect them to do something more compact, maybe doing artisinal CBOR or doing something more dynamic like CBOR-LD. I’d be surprised if people used the lazy conversation as the CBOR representation they prefer.
… That’s the strongest reason I think to move it out, it’s a bit of weird encoding. Also, I don’t know any implementers that plan on using it. I would love to hear from the group if there are any implementers excited to use it and “for reason X”.
… I’m happy to volunteer to take it out an put it in its own spec and it would be good to have an example of using the DID spec registries to register it.

Jonathan Holt: The entire point of going down the road with an ADM is to facilitate lossless translations to/from the ADM. CBOR is critical to that. As I showed, it’s a binary representation. So it’s a lot easier/more straightforward transformations into other formats. I think that’s the point to facilitate that.
… I don’t like the characterization of Vanilla CBOR or lazy CBOR.
… I think that’s unfair, when talking with Jim Schaad about the discussion around JSON/CBOR they settled on a compromise to ensure there’s lossless translations. I’m not opposed to the artisanal approach with ints as keys, and that’s a great use of the DID spec registries since all properties need to be registered there. If we register an int with each one that would be great.

Orie Steele: +1 to jonathan’s point regarding registering properties that cbor might make use of

Jonathan Holt: I would hate to see the section yanked because I spent so much time on it, I would use it, I can settle on CBOR since DagCBOR isn’t there. I think there’s another implementer [missed] as well. He’d leverage the CBOR section just as I am.

Daniel Burnett: Issue is not inviting others, it’s that they needed to be here 4 or more months ago.

Jonathan Holt: I was hoping to get the IPFS community involved in W3C and at least a few are considering becoming members. I think it would behoove the W3C to get IPFS to come to W3C to use as their standardization body. It would be great to have their things get under the W3C lab. They have keen interest in joining and they are trying to figure out what category they fall under for the size of their organization.
… I would hate to have them rally to participate in this discussion only to have a non-receptive ear when they join.

Markus Sabadello: I wanted to support Jonathan’s view that there was strong interest in having a CBOR representation. I also think that it’s important to have that to illustrate why we did the ADM. I agree with Jonathan on that. It’s in pretty good shape. My personal preference would be to keep that in DID core but remove DagCBOR.

Ivan Herman: +1 to markus_sabadello

Justin Richer: I think having maps with ints as keys – the production and consumption rules with the ADM allow translation into and out of a representation. If the CBOR community wants to and likes to do that, it’s a very clear message to other representations that you can call a property whatever you like in your serialization as long as you can get it in/out in a deterministic fashion.
… You aren’t bound to do just a lazy translation as has been claimed.

Markus Sabadello: For reference, notes from a Topic Call on CBOR last year: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-09-10-did-topic

Manu Sporny: Just to run a couple of proposals.

Proposed resolution: All canonicalization algorithms will be removed from, and no new canonicalization algorithms will be added to, the DID Core specification. (Manu Sporny)

Justin Richer: I would just like to see a list of what is considered a canonicalization algorithm because that could be a wider net than I’m interpreting that as.

Manu Sporny: There is specifically the CBOR canonicalization algorithm that is in the CBOR section right now. Presumably the DagCBOR canonicalization algorithm that exists outside of the spec and isn’t referenced but was planned to be pulled into the spec.
… Right now there’s only one, there were plans to be two, and the group is saying: We don’t want any.

Justin Richer: To be clear, I agree with the scope statement, I am worried about the interpretation

Daniel Burnett: It is the determination of the chairs, in consultation with the team contact, that defining a canonicalization algorithm is out of scope. This determination has already been made and your proposal just captures what will happen.

Jonathan Holt: I’m agreeing with Justin, there’s no algorithm. With a list of items – there are 5, they are constraints. To get to determinism. The only algorithm is sorting of the order of the map.
… In which case, ordered maps is the algorithm. That’s it.

Justin Richer: +1, I’m not seeing any algorithm here

Ivan Herman: As Dan said, “canonicalization is out of scope” is a fact, we don’t have to vote on this. We are over-administrating ourselves. We also had a proposal to take DagCBOR out of the spec into a NOTE. If that’s accepted, that makes part of this proposal moot. This is a bit of loss of time.
… We can discuss what to do with the CBOR section if we keep it in.

Jonathan Holt: I’m fine with moving dagCBOR as a note and would like to see it in did-spec-registries

Justin Richer: To echo what I said in the chat, I’m not seeing a canonicalization algorithm. I know Manu and Ivan have said they are dropping this specific proposal.

Jonathan Holt: +1 to justin_r ,

Justin Richer: I’m fine with that. I just read through the CBOR section and it gives you rules for producing CBOR, it’s not changing the data model at all. It’s no more canonicalization than saying each value of the JSON array is added in order. It’s telling you how to create the objects in the underlying representation.

Shigeya Suzuki: +1 to justin_r, too.

Justin Richer: +1 to markus_sabadello

Orie Steele: > “To produce a deterministic canonical CBOR representation of a DID document and facilitate maximal lossless compatibility with other core representations via the Abstract Data Model the following constraints of a CBOR…” from https://w3c.github.io/did-core/#production-1

Justin Richer: Orie: Right, remove the word “canonical”, the rest can stay

Markus Sabadello: I don’t think it’s a problem to remove the word “canonical” from the sections and then maybe everyone is happy. Regarding the one rule that says ordering the keys in the map – is that important or could that also be removed?

Jonathan Holt: It would be nice to have it in that format.
… For determinism it’s needed.
… Order matters just like order matters for a naked array, there’s meaning behind the order. In an infra ordered map, we’re agnostic but it could be important for the producer.

Proposed resolution: The DagCBOR representation will be moved into its own specification and registered in the DID Spec Registries. (Manu Sporny)

Orie Steele: +1

Dave Longley: +1

Justin Richer: +0

Ted Thibodeau Jr.: +1

Manu Sporny: +1

Brent Zundel: +1

Markus Sabadello: +1

Drummond Reed: +1

Shigeya Suzuki: +1

Amy Guy: +1

Jonathan Holt: 0

Daniel Burnett: +1

Ivan Herman: +1

Adrian Gropper: +0

Jonathan Holt: dag+cbor to the moon!

Resolution #1: The DagCBOR representation will be moved into its own specification and registered in the DID Spec Registries.

Manu Sporny: We do both proposals from both ways to see if there’s one that gets more support than the other, just because you -1/+1 one doesn’t mean you’ll do the same in reverse.

Proposed resolution: The CBOR representation will be moved into its own specification and registered in the DID Spec Registries. (Manu Sporny)

Orie Steele: +1

Manu Sporny: +1

Justin Richer: -1

Dave Longley: +1

Ivan Herman: -0.9

Jonathan Holt: -1

Ted Thibodeau Jr.: +1

Markus Sabadello: -1

Drummond Reed: -1

Adrian Gropper: -1

Brent Zundel: -1

Shigeya Suzuki: -1

Daniel Burnett: 0

Proposed resolution: The CBOR representation will be kept in the DID Core specification as an at-risk representation. (Manu Sporny)

Orie Steele: +1

Ivan Herman: +1

Manu Sporny: -0.5

Drummond Reed: +1

Shigeya Suzuki: +1

Markus Sabadello: +1

Dave Longley: +1

Adrian Gropper: +1

Brent Zundel: +1

Daniel Burnett: +1

Jonathan Holt: -1, what makes it at risk?

Ted Thibodeau Jr.: +0.5

Justin Richer: +0.5

Brent Zundel: We add the at-risk flag so that if circumstances require us to remove it from the spec during CR we don’t have to enter another CR phase.

Manu Sporny: No formal objection from me.

Brent Zundel: Jonathan will you formally object to marking it at-risk?

Ivan Herman: The only role of at-risk is to make sure we don’t get into trouble if we don’t have two interop implementations – if you are confident we’ll get to that it doesn’t matter.

Jonathan Holt: I will not formally object.

Resolution #2: The CBOR representation will be kept in the DID Core specification as an at-risk representation.

Daniel Burnett: And writing tests is also important to be able to keep a section in! For everything!

Ivan Herman: We say in the spec that infra doesn’t have an unordered structure that we need and we say in the spec we don’t care about the order.

Justin Richer: clarification: ordered maps, not lists

Justin Richer: lists are explicitly ordered in both places

Justin Richer: that’s a problem with the signing alg not the representation

Ivan Herman: +1 to justin_r, sorry

Jonathan Holt: +1 justin_r

Jonathan Holt: ordered set, not list

Orie Steele: https://infra.spec.whatwg.org/#sets

Brent Zundel: Thank you all for joining in the conversation and thanks to the scribe.

6. Resolutions