Phone as Personal Identifier Provider: Difference between revisions
Jump to navigation
Jump to search
| (4 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== | ==Challenge== | ||
* User want to be in control of their own private information. | * User want to be in control of their own private information. | ||
| Line 23: | Line 19: | ||
==Benefits== | ==Benefits== | ||
* The | * 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: | |||
#SP 1800-xxA: Executive Summary (PDF) | |||
#SP 1800-xxB: Approach, Architecture, and Security Characteristics (PDF) | |||
#SP 1800-xxC: How-To Guides (PDF) | |||
==References== | ==References== | ||
* This wiki page is derived, in part, from the [[Privacy Enhanced by User Agent]] created by Tom Jones in September 2013. | * 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. | *[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]] | *[[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://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. | *[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:
- SP 1800-xxA: Executive Summary (PDF)
- SP 1800-xxB: Approach, Architecture, and Security Characteristics (PDF)
- SP 1800-xxC: How-To Guides (PDF)
References
- This wiki page is derived, in part, from the Privacy Enhanced by User Agent created by Tom Jones in September 2013.
- Self-Issued OpenID Connect Provider DID Profile DIF Working Group Draft
- 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.
- 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.