Open OliverPfaff opened 4 years ago
Meeting:
Plan:
This is in alignment with our goals to add onboarding to the current scope. In which case we may need to add a section and revise the scope. Maybe expanding the scope should be another issue...
For onboarding, maybe want to look at SDO as well. Also, if ACE can use OAuth flows, then do we need a new security scheme for ACE in TDs? Probably we should mention ACE. Also, we still need a lifecycle.
Included in PR https://github.com/w3c/wot-security/pull/150 but this issue will not be resolved until that PR is merged, and it is not ready yet. That PR also includes SDO.
Marking this as WIP and PR available since covered in PR https://github.com/w3c/wot-security/pull/150
A reference has been added via PR https://github.com/w3c/wot-security/pull/150; however, some text still needs to be added summarizing Anima. Once that has been done this issue can be closed.
Still need to add text. The reference now exists - see PR #19 ; it specifically refers to bootstrapping and so is also related to the lifecycle discussion.
The IETF ACE WG is referred to in https://w3c.github.io/wot-security/#references-to-existing-security-best-practices
If I recall the deliverables/objectives of ACE correctly, ACE is mostly concerned with elaborating security in a relational context (there are components A, B, C in a site/domain, how can they interact securely)
This comes with an assumption of a prior step in an indiviual context (how to make A part of the site/domain, how to make B site/domain...)
In the IETF there is another WG (Anima, https://datatracker.ietf.org/wg/anima/documents/) elaborating techniques for this prior step that can then be used by ACE
From my perspective, referring to this WG is at least as important than referring to ACE (as long as one does not aim at granularity such as A may talk to B but not to C [at least not on weekdays] an adoption of IETF Anima suffices to enable security in a site/domain)