Closed mlagally closed 3 years ago
@mmccool : Please add also Clerley from Connexxus
I will review
Please use https://github.com/w3c/wot-architecture/pull/478 for commenting on the text document, and this issue for commenting on the diagram.
I do not have access to the Google Drive link. I have requested access. I have reviewed the text and did have a few questions. Please, see w3c/wot-architecture#478 for my comments.
Very rarely the manufacturer will also be responsible for destroying the "Thing". Would it make more sense to have the arrow going from "Maintenance" to "Destroyed"? Usually the "Service Provider" or "Device Owner" will destroy the "Thing".
There is an asterisk in the "Service Provider Key: set *" . What does it mean? Can we add that to the legends?
I think the legends in R1 and D3 are backwards. From Operational you stop the service and go to Maintenance. Once the maintenance is complete, service is resumed.
Very rarely the manufacturer will also be responsible for destroying the "Thing". Would it make more sense to have the arrow going from "Maintenance" to "Destroyed"? Usually the "Service Provider" or "Device Owner" will destroy the "Thing".
The reasons the arrow is from Maintenance state to Destroyed are the following:
I think the legends in R1 and D3 are backwards.
Indeed, I corrected. Thank you!
There is an asterisk in the "Service Provider Key: set *" .
Right, that was because I copied the state text from the other (previous) diagram - which is not obsoleted, it's still valid. For now actually I have deleted the asterisk.
Oh, I see! I was looking at it incorrectly. I thought the manufacture was the actor and not the state. It makes more sense now. Before the device can be disposed, it must be reset back to the manufactured state so that staled information can be wiped out.
I think the lifecycle has been stable for a while now (and merged) and perhaps ready to close. Let's ask @zolkis about the status and see if we can close this.
Tried to review https://github.com/w3c/wot-security/issues/169 but could not access https://drive.google.com/file/d/1E7dF65r8i1rx5ykJujMYe14RYPOvXAPf/view (asked for granting access but not yet have access). Moreover https://github.com/zolkis/wot-architecture/blob/lifecycle/proposals/lifecycle-model-proposal-zolkis.md results in a 404 error
@OliverPfaff try again for this link: https://drive.google.com/file/d/1E7dF65r8i1rx5ykJujMYe14RYPOvXAPf/view , I have given you the rights now via your Siemens mail
Hi,
I have given access, but should not be bound to my permission. The link has changed: https://github.com/zolkis/wot-architecture/blob/master/proposals/lifecycle/lifecycle-model-proposal-zolkis.md (lifecycle stuff got its own dir).
Best regards, Zoltan
From: Oliver Pfaff notifications@github.com Sent: Monday, August 17, 2020 10:53 AM To: w3c/wot-security wot-security@noreply.github.com Cc: Kis, Zoltan zoltan.kis@intel.com; Mention mention@noreply.github.com Subject: Re: [w3c/wot-security] Security review of Lifecycle model and diagram (#169)
Tried to review #169https://github.com/w3c/wot-security/issues/169 but could not access https://drive.google.com/file/d/1E7dF65r8i1rx5ykJujMYe14RYPOvXAPf/view (asked for granting access but not yet have access). Moreover https://github.com/zolkis/wot-architecture/blob/lifecycle/proposals/lifecycle-model-proposal-zolkis.md results in a 404 error
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/wot-security/issues/169#issuecomment-674722978, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHTFWWK5VNEYDGIQMUDLA3SBDOWNANCNFSM4M53ZVEQ.
Thanks for giving access. Some comments:
RFC 8576 (https://tools.ietf.org/html/rfc8576#section-2) does a pretty decent job in elaborating the lifecycle of a thing in IoT. The RFC 8576 lifecycle model is also accepted by OT communities - with some minor modifications/extensions. The WoT lifecycle model seems to re-use and refine the IoT lifycycle from RFC 8576. However this remains implicit. Consider to make it explicit (in e.g. an accompanying text)
User data should be qualified as optional (can be assume to be present in "Consumer IoT"; can be assumed to be absent in "Industrial IoT"; should be optional when "Consumer IoT" as well as "Industrial IoT" cases are to be covered by the WoT Thing lifecycle)
Factory reset should not point back to the actor "Manufacturer" (is a product feature that is shipped with the Thing but which is under control of the owner/user i.e. its usage has little to nothing to do with the actor "Manufacturer"; the link R2 could be confusing/misleading)
Similarily for R3 (R2/R3 are understood to be under control/responsibility of the user/owner i.e. should be associated to them)
Revisit the term "service provider"; is known from IT; could be confusing/misleading. The suggestion is to consider the terms Thing user/owner and distinguished human users as well as legal entities as user/owner
Differentiation of properties on the levels "Providers" and "Applications" could be more clear e.g. Configuration data
@OliverPfaff I agree with the comments, thanks!
RFC 8576
That was one of the inputs for this work and it is explicitly stated in the md file. It also came up during the common workshop with T2TRG. Also, this model is very close to the T2TRG model, while works with other protocols as well (OCF etc).
However, keep in mind these will all be inputs to the text that enters the Architecture spec - so these comments should apply to that to-be-defined section in the Architecture spec and we need to keep it in mind.
About the terms, they are overloaded multiple times - I expect the Architecture doc will contain the right term definitions.
Recommendations (from Security Review, these were reviewed and written during the 2020.08.32 security TF):
Some of the above does make things more verbose; a reasonable tradeoff for clarity.
Please put future comments into issue https://github.com/w3c/wot-architecture/issues/533 so they are all in one place and the Architecture TF is sure to see them. Closing this issue (because the stated goal, to review the lifecycle and provide feedback, has been done) but once the architecture doc has been updated, we may need to do future work to update our guidelines. Suggest we do that once the arch doc goes to CR so the target is stable.
Closed since review done. Discussion should move to linked Arch issue.
Please review the lifecycle model we are working on from a security perspective: