/The Identity of Things

A Reference Architecture for the Internet of Things

 Table of Contents

I. Introduction: The Security Challenges of the IoT 3

II. Why the IoT Needs Identity 4

III. Applying Identities to Devices 5

IV. Building Relationships Means Building Value 5

Use Case: Enabling a Smart TV 6

V. Smart Devices vs. Constrained Devices 6

Use Case: Supporting the Smart Factory 7

VI. IoT Component Architecture 7

VII. Identity for IoT: The ForgeRock Identity Platform 11

VIII. The Future 12

IX. Glossary 13

Copyright © 2016 ForgeRock, All Rights Reserved. 2

The Security Challenges of the IoT

As organizations transition into digital businesses, where their goods and services are available online and via devices, companies
and governments alike are realizing that their ability to manage the digital identities of millions of people and billions of devices is a
fundamental requirement for success. While legacy identity and access management (IAM) was designed for enterprises and their
employees, IAM for the Internet of Things (IoT) needs to be designed for customers, devices, connected things, and the relationships
between them – a concept called identity relationship management (IRM). Faced with the prospect of managing millions of connected
devices in their digital ecosystems, organizations must adjust their approach to identity management and security.

Gartner Research forecasts that over 20 billion IoT devices will be in use
worldwide by 20201

The IoT requires security at scale, designed for devices with varying levels of sophistication, interfaces, and standards. Device,
appliance, and machine makers have a lot of experience building products. But now, all of a sudden, these products need to connect
to the internet. They need to interact with other devices and with users. They face threats they never had to deal with before. Devices

expert at linking devices to the internet, let alone linking them to users and fellow devices. That is why, so far, we have seen so many
examples of weak device security, easy to break and hijack.

Any company producing IoT-connected devices should take the October 2016 Dyn DDoS attack as a warning: the onslaught was
apparently caused by millions of internet-connected devices like thermostats, webcams, and refrigerators infected with malware
because they were connected to the internet without necessary digital identity security protocols in place. These devices were

web that day. And security experts say this is just the tip of the iceberg - the IoT presents a massive security vulnerability, especially
if the companies that produce, utilize, or sell these devices do not take identity management and security for the IoT into account up
front, and make it a top priority. To date, there has been no security model for the IoT.

“
The [Dyn DDoS] attack appears to have relied on hundreds of thousands of internet-connected
devices like cameras, baby monitors and home routers that have been infected — without their

NICOLE PERLROTH
Technology security reporter, The New York Times2

1. http://www.gartner.com/ newsroom/id/3165317
2. http://www.nytimes.com/2016/10/22/business/internet-problems-attack.html?smprod=nytcore-iphone&smid=nytcore-iphone-share

Copyright © 2016 ForgeRock, All Rights Reserved. 3

Managing and securing the IoT is a critical step for organizations looking to use connected devices to deliver on their digital business objectives, like

connect customers and citizens to relevant goods and services in the digital age, businesses and governments instead require IoT-ready IRM.

whatever their level of sophistication. With an IoT-ready identity platform, you can securely support healthcare wearables, connected cars, set-top
boxes, e-citizen portals, home security systems, industrial machines, or whatever yet-to-be-invented “thing” you and your customers are using now
and in the years ahead.

enterprises will involve IoT, although IoT will account for less than 10 percent
of IT security budgets3

Why the IoT Needs Identity

In the great IoT gold rush, early adopters have largely left behind identity and access management. As a result, many organizations are
scrambling to deal with the consequences. Successful IoT implementations have complex relationships to people, things, and services, and
the only sustainable and secure method for delivering real end user or operational value from device led solutions, is to enable persistent
identity across all touchpoints and interactions.

We have reached a point where consent and control over devices and data is critical to the further success of IoT, both in the consumer
and industrial spaces. IoT solutions must offer a set of identity controls that properly govern who has access to what, when and why. In the
identity world, these controls are the well-known concepts of authentication and authorization.

With respect to general device security, some basic principles should exist before the identity layer is introduced. Devices should contain a

services and ports should be disabled, with a limited reliance on root or full admin accounts. Default passwords should also have the ability to
be changed on initial use with transport layer security also enabled by default.

consumer of personalization. The second is to the device manufacturer or service provider, who can leverage device ownership information
to develop a better understanding of device and service usage, such as component failure data or service popularity statistics.

management, predictive failure management, and automation.

3. http://www.gartner.com/newsroom/id/3291817

Copyright © 2016 ForgeRock, All Rights Reserved. 4

Applying Identities to Devices

But to achieve these benefits, devices need identities too! For organizations and service providers to fully leverage the value
of connected device infrastructures, the devices themselves need to become part of the identity ecosystem. But what attributes
make up the identity of a device? Is there a common schema or data model that IoT manufacturers can leverage to make the
registration, verification, and authentication process simple, repeatable, and non-proprietary?

Once a collection of attributes has been defined and collected from a device, the attributes need to be stored during the device
registration process. For some devices, registration may need some sort of unique verification to confirm that the device itself is
legitimate. This is especially important in the consumer IoT space, where connected luxury items such as cars, sports apparel and
equipment need to be protected from the threat of fake items. But how can a device prove the validity of the attributes associated
with it? A simple approach could be to compare a value provided by the device to data held by the manufacturer of the device,
such as a hard-coded (burned-in) unique identifier or a piece of cryptographic data stored in a secure element (SE) or Trusted
Execution Environment (TEE). This is a concept similar in design to a device passport.

Building Relationships Means Building Value

In the consumer world, device-to-person relationships are one simple example of the interaction between the physical and digital.
However, many other relationships need to exist to make the devices fully effective. Nearly all of the actors (devices, people,
services, and data) will have many-to-many relationships and interactions.

Some relationships will simply be for temporary data access, while others will be persistent and long-standing, such as the owner-
to-smart-TV relationship or the sensor-to-production-line relationship. These relationships need to be registered, verified, and then
ultimately terminated.

A simple example in the consumer world, would be the relationship between a smart-TV and the TV owner. At purchase, a long
standing relationship is created that allows the smart-TV to represent the user to a host of services provided by the network or cable
TV operator. The relationship is created and managed by the owner and ultimately terminated if the TV is sold or stolen.

McKinsey Global Institute

4. http://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/the-internet-of-things-the-value-of-digitizing-the-physical-world

Copyright © 2016 ForgeRock, All Rights Reserved. 5

Use Case: Enabling a Smart TV
The modern media landscape is littered with the user can start the process of actively
devices capable of delivering movie, TV and managing their new media device. The communicate back to the cloud service.
music content to the home. These devices device is often of medium power, with
are often internet connected, to provide HTTPS based communications, so can Modern authorization standards such
catchup, record and on-demand services.
Many providers are now introducing the have limited end user interface or input extension, can allow devices to be paired
capability to “pair” a device to a particular capabilities. A typical process to pair the to an individual, gaining permissions to
individual. This can provide a personalized item, is to initiate a polling process on the communicate to back end cloud services on
end user experience, by storing viewing device, as it communicates back to a cloud
history, preferences, recommendations and based authorization service. history, preferences and recommendations.
more. However, how can a user pair a device The powerful aspect of OAuth2, is that the
to their physical identity? In parallel, the end user accesses the cloud user identity can revoke, at any time, the
service over their laptop or tablet to perhaps permissions the device has, in case the
First, the user themselves must be enter a uniquely assigned PIN or code to device is lost, stolen or sold. As OAuth2 is
registered to a media service provider, take ownership of the media player. Once a token based implementation, the device
generally via a typical web based self- does not require access to any usernames,
service user interface. Once completed, that a user identity has authorized the device passwords or credentials.

Smart Devices vs. Constrained Devices

But not all devices are created equal. Their physical power and computational capabilities will vary dramatically, based on their intended usage and

Smart devices are often seen in the consumer identity space, where examples include sports wearable technology, health monitoring
devices, connected vehicles and media systems.

In the operational technology (OT) landscape, where connected devices are often used as sensors, logic controllers and production line
monitors, the devices themselves are typically much smaller with lower processing capabilities.

The difference between smart devices and constrained devices is outlined in this table.

Characteristic / Type Smart Device Constrained Device

CPU Power Mobile phone equivalent Thermostat equivalent

Batter only; non-replaceable; non-rechargeable; limited

Electrical Power Mains or rechargeable long life battery; always on
on-time

Memory Hundreds of megabytes Less than 256 kilobytes

Storage Gigabytes / hundreds of megabytes None / kilobytes

Networking HTTP/HTTPS Non-HTTP; CoAP; MQTT

User Interface Basic/None None

Devices of both types are now fully operational in both the consumer and operational technology (OT) fields, collecting, aggregating
and sending data and interacting with APIs and services.

Copyright © 2016 ForgeRock, All Rights Reserved. 6

Use Case: Supporting the Smart Factory
The modern manufacturing organization, often referred to as an Industry 4.0 enterprise, will consist of a set of highly optimized and
cyber-connected production lines, monitoring, management, analytics and response systems. Industry 4.0 organizations, are highly
focused on reducing operational downtime through predictive component failure and preventative servicing, while simultaneously
increasing output efficiency through continuous analytics and big data business intelligence.

According to Accenture research 5, predictive maintenance powered by IoT devices will help manufacturers to:

• Save up to 12% in scheduled repair costs

• Reduce overall maintenance costs by up to 30%

• Experience up to 70% fewer breakdowns

These organizations place a heavy burden on tiny network connected components that provide a range of functions such as data
collection, aggregation and forwarding, as well as more active functions such as pressure, valve and environmental controller responses.

There are several identity related controls against the APIs and publish/ devices. These APIs will also need
requirements to make these subscription services the devices registers protecting, often again via the popular
environments more automated and against? These APIs will often need OAuth2 standard, with the correct scopes
more secure. First, device provisioning protecting, probably via OAuth2, with and permissions being applied.
is the requirement that confirms that a enhanced proof-of-possession features to
new device that enters production, is a prevent token theft and misuse. But what does that component
trusted device, in the correct location, architecture look like?
performing the correct function - the Many of these tiny devices lack the ability
same use case as when a new employee to communicate over HTTP and require
joins an organization. communication brokers to translate from
lower level protocols such as CoAP and
Second, can the data that a monitoring MQTT. These brokers have management
device collects be trusted? Are there any

IoT Component Architecture

The IoT landscape contains a mixture of hardware, software, and services components that will be deployed in a variety of scenarios or phases.

Figure 1 shows a basic architecture from a service-interaction perspective. This scenario focuses primarily on how data flows from
a set of devices to a centralized hub or cloud service. The assumption here is for constrained devices - devices that cannot natively
communicate over HTTP. They often require a communications broker that can translate lower level protocols such as CoAP or
MQTT to HTTP.

“Little data” generated locally by the devices transforms into “big data” as it travels to a centralized store in the cloud. Data in
isolation has little value, but when aggregated, the data offers useful insight that can improve processes or identify common trends.

5. https://www.accenture.com/us-en/insight-industrial-smart-production

Copyright © 2016 ForgeRock, All Rights Reserved. 7

The cloud service could represent an Figure 1: Basic IoT Template Architecture - Services
analytics platform in the operational
technology (OT) landscape. Da
Big ta
SEMANTIC
ANALYTICS

OAuth2 device flow, will be used to pair DISTRIBUTED API

STORAGE PUBLICATION
a device to a physical individual, with
backend cloud services being used Cloud
for everything from profile and device Services
registration, relationship management,
and access control as well as data CENTRALIZED DATA
QUERY SHARING
capture, management and reporting.
The backend infrastructure will often
consist of microservices style systems, HTTPS
with multiple APIs being chained and
accessed simultaneously, perhaps
requiring high scale token issuance and
introspection using techniques such as Local Brokers
stateless JSON Web Tokens coupled
with proof-of-possession security CoAP MQTT
Low Power
architectures. Networking & Comms

IoT Component CUSTOMER M2M

DEVICES MANUFACTURING
Architecture L it
tl e D a t a
INTRANETS
SENSORS
Combined
with Identity
regardless of location, to empower digital transformation. There are several identity
The IoT component architecture is a integration touch-points where registration, authentication, and authorization services
complex, evolving landscape and has are available. In short, an identity solution should be capable of the following:
a strong focus on interoperability and
data management. Traditional IAM Identity Registration
This is the simple use-case of a persona providing attribute values to a persistent store. The
internal use to assist with manual on basic self-service form, or perhaps a social login, can be used here; a web service ultimately
and off-boarding and to establish access
privileges to company data and systems consumer IoT market.
behind the firewall. Today, a company
must implement a dynamic identity Device Registration
solution that is capable of serving
and connecting employees as well
as customers, partners, and devices, capabilities. So how does the device register? And to what does it register? The device

Copyright © 2016 ForgeRock, All Rights Reserved. 8

needs a network and the ability to send a Figure 2: IoT Constrained Device Template Architecture
JSON object or some other representation
Da
of itself to a service that can capture such Big ta
REST / JSON
data. The device identity data may need to
ATTRIBUTE
OAUTH2 / OIDC CAPTURE

thing attempting registration is actually real

and not a fake.
Cloud
Services

Device-to-Identity Linking SHARED SYNCING AND

SECRETS VERIFICATION
There are now a minimum of two
identities; one is a set of attributes that
map to a person, the other is a set of HTTPS
OAUTH2 / OIDC

to a certain degree of assurance; then

relationships between the identities can
Local Brokers
SHARED SECRETS / JWT
PKI / CERT MATERIAL
be built. For example, the device owner
CoAP MQTT
wants to claim ownership of the device
Low Power
Networking & Comms
via a linking process, entering a code or
the GUID or in some other way proving
OWNER REGISTRATION DATA POLICY
possession of the thing and that the thing DEVICE REGISTRATION CHECKING

is real. This is typically achieved using DEVICE DATA

L it PUBLICATION
tl e D a t a AUTHN/AUTHZ

Device Authorization Figure 2 outlines some example key protocols and standards that may be leveraged

Once a device is paired to an individual,

it will generally receive token material
that it can use against APIs and services,
to upload or access data. These token Device Data-Sharing captured or perhaps even to a level of
materials - often OAuth2 access and Picture a device that is authenticated access to the device itself. This three-way
refresh tokens, need to be protected to a service or API and perhaps is also interaction requires that simple registration
whilst in transit, generally with TLS. and authorization decisions be made in
In addition, proof-of-possession style to a third-party service or is at least a way that both humans and devices can
bearer token protection approaches, capturing data that can be shared with understand, easily revoke, and sustain.
can be used to bind token materials a third party service. What is the best
to specific devices using public key method of sharing that data effectively in Multifaceted Relationships
technology. This can help reduce token a transparent and simple way? OAuth2 The more relationships the individual
misuse from theft or man-in-the-middle and the more recent UMA standard can has with things, the more chance
style attacks which may be more help here. They enable third parties that there will be relationships between
common in device lead infrastructures. cannot be controlled directly to gain those things, and certainly there

access to the data that the device has will be many-to-many relationships

Copyright © 2016 ForgeRock, All Rights Reserved. 9

 Figure 3: Basic IoT Smart Device Template Architecture
devices. How can those relationships
be handled? Two angles must be
addressed - persistent relationship
Pairing
storage (the personal identity contains
sub-attributes, i.e., device objects) and
CONSUMER
temporary storage of relationships with DEVICE

data consumers.
HTTPS HTTPS

Device Deregistration
The consumer and enterprise worlds
both need to remove a device from
the IoT landscape when, for example,
the device changes ownership. A
deregistration or deprovisioning process
is needed to remove any associations,
credentials, certificate materials,
configuration, and relationship data.
HTTPS
That deprovisioning process may be
scheduled, be based on a trigger event,
or be done via manual disassociation.
API API API API

Permission Revocation
An entire device may be deprovisioned
or only certain attributes or permissions
Verification Monitoring Device Analytics
associated with the device or the Management

data that the device has captured.

The second approach is likely to be Figure 3 shows a classic smart device architecture, typically seen in the consumer
identity world. Many services and API interactions will be completed over HTTPS using
employed in federated authorization
landscapes that have multiple temporary
relationships between data owners, data Logging and Event Analytics
consumers, and data custodians. Such All of the device interactions, from and authentication and authorization

relationships could be accomplished registration and association to a broker services do. A mechanism is needed

via the use of token revocation or person, through to data capturing to identify unique devices and their

infrastructures such as OAuth2 or and publication, must be logged and associated transactions, and perhaps to

through things such as the expire at analyzed for things like fraudulent or correlate them to other identity-related

(exp) attribute within a JWT claim. malicious use. Devices themselves may actions and activities. This would provide

not be able to log or generate log data, a complete 360-degree view of the

but central hubs, registration services, transaction landscape.

Copyright © 2016 ForgeRock, All Rights Reserved. 10

Identity for IoT: The ForgeRock Identity Platform

ForgeRock ® secures digital identities for people, devices, and connected things online. The ForgeRock Identity Platform™ is the
only commercial open source offering for access management, identity management, directory services, and an identity gateway,
designed and built as a single platform, with a single REST API for invoking any identity service. IoT ready and flexible enough
to handle any digital application on premises or in the cloud, our platform scales to handle hundreds of millions of identities and

because it can fully support and secure device identities throughout the device lifecycle, from registration to deprovisioning. It is
a rich and flexible model that allows organizations to do what they do best, building products, while we make it easy to securely
connect them to the internet. At ForgeRock, we treat all identities equally – no matter who, or what, they are. We help you to build
trusted relationships with customers, employees, partners, and things anywhere, on any device.

The ForgeRock Identity Platform, built from the OpenAM, OpenIDM, OpenDJ, and OpenIG open source projects, includes
these solutions:

ForgeRock Access Management

ForgeRock Access Management is a single, unified solution providing advanced authentication, mobile authentication, authorization,
federation, single sign-on, social sign-on, adaptive risk, privacy and consent, and session management all in one self-contained
Java application.

ForgeRock Identity Management

ForgeRock Identity Management is a lightweight user administration and provisioning solution purpose-built for Internet scale. It is
easy to embed and deploy, with a small footprint and out-of-the-box REST interfaces that use standard Java development tools. It
includes role based provisioning, high availability, workflow synchronization (with delivery guarantees) support for SaaS connectors,
customizable user interfaces requiring no programming and password management. Our Identity Management solution uses the
Open Identity Connector Framework and Toolkit (OpenICF) to aid development of resource connectors.

ForgeRock Directory Services

ForgeRock Directory Services is a LDAP directory server — the first-ever directory natively supporting REST — with a flexible
access model that lets developers choose between REST, LDAP or web services. The 100% Java-based LDAPv3- compliant server
is extremely efficient with minimal CPU, memory and on-disk footprint. Lightweight and easy to embed, it allows users to easily
share real-time identity data across enterprise, cloud, social, and mobile environments.

ForgeRock Identity Gateway

ForgeRock Identity Gateway is an IoT, mobile application and API gateway, enabling consistent enforcement of enterprise access
policies for applications and APIs on premises or in the cloud, whether they are legacy or modern. Our Identity Gateway solution
provides a simple standards based approach to extend identity to any web application and API that utilizes HTTP including OAuth2,
OpenID Connect, SAML, and UMA.

ForgeRock enables leading digital organizations to deliver innovative IoT products and services. Figure 4 shows how the ForgeRock
Identity Platform builds trusted relationships throughout the device lifecycle.

Copyright © 2016 ForgeRock, All Rights Reserved. 11

Figure 4: The ForgeRock Identity Platform and the Internet of Things

HTTP

Smart Things DIRECTORY

SERVICES

Constrained Things
ACCESS IDENTITY
MANAGEMENT MANAGEMENT

MQ
TT
DEVICE AUTHENTICATION
& AUTHORIZATION

Broker
AP
CO
DEVICE REGISTRATION
& SYNCHRONIZATION

The Future

The drive for the increased “online-ification” of previously dumb devices, and the improved data collection and analytics capabilities
associated with existing devices, will undoubtedly continue. The resulting data - from a generator, owner, custodian, and sharing
perspective - will require a high level of internal and external security controls in which identity relationship management, including
registration, linking, authentication, authorization, and context, will have a key role to play. How those identity services are applied
depends, of course, on the underlying device architecture and the native protocols and standards being used, but modularity,
scalability, and extensibility will play a significant role.

it seems the end result of increased connectivity and data collection is yet more data. The key value of that data in the consumer
world is personalization and service improvement. From an operational technology (OT) standpoint, that data is used to power
predictive analytics and efficiency platforms, that can help to build a competitive advantage.

Whether the IoT solution is focused on customer service and improved experiences, healthcare monitoring, energy efficiency within
a “smart city,” or helping to develop autonomous machines within the Industry 4.0 landscape, data is what drives new revenue
and business development opportunities. This basic approach, building on the principles of the Unix pipeline (where the output of
one function becomes the input into another), will provide new business opportunities ranging from service improvement to more
predictive and self-managing objects.

Copyright © 2016 ForgeRock, All Rights Reserved. 12

Glossary

Communications Protocols
Bluetooth Low Energy (BLE) – BLE is a “smart” version of the Bluetooth standard especially for ultra power efficiency and intricate application deployment [1].

Constrained Application Protocol (CoAP) – CoAP is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy)
networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet-error
rates and a typical throughput of tens of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation [2].

IP6 Over Low Power Personal Area Networks (6LoWPAN) – Well-established fields such as control networks, and burgeoning ones such as sensor (or transducer)
networks, are increasingly being based on wireless technologies. Most (but certainly not all) of the nodes these networks employ are among the most constrained that
have ever been networked wirelessly. Extreme low power (so low that nodes will potentially run for years on batteries), extreme low cost (total device cost in dollars is

numerous low-power, low-memory devices [3].

Message Queue Telemetry Transport (MQTT) - MQTT is a publish-subscribe-based lightweight messaging protocol for use on top of the TCP/IP protocol. It is designed
for connections with remote locations where a small code footprint is required and/ or network bandwidth is limited. The Publish-Subscribe messaging pattern requires a
message broker, which is responsible for distributing messages to interested clients based on the topic of a message [4]

Data Handling
JavaScript Object Notation (JSON ) - JSON is a lightweight data-interchange format that is easy for humans to read and write and for machines to parse and generate.
It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language
independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others.
These properties make JSON an ideal data-interchange language [5].

Representational State Transfer (REST) – REST is an abstraction of the architecture of the World Wide Web; more precisely, REST is an architectural style consisting of
a coordinated set of architectural constraints applied to components, connectors, and data elements within a distributed hypermedia system. REST ignores the details of
component implementation and protocol syntax to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation
of significant data elements [7].

Authentication, Authorization, and Privacy Standards

OAuth2 – OAuth 2.0 is the next evolution of the OAuth protocol, which was originally created in late 2006. OAuth 2.0 focuses on client developer simplicity while providing
specific authorization flows for web applications, desktop applications, mobile phones, and living-room devices. This specification is being developed within the IETF
OAuth WG and is based on the OAuth WRAP proposal [8].

OpenID Connect (OIDC) – OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on
the authentication performed by an Authorization Server, as well as to obtain basic profile information about the enduser in an interoperable and REST-like manner.

OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and
end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and
session management when it makes sense for them [9].

User Managed Access (UMA) – UMA is a profile of OAuth 2.0 that defines how resource owners can control protected-resource access by clients operated by arbitrary
requesting parties. The resources may reside on any number of resource servers; a centralized authorization server governs access based on resource-owner policy. This
revision of the specification is part of the UMA “candidate V1.0” process [10].

Copyright © 2016 ForgeRock, All Rights Reserved. 13

Access In Constrained Environments (ACE) – The Provisioning JavaScript Web Token (JWT) – JWT is a compact,
IETF has recently developed protocols for use in Lightweight Machine-to-Machine (LWM2M) – The URL-safe means of representing claims to be
constrained environments, where network nodes motivation of LWM2M is to develop a fast deployable transferred between two parties. The claims in a
are limited in CPU, memory, and power. REST JWT are encoded as a JSON object that is used
architecture is widely used for such constrained to machine service. LWM2M is principally a device as the payload of a JSON Web Signature (JWS)
environments. Internet protocols can be applied management protocol, but it should be extended to meet structure or as the plaintext of a JSON Web
to these constrained environments and often only the requirements of applications and to transfer service Encryption (JWE) structure, enabling the claims to
require minor tweaking and profiling. In other cases, and application data. LWM2M implements the interface be digitally signed or MACed and/or encrypted [14].
new protocols have been defined to address the between M2M device and M2M Server, which gives the
specific requirements of constrained environments. Service Provider the choice to provide service to M2M JavaScript Object Signing & Encryption (JOSE)
An example of such a protocol is the Constrained users [11]. – JOSE is a text format for the serialization of
Application Protocol (CoAP). structured data described in RFC 4627 that is often
Open Identity Connector Framework (OpenICF) used for serializing and transmitting structured
As in other environments, authentication and – An ICF connector allows provisioning software data over a network connection. With the increased
authorization questions arise in constrained such as OpenIDM to manage identities maintained usage of protocols in the IETF and elsewhere,
environments. For example, a door lock has to by a specific identity provider. ICF connectors there is now a desire to offer security services that
authorize a person who is seeking access using a provide a consistent layer between target resources use encryption, digital signatures, and message
digital key. Where is the authorization policy stored? and applications and expose a set of programming authentication code (MAC) algorithms that carry their
How does the digital key communicate with the lock? functions for the full lifecycle of an identity [12]. data in JOSE format [15]
Does the lock interact with an authorization server
to obtain authorization information? How can access System for Cross-Domain Identity Management Scripting and Extensibility
be temporarily granted to other persons? How can (SCIM) Key to an IoT platform is the ability to develop
access be revoked? Such questions have been user identities in cloud-based applications and services extensions or manage metadata and logic.
answered by existing protocols for use cases outside Leveraging nonproprietary and widely adopted
constrained environments; however, in constrained experience with existing schemas and deployments, languages that require limited deployment effort or
environments, additional and different requirements no compilation allows for rapid adoption and simpler
pose challenges for the use of various security and integration, while applying existing authentication, interoperability and mashups.
protocols. In particular, the need arises for a dynamic
to reduce the cost and complexity of user-management JavaScript (JS) – JS is a dynamic computer
clients and/or resource servers are constrained [19]. operations by providing a common user schema and programming language most commonly used as
extension model, as well as by binding documents to part of web browsers. Implementations allow client-
Fast Identity Online (FIDO) – The FIDO Alliance is provide patterns for exchanging this schema using side scripts to interact with the user, control the
a 501(c)6 non-profit organization nominally formed standard protocols. In essence, SCIM makes it fast, browser, communicate asynchronously, and alter the
in July 2012 to address the lack of interoperability cheap, and easy to move users into, out of, and around document content that is displayed. JS is also used
among strong authentication devices as well the cloud [20]. in server-side network programming with frameworks
as the problems users face with creating and such as Node.js as well as in game development and
remembering multiple user names and passwords. Cryptography the creation of desktop and mobile applications [16].
The FIDO Alliance plans to change the nature of Cryptography will apply at all stages of the data flow,
authentication by developing specifications that from basic HTTP/SSL-style communication within the Lua – Lua is a powerful, fast, lightweight,
define an open, scalable, interoperable set of cloud to the communication methods at the device embeddable scripting language. Lua combines
mechanisms that supplant reliance on passwords level. Encryption of data objects and data at rest is simple procedural syntax with powerful data
to securely authenticate users of online services. also a priority, but should be no different from a non- description constructs based on associative arrays
This new standard for security devices and browser IoT environment. and extensible semantics. Lua is dynamically
plugins will allow any website or cloud application to typed, runs by interpreting bytecode for a register-
interface with a broad variety of existing and future Datagram Transport Layer Security (DTLS) – The based virtual machine, and has automatic memory
FIDO-enabled devices that the user has for online DTLS protocol provides communications privacy management with incremental garbage collection,
security [18]. for datagram protocols. The protocol allows client/ making it ideal for configuration, scripting, and rapid
server applications to communicate in a way that prototyping [17]
prevents eavesdropping, tampering, or message
forgery. Based on the Transport Layer Security
(TLS) protocol, DTLS provides equivalent security
guarantees [13].

Copyright © 2016 ForgeRock, All Rights Reserved. 14

References

[1] - Bluetooth Smart https://www.bluetooth.org/en-us/marketing/bluetoothsmart-technology

[2] - CoAP IETF Draft Standard https://tools.ietf.org/html/draft-ietf-core-coap-18
[3] - 6LowPAN IETF Working Group https://datatracker.ietf.org/wg/6lowpan/charter/
[4] - MQTT http://mqtt.org/
[5] - JSON http://www.json.org/
[6] - EXI http://www.w3.org/XML/EXI/
[7] - REST http://en.wikipedia.org/wiki/Representational_state_ transfer
[8] - OAuth2 http://oauth.net/2/
[9] - OpenID Connect http://openid.net/connect/
[10] - User Managed Access https://docs.kantarainitiative.org/uma/draft-uma-core.html
[11] - Lightweight Machine to Machine http://technical.openmobilealliance.org/Technical/technicalinformation/release-program/current-releases/omalightweightm2m-v1-0
[12] - Open Identity Connector Framework http://openicf.forgerock.org/
[13] - Datagram Transport Layer Security https://tools.ietf.org/html/rfc6347
[14] - JavaScript Web Token https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32
[15] - JavaScript Object Signing & Encryption https://datatracker.ietf.org/wg/jose/charter/
[16] - JavaScript http://en.wikipedia.org/wiki/JavaScript
[17] - Lua http://www.lua.org/about.html
[18] - Fast Identity On Line https://fidoalliance.org/about
[19] - Access in Constrained Environments https://datatracker.ietf.org/wg/ace/charter/
[20] - SCIM http://www.simplecloud.info/
[21] - Groovy Programming Language http://groovy.codehaus.org/

About ForgeRock
The ForgeRock Identity Platform™ transforms the way millions of customers, prospects, and citizens interact with businesses and
governments online, providing better security, building relationships, and enabling new cloud, mobile, and IoT offerings from any
device or connected thing. ForgeRock® customer identity serves hundreds of brands globally, like Morningstar, Vodafone,
GEICO, and the government of Norway.

For more information visit http://www.forgerock.com and follow us on Twitter @forgerock

Copyright © 2016 ForgeRock, All Rights Reserved. 11/16 15