High Assurance AZ Token

Full Title

Ensure the security of a stand-alone Token to provide high assurance of (1) Identity, (2) Authentication and (3) Federation in high volume, universally accessed web services.

Context

• The page is directed to the problem of providing high assurance identifier tokens that can be used for high volume use cases, such as health services.
• Existing standards for identifier tokens are based on the assurance of the trust of the Relying Party (aka client) in the tokens produced by the Identifier provider, typically on of the well-known social sites.
• To get high assurance identifiers, the web site that wants the higher level of assurance (whether RP or IDP) will perform additional validation of the user with protocols like FIDO Universal 2nd Factor (U2F) 1.x or Web Authentication (aka Fido 2.0).
• Pew charitable trust and MITRE have recommended the use of the Smart Phone as a source of patient identifiers in healthcare.

Problems

• The IdP needs to be trusted by the RP. That can be difficult to achieve when the RP has the high value resource that the user wants to access.
• The users are accustomed to using the "free" social media sites as an IDP that will be trusted by the RP.
• The liability associated with high assurance IDPs is not likely to be available on "free" social media sites.
• The assurance associated with out-of-band assurance, like web authentication has not been successful with the large number people that are expected to be using high assurance sites, like health services.
• While standards exist for cryptographic operations in software (FIPS 140 and common criteria) there is not similar controls on assuring the identity of users of software, especially on apps running on smart phones.

Proposed Solution

1. Create a structure of a json identifier token that is:
   1. not dependant on the underlying transport media for any integrity.
   2. able to contain parts that come from different attestation authorities (i.e. that are signed by different keys).
2. Enable users to create their own high assurance identifier tokens. (aka self-issued, or self-sovereign identifiers.)
3. Enable federations to create their own specific measures of what factors are needed to meet their environment. They may choose whether to implement centralized, decentralized or distributed means for attesting to the assurance levels that they have specified.
4. Create an infrastructure that can be implemented by federation authorities to certify that users have the ability to meet the high assurance requirements of NIST 800-63-3,

References

• Matching patient health care records and interoperability among EHR have been hard problems to address. Much of the focus has been on the health care providers rather than the patient. But now the patient has guaranteed access to their medical records, they might be able to overcome some of the resistance to sharing seen today. Patient control of the distribution of medical records would give patients both the appearance and the reality of limited access to private health care information. This example of a patient-oriented Native App for them to host on their personal Smart Phone is designed to show how patients might be the best answer to health care sharing in any case.
• The Pew Trust report<ref> Pew Charitable Trust, Enhanced Patient Matching Is Critical to Achieving Full Promise of Digital Health Records. https://www.pewtrusts.org/-/media/assets/2018/09/healthit_enhancedpatientmatching_report_final.pdf</ref> sponsored a collaboration with the Rand corporation and reported this conclusion about an opportunity for a Patient-empowered solution:

  In a report released in August 2018, RAND recommended a patient-empowered approach for matching involving two main components: validating patient information and a smartphone application, which would then be used together once developed.

• MetaData or capabilities from FHIR - might not survive till next versions.
• The H-ISAC Healthcare Information Sharing and Analysis Center provides a forum for coordinating, collaborating and sharing vital Physical and Cyber Threat Intelligence and best practices with each other.
• Authenticate Node section 19 of (2018-07-24) IHE IT Infrastructure Technical Framework primarily relies on mutual authentication with no specific trust anchor other than X.509 certificate chains.
• IDEF health wiki pages.