DID WG Telco — Minutes
Date: 2020-07-28
See also the Agenda and the IRC Log
Attendees
Present: Daniel Burnett, Manu Sporny, Markus Sabadello, Tobias Looker, Dave Longley, Drummond Reed, Brent Zundel, Wayne Chang, Orie Steele, Jonathan Holt, Kaliya Young, Kyle Den Hartog, Michael Jones, Justin Richer
Regrets:
Guests:
Chair: Daniel Burnett
Scribe(s): Tobias Looker, Drummond Reed
Content:
- 1. Agenda Review, Introductions, Re-introductions
- 2. Next Topic Call
- 3. Unknown Properties
- 4. Core issue status check (extra-filtered edition)
Daniel Burnett: rragent, draft minutes
Orie Steele: Made this over the weekend, https://didme.me/did:meme:1zgsya8mdj6mq4ytx7a57fx89r0c404eyqej6kfl2wtm3fyvm5qgpngs0725xp
1. Agenda Review, Introductions, Re-introductions
Daniel Burnett: We are going to have 10 mins on unknown properties, to see what is to be done
… then we are going through our core issue status check
… I will officially re-introduce my self as the ED of the enterprise ethereum alliance, no change from my chairing positions at W3C
2. Next Topic Call
Daniel Burnett: https://github.com/w3c/did-core/labels/keys
Daniel Burnett: Next topic call going to be on JWK keys will be on our usual thursday time
… any questions about this?
Orie Steele: related to the did keys topic call, you may want to review this work: https://github.com/decentralized-identity/did-jose-extensions/blob/master/options.md
3. Unknown Properties
Daniel Burnett: https://github.com/w3c/did-core/issues/205
Daniel Burnett: So i am hoping someone would like to speak to this issue
Manu Sporny: There are only a handful of options for unknown properties in a did document, e.g., if you see an unknown error through an error or ignore the unknown error
Orie Steele: on the subject of input validation and “unknown properties”
Orie Steele: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
Manu Sporny: we need to pick some form of behaviour, some in the WG have asked for firm guidance around this
… we are looking for feedback on WG members on what we should do with regards to this
Dave Longley: from my comment on that thread regarding “what unknown means”: “…we should refer to “unknown” properties as “ambiguous” properties (or properties with ambiguous semantics) because it helps highlight the problem. Such properties could be interpreted in multiple ways; it isn’t just that there is one global meaning and our application doesn’t happen to be programmed to understand it.”
Jonathan Holt: My challenge is understanding what we mean by unknown, its helpful to understand how some cryptographic libraries handle unknown properties, for example how linked data proofs handle unknown properties
Orie Steele: where as a JWT doesn’t actually drop “ignored” properties… it still signs over them…. VC JWT does nothing different than vanilla JOSE.
Michael Jones: my first reaction is i’m puzzled as to why we are having this conversation, there is already text in the spec that says unknown members must be ignored
… can anyone illuminate why this is a topic for conversation
Manu Sporny: the definition for unknown is unclear
… that is why we are having this conversation
Orie Steele: as we consider extensibility for JSON we should be considering how this is used in other languages, e.g., how JSON is used in javascript is very different to other strongly typed langugages
Markus Sabadello: I dont have a strong opinion here, just wanted to respond to mike’s comment, that section is specifically in just the JSON section at present, instead it should be across all representations
Orie Steele: its my opinion that JSON and JavaScript are not great sources of good security engineering… if I were picking a language and a data format where I had more security built in… I would look at protocol buffers and go or rust.
Orie Steele: there is a
critheader in JOSE, and nobody uses it properly :)
Orie Steele: https://snyk.io/learn/javascript-security/ - > See the input validation section.
Manu Sporny: +1 to that being consistent across representations, typically this issue is not present for a JWT because members are included but ignored by application processors, however this is different to how linked data security handles this where unknown members can be dropped and therefore signatures will throw an error
… because they think it is unsafe to leave it in, where as JWT processors will just keep that information in, so the question is does ignore mean dont do anything at all or clean it up
… essentially I think we need to have a deeper conversation on this issue as there appears to be confusion about what we mean
… in regards to ignore
Dave Longley: converting between representations is also important here – which is important in this discussion vs. other specs where there is only one concrete serialization.
Daniel Burnett: sounds like we need more discussion time, we will put this on the special topics list for a later call
… any objections to a special topic call on this?
Jonathan Holt: I’d just like for us to explore threat models as a part of this too
… and I think we need to invite some invited experts to give us a hand to discuss the implications
Michael Jones: Again we tried to settle and close issues, and we discussed this and closed the issue. I believe we agreed in amsterdam that across all representations this behaviour applied i.e ignore if you don’t understand
… I don’t believe there is a substantive decision remaining around this
Orie Steele: we don’t need extensibility if we are going to pull in JSON security tradeoffs…
Orie Steele: also, we have yet to see a DID Method that ONLY uses JSON… so evaluating security decisions related to it is difficult.
Manu Sporny: there is a fundamental difference in how un-known members are treated in JSON vs JSON-LD that is requiring we address this in a follow on call
4. Core issue status check (extra-filtered edition)
Daniel Burnett: This is where we try to take out the issues that are already being worked on in someway
Daniel Burnett: https://github.com/w3c/did-core/issues/198
Daniel Burnett: starting with issue 198
Markus Sabadello: once actions on did resolution have been added it can be closed
… one thing that hasn’t been added is addressing dereferencing
Daniel Burnett: can you add a comment that suggests closing and opening a new issue for dereferencing?
Markus Sabadello: yes
Daniel Burnett: https://github.com/w3c/did-core/issues/185
Daniel Burnett: issue 185
Tobias Looker: The consensus landed that all of the issues have been addressed so it can be closed.
Daniel Burnett: Are you willing to leave a comment to that effect?
Tobias Looker: Yes
Daniel Burnett: https://github.com/w3c/did-core/issues/332
Daniel Burnett: issue number 332
Brent Zundel: issue status has not changed waiting on github pages
Daniel Burnett: https://github.com/w3c/did-core/issues/249
Daniel Burnett: next issue is 249
Markus Sabadello: this is on how to trust the resolver a very frequent topic on the did resolution call, we have discussed the desire for the did core spec to speak about this issue, however I think most of it belongs in did resolution
Daniel Burnett: looks like there is disagreement about whether commentary in the implementation guid is sufficient, can you please add a comment around this?
Daniel Burnett: https://github.com/w3c/did-core/issues/333
Daniel Burnett: issue 333 appears to be marked pending close
… not sure why it is not on our list, any objections to closing otherwise we will move on
Markus Sabadello: yeah this should be closed
Brent Zundel: technically we can close it now
Orie Steele: +1 to closing stuff
Daniel Burnett: any objections to closing now
… issue closed
Daniel Burnett: https://github.com/w3c/did-core/issues/339
Daniel Burnett: issue 339
… opened by jonathan
Jonathan Holt: I used the same framework for how we determine about why this feature should not be marked at risk
… I see manu just added a link around CBOR-LD and I am supportive of discussing it
… Im working on PR around key formats but having problems with existing statements about them having to be stringified, also working on around mime type to detect the did document is expressed in CBOR
Daniel Burnett: as a comment around features at risk we need to be sure we have sufficient implementations to make, if we do not have at least 2 implementations of a feature then it needs to be pulled
Jonathan Holt: I believe between my and ories implementation we have two
Manu Sporny: I’d challenge that I dont think there are two completely compatible implementations of CBOR based did documents today
… orie is that correct?
Orie Steele: yes the work i am doing is to explore the size trade offs but my implementation is not totally interoperable
Daniel Burnett: https://github.com/w3c/did-core/issues/340
Jonathan Holt: related to the previous issue
Daniel Burnett: https://github.com/w3c/did-core/issues/328
Daniel Burnett: moving on to 328
Orie Steele: we may want to talk about COSE (JOSE?) on keys all as well
Daniel Burnett: amy says there is a PR for it
… which is now merged, manu is this sufficient to close?
Manu Sporny: yeah I think this is done, I made a full pass
Daniel Burnett: marking as pending close
Daniel Burnett: https://github.com/w3c/did-core/issues/324
Daniel Burnett: next one is number 324
Justin Richer: just a note on 328, there were some comments on the issue, infra does not currently define things like numbers which is problematic as we will need this going forward, because of that this issue is mostly done
Daniel Burnett: can you please put a comment around that, or raise a new issue
Justin Richer: ok I will raise a new issue
Drummond Reed: with regards to 324 this is deep enough that we might want to consider a specific note on this issue
… I think this needs to be labeled with security and privacy GH labels
Manu Sporny: https://github.com/whatwg/infra/issues/87
Manu Sporny: just to follow up on justin_r’s comment w.r.t the numbers stuff we may be able to get numbers but unlikely to get date
Justin Richer: +1 it should be simple but it shouldn’t be overlooked
Kyle Den Hartog: Just giving an update on 87, there is a discussion on the CCG about this topic, what I gathered from adrian is that the text is no sufficient is addressing all of his concerns
Daniel Burnett: can you please add a comment and a link to the CCG discussion please
Justin Richer: https://github.com/w3c/did-core/issues/361 to capture the infra thing
Kyle Den Hartog: I will add a link pointing to the archive
Daniel Burnett: next issue is number 341
Daniel Burnett: https://github.com/w3c/did-core/issues/341
Daniel Burnett: iana registration for CBOR, no one assigned
… I am going to assign chris who opened it
Manu Sporny: i am a bit concerned that chris is asking for something that the WG is not working on, the use case is not clear, I will add a comment to the issue
Daniel Burnett: https://github.com/w3c/did-core/issues/202
Daniel Burnett: issue 202, opened by justin_r, what’s the status
Justin Richer: Has this been added to the producer and consumer section yet?
… i liked dave’s language happy for that to be added
… as long as it aligns over all representations
Daniel Burnett: https://github.com/w3c/did-core/issues/349
Justin Richer: issue 349
Markus Sabadello: a direct consequence of removing matrix parameters from the spec
… we talked about this at length at DIF F2F there is a PR for this
Drummond Reed: Pull it in!
Daniel Burnett: PR is close to being merged, once done this will be ready to close
Daniel Burnett: https://github.com/w3c/did-core/issues/122
Daniel Burnett: issue 122 a great one to finish on
Kyle Den Hartog: amy did a PR in the past however it looks like there is some additional language to add
Daniel Buchner: I say that after every glass of wine
Markus Sabadello: Regarding https://github.com/w3c/did-core/issues/344, we could use some additional input on this..
Orie Steele: ^ its not in the minutes… but i said just one more.