Thank you Nathan! This makes perfect sense, and very helpful in explaining how things should work. Thiago - sorry my wording was not the most precise, but I meant what Nathan described. We are doing the Node.js bindings to iotivity and will enable the SRM in the user agent. Will let you know if we run into issues. The JS applications will only face device id's, transparently managed.
One more question: what is the actual mechanism which is used to ensure uniqueness of a device id in a network (and eventually globally) during the onboarding process? How is this implemented in iotivity? My speculation (maybe stupid) is that one would need registrars for this, and I assume that discovery resources (oic/res) could act as registrars. Are device id conflicts checked when a device is added to a discovery resource? Thanks, Zoltan On Wed, Dec 2, 2015 at 9:33 PM, Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com> wrote: > 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:iotivity-dev-bounces > at lists.iotivity.org] 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
