IAL2 Claims Tokens

Specification v3.4.0, section III.D and III.E

D. IAL2 Claims Tokens

A patient-facing app SHALL include a CSP-issued IAL2 Claims Token in a query to match a patient. For purposes of this framework, an "IAL2 Claims Token" means a signed OpenID Connect ID token issued by a CSP after identity proofing to at least NIST IAL2. The presence of a valid IAL2 Claims Token provides high-confidence evidence regarding the provenance and prior identity proofing of the demographic attributes conveyed in the query and strengthens the Responder's ability to verify that the matching request is being made at the patient's direction.

If an IAL2 Claims Token is included in a query, the Responder SHALL validate the token prior to responding. Validation SHALL include:

1. The token's digital signature using the CSP's published JWKS or other applicable key distribution mechanism
2. The iss claim identifies a trusted CSP. A trusted CSP must use distinct issuer URLs for production and non-production id_tokens.
3. The aud claim identifies the intended relying party, IAS Provider, or other expected audience for the transaction
4. The token is unexpired based on the exp claim, or otherwise within the Responder's maximum acceptable age based on iat; and reasonable checks of token integrity and freshness.
5. Anti-replay controls using the jti claim in combination with issuer context. At a minimum, the Responder SHALL record previously accepted iss + jti values, or maintain equivalent controls, for the applicable token-validity window and SHALL reject subsequent reuse of the same token identifier.

If token validation fails or replay is detected, the Responder SHALL NOT rely on the token or any claim extracted from it for matching or response.

When an IAL2 Claims Token is successfully validated, demographic claims extracted from the token SHALL be used as query demographics for matching. Such demographics SHALL be subject to the same normalization, placeholder suppression, historical-value handling, exact and fuzzy comparison constraints, approved Table 2 combinations, and uniqueness requirements that apply when the same demographics are transmitted directly in the query.

6. Adding additional non-standard claims

The core set of non-standard OIDC claims that are utilized in existing matching specifications have been called out above as “non-standard”. Additional non-standard OIDC verified claims MAY be added to the id_token by labeling them using the following formats:

For CMS-Aligned Networks:

http://<network-specified-url>/OIDC/claim/[claim]

For TEFCA-specific elements:

http://rce.sequoiaproject.org/OIDC/claim/[claim]

E. IAL2 Claim Token Fields