Phone as Personal Identifier Provider

Full Title

Mobile Device Security: Phone as Personal Identifier Provider (PPIP)

Context

• This paper is designed to be a proposal to NIST for a SP 1800-xx document in their series of Cybersecure Infrastructure papers.
• It is an extension of the Kantara work to provide such a solution for US Healthcare.
• The following are the 3 parts of a sp 1800 document. We propose an outline of the first part below:

1. SP 1800-xxA: Executive Summary (PDF)
2. SP 1800-xxB: Approach, Architecture, and Security Characteristics (PDF)
3. SP 1800-xxC: How-To Guides (PDF)

Challenge

• User want to be in control of their own private information.
• Accessing some material, like user health information, should be well protected from leakage.
• The common approach to high assurance (IAL2 AAL2) access it to provide a trust and credentialed Identifier Provider that also performs user authentication.
• All past successful attempts to get users to create and maintain high assurance have been driving by enterprise solutions like technology companies or educational institutions.
• Consumers have been unwilling to accept the inconvenience of such high assurance solutions.

Solution

• Put the high assurance identifier in the consumer's hand, in their smart phone.
• They get to have as many identifiers as the want and can select which one to use with which provider.

Mobile Identifier Sources

• Interoperability with Mobile Driver's Licence
• Phone as Health Care Credential

Benefits

• The user feels like, and is, in control of their data sharing.

References

• This wiki page is derived, in part, from the Privacy Enhanced by User Agent created by Tom Jones in September 2013.
• Google will now let you use your Android phone as a physical security key using the phone and PC blue tooth connection.
• Phone as Health Care Credential
• SP 1800-21 (DRAFT) Mobile Device Security: Corporate-Owned Personally-Enabled (COPE)
• Mobile Initiated SEPA (Instant) Credit Transfer (MSCT) Interoperability Guidance from the European Payments Council (EPC) AISBL contains many use case. Many of the use cases appear to require more user entered data than users are likely to tolerate.