800-63-3-trustmark instead

*NOTICE: Use https://github.com/TransparentHealth/800-63-3-trustmark instead of this document. NIST intends to cover "low assurance identity proofing and enrolment" in revision 4 of Digital Identity Guidelines (SP 800-63-4). Version 4 should be released in the first half of 2022. Please see this GitHub issue for more information https://github.com/usnistgov/800-63-4/issues/1 *

This document was created to standardize the way Identity Assurance Levels are communicated electronically. It is based on NIST SP 800-63-3 (Digital Identity Guidelines), where Identity Assuance Levels are defined as 1, 2, or 3. The Trustmark adds one additional Identity Assurance Level, 1.5. 1.5 is a level to signify some corroborating evidence of identity is given but the Identity Assurance Level does not meet Level 2 as defined by NIST SP 800-63-3 (Digital Identity Guidelines).

The Trustmark Details (Mapping to NIST 800-63-3 and TH 1.5)

Identity Assurance Level `IAL` Value	VoT Identity Proofing `P` Value
IAL1	P1
IAL1.5	P2
IAL2	P2
IAL3	P3

Autheticator Assurance Level `AAL` Value	VoT Credential `C` Value
AAL1	C1
AAL2	C2
AAL3	C3

Details on Use

While designed with OpenID Connect in mind, this Trustmark can be applied to other systems including LDAP, SAML, FHIR, or user profile calls using OAuth2. For example, a user profile request may include the name\value pair vot=P2, to indicate a user has undergone identity proofing to a NIST Identity Assurance Level of IAL 2. Communicating an IAL of 1,,1.5, 2, or 3 was the motivation of this document, but it also provides a basic mapping for AAL and FAL. See scope and security sections for use and implementation guidance.

URL

The URL to this public Github repository serves as the Trustmark itself. The value of the vtm field shall be https://github.com/TransparentHealth/healthca-trustmark/.

Scope

The is a Vectors of Trust Trustmark based on NIST SP 800-63-3 Digital Identity Guidelines. It adds one additional Identity Assurance Level to accomidate health care scenerios.

It was created as part of an effort to establish a best practice for sharing digital identities in a healthcare setting. Entities who are operating or implementing OpenID Connect Identity Providers(IdP) may use this as an implementation guide. While designed with US healthcare in mind, it is not healthcare specific.

Identity Assuance Levels (IAL) as defined in (NIST SP 800-63A: Enrollment and Identity Proofing)
Autheticator Assurance Levels (AAL) as defined in (NIST SP 800-63B: Authentication and Lifecycle Management)

Security Considerations

While communicating IAL is acceptable within a user profile API call, communicating AAL in this way should be avoided. This is because the user profile API call can be made without the user being present. AAL, therefore, should be communicated within an id_token or in some manner which verifies that the user is actually present. The value "C2.P2" is would be appropriate in an id_token but not in the response from a user profile endpoint. In a user profile endpoint, a value of vot="P2" would be acceptable, but a value incluing authenticator assurance information (e.g. vot="P2.C2") should be avoided.

How To Use this Trustmark within an Identity Provider (IdP) That Your Organization Operates

OpenID Connect Provider

Whithin your OpenID Connect Identity Provider, include the folling value in the ink to this repository shall be used as the value of the vtm claim. The votclaim must also be present. The folowing is an example OpenID Connect id_token which is provided to relying parties updon successful authentication.:

{
"issuer": "https://oidc.example.com",
"sub": "12345678901234",
"given_name": "James",
"family_name": "Kirk",
...
"vot": "P2.C2",
"vtm": "https://github.com/TransparentHealth/healthcare-trustmark/",
...
}

Other Identity Providers

The vot value for identity assurance may also be stored in LDAP, Active Directory, or SAML. The document's only guideance is to use the field name vot and to include the value P1, P2, or P3.

How To Use This Trustmark as a Relying Party (i.e. as a client )

Isolate the value of vot to make informed decisions on what a user should and shouldn't be allowed to do.

For example, you may want to limit release health information to the users with an Identity proofing of at least 2.

Below is a pseudocode illustation

payload = get_id_token_payload(idp_callback_verified_response)

if "P2" not in payload["vot"] or "P3" not in payload["vot"]: 
    # Deny Access or begin an ID proofing event
else:
    # Grant access to a resource.
    # Example: Allow Access to an authorization endpoint(to get an oauth2 token).
    # Example: Health data as PDF or JSON

TransparentHealth/healthcare-trustmark