DID WG Telco — Minutes

Date: 2020-09-22

See also the Agenda and the IRC Log


Present: Markus Sabadello, Wayne Chang, Amy Guy, Justin Richer, Brent Zundel, Orie Steele, Jonathan Holt, Drummond Reed, Dave Longley, Tobias Looker, Kyle Den Hartog, Kaliya Young, Manu Sporny, Pamela Dingle, Daniel Buchner, Adrian Gropper, Daniel Burnett



Chair: brent zundel, Brent Zundel

Scribe(s): Drummond Reed, Kyle Den Hartog


Brent Zundel: we’ll start with agenda review and intros
… we’ll briefly talk about our Web of Things special meeting
… then a discussion about the abstract data model type system…
… and then issues
… please type present+ when you join IRC…
… and q+ for queuing, with q+ to “text” for a reminder of your topic

Kyle Den Hartog: In New Zealand, working for Mattr, working on decentralized identity…
… and favorite food is STILL Taco Bell

Kaliya Young: do they have taco bell in NZ

Daniel Buchner: In NZ, I hear Taco Bell changed their slogan to “Swim for the border”

Brent Zundel: we will have a joint meeting with Web of Trust at our regular time on 13th October
… next special topic call Thursday

1. abstract data model system

Manu Sporny: https://docs.google.com/presentation/d/1mb46JM7vgItg84Ucn3xUt021x3e9Te2lqUwZ-4OYk2w/edit

Manu Sporny: including link into IRC
… We wanted to review did-core type system and the related issues to it
… part of this is a rehash of what we have right now and the rest is the remaining issues
… What do we have today. Today we have an abstract data model using INFRA
… This is used by W3C to describe data types in abstract data models
… Basically supports all the types we’ve needed to represent in this WG
… INFRA doesn’t support numbers though
… This has led to some issues in the WG as of today
… Is also silent on unknown properties
… Those are really the two issues left. We don’t support numbers because INFRA leaves them undefined and we can’t represent unknown properties
… Everything we want to representable using INFRA as base model and then layer additional things on top
… people seem to be more or less ok with this today
… There is an issue (click first link in slide 3)
… that discusses use of Numbers in INFRA
… There won’t be a definition of number before we’re done though.
… We can define number as a Real Number, in the mathematical sense
… Implementations SHOULD limit ranges for interoperability
… specify ranges for integers and IEEE 754 floats
… Suggestions for unknown properties found here: https://docs.google.com/presentation/d/1mb46JM7vgItg84Ucn3xUt021x3e9Te2lqUwZ-4OYk2w/edit#slide=id.g99f34da178_0_13
… We can also say if you can’t convert to and from the INFRA model (such as a 64 bit int) then you should throw an error
… another thing we can do is push this onto did methods
… That’s it thoughts concerns?

Orie Steele: https://github.com/microsoft/api-guidelines/blob/vNext/Guidelines.md#61-ignore-rule

Orie Steele: “For loosely coupled clients where the exact shape of the data is not known before the call, if the server returns something the client wasn’t expecting, the client MUST safely ignore it.”

Justin Richer: Orie: that’s the root of the question though – does “ignore” mean “preserve” or “drop”?

Justin Richer: Orie: that was the root of the question in issue 205

Orie Steele: justin_r i hope that ignore means “preserve”

Orie Steele: i like json

Justin Richer: Orie: “hope” is not good spec language…

Dave Longley: reminder that I-JSON exists: https://tools.ietf.org/html/rfc7493

Markus Sabadello: This is interesting. 1 comment first. You mentioned we’d probably want to define what a number means. We’ll likely also want to do that for datetime.
… I did that in my PR for consistency of language. I don’t think we should assume a specific format of a datetime

Justin Richer: +1 the abstract data model shouldn’t do “datetime” as a formatted string when it can be a data type

Markus Sabadello: so we likely need to do the same thing for datetime

Jonathan Holt: We ran into this when doing the CBOR section
… I at first was fine with INFRA. It’s kind of a loose constraints. I’d prefer that we constrain possible representations and allows for better cross representations
… I’ve been working a lot with CDDL and that’s worked well with JSON and CBOR

Drummond Reed: Manu mentioned that an option to allow did methods to change representations. I’ve been discussing this lately and I don’t believe they should not change the representations to allow for better cross representations

Orie Steele: I’m hopeful that by clarifying the core data model that will help us to better understand how dates and numbers will be represented

Manu Sporny: to markus your point on datetime we could specify a datetime as a different type, but everyone seems happy with XMLDatetime
… it’s a choice that we can take, but it’s not clear what defining a type for would be for

Brent Zundel: xml datetime or https://tools.ietf.org/html/rfc3339 ? or are those the same?

Manu Sporny: for Drummond, it wouldn’t be about allowing DID methods to chose their types, but rather they can chose if they want to exclude types
… or want to keep. This would allow us to preserve as much at the core layer while keeping the methods to defining the security model

Drummond Reed: That helps quite a bit and make sense. I’m more trying to have us get more precise about the question Orie brought up. If we have a sufficient data type system to describe how to go in and out of the data model
… then we don’t have an unknown property problem if we define all the possible types

Justin Richer: it’s clear that we need more data types then what INFRA offers.
… we have string but it’s more than a string it’s a URI

Orie Steele: if we are not going to use infra, I propose we just use JSON.

Justin Richer: I’d rather define our data model with actual types like datatime and uri
… these are things that can be represented in multiple representations and programming languages

Orie Steele: lets create our own type system, so we can represent datetimes.

Justin Richer: this way if I have a datetime object then how do we put it in the representation
… representations then need to define how to fit every type in the did document

Drummond Reed: +1 to representations needing to define how they serialize every abstract data type defined in the ADM. This will give us the precision we are looking for and take care of the issue of “unknown types”.

Manu Sporny: +1 to what Justin just said wrt. sanitization.

Justin Richer: also quick note on data sanitization. It’s unclear if data sanitization would happen after consumption or before production
… I think we need to be much more clear about things like that
… since representations affect the sanitization that leaves me confused how we “properly” without thinking about the sanitization without knowing the representation
… on the production side I’m unconvinced that we can do anything with regards to sanitization
… I think we can do it on the consumption side though

Orie Steele: you cannot sanitize an abstract data model

Orie Steele: To respond to Justin, I’m having a hard time understanding what sanitization is in a abstract data model.

Drummond Reed: “sanitization” takes place before you go into the ADM or once you go out of the ADM

Drummond Reed: touche

Justin Richer: I think this is a rabbit hole because this isn’t the kind of sanitization that I was talking about

Drummond Reed: @justin, you might want to clarify that’s not what you meant by “sanitization”

Manu Sporny: I wanted to get feedback from the group to get consensus. It’s suggested that we throw INFRA out. We picked it for a reason. I want to make sure the WG doesn’t have something else that’s workable as well.

Orie Steele: +1 to throwing infra out :) we already don’t support CBOR…. we should support CBOR properly when we can… until then, we should DO JSON right!

Manu Sporny: a few options build ontop of INFRA, define our own, etc
… 2 questions: Is there a serious question to move away from INFRA please make the proposal

Drummond Reed: URI

Manu Sporny: I want to see if there’s anything other than datetime and number that we need to define

Brent Zundel: yes we’ll handle this at the end

Justin Richer: There’s a lot of byte set values that we need to be clear about how they’re used
… my suggestion is we build on top of INFRA but then we define all of the abstract data types in addition
… e.g. datetime would be just like what we would have to do with numbers
… then it’s up to the representations to define how to take all the types and translate that into the defined representations

Drummond Reed: Justin stole all my best lines ;-)

Justin Richer: I should be able to create a brand new representations by looking at all the types defined and if I can represent all of them then it should work

Jonathan Holt: To respond to manu it’s not mutually exclusive that what’s represented in JSON can be represented in CBOR
… I’ve been impressed with CDDL
… What I think is lacking is that we have a concept but not the required properties types

Drummond Reed: I’d like to see the proposal that Justin just said and then representations could say what types we need

Drummond Reed: +1 to making sure the representation production rules and consumption rules cover conversion of property names as well as values

Justin Richer: I wanted to point out this more then representation values but also representation property names. Eg. with CBOR when I see a specific property name then I can recognize those CBOR tags

Proposed resolution: The Abstract Data Model will support ONLY JSON types, and will use JSON for the Abstract Data Model for this version of the spec. (Manu Sporny)

Orie Steele: +1

Manu Sporny: -1

Drummond Reed: -1

Justin Richer: -1

Dave Longley: -1

Jonathan Holt: -1

Brent Zundel: -1

Markus Sabadello: -1

Tobias Looker: -1

Kyle Den Hartog: -1

Proposed resolution: The Abstract Data Model will use INFRA it’s base and will add additional types on top of INFRA. (Manu Sporny)

Orie Steele: -1

Drummond Reed: +1

Manu Sporny: +1

Jonathan Holt: -1

Justin Richer: +1

Amy Guy: +1

Brent Zundel: +1

Kyle Den Hartog: +1

Dave Longley: +1

Tobias Looker: +1

Markus Sabadello: +1

Jonathan Holt: I think I’m ok with JSON, but I’m not impressed with INFRA
… I’d suggest everyone take a look at CDDL

Justin Richer: I would be ok with “json as a base” for the data structure types but it would need to be extended too

Orie Steele: My main concern is that I wanted to create DIDs in JSON and so I find the engagement in defining abstract data models and date types and I think it’s going to be a giant distraction

Brent Zundel: remember we passed a previous proposal to use INFRA as a type system

Orie Steele: modifying a type system is making a type system

Orie Steele: extension is a form of creation

Justin Richer: Orie: yes. The DID Core Document Type System

Proposed resolution: Add Number as a primitive type to the Abstract Data Model. (Manu Sporny)

Manu Sporny: +1

Justin Richer: +1

Brent Zundel: +1

Dave Longley: +1 with appropriate ranges for interoperability like I-JSON specifies

Kyle Den Hartog: +1

Drummond Reed: +1

Tobias Looker: +1

Orie Steele: +0 numbers should be supported.

Markus Sabadello: +1

Jonathan Holt: 0, but not a big fan of INFRA

Resolution #1: Add Number as a primitive type to the Abstract Data Model.

Brent Zundel: That proposal is resolved

Proposed resolution: Add DateTime as a primitive type to the Abstract Data Model. (Manu Sporny)

Orie Steele: -1

Justin Richer: +1

Manu Sporny: -1, don’t think we need it, happy to reconsider if we have a use case/limitation

Tobias Looker: +1

Kyle Den Hartog: +0

Dave Longley: -1 don’t think we need it

Markus Sabadello: +1 the format used by XML Schema is not abstract

Drummond Reed: +1

Proposed resolution: Add URL as a primitive type to the Abstract Data Model. (Manu Sporny)

Orie Steele: -1

Justin Richer: +1 (actually URI)

Drummond Reed: +1

Jonathan Holt: URI

Manu Sporny: -1, don’t think we need it, happy to reconsider if we have a use case/limitation

Dave Longley: -1 don’t think we need it

Tobias Looker: +1

Manu Sporny: Treat URL as URI as well

Kyle Den Hartog: +1

Jonathan Holt: 0

Markus Sabadello: +1

Drummond Reed: Consider that this is an identifier specification

Pamela Dingle: Do we have a plan for when INFRA adds some of these types we want to define?

Dave Longley: everything we create an abstract type for that can’t be covered by simple JSON types (strings, numbers, etc.) requires more work to document canonical representations

Orie Steele: what justin just said is exactly why I don’t want to get into defining a type system for URIs

Drummond Reed: Precision = better security

Justin Richer: if you’re thinking about URIs as a string that contains a string that’s a URI. If we can be more precise then we should

Justin Richer: dlongley: literally everything can just be a string so that’s a strawman argument

Justin Richer: a URI is a collection of scheme, authority, path, query, fragment, etc. It has a string syntax but it’s also a data object model.

Manu Sporny: to respond to Pam, as you know pointing to living docs is an issue. There’s been recommendations that do point to living docs like HTML5
… what WG are doing now is they go into maintenance mode, and in then if INFRA added those types then we could modify as necessary in the maintainence WG to keep it up to date

Drummond Reed: This whole conversation is a prelude to the unknown properties issue and the ability to go in and out of representations

Dave Longley: justin_r, it’s just about where to draw the line, it has to be drawn somewhere … you can always add more “abstract types”.

2. Issue review

Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc

Brent Zundel: https://github.com/w3c/did-core/issues/119

Brent Zundel: first 3 horizontal related
… 119 is waiting on TAG and we’re waiting on security/privacy questionnaires to resubmit
… 104 and 105 are simply tracking items for CR phase

Brent Zundel: https://github.com/w3c/did-core/issues/356

Orie Steele: We talked about this and adding restrictions such as no private key material
… we should be at the point of just needing to add a PR

Brent Zundel: https://github.com/w3c/did-core/issues/337

Justin Richer: dlongley: yes, exactly. And I think we can do better than drawing the line at “JSON” and throwing up our hands.

Daniel Buchner: I’ve still got to do a PR for this sorry for the delay

Brent Zundel: https://github.com/w3c/did-core/issues/291

Adrian Gropper: we’re still waiting on the service endpoints to finish up the security and privacy questionnaire

Brent Zundel: https://github.com/w3c/did-core/issues/58

Wayne Chang: we’re happy to accept this as a work item in the CCG but we need work item owners to step up

Brent Zundel: https://github.com/w3c/did-core/issues/72

Drummond Reed: we’re planning to update this once we’re done with the normative sections of the core spec
… buying us time is helpful because we’re learning more about DIDs and GDPR everyday
… if there’s a reason this surfaces to be faster I can reprioritize

Brent Zundel: https://github.com/w3c/did-core/issues/163

Brent Zundel: this is going to be done right before CR
… same status is for 118

Brent Zundel: https://github.com/w3c/did-core/issues/375

Tobias Looker: +1

Drummond Reed: I’m not sure about this issue but I’ll reach out to daniel hardman to figure out what’s needed to get it done

Kaliya Young: thank you Markus

Drummond Reed: special topic call on service endpoints is at Noon EST on Thursday

3. Resolutions