DID WG Telco — Minutes
Date: 2020-09-22
See also the Agenda and the IRC Log
Attendees
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
Regrets:
Guests:
Chair: brent zundel, Brent Zundel
Scribe(s): Drummond Reed, Kyle Den Hartog
Content:
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
- Resolution #1: Add Number as a primitive type to the Abstract Data Model.