Token Content and Validation

IAS replaces plaintext demographic exchange with a signed identity token issued by a Credential Service Provider (CSP). Proper validation of this token is required before initiating retrieval.

Token Structure

An IAS token is formatted as a JSON Web Token (JWT) consistent with OpenID Connect (OIDC) standards.

The token contains:

• Verified identity attributes such as given name, family name, and date of birth
• Additional attributes required for matching, such as address or contact information when available
• CSP metadata, including issuer (iss) and audience (aud)
• Issuance and expiration claims (iat, exp)
• A purpose of use claim, typically T-IAS

Claim names and optional attributes may vary depending on the CSP profile in use.

Demographic Encapsulation

Under the 2024 IAS SOP, demographic attributes are no longer transmitted as individual SAML attributes.

Instead:

• Verified identity attributes are embedded within the JWT claims
• The signed token replaces direct transmission of plaintext demographic fields
• Downstream systems rely on token validation rather than raw demographic exchange

This model reduces exposure of sensitive data during interoperability transactions.

Signature and Key Validation

Each IAS token is digitally signed by the issuing CSP.

Before initiating retrieval, your system must:

• Retrieve the CSP’s JSON Web Key Set (JWKS) from the published endpoint
• Validate the token signature using the appropriate public key
• Confirm that the iss claim matches the expected CSP issuer
• Confirm that the aud claim targets your integration or environment

CSP keys may rotate periodically. Your system should retrieve keys dynamically or honor cache control headers to prevent use of stale keys.

Time Bound Enforcement

IAS identity tokens are time limited.

Your system must:

• Validate that the current time falls within the iat and exp bounds
• Allow only minimal clock skew if required
• Reject expired tokens

If a token expires before retrieval is initiated, obtain a new valid token before retrying.

Demographic Match Enforcement

Before initiating exchange processing, IAS validates that the identity attributes in the verified token match the demographics stored in the tenant Patient resource.

If demographic attributes do not match, retrieval is rejected. This validation step ensures identity integrity prior to exchange activity.

Replay Protection

If a unique token identifier, for example jti, is present, your system should use it to detect and prevent replay.

Tokens must not be modified, reused beyond their validity window, or stored longer than operationally necessary.

Error Handling

Token validation failures may result from:

• Invalid signature
• Issuer or audience mismatch
• Expired token
• Missing required claims
• Demographic mismatch with the tenant Patient record

When validation fails:

• Do not expose token contents in error responses
• Log failure reason codes for operational review
• Obtain a new valid token when appropriate

Proper token validation protects your system and downstream participants from unauthorized or malformed identity assertions.