Meeting minutes
Minutes
approved
Recently merged PRs for TD
TD PR 1544
wot-thing-description PR 1544 - Add RFC9200 reference
McCool: RFC 9200 is "publication in process"
(the PR itself has been already merged)
TD PR 1543
wot-thing-description PR 1543 - Revise statements about auto SecurityScheme
McCool: (shows the diff)
diff - 5.3.3 Security Vocabulary Definitions
McCool: decided to put informative text on "auto"
… probably fine
auto : The location is determined as part of the protocol, or negotiated. If a value of auto is set for the in field of a SecurityScheme , then the name field SHOULD NOT be set. In this case, the application of the SecurityScheme is subject to the respective specification for the given protocol (e.g. [ RFC8288 ] when using the BasicSecurityScheme with HTTP).
McCool: and then some statement around "5.3.3.3 AutoSecurityScheme"
TD PR 1542
wot-thing-description PR 1542 - Discuss Secure Transport in Security Schemes
Jiye: what about nosec security?
McCool: yeah, some scheme doesn't require security
Jiye: that's why I added a sentence
… nosec is clear that we don't use TLS
McCool: wondering what kind of simple sentence to be added the other schemes
diff - 5.3.3.5 BasicSecurityScheme
Jiye: we could leave it asis
… and add another text for clarification
McCool: let me add a comment about that
… will create an issue for that
<McCool> https://
Pending updates
Architecture PR 783
wot-architecture PR 783 - Specify TLS and DTLS versions
McCool: added these assertions on security
Jiye: don't see any problems
(will be merged)
<McCool> Architecture PR 781 wot-architecture PR 781 - Define Trusted Environment
McCool: added some definition
… for "Trusted Environment"
… "isolated network" might be a bit too strong here, though
… could say "protected network"
Kaz: not a completely separate network from the Internet but a network connected to the Internet which is protected. right?
McCool: right
(fixed the expression)
Privacy wide review
TD Issue 1497
wot-thing-description Issue 1497 - Identifiers don't seem to rotate enough
McCool: had a proposal and discussed it
… then made 2 PRs
wot-thing-description PR 1547 - Improve Privacy Assertions
McCool: TD PR 1547 has been merged
… technically could rotate IDs more frequently
… added text saying:
Ideally, any required immutable identifiers SHOULD only be
made available via affordances, such as a property, whose value can
only be obtained after appropriate authentication and
authorization, and managed separately from the TD identifier.</span>
If it is necessary to use an immutable identifier as the TD identifier,
extra attention should be paid to secure
McCool: then removed redundant text
Jiye: ok with the changes
… much clearer now
McCool: more rotation of IDs and immutable IDs
(already merged 5 days ago, and that's fine)
wot-discovery PR 353 - Update Privacy Considerations
McCool: statement around GDPR
In general, "profiling" includes any mechanism used to evaluate
information about a person, including economic status, health,
preferences, interests, reliability, and behavior.
To avoid location tracking and other forms of profiling,
a WoT Thing associated with a person MAY
McCool: about generating new IDs
… then
It is also prudent to generate new identifiers upon major changes in configuration, such as unregistering from a local network or hub and registering with a new one (which typically indicates a change in ownership).
and
Finally, there is a problem with devices that require immutable identifiers,
e.g. medical devices in such jurisdictions.
This is discussed in [[wot-thing-description11]], but in summary the
problem can be avoided if such immutable identifiers are made available
only as protected properties, e.g. via affordances requiring authentication,
not in the TD, and the TD identifier itself (if used) is
independent of the immutable identifier, and so can be made mutable.
McCool: a bit redundant but should be OK
… (shows diff as well)
diff - 9.1 Location Tracking and Profiling
Jiye: good idea to add text around GDPR
McCool: hopefully could merge this during the Discovery call today
Architecture PR 783 (revisited)
Mizushima: question about Architecture PR 783
… wondering about the versions of TLS
… SHOULD use TLS 1.3
… MAY use TLS 1.2
… seems not really consistent
McCool: yeah
… generally a bad idea...
… but not enough just say "use TLS"
… and we need to specify the versions
Kaz: so using TLS 1.3 would be better
… but if it's not possible, we should use TLS 1.2
… is that our basic stance?
McCool: yeah
… if TLS 1.3 cannot be used for compatibility reasons TLS 1.2 MAY be used
Kaz: so the comments on the PR 783 are not clear
<McCool> https://
Kaz: but the proposed text for the spec itself is clear enough, I think
McCool: yeah
… anyway the PR 783 itself is still open
… so we can add further clarification if needed
Mizushima: TLS 1.1 is also still used by some of the applications
McCool: the question is that some of the existing devices might use TLS 1.1
… but don't think it's secure enough
Kaz: in that case, the question here is whether we want to allow people to use TLS 1.1 or not
… if yes, we should mention "1.1 MAY be used" too
… or if not, we should clarify 1.1 should be avoided
McCool: (adds comments about that point to PR 783)
Kaz/Mizushima: tx
Wide review status
McCool: (sees the latest status)
… nothing new...
… once those PRs are merged, we can close the wide reviews
[adjourned]