- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 10 Jan 2022 17:58:53 +0900
- To: public-wot-ig@w3.org, public-wot-wg@w3.org
available at: https://www.w3.org/2021/12/06-wot-sec-minutes.html also as text below. Thanks, Kazuyuki --- [1]W3C [1] https://www.w3.org/ WoT Security 06 December 2021 [2]Agenda. [3]IRC log. [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#6_December_2021 [3] https://www.w3.org/2021/12/06-wot-sec-irc Attendees Present Jiye_Park, Kaz_Ashimura, Michael_McCool, Philipp_Blum, Tomoaki_Mizushima Regrets - Chair McCool Scribe kaz Contents 1. [4]Logistics 2. [5]Minutes 3. [6]TD issues 1. [7]Issue 949 4. [8]AOB Meeting minutes Logistics McCool: meeting cancellations … from the week of Dec 20 except the main call on Dec 22 … regarding the Security call … Dec 20 and 27 will be cancelled due to the winter holidays … Jan 3 will be also cancelled … would like to go through issues today … let's look at the minutes first Minutes [9]Nov-29 [9] https://www.w3.org/2021/11/29-wot-sec-minutes.html McCool: (goes through the minutes) … "DTL" should be "DTLS" … "upcoming issues" should be actually "TD issues" Kaz: fixed (quick discussion on OAuth2 implementation) TD issues Issue 949 [10]TD Issue 949 - We need extension ontology to include implicit and password flows in OAuth2 [10] https://github.com/w3c/wot-thing-description/issues/949 McCool: would see the TD 1.0 spec [11]TD 1.0 REC - 5.3.3.8 OAuth2SecurityScheme [11] https://www.w3.org/TR/wot-thing-description/#oauth2securityscheme Philipp: should keep backward compatibility [12]RFC8252 - OAuth 2.0 for Native Apps [12] https://datatracker.ietf.org/doc/html/rfc8252 McCool: this (RFC8252) is a Best Current Practice by IETF … it says "the use of the Implicit Flow with native apps is NOT RECOMMENDED." … (adds comments to issue 949) … TD 1.0 document only explicitly mentions "code" … and uses "string" for the flow and gives "code" as an example … also sites RFC8252 which says "implicit is NOT RECOMMENDED" … so for TD 1.1, we can take the stance we're clarifying what is allowed and what is not … the bottom line is that the current TD 1.1 draft doesn't remove the code, so no conflict with the TD 1.0 spec … so think we're ok … don't think we want or need a normative ontology for implicit and password (if we did do it, we would have to test it, too). … what do you think? Kaz: we might want to ask the TAG and the Security group for advice during our wide reviews Jiye: what is the expectation for the password? McCool: even if we just define a URL it opens a can of worms … since it would only be useful for brownfield devices that can't be updated … (adds some more comments) … TD 1.0 unfortunately doesn't have "client" but we agreed we can *add* flows and maintain compatibility Kaz: we can ask implementers for feedback … in any case, we need to ask the TAG and the security group for review during the Wide Review McCool: leave the current text alone, and don't define an ontology for implicit and password. Nothing to do here (except maybe delete an ed note if there is one) and this issue can be closed. [13]McCool's comments [13] https://github.com/w3c/wot-thing-description/issues/949#issuecomment-986786771 McCool: (goes through the TD 1.1 draft) [14]TD 1.1 draft - 5.3.3.9 OAuth2SecurityScheme [14] https://w3c.github.io/wot-thing-description/#oauth2securityscheme McCool: both the token and the endpoint should not have scope … not sure it's clear enough here … any comments? Jiye: question about security vocabulary within TD spec in general … a bit confused here … combo security is a bit confusing McCool: "combo" itself is a security scheme … one example is proxy … and also endpoint mechanism Jiye: what about "basic"? McCool: one of the orthogonal schemes … btw, currently security scheme is an array … we followed the notation of Open API … at some point we may deprecate the notation and use only one value … and use combo to express combination … we're asking feedback on recursive use Jiye: how to deal with encryption? McCool: the basic requirement is using HTTPS … we should say "SHOULD" for security mechanism for BasicSecurityScheme too … regarding DigestSecurityScheme uses Digest Access Authentication Jiye: which scheme uses TLS or not? McCool: can create an issue to clarify that [15]TD issue 1313 - add SHOULD assertion to security schemes that need TLS to be secure [15] https://github.com/w3c/wot-thing-description/issues/1313 AOB McCool: would like to go through the TD 1.1 document and see consistency … please give comments to me or create GitHub issues about your comments [adjourned] Minutes manually created (not a transcript), formatted by [16]scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC). [16] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 10 January 2022 08:58:57 UTC