This is best illustrated through an example: A medical centre wishes to conduct a trial to monitor patients using fitness trackers. To do this, it provides a mobile app and cloud services and also manages the registration of the patients and their use of the app. In Oasis terms, the patient obtains the role Participant(id=…) when they join the trial and the app obtains the role PatientSession(id=…) when a patient logs into it. Additionally, we want to ensure that suitable devices can obtain the DeviceFor(user=…) role and securely upload data to the trial.
This is illustrated below…
In our example, the medical centre only wishes to enable devices certified, by a body such as the NHS, as having high quality sensors. However neither it, nor the NHS, are likely to have direct relationships with all of the device manufacturers. This is the sort of real world “trust federation” problem that Oasis can address.
In Oasis terms, we think in terms of services: Firstly, there are services provided by the fitness tracker manufacturers, each of whom generates roles for their own user – perhaps Fitbit has a role called Flex and Jawbone has a role called Device(model=..). We won’t look into how these roles are issued, but let us assume that each device can obtain the appropriate role from its parent service and is willing to share this role with any other service that wishes to make use of it.
Next, the NHS might provide a service to indicate which devices are certified; by issuing them with CertifiedDevice roles. It might have an Oasis policy indicating this:
CertifiedDevice() < Jawbone.Device(model=’flex’)
CertifiedDevice() < Fitbit.Flex()
This policy can be linked to a web service. Common programming patterns, such as annotations, can be used to indicate which roles are required and which are issued by each service. This makes it easy for a programmer both to use this service without having to understand the details of the policy or to re-code things if the policy is updated.
The device part of the picture then looks like this:
To complete the example, the medical centre can use a more elaborate policy to indicate how a patient using the app can enrol a device for the trial.
DeviceFor(user=x) < CertifiedDevice() < PatientSession(id=x)
This policy introduces the notion of ‘election’ and can be read as: a client (the phone app in this example) who has role PatientSession can elect another client (the device) who has role CertifiedDevice, to have role DeviceFor parameterised with the patient name.
This policy can be attached to a suitable web service and the medical centre app can then orchestrate the enrolment of any suitable device.
This takes care of the complex trust establishment and, assuming that every device can use a standard API such as MQTT to publish actual data readings, we have a complete solution. This solution ensures that only enrolled, certified devices can upload data and only for patients who explicitly registered them.
Oasis can also ensure that, if a patient exits the trial, their devices immediately lose the ability to upload data. The same can also happen if a device is deemed no longer worthy of certification. The policy and enforcement mechanisms behind Oasis are flexible and scalable, enabling each service to evolve independently and to enforce its own policy – whilst participating in larger federated systems.
This blog demonstrated a simple example of why federated trust is essential to delivering the promise of IoT interconnections. It illustrates the building block nature of Oasis and how it can be used to build a simple, secure and scaleable system.
If you would like to do this for real, please contact Trustonic.
