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
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
TD Issue 949 - We need extension ontology to include implicit and password flows in OAuth2
McCool: would see the TD 1.0 spec
TD 1.0 REC - 5.3.3.8 OAuth2SecurityScheme
Philipp: should keep backward compatibility
RFC8252 - OAuth 2.0 for Native Apps
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.
McCool: (goes through the TD 1.1 draft)
TD 1.1 draft - 5.3.3.9 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
TD issue 1313 - add SHOULD assertion to security schemes that need TLS to be secure
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]