Conveying Identity and Authenticator Assurance Levels in OpenID Connect and Beyond in Healthcare

Conveying Identity and Authenticator Assurance Levels in OpenID Connect and Beyond in Healthcare

1. Standards and the Proposed Rule

NIST's Special Publication 800-63-3 Digital Identity Guidelines outlines 3 identity assurance levels, "1", "2", and "3" to codify how well a person is or isn't, with 1 being a low confidence a person is who they say they are.  Similarly, Authentication Assurance Levels (AALs) of "1", "2", and 3" are also defined in NIST guidelines.  IAL details the  "login" or Authentication event.

In ONC's proposed rule, "21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program", OpenID Connect is proposed in the following passage:  

To enable and support persistent user authentication and app authorization processes, we propose to adopt a standards and additional implementation specification for the FHIR standard. First, we propose to adopt the “OpenID Connect Core 1.0 incorporating errata set 1” standard in § 170.215(b) as it complements the SMART Application Launch Framework Implementation Guide Release 1.0.0  (87) (SMART Guide). The OpenID standard is typically paired with OAuth 2.0 implementations and focuses on user authentication.

The NIST's Guidelines do not provide specific guidance on implementation within Identity providers such as OpenID Connect, LDAP, and SAML. This article proposes a common way to express these important pieces of information across such systems and systems which rely on them.

2. Authentication and Multi-Factor Authentication (AAL)

With respect to Authentication the text of the proposed rule specifically asks for guidance on the requirement for multi-factor authentication. It  calls out "NIST 800-63-3B" by name. NIST 800-63-3B, entitled "Authentication and Lifecycle Management" is in the proposed rule in the following excerpt:

"...However, despite the benefits of adopting MFA, we are also aware of some of the challenges. Specifically, in health care, many providers are resistant to adopt MFA because of the inconvenience and loss of time of going through another step to access the patient's EHI. Also, MFA has not been deployed very long in the health care setting, so it is not clear how much it actually addresses the risk. In most MFA implementations, passwords are still present. In addition to having to manage passwords, users also have to manage an additional layer of security. Another usability challenge is that systems often require different types of MFA, which adds to the complexity and also may require providers to keep track of tokens. MFA is often recommended as a solution to password problems, but it is still vulnerable to theft. These alternative forms of authentication have their own set of vulnerability issues. The cost of implementing MFA and ensuring it will be implemented in a way that does not inhibit clinical workflow is also an issue to be considered.

To provide clarity as to what a “yes” attestation for “multi-factor authentication” attestation would mean, we provide the following explanation. MFA requires users to authenticate using multiple means to confirm they are who they claim to be in order to prove one's identity, under the assumption that it is unlikely that an unauthorized individual or entity will be able to succeed when more than one token is required. MFA includes using two or more of these: (i) Something people know, such as a password or a personal identification number (PIN); (ii) something people have, such as a phone, badge, card, RSA token or access key; and (iii) something people are, such as fingerprints, retina scan, heartbeat, and other biometric information. Thus, in order to be issued a certification, we propose to require that a Health IT Module developer attest to whether or not its certified health IT supports MFA consistent with industry recognized standards (e.g., NIST Special Publication 800-63B Digital Authentication Guidelines, ISO 27001).

We propose that, for health IT certified prior to a subsequent final rule's effective date, the health IT would need to be certified to the “multi-factor authentication” certification criterion within six months after the final rule's effective date. For health IT certified for the first time after the final rule's effective date, we propose that the health IT must meet this criterion at the time of certification. This should allow sufficient time for health IT developers to assess their Health IT Modules' capabilities and attest “yes” or “no” to the certification criterion.

We generally seek comment on whether there is value in adopting the proposed “multi- factor authentication” criterion. We also solicit comment on the method of attestation and, if the health IT developer does attest to supporting MFA, whether we should require the health IT developer to explain how they support MFA. For example, should the health IT developer be required to identify the MFA technique(s) used/supported by submitting specific information on how it is implemented, including identifying the purpose(s)/use(s) to which MFA is applied within their Health IT Module (such as where in the clinical workflow it is required), and, as applicable, whether the MFA solution complies with industry standard? This information could enable the health IT developer to highlight their health IT's capabilities to support MFA."

3. Identity Assurance (IAL)

With respect to verifying a person's identity, the the proposed rule does not make any specific standards reference such as NIST 800-63-3A Enrollment and Identity Proofing requirements, It is however stated more than once in the proposed rule that NOT being able to verify an actor's identity is a reason not to release Personal Health Information (PHI). The following excerpt blocking is with respect to the prohibition on information blocking rule.  See the following excerpt form the proposed rule concerning information blocking:

"The HIPAA Privacy Rule, and many state privacy laws, authorize the disclosure of PHI in certain circumstances only once the identity and authority of the person requesting the information has been verified. We acknowledge that it is reasonable and necessary that actors take appropriate steps, consistent with federal and state laws, to ensure that EHI is not disclosed to the wrong person or to a person who is not authorized to receive it. Where an actor cannot verify the identity or authority of a person requesting access to EHI, and such verification is required by law before the actor can provide access, exchange, or use of the EHI, the actor’s refusal to provide access, exchange, or use will, subject to the conditions discussed herein, be reasonable and necessary and will not be information blocking."

It is my opinion that NIST Identity Assurance Level 2 is a reasonable standard for access to health information. IAL 2 requires some "real-world existence of the claimed identity". The test in NIST Digital Identity Guidelines are as follows:

IAL2: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL2 can support IAL1 transactions if the user consents.

When it comes to patient access, the credentials used to access the patient portal and to authorize 3rd party application are one and the same.  Many health care providers give patients a signup code to set up their online account in person after their ID has been checked at check in.  For example, I was given my DukeMyChart account access upon leaving my primary care doctor's office. My driver's license was checked upon check in.  In many ways, this process meets most of the requirements  set for for IAL 2, although clear guidance is not in the proposed rule.

4. Applying Vectors of Trust as a Common "Way to Say it"

Whether or not the final rule outlines the NIST guidelines or not, what we, as an industry, need is a standard way of conveying Authenticator Assurance Levels (e.g. MFA or Single-factor) and Identity Assurance Levels.  There is a standard for communicating this information in  OpenID Connect, Vectors of Trust, but there is no direct mapping to NIST 800-63-3.  To this end I've made a simple 1-to-1 mapping which can be found here: https://github.com/TransparentHealth/800-63-3-trustmark

What if we want to store Identity Assurance Level (IAL) information in LDAP or SAML?  We do not have clear guidance or standards on that front.  I propose that the US healthcare industry adopt the field and value format defined in Vectors of Trust even in implementations beyond OpenID Connect.  For example, an LDAP  service could store and report an IAL of "1", "2", "3" by adding a custom attribute "vot" with the  values "P1", "P2", or "P3".  Such information could also be obtained in the user profile response using a user's valid OAuth2 access token.  It would not be okay to obtain Authenticator Assurance Level information in the same way however, because the authentication refers to a specific authentication event when the user is present, and an OAuth2 access token can be used when the user is not present.  The Vectors of Trust specification only covers how to do this within an OpenID Connect ID token, but we should really also standardize on the field's name and the expected content in other contexts.  For this we could still use Vectors of Trust.

5. Looking Forward

Such details and considerations need to be formalized into a profile. Additional work is needed to build the kind of data fluidity that we all deserve.  At Transparent Health we  will continue to pursue interoperability through standards. If you, or your organization, would like to help in these efforts, please get in touch.

Alan Viars
alan at transparenthealth dot org