| CARVIEW |
Navigation Menu
-
Notifications
You must be signed in to change notification settings - Fork 6
Expand description of Onboarding in Details #77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
wot-wg-2023-details.html
Outdated
| Onboarding is part of the larger WoT Thing lifecycle which is described in the | ||
| Architecture document. | ||
| In this work item we will define mechanisms to perform secure minimum-effort | ||
| trust establishment and identity confirmation amoung sets of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
amoung -> among
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just have one minor comment below.
| role can be used to establish transitive trust. | ||
| </p><p> | ||
| Onboarding is part of the larger WoT Thing lifecycle which is described in the | ||
| Architecture document. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
warning I'm just noticing that if the architecture becomes not normative we will have a soft dependency with a non-normative document from a "normative but optional" text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I've been saying this. If arch becomes non-normative, then certain normative content (current and planned) for security needs a new home - which means IMO a new normative security document.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is necessarily a dependency. The architecture document can introduce and explain the lifecycle of a Thing without making normative assertions about it. I also don't think that "lifecycle" really comes under the category of "security".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but the intention is that onboarding would be normative, too. So it would be in the same category as the security assertions in the Architecture doc: it would need a new home if Architecture became informative. One option would be to put it in Discovery, but it's not really discovery. It could also go (along with security assertions) into a normative security doc. HOWEVER, the point of this PR is just to define the work item, not to decide where it would live.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for clarifying this wording, I agree this is an important missing component for using WoT securely on local networks.
It would ideally be incubated in the CG/IG first in order to solidify requirements, prototype a solution and determine whether that solution should be standardised within the WoT WG or elsewhere, but I don't object to this exploratory work being done in the WG.
|
Thanks @mmccool for the heads up on this thread. I'm writing on behalf of the APA WG. Onboarding is one key part of the issues we discussed with you just prior to last TPAC, and we'd like to add the following for your consideration in addition to the updates to the onboarding section that are proposed in this PR:
Note: we included the phrase " (or reconfiguration)" which alludes to that wider issue; if you need to keep the scope of this strictly to onboarding, we understand, of course. On that subject (the wider scope)... as our groups have discussed together (at TPAC 2022), we have come across situations in which important lifecycle events—updates, maintenance—can't be performed in an accessible manner. This can have serious effects, such as people being un-able to re-start their thermostats. Could such "lifecycle accessibility" (we also termed it "middleware accessibility" in our prior discussion) be considered in scope for your charter too? Would you like us to file an issue, or make a separate PR, if so? |
|
@matatk I added the suggested paragraph at the end. In general, the intention is to make onboarding possible and as easy as possible, and ideally touchless, which should address the goals you mention. However, we do have limited ability to constrain device manufacturers since W3C does not do conformance testing. So in particular "pairing" often needs some way to confirm and/or set a device into pairing mode and since devices vary so much in their physical interfaces this can be a difficult problem to make accessible generally. But we can at least think about it... |
|
Thank you @mmccool; we are thrilled to have the onboarding accessibility included! If there's any way we can help with this (or other stuff), we'd be happy to. I noticed there is already some feedback on most of the issues I filed arising from our recent review, and I (or one of our members) will get back to those threads shortly. |
|
from today's planning session: decided to merge |
Resolves #67
WIP: Need to review in Security TF and refine. However, please comment and provide suggestions. Also, if a part is unclear, please comment and we can try to clarify.