Dear Uze & Madan,


Nathan had replied to this chain with below information couple of days ago,
you may have missed it, does this help you? 

If not, can you please elaborate on how it cannot resolve the issue?




Hi Uze,



I may be misinterpreting your below email, but I am concerned there may be
some confusion regarding the ?secure build? vs ?non-secure build?. 


I believe SECURED=0 build should be purely for development and testing, and
should not be expected to function with a SECURED=1 ?real-world? build.
There are basic functions (e.g. Device ID persistent across reboots) that
require SECURED=1 build, regardless of whether there are ?public?
resources on the device (resources which do not need Access Control).



To be clear, resources can be effectively made ?public? using a SECURED=1
build.  If a resource doesn?t need access control at all, then (still
using a SECURED=1 build) the Device will have an Access Control Entry that
allows all requests from any requester (even from anonymous endpoint).
Effectively, the resource is ?non-secure?, even though the *build* is
still SECURED=1, and the resource is hosted on a CoAPS port.


In short, I would not expect a SECURED=0 Client to be able to access any
real-world Server, and a SECURED=0 Server would never be deployed in a real-
world product.  Therefore the SECURED=1 configuration should be expected
for proper functioning, and SECURED=0 just kept for dev/testing/debug use.



Thanks,
Nathan



Regards

Dwarka

----------------------------------------------------------------------------
------

Software R&D Center | Software Platform Team | IoT Lab

Open Connectivity Foundation - OSWG - Spec Coordination TG Chair

Iotivity Steering Group - Advisory Committee



From: [email protected] [mailto:iotivity-dev-
bounces at lists.iotivity.org] On Behalf Of ???(Uze Choi)
Sent: Thursday, June 02, 2016 11:32 AM
To: lanka.madan at samsung.com; 'RANDEEP SINGH'
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] [feature request] merging secure/non-secure IoTivity
build binaries



Hi Randeep,



Could you share your idea or progress for this requirement?



BR, Uze Choi

From: Madan Kanth Lanka [mailto:[email protected]] 
Sent: Thursday, May 26, 2016 2:30 PM
To: Uze Choi; RANDEEP SINGH
Cc: iotivity-dev at lists.iotivity.org <mailto:iotivity-
dev at lists.iotivity.org> 
Subject: Re: [dev] [feature request] merging secure/non-secure IoTivity
build binaries



Hi Randeep,



I also think the scenario requested by Uze is valid scenario. There is
already a JIRA ticket reported during 1.0.0 release.

https://jira.iotivity.org/browse/IOT-920



Thanks,

Madan

------- Original Message -------

Sender : Uze Choi<uzchoi at samsung.com <mailto:uzchoi at samsung.com> >
S6/Principal Engineer/IoT Lab./Samsung Electronics

Date : May 26, 2016 09:16 (GMT+05:30)

Title : [dev] [feature request] merging secure/non-secure IoTivity build
binaries



Hi Randeep,



As a member Developer Ecosystem Build TG, I have the requirement merging
the non-secure binary and secure binary into single one.

Currently, secure mode build does not provide the communication with non-
secure resource.

If this is configurable by API or both support by default, it will be very
easy to distribute iotivity binary.

Moreover, current separate build scheme cannot support the use case that
connects both resources one is secure resource and the other is non-secure
resource.

e.g) An application read the temperature resource (public resource) and
personal information storage resource together.

Please evaluate this requirement from maintainer perspective.

If feasible, I?ll issue the jira ticket for this thing.



BR, Uze Choi






-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160602/97d430a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 13168 bytes
Desc: not available
URL: 
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160602/97d430a0/attachment.gif>

Reply via email to