A) the concensus seems to be that SECURED=1 should be the default. question: why should SECURED=0 even be an option? why not remove this option altogether?
B) creating a resource without OC_SECURED apparently causes problems if SECURED=1. this strikes me as a bug that should be fixed, not something to be worked around. how hard can it be? C) this has been around for approximately forever: https://jira.iotivity.org/plugins/servlet/mobile#issue/IOT-693 but the solution seems very simple to me: initResources should always be called as part of stack initialization. C2) here's another one: https://jira.iotivity.org/plugins/servlet/mobile#issue/IOT-920 the recommendation is to bypass security, on grounds that it is unintuitive to provide a wildcard ACL for "unsecured" resources. fwiw I strongly disagree - there should be no such thing as an unsecured resource, and providing an ACL for every resource should be considered standard pactice. There's a big difference between "unsecured" and "freely accessible. More below. D) security is a house of many mansions. encryption, authentication, and authorization are just three. IMHO an audit trail is another: we all know that any system can be compromised, so a complete security solution must support after-the-fact forensics. if we just *disable* security (e.g. ACLs) for some resource, what does that do to our audit trail? E) it follows that it should not be possible to create an unsecured resource. there should be no OC_SECURED flag for resource creation. auth/auth should be entirely controlled by the config file with ACLs etc. if you want a resource to be accessible to anybody, the way to do that is to allow it, not to disable security. this is not an unendurable burden for developers; it's just a bit of configuration. F) for debugging we may need to disable encryption. we should be able to do that without affecting any other security mechanisms. as far as I can tell, encryption, authentication and authorization are orthogonal. G) Any or all of the above may be wrong. ;) gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160922/297269ba/attachment.html>
