- 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:58 UTC