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. (reference below)

Example of an ID Token from the OpenID Connect spec.

 {
   "iss": "https://server.example.com",
   "sub": "24400320",
   "aud": "s6BhdRkqt3",
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,
   "iat": 1311280970,
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
 }

Two specific fields that can serve as the basis for assurance statements.

• acr - for AAL2+

  OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied. The value "0" indicates the End-User authentication did not meet the requirements of ISO/IEC 29115 [ISO29115] level 1. Authentication using a long-lived browser cookie, for instance, is one example where the use of "level 0" is appropriate. Authentications with level 0 SHOULD NOT be used to authorize access to any resource of any monetary value. (This corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] nist_auth_level 0.) An absolute URI or an RFC 6711 [RFC6711] registered name SHOULD be used as the acr value; registered names MUST NOT be used with a different meaning than that which is registered. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The acr value is a case sensitive string.

• amr - for IAL2+

  OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The definition of particular values to be used in the amr Claim is beyond the scope of this specification. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The amr value is an array of case sensitive strings.

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 IdP is not the intended target of FIDO or Web Authentication, but raht the RP is the expected place where assurance is needed and acquired.
• 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,
5. ID tokens need to carry more types of assurances than the single level issuser that is the current implementations support. For example these requirements are all to be addressed by the proposed changes:
   1. must have an identity assurance from a trust authority
   2. must have an authentication assurance from a trust authority
   3. must enforce that any id-token comes with (or after) a user consent to share data
   4. must allow all users to create self-issued identifiers and can be attested to above criteria.
   5. recommend that future changes can support federation assurance level 2

References

• Matching patient health care records and interoperability among Electronic Health Records (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.