This document was created to standardize the way Identity Assurance Levels are communicated electronically. While designed with OpenID Connect in mind, this can be applied to other systems including LDAP, SAML, 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 IAL2. Communicating an IAL of 1, 2, or 3 was the motivation of this document, but it also provides a basic mapping for AAL. See scope and security sections for use and implementation guidance. See https://csrc.nist.gov/publications/detail/sp/800-63/4/draft
Identity Assurance Level IAL Value |
VoT Identity Proofing P Value |
|---|---|
| IAL1 | P1 |
| IAL2 | P2 |
| IAL3 | P3 |
Autheticator Assurance Level AAL Value |
VoT Credential C Value |
|---|---|
| AAL1 | C1 |
| AAL2 | C2 |
| AAL3 | C3 |
The URL to this public Github repository serves as the Trustmark itself. The value of the vtm field shall be https://github.com/TransparentHealth/800-63-3-trustmark/.
The is a Vectors of Trust Trustmark based on NIST SP 800-63-3 Digital Identity Guidelines. 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)
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.
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/800-63-3-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.
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 illustration:
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