21:43:24 <RRSAgent> RRSAgent has joined #did
21:43:24 <RRSAgent> logging to https://www.w3.org/2020/07/28-did-irc
21:43:28 <Zakim> Zakim has joined #did
21:43:38 <burn> rragent, draft minutes
21:43:47 <burn> rrsagent, draft minutes
21:43:47 <RRSAgent> I have made the request to generate https://www.w3.org/2020/07/28-did-minutes.html burn
21:59:32 <markus_sabadello> markus_sabadello has joined #did
21:59:52 <burn> present+
22:00:48 <Orie> Orie has joined #did
22:01:45 <manu> present+
22:01:59 <markus_sabadello> present+
22:02:07 <tplooker_> tplooker_ has joined #did
22:02:07 <manu> rrsagent, make logs public
22:02:14 <tplooker_> present+
22:02:18 <manu> rrsagent, draft minutes
22:02:18 <RRSAgent> I have made the request to generate https://www.w3.org/2020/07/28-did-minutes.html manu
22:02:28 <drummond> drummond has joined #did
22:02:29 <dlongley> present+
22:02:35 <drummond> present+
22:03:00 <brent> brent has joined #did
22:03:22 <brent> present+
22:03:57 <wayne> present+
22:04:16 <Orie> Made this over the weekend, https://didme.me/did:meme:1zgsya8mdj6mq4ytx7a57fx89r0c404eyqej6kfl2wtm3fyvm5qgpngs0725xp
22:04:43 <manu> scribe: tplooker_
22:04:46 <Orie> present+
22:04:46 <burn> Topic: Agenda Review, Introductions, Re-introductions
22:04:50 <manu> scribe+ tplooker_
22:05:07 <jonathan_holt> jonathan_holt has joined #did
22:05:12 <tplooker_> burn: We are going to have 10 mins on unknown properties, to see what is to be done
22:05:18 <jonathan_holt> present+
22:05:22 <tplooker_> ... then we are going through our core issue status check
22:05:59 <drummond> Huge!
22:06:11 <tplooker_> ... I will officially re-introduce my self as the ED of the enterprise ethereum alliance, no change from my chairing positions at W3C
22:06:24 <identitywoman> identitywoman has joined #did
22:07:13 <kdenhartog> kdenhartog has joined #did
22:07:22 <kdenhartog> present+
22:07:55 <selfissued> selfissued has joined #did
22:07:59 <selfissued> present+
22:08:20 <burn> Topic: Next Topic Call
22:08:36 <burn> https://github.com/w3c/did-core/labels/keys
22:08:59 <tplooker_> burn: Next topic call going to be on JWK keys will be on our usual thursday time
22:09:10 <tplooker_> ... any questions about this?
22:09:11 <Orie> 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
22:09:15 <burn> Topic: Unknown Properties
22:09:25 <burn> https://github.com/w3c/did-core/issues/205
22:09:42 <tplooker_> ... So i am hoping someone would like to speak to this issue
22:10:35 <jonathan_holt> q+ to ask to define "unknown property really means"
22:10:36 <tplooker_> manu: 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
22:10:36 <selfissued> q+
22:10:36 <Orie> on the subject of input validation and "unknown properties"
22:10:37 <Orie> https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
22:10:48 <wayne> q+
22:11:06 <tplooker_> ... we need to pick some form of behaviour, some in the WG have asked for firm guidance around this
22:11:35 <tplooker_> ... we are looking for feedback on WG members on what we should do with regards to this
22:12:01 <burn> ack jonathan_holt
22:12:01 <Zakim> jonathan_holt, you wanted to ask to define "unknown property really means"
22:12:04 <manu> ack jonathan_holt
22:12:22 <dlongley> 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."
22:12:47 <tplooker_> 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
22:13:15 <wayne> q-
22:13:32 <manu> ack selfissued
22:13:37 <Orie> where as a JWT doesn't actually drop "ignored" properties... it still signs over them.... VC JWT does nothing different than vanilla JOSE.
22:13:59 <manu> q+
22:14:02 <Orie> q+
22:14:09 <tplooker_> selfissued: my first reaction is im puzzled as to why we are having this conversation, there is already text in the spec that says unknown members must be ignored
22:14:43 <tplooker_> ... can anyone illuminate why this is a topic for conversation
22:14:59 <tplooker_> manu: the definition for unknown is unclear
22:15:08 <markus_sabadello> q+
22:15:09 <manu> ack manu
22:15:11 <manu> ack Orie
22:15:11 <tplooker_> ... that is why we are having this conversation
22:15:43 <dbuc> dbuc has joined #did
22:16:29 <manu> q+ to explain one difference -- JWT will happily keep properties in... LD Security will throw when signing when a property is not known.
22:16:38 <tplooker_> orie: 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
22:17:49 <tplooker_> markus_sabadello: I dont have a strong opinion here, just wanted to respond to mikes comment, that section is specifically in just the JSON section at present, instead it should be across all representations
22:18:02 <manu> ack markus_sabadello
22:18:17 <burn> q+
22:18:38 <Orie> 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.
22:19:27 <tplooker_> manu: +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
22:19:30 <burn> ack manu
22:19:30 <Zakim> manu, you wanted to explain one difference -- JWT will happily keep properties in... LD Security will throw when signing when a property is not known.
22:20:06 <Orie> there is a `crit` header in JOSE, and nobody uses it properly :)
22:20:18 <tplooker_> ... 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
22:20:45 <dlongley> converting between representations is also important here -- which is important in this discussion vs. other specs where there is only one concrete serialization.
22:20:47 <tplooker_> ... essentially I think we need to have a deeper conversation on this issue as there appears to be confusion about what we mean
22:20:52 <burn> ack burn
22:20:57 <tplooker_> ... in regards to ignore
22:21:05 <Orie> https://snyk.io/learn/javascript-security/ - > See the input validation section.
22:21:17 <tplooker_> burn: sounds like we need more discussion time, we will put this on the special topics list for a later call
22:21:23 <jonathan_holt> q+
22:21:28 <burn> ack jonathan_holt
22:21:29 <tplooker_> ... any objections to a special topic call on this?
22:21:49 <selfissued> q+
22:21:51 <tplooker_> jonathan_holt: I'd just like for us to explore threat models as a part of this too
22:22:04 <identitywoman> present+
22:22:29 <burn> ack selfissued
22:23:14 <jonathan_holt> and I think we need to invite some invited experts to give us a hand to discuss the implications
22:23:29 <tplooker_> selfissued: 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 dont understand
22:23:50 <tplooker_> ... I dont believe there is a substantive decision remaining around this
22:23:51 <Orie> we don't need extensibility if we are going to pull in JSON security tradeoffs...
22:24:46 <burn> q?
22:24:47 <tplooker_> manu: 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
22:24:51 <Orie> also, we have yet to see a DID Method that ONLY uses JSON... so evaluating security decisions related to it is difficult.
22:24:58 <burn> Topic: Core issue status check (extra-filtered edition)
22:25:39 <tplooker_> burn: This is where we try to take out the issues that are already being worked on in someway
22:25:43 <burn> https://github.com/w3c/did-core/issues?q=is%3Aopen+is%3Aissue+sort%3Aupdated-asc+-label%3Aeditorial+-label%3Adiscuss+-label%3Aneeds-special-call+-label%3A%22horizontal+review%22+-label%3Ametadata+-label%3Akeys+
22:26:21 <burn> https://github.com/w3c/did-core/issues/198
22:26:27 <tplooker_> ... starting with issue 198
22:26:51 <tplooker_> markus_sabadello: once actions on did resolution have been added it can be closed
22:27:04 <tplooker_> ... one thing that hasn't been added is addressing dereferencing
22:27:24 <tplooker_> burn: can you add a comment that suggests closing and opening a new issue for dereferencing?
22:27:34 <tplooker_> markus_sabadello: yes
22:27:57 <burn> https://github.com/w3c/did-core/issues/185
22:28:01 <tplooker_> burn: issue 185
22:28:09 <justin_r> justin_r has joined #did
22:28:24 <justin_r> present+
22:28:25 <drummond> scribe+
22:29:00 <Orie> q+
22:29:25 <drummond> tplooker_: The consensus landed that all of the issues have been addressed so it can be closed.
22:29:41 <drummond> burn: Are you willing to leave a comment to that effect?
22:29:43 <dlongley> q?
22:29:46 <drummond> tplooker_: Yes
22:29:48 <Orie> q-
22:29:50 <tplooker_> scribe+
22:29:54 <burn> https://github.com/w3c/did-core/issues/332
22:30:00 <tplooker_> burn: issue number 332
22:30:51 <tplooker_> brent: issue status has not changed waiting on github pages
22:31:34 <kristina> kristina has joined #did
22:31:51 <burn> https://github.com/w3c/did-core/issues/249
22:32:01 <tplooker_> burn: next issue is 249
22:33:07 <tplooker_> 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
22:33:35 <tplooker_> burn: looks like there is disagreement about whether commentary in the implementation guid is sufficient, can you please add a comment around this?
22:33:40 <burn> https://github.com/w3c/did-core/issues/333
22:33:59 <tplooker_> burn: issue 333 appears to be marked pending close
22:34:21 <tplooker_> ... not sure why it is not on our list, any objections to closing otherwise we will move on
22:34:29 <tplooker_> markus_sabadello: yeah this should be closed
22:34:40 <tplooker_> brent: technically we can close it now
22:34:46 <Orie> +1 to closing stuff
22:34:57 <tplooker_> burn: any objections to closing now
22:35:11 <tplooker_> burn: issue closed
22:35:17 <burn> https://github.com/w3c/did-core/issues/339
22:35:19 <tplooker_> ... issue 339
22:35:36 <tplooker_> ... opened by jonathan
22:36:03 <burn> q?
22:36:08 <tplooker_> jonathan_holt: I used the same framework for how we determine about why this feature should not be marked at risk
22:36:34 <tplooker_> ... I see manu just added a link around CBOR-LD and I am supportive of discussing it
22:37:36 <tplooker_> ... 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
22:38:51 <Orie> q+
22:38:53 <tplooker_> burn: 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
22:39:15 <tplooker_> jonathan_holt: I believe between my and ories implementation we have two
22:39:57 <tplooker_> manu: I'd challenge that I dont think there are two completely compatible implementations of CBOR based did documents today
22:40:00 <burn> ack Orie
22:40:15 <tplooker_> ... orie is that correct?
22:40:59 <tplooker_> orie: yes the work i am doing is to explore the size trade offs but my implementation is not totally interoperable
22:41:32 <burn> https://github.com/w3c/did-core/issues/340
22:41:50 <tplooker_> jonathan_holt: related to the previous issue
22:41:52 <burn> https://github.com/w3c/did-core/issues/328
22:41:59 <tplooker_> burn: moving on to 328
22:42:03 <Orie> we may want to talk about COSE on keys all as well
22:42:31 <tplooker_> ... amy says there is a PR for it
22:42:54 <tplooker_> ... which is now merged, manu is this sufficient to close?
22:42:55 <justin_r> q+
22:43:05 <tplooker_> manu: yeah I think this is done, I made a full pass
22:43:12 <tplooker_> burn: marking as pending close
22:43:21 <burn> https://github.com/w3c/did-core/issues/324
22:43:23 <tplooker_> ... next one is number 324
22:43:24 <drummond> q+
22:44:09 <burn> ack justin_r
22:44:35 <manu> q+ to note number thing...
22:45:10 <tplooker_> justin_r: 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
22:45:47 <tplooker_> burn: can you please put a comment around that, or raise a new issue
22:45:58 <tplooker_> justin_r: ok I will raise a new issue
22:46:07 <kdenhartog> q+
22:46:07 <burn> ack drummond
22:47:06 <burn> q?
22:47:10 <tplooker_> drummond: with regards to 324 this is deep enough that we might want to consider a specific note on this issue
22:47:25 <burn> ack manu
22:47:25 <Zakim> manu, you wanted to note number thing...
22:47:33 <tplooker_> ... I think this needs to be labeled with security and privacy GH labels
22:47:39 <manu> https://github.com/whatwg/infra/issues/87
22:48:01 <tplooker_> manu: 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
22:48:06 <justin_r> +1 it should be simple but it shouldn't be overlooked
22:48:06 <burn> ack kdenhartog
22:48:53 <tplooker_> kdenhartog: 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
22:49:24 <tplooker_> burn: can you please add a comment and a link to the CCG discussion please
22:49:43 <justin_r> https://github.com/w3c/did-core/issues/361 to capture the infra thing
22:50:04 <tplooker_> kdenhartog: I will add a link pointing to the archive
22:50:21 <tplooker_> burn: next issue is number 341
22:50:24 <burn> https://github.com/w3c/did-core/issues/341
22:50:32 <tplooker_> ... iana registration for CBOR, no one assigned
22:50:44 <tplooker_> ... I am going to assign chris who opened it
22:50:45 <jonathan_holt> q+
22:51:14 <jonathan_holt> q-
22:51:21 <tplooker_> manu: i am a bit concerned that chris is asking for something that the WG is not working on, the usecase is not clear, I will add a comment to the issue
22:51:37 <burn> https://github.com/w3c/did-core/issues/202
22:51:55 <tplooker_> burn: issue 202, opened by justin_r, whats the status
22:52:14 <tplooker_> justin_r: Has this been added to the producer and consumer section yet?
22:52:35 <tplooker_> ... i liked daves langugage happy for that to be added
22:53:11 <tplooker_> ... as long as it aligns over all representations
22:53:38 <burn> https://github.com/w3c/did-core/issues/349
22:53:49 <tplooker_> ... issue 349
22:54:15 <tplooker_> markus_sabadello: a direct consequence of removing matrix parameters from the spec
22:54:52 <tplooker_> ... we talked about this at length at DIF F2F there is a PR for this
22:54:58 <drummond> Pull it in!
22:55:05 <tplooker_> burn: PR is close to being merged, once done this will be ready to close
22:55:14 <burn> https://github.com/w3c/did-core/issues/122
22:55:21 <tplooker_> ... issue 122 a great one to finish on
22:56:05 <tplooker_> kdenhartog: amy did a PR in the past however it looks like there is some additional language to add
22:57:35 <dbuc> I say that after every glass of wine
22:57:45 <markus_sabadello> Regarding https://github.com/w3c/did-core/issues/344, we could use some additional input on this..
22:57:55 <Orie> ^ its not in the minutes... but i said just one more.
22:58:31 <burn> rrsagent, draft minutes
22:58:31 <RRSAgent> I have made the request to generate https://www.w3.org/2020/07/28-did-minutes.html burn
23:41:16 <tzviya> tzviya has joined #did