| Trustmark Definition Name | Version |
|---|---|
|
Defines conformance and assessment criteria for verifying that an organization uses FBI authorized originating agency identifiers (ORIs) in each transaction on CJIS systems.
|
1.0 |
|
Addresses the requirement for cross-certified PKI certificate authorities (CAs) to continue to interoperate with the FBCA after the FBCA performs a key rollover.
|
1.0 |
|
Addresses requirements for establishing that an organization requires a Federal Government-issued Picture I.D. for the purpose of identity proofing.
|
1.0 |
|
Identity Providers that exclusively register Relying Parties manually must be sure to exchange all key material required for the trusted relationship in a secure fashion.
|
1.0 |
|
Relying Parties may establish a set of IdPs via a blacklist with whom they do not interoperate.
|
1.0 |
|
Relying Parties may allow authorized parties (usually a subscriber) to establish trust with an IdP of their choosing at runtime.
|
1.0 |
|
Relying Parties may establish a set of trusted IdPs via a whitelist as long as the trusted IdPs adhere to defined federation requirements.
|
1.0 |
|
Identity Providers may establish a set of RPs via a blacklist with whom they do not interoperate.
|
1.0 |
|
Identity Providers may allow authorized parties (usually a subscriber) to establish trust with an RP of their choosing at runtime.
|
1.0 |
|
Identity Providers may establish a set of trusted RPs via a whitelist as long as the trusted RPs adhere to defined federation requirements.
|
1.0 |
|
Identity Providers must include ensure all assertions generated are unique and include fundamental metadata including, subject identifier, issuer identifier, audience, timestamps, a digital signature, and authentication time.
|
1.0 |
|
Identity Providers must send RPs information about the last time the subscriber authenticated to the IdP when engaging in federated login, this is particularly important if the IdP supports long-term sessions.
|
1.0 |
|
All members of a federation must establish parameters for expected and acceptable IALs and AALs for operations within the federation.
|
1.0 |
|
Identity Providers must provide subscribers explicit notice and request confirmation prior to transmitting attributes to an RP. If possible, it should allow subscribers to selectively control the transmission of individual attributes.
|
1.0 |
|
All pairwise pseudonymous subject identifiers must be opaque and should be uniquely issued for RPs. In the rare case where there is a legitimate need for shared pairwise pseudonymous identifiers, an IdP must take precautions to avoid the additional risk of fraud.
|
1.0 |
|
Relying Parties should only use an assertion for a single login event.
|
1.0 |
|
Identity Providers shall not disclose subscriber information to RPs outside of well defined purposes, such federated authentication, related fraud mitigation, to comply with law or legal process, notification of security issues, or in the case of a specific user request, to transmit the information.
|
1.0 |
|
Identity Providers must by default mask sensitive data (e.g. passwords) displayed to the subscriber, although it SHALL allow users to unmask such values if they subscriber so chooses.
|
1.0 |
|
Identity Providers must only transmit attributes that are explicitly requested by RPs.
|
1.0 |
|
Identity Providers that support dynamic registration must make their configuration information available in a way that minimizes administrator involvement (such as dynamic registration endpoints).
|
1.0 |
|
After federation login, a RP may not assume that the subscriber has an active session with their IdP.
|
1.0 |
|
Relying Parties should not assume the ability to fetch supplemental attributes is equivalent to processing assertions.
|
1.0 |
|
Relying Parties should not assume subject identifiers transmitted by IdPs are globally unique as it could cause conflicts with values transmitted by other IdPs.
|
1.0 |
|
Relying Parties should make IAL and AAL determinations exclusively based on data passed within assertions and not make any assumptions about their values.
|
1.0 |
|
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 |
