Phone as Personal Identifier Provider: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
(Created page with "==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...")
 
 
(19 intermediate revisions by the same user not shown)
Line 2: Line 2:
Mobile Device Security: Phone as Personal Identifier Provider (PPIP)
Mobile Device Security: Phone as Personal Identifier Provider (PPIP)
==Context==
==Context==
This is an extension of the [[Phone as Health Care Credential]] proposal to a broader audience of teams interested in high assurance [[Authentication]].
==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===
* [https://ims.ul.com/interoperability-mobile-driver-license-mdl-application Interoperability with Mobile Driver's Licence]
* [[Phone as Health Care Credential]]
==Benefits==
* The user feels like, and is, in control of their data sharing.
==Next Steps==
* This paper is designed to be a proposal to NIST for a SP 1800-xx document in their series of Cybersecure Infrastructure papers.
* 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.
* 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:
#SP 1800-xxA: Executive Summary (PDF)
#SP 1800-xxB: Approach, Architecture, and Security Characteristics (PDF)
#SP 1800-xxC: How-To Guides (PDF)
==References==
==References==
*[[Phone as Health Care Credential]]
* This wiki page is derived, in part, from the [[Privacy Enhanced by User Agent]] created by Tom Jones in September 2013.
* [https://identity.foundation/did-siop/ Self-Issued OpenID Connect Provider DID Profile] DIF Working Group Draft
*[https://www.theverge.com/2019/4/10/18295348/google-android-phone-fido-webauthn-phishing-two-factor-authentication 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]] is one specific vertical instance which was created before this proposal.
*[https://csrc.nist.gov/publications/detail/sp/1800-21/draft SP 1800-21 (DRAFT) Mobile Device Security: Corporate-Owned Personally-Enabled (COPE)]
*[https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2019-11/EPC%20269-19v1.0%20Mobile%20Initiated%20SEPA%20%28Instant%29%20Credit%20Transfer%20Interoperability%20Guidance%20%28MSCT%20IG%29.pdf 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.

Latest revision as of 17:40, 24 May 2020

Full Title

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

Context

This is an extension of the Phone as Health Care Credential proposal to a broader audience of teams interested in high assurance Authentication.

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

Benefits

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

Next Steps

  • 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)

References