Meeting minutes
Minutes
<kaz> Mar-13
approved
Security Issues
Issue 220
<McCool_> Issue 220 - Consider moving Terminology to the beginning
(still waiting for comments)
issue 214
<kaz> Issue 214 - Expand the (currently very short) intro section
McCool: can we close this issue #214? any objection?
(no objection)
Issue 208
<kaz> Issue 208 - Remove Reference to "Security Best Practices"
McCool: assigned to myself
Next Charter Work Items
Onboarding
<kaz> wot-charter-drafts PR 77 - Expand description of Onboarding in Details
McCool: (Summary of the issue) previous description was short and Ben asked more details.
McCool: people think that we need to start with experimental implementation, what is our opinion on this?
Kaz: for the charter discussion we don't need to talk about details now, we can discuss where the onboarding part goes.
McCool: I would like to know what the recommendation would be for this onboarding topic
… we are not constrained right now where to add onboarding. We have several choices if we go informative right now.
Kaz: We need to focus on charter discussion first than having discussion on details
McCool: If we go for informative, onboarding part doesn't need to be at the architecture document, so I am fine with having some experimental document and then see if we can go for normative document
Signing
<kaz> wot-charter-drafts PR 88 - Revised scope section, reordered, clarified language
McCool: questions is we don't have many people to work on both onboarding and signing. Do we need to work on this? IMO, signing has higher priority
Ege: I think also onboarding part is more like life cycle thing
McCool: in security perspective, it is important feature, but for now we are ignoring.
Ege: onboarding is more like we are using existing mechanism but signing is more like we need to define how to do it
McCool: agree
TD Assertions for Dev Meeting
<kaz> Ege's draft slides for Dev Meeting
(Ege explaining overall list of TD assertions)
Kaz: we should clarify to participants about the goal of developer meeting itself. If we want to give information for each assertions at risk ? that kind of clarification is needed
Ege: so I'll add the slides about goal, risk, and how to contribute.
McCool: need to check the date, we talk latest mid may.
McCool: maybe a bit of more structure on overall list slide is needed
… distinguishing security part and rest to easy to recognize.
Kaz: this slide should show overall list of at risk features, right?
(Ege changed title of the slide)
Ege: td-security-uri-variables-distinct might not really security feature, need double check
Kaz: we also need to provide context of this list. What kind of description is clarified.
McCool: security-server-auth-td might be able to go to discovery
… let's check redundancy first, and if it's not we can move it to discovery
… kaz, can we do that?
Kaz: Technically, that's possible, but that implies we need to publish updated CRs for TD and Discovery. That's why I've been suggesting we clarify the goal of the Dev Meeting, and my understanding simply clarifying the assertion texts and spec texts with the current spec structure.
McCool: OK. That's my preference too. On the other hand, there is no reason why this assertion is at risk as it's easy to be satisfied.
Ege: this is not TLS, right?
McCool: no this is about TLS, mutual authentication
(discussion on security-contect-secure-fetch assertion)
McCool: bottom line is when you fetch, you should try https first,
… it will be redirected if you do http, and server requires https
Luca: this is yet another larger topic if we have full JSON LD or not, and if it's fulled in case of full JSON LD implementation
McCool: that's why we have condition
… we also have other assertions, pointing out that concern
Luca: the problem I see is that either you decide you don't support real JSON LD and don't have security issue but parsing context.
McCool: I don't disagree with you.
Luca: I will make this assertion even stronger, would recommend MUST.
McCool: we are trying not to make MUST assertion.
Ege: have a question regarding implemetability of assertions in general
Kaz: given we're out of time, we need to clarify how to proceed with the discussion
… we at least should use the Testing slot, though
McCool: can have a further discussion in TD call as well.
… also can talk about this offline
… also can discuss in testing call as well
<kaz> Note: Dev Meeting page says the proposed dates for the Dev Meeting (Global one and Japanese one) are as following:
proposed date of the dev meetings Global: Reuse second hour of TD slot: 3/29 15:00 UTC Japanese: 3/30 11:00 JST
[adjourned]