Mobile Cloud Identity Profile Version 1.0
Committee Note 01
05 August 2013
Anil Saldhana (Anil.Saldhana@redhat.com),
Anthony Nadalin (firstname.lastname@example.org),
Anil Saldhana (Anil.Saldhana@redhat.com),
This document is intended to provide a profile for Mobile Identity Management.
This document was last revised or approved by the OASIS Identity in the Cloud TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.
Technical Committee members should send comments on this document to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “” button on the Technical Committee’s web page at
When referencing this document the following citation format should be used:
Mobile Cloud Identity Profile Version 1.0. 05 August 2013. OASIS Committee Note 01.
Copyright © OASIS Open 2013. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document describes the consumers’ mobile device authentication as an additional strong authentication use case, challenges and applicable standards in the Cloud -As-A-Service (*aaS) model.
P. Mell, T. Grance, The NIST Definition of Cloud Computing SP800-145. National Institute of
Standards and Technology (NIST) - Computer Security Division – Computer Security
Resource Center (CSRC), January 2011. http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
L. Chen, J. Franklin, A/ Regenshcheid, Guidelines on Hardware-Rooted Security in Mobile Devices (Draft), Recommendations of the National Institute of Standards and Technology (NIST) - Computer Security Division – Computer Security
Resource Center (CSRC), October 2012. http://csrc.nist.gov/publications/drafts/800-164/sp800_164_draft.pdf
M.Rutkowski, OASIS Identity in the Cloud Use Cases v1.0, OASIS Standards Consortium,
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. [NISTSP800-145]
A Device Owner is an entity that has purchased and maintains ownership of a mobile device. [NISTSP800-164]
An Information Owner is an entity whose information is stored and/or processed on a device. An Information Owner can be an application-specific provider, a digital product provider, or an enterprise that allows access to resources from mobile devices, for example. Every mobile device has a single Device Owner and one or more Information Owners. [NISTSP800-164]
Device integrity is the absence of corruption in the hardware, firmware and software of a device. A mobile device can provide evidence that it has maintained device integrity if the state of the device can be shown to be in a state that is trusted by a relying party. A device has integrity if its software, firmware, and hardware configurations are in a state that is trusted by a relying party. The mechanism for communicating this trusted state is through one or more assertions that the Device Owner allows a device to make to the Information Owner. A device may establish a unique device identity for the purpose of device authentication. Mobile devices may use assertions to represent the state of firmware as either verified or unverified, the state of an OS as either validated or not, the state of file encryption as either on or off, the state of the microphone as either on or off, etc. [NISTSP800-164]
A device may establish a unique device identity for the purpose of device authentication.
We now look at a typical Mobile Device identity interaction with the Cloud as an Information owner.
Figure 1 : Interaction between Mobile users (using mobile unique attributes as multi-factor authentication) and cloud service
Authentication scenario sequence includes:
This document demonstrates the need to have a standard secure identity authentication to authenticate mobile consumer user that exists in Cloud-based Identity and Access Management services offering identity proofing, credential management, strong authentication, single sign-on, and provisioning solutions when Cloud –based identity service is used as an intermediary between a consumer and a business enterprise.
There is a need to support Federated Identities in any *aaS model.
There is a need to perform authorization of resources and applications by users and processes.
There is a need to ensure secure connection between Mobile Device, Cloud Information Owner and Enterprise Application.
There is a need to authenticate the mobile user.
One potential solution is as follows:
The goal is to identify a user using a secure channel. Sending a hash sets up the channel. The hash is a combination of the phone IMEI Number and the SIM card serial number. The reason these attributes are used is because they are common to all manufacturers and all carriers. They can also be obtained in the same manner independent of a manufacturer and carrier. The hashing is done so none of the info is sent as clear text over a carrier.
There's 2 ways of provisioning:
Once a secure channel is established user authentication is done by means of a certificate and pin.
The standards that are applicable to *-as-a-Service are divided into the following sections.
The following OASIS standards for Federated Identity are applicable:
• OASIS SAML
• OASIS WS-Trust and WS-Federation
• OASIS XSPA profile of SAML
The following OASIS Standards for Identity Management provisioning are applicable:
• OASIS SPML
The following OASIS Standards for Authorization are applicable:
• OASIS OAuth
• OASIS XACML
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Anil Saldhana, Red Hat
Anthony Nadalin, Microsoft
David Turner, Microsoft
Matt Rutkowski, IBM
David Kern, IBM
Chris Kappler, Pricewaterhousecoopers
Abbie Barbir, Bank of America
Dominique Nguyen, Bank of America
Thomas Hardjono, MIT
Jeffrey Broberg, CA Technologies
John Tolbert, The Boeing Company
Gines Dolera Tormo, NEC Corporation
Felix Gomex Marmol, NEC Corporation
Cathy Tilton, Daon
Dale Moberg, Axway Software
David Chadwick, Individual
Gershon Jannsen, Individual
Roger Bass, Individual
Michele Drgon, Individual
May 13, 2013
Anil Saldhana and Dominique Nguyen