Hello Zoltan, You are correct in your observation that DeviceID is not maintained across resets in most of the test applications.
You are also correct that it is the job of the IoTivity stack to maintain the DeviceID. Specifically, the Secure Resource Manager (SRM) owns the oic.sec.doxm resource that contains the DeviceID. The issue you have discovered is that most of the apps do not currently enable the SRM (via the "SECURED=1" compile flag). The reason is that enabling the SRM via this flag currently breaks most of the apps because the apps need to implement a callback for the SRM to store/retrieve the database file (which contains among other things the oic.sec.doxm resource). The reason that it's a callback is that it's platform-specific, as the callback accesses platform persistent storage. This is an issue we are working on and if you have time/interest, there is a HOWTO on enabling an application for SECURED=1, and this could be done to each test application. Perhaps a bug should be filed to track the work, because most of the C++, CSDK, and Svc layer apps need to have this change done to them. Let me know if this is something you want to drive, as we do not currently have a resource identified to do this enabling, but it is a very important thing to get done before the next plugfest. Separately, the intra-domain-uniqueness of the DeviceID is the responsibility of the Owner Transfer Method (OTM) and is currently just a random number, which needs to be replaced by the provisioning process during Owner Transfer. Another TODO for our reference provisioning tool, but one which is related to the SWG discussion on OTMs and currently on hold. Hope that helps and let me know if you have further questions or especially if you would like to help with storage-enabling some of the sample apps! Thanks, Nathan -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Kis, Zoltan Sent: Wednesday, December 2, 2015 1:56 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Device id? OK, the security spec section 7.1. is the normative reference for device ids. However, the OIC Cor spec could also use more specific wording. Interestingly the C++ example in iotivity does maintain device id's over reboot, since it uses persistent storage. However, the C example does not. And in the C++ example the device id is provisioned by the application as a static value in a config file, which is wrong. According to the security spec, the onboarding process should ensure uniqueness of device id. Therefore it is not the application, but the iotivity stack to own this, and manage device id's transparently. For instance there are already solutions to generate a UUID based on HW features. Should I file a bug? Or is there an explanation? Best regards, Zoltan On Wed, Dec 2, 2015 at 9:56 AM, Kis, Zoltan <zoltan.kis at intel.com> wrote: > Hello, > > Problem: the device id as provided by iotivity does not persist over reboots. > > Although the OIC Core spec is not very clear about this, it does say > > "The identifier should be immutable over the lifecycle of that element > and shall be unique within a context or domain." > > and > > "IP address is used when the device is using an IP configured > interface. When an OIC Device only has the identity information of its > peer, a resolution mechanism is needed to map the identifier to the > corresponding address. The location information is embedded in > identifier, and a separate resolution mechanism is not specified." > > So far we know there should be a lifecycle-bound id (whatever > lifecycle means), and a resolution mechanism to address:port. > > The Remote Access spec is more clear: > > "The UUID shall be maintained over the lifecycle of the OIC Client. > That is, when an OIC Client > re-establish a connection after a reboot it shall use the same UUID. > The following scheme full-JID scheme shall be supplied by an OIC Server: > RAE Server: {user}@{domain.com}/OIC/1.0/{OIC-device type}/{UUID} The > UUID shall be maintained over the lifecycle of the OIC Server and is > the same UUID as defined in property ?di? of resource /oic/d. The > OIC-device-type shall be the same value as the property ?rt? in > /oic/d." > > This is much more clear. So I deduce we should use device id in the > applications, and the stack has a resolution mechanism to translate > between the device id and the address:port. > > Now the problem is the device id is not the same between reboots. We > tested this with the JS bindings, and also with the iotivity test app. > Could someone please explain whether is this a known feature or > decision, or a bug? > > Thanks, > Zoltan _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
