| Trustmark Definition Name | Version |
|---|---|
|
Identity Providers must not rely on RPs to terminate subscriber sessions when the IdP terminates the subscriber session. It must not rely on such functionality for any security requirement.
|
1.0 |
|
A federation member should not share pairwise pseudonymous identifiers outside of very special circumstances.
|
1.0 |
|
Identity Providers that do not allow direct RP to IdP communication must not use assertion references.
|
1.0 |
|
Identity Providers must generate all assertions with short lifetimes (minimize time between issuance and expiration time) to minimize the risk of replay attacks.
|
1.0 |
|
Relying Parties must not use an assertion past its expiration time.
|
1.0 |
|
Agencies engaging in federated activities must undergo a thorough privacy analysis and impact assessment publishing the results.
|
1.0 |
|
Relying Parties must conduct a privacy risk assessment to determine which attributes to request from IdPs.
|
1.0 |
|
A federation member that shares pairwise pseudonymous identifiers, because of a specific mission need, must thoroughly document the risk of this sharing within their privacy risk assessment.
|
1.0 |
|
Identity Providers operating at higher assurance levels must support holder of key assertions, which must not include an unencrypted private or symmetric key to be used with holder-of-key presentation
|
1.0 |
|
Relying Parties must protect themselves against injection attacks attempting to use captured or manufactured assertions.
|
1.0 |
|
Relying Parties must protect themselves against injection attacks attempting to use captured or manufactured assertion references.
|
1.0 |
|
Identity Providers that use assertion references (e.g. SAML Artifact Profile or OIDC) must protect assertion references and verify that when the reference is presented back to the IdP that the RP presenting it was the RP that was issued the reference (most typically by authenticating the RP).
|
1.0 |
|
Identity Providers must encrypt assertions using approved cryptography.
|
1.0 |
|
All assertions must be digitally signed using approved cryptography. The entire assertion including all metadata must be signed.
|
1.0 |
|
Identity Providers must protect their assertion signing and encryption keys appropriately. This requires the use of FIPS 140 Level 1 for some AALs.
|
1.0 |
|
Identity Providers must have an effective mechanism for subscribers to report problems or complaints.
|
1.0 |
|
During federation registration events for IdPs and RPs, all key exchanges must be done using a secure method. If any symmetric keys are used, they must be unique for each IdP/RP pair.
|
1.0 |
|
Assertions that cover authentication events should include the AAL, and when assertions include identity attributes, they should include the IAL.
|
1.0 |
|
Identity Providers will support attribute references where feasible. Attribute references can be used to minimize revealing PII in cases where an RP only needs to broad issues, for example is the user over 18 as opposed to requesting the user's birthdate.
|
1.0 |
|
Identity Providers supporting lower assurance levels need to support bearer assertions for federated login.
|
1.0 |
|
Credential Service Providers that operate at IAL2 and higher should request user consent before transmitting user data to relying parties that only require IAL1
|
1.0 |
|
Identity Providers SHALL only operate at FALs for which they have demonstrated the ability to operate at appropriately.
|
1.0 |
|
Identity Providers that support dynamically registered RPs must allow subscribers to authorize these RPs before releasing user information to them.
|
1.0 |
|
All assertions must be uniquely identifiable, this may be accomplished using unique identifiers, nonces, and timestamps.
|
1.0 |
|
All assertions must include audience restrictions so that RPs are able to verify they are an intended recipient of the assertion.
|
1.0 |
