This section is normative.
This section details the requirements for IdPs and RPs in a PIV federation context.
PIV IdPs SHALL follow all requirements for IdPs enumerated in [SP800-63C] in addition to the applicable requirements in this section.
All assertions generated by a PIV IdP SHALL follow the requirements enumerated in [SP800-63C]. In addition, all assertions for PIV federation need to follow the requirements in Sec. 6.2.
The PIV IdP SHALL authenticate the subscriber using a valid and current PIV credential, which can be a PIV Card or derived PIV credential bound to the PIV identity account. Note that [FIPS201] specifies that derived PIV credentials must only be bound to a PIV identity account by the issuing department or agency responsible for managing that PIV identity account. By implication, PIV IdPs operated by third parties must still be in a position to verify the validity and currency of PIV credentials issued by the home agency. For PKI-based authenticators, this could be accomplished using PIV authentication certificates and the accompanying certificate status infrastructure. However, because non-PKI-based derived PIV credentials can on be verified by the issuing home agency, PIV IdPs operated by third parties would need close integration with those issuing home agencies to capable of verifying those authenticators.
The IdP SHALL issue an assertion within a valid session lifetime at the IdP. The IdP SHOULD require a recent successful authentication with a PIV credential.
If the RP requests a maximum authentication age, the IdP SHALL reauthenticate the subscriber if the requested authentication age from the RP is not met by the subscriber’s current session at the IdP.
The IdP SHALL issue assertions only for PIV identity accounts that the IdP knows to be valid and current (e.g., the PIV identity account and associated PIV card have not been terminated). To provide timely and accurate status information, home IdPs SHOULD derive this directly from the issuing agency’s authoritative records, such as its enterprise identity management system. For other PIV IdPs using PKI-based PIV credentials as the only authenticators, the status of the PIV identity account could be inferred from the validity of the certificate used for authentication, including revocation and expiration checks. Note that certificate status does not necessarily reflect the status of the associated PIV identity account. A PIV certificate could be expired, or revoked due to compromise, for a cardholder whose PIV identity account remains in good standing. Similarly, a terminated PIV identity account will not be immediately reflected in associated certificate revocation lists.
The IdP SHALL issue a unique federated identifier for each PIV identity account according to the requirements in Sec. 6.2.1, consisting of the logical combination of:
To protect privacy, the IdP SHOULD use a cryptographically random value or a cryptographically derived value for the subject identifier portion of the federated identifier. The federated identifier SHALL NOT contain any personally identifiable information or any personal identifiers, such as the cardholder UUID, in an unencrypted or reversible form. The federated identifier SHOULD be stable over time for a PIV identity account at an IdP.
The IdP SHALL create a secure session with the subscriber after a successful authentication event with a PIV credential using session management, as described in [SP800-63B]. The IdP SHALL record the time of the last successful authentication event for a subscriber within the session associated with that subscriber. This time is used to calculate the authentication age of the session.
In managing the subscriber’s session at the IdP, the IdP SHALL follow all reauthentication guidelines as established in [SP800-63B] and [SP800-63C].
When using PKI-based authenticators such as PIV authentication certificates, an IdP SHOULD require presentation of the certificate for only a specific path that represents the explicit authentication event. This configuration mirrors the verification process for other forms of authenticators and enables the use of a secure session.
PIV RPs SHALL follow all of the requirements for RPs enumerated in [SP800-63C].
The RP SHALL verify that all assertions received contain the requirements enumerated in Sec. 6.2. The RP SHALL reject any assertion that does not meet these requirements.
It is common practice for the RP to associate that login with a local account record, which is defined as the RP subscriber account in [SP800-63C].
The RP subscriber account SHALL be uniquely associated with a single federated identifier, as described in Sec. 6.2.1. The RP subscriber account SHALL NOT rely on any other identifiers within the PIV data record (e.g., card UUID or email address) for uniqueness or tracking a PIV identity account over time.
The presentation of two distinct federated identifiers to the same RP SHALL be treated as two distinct PIV identity accounts from the perspective of that RP.
To minimize the amount of information sent to the RP, RPs SHOULD use just-in-time provisioning for the RP subscriber account, as defined in [SP800-63C], when possible. To avoid data duplication and synchronization issues, the RP SHOULD minimize the amount of data stored in the RP subscriber account.
The RP SHALL NOT allow access to the RP account outside of the context of a verified assertion from a trusted IdP. This includes local authentication with an authenticator known to the RP.
Note that it is possible for an RP to associate the same set of authorizations and attributes to two different RP subscriber accounts, depending on the needs of the RP. The means and details of doing so are outside the scope of this specification.
The RP SHALL create a secure session with the subscriber upon successfully processing the assertion from the IdP. The RP SHALL NOT tie the session lifetime to the lifetime of the assertion. In common practice, the session lifetime at the RP is expected to outlive the validity window of the assertion.
The RP SHALL follow all session management requirements for RPs defined in [SP800-63C].
To facilitate recovery of an account when a federated PIV identity account can no longer be used, an RP MAY change the federated identifier bound to an RP subscriber account in limited circumstances to be recorded in the trust agreement:
When the federated identifier is changed, the RP SHALL make the RP subscriber account inactive and SHALL require a succesful federated authentication using the new federated identifier before considering the RP subscriber account active again. The RP SHALL NOT allow the previously used federated identifier to be used to access the account.
The RP SHALL make a record of any such change, including the identifiers of all affected RP subscriber accounts at the time of the change. The RP SHALL provide notice to the subscriber when a federated identifier is bound or unbound to an RP subscriber account.
The RP SHALL NOT convert an RP subscriber account to be available using local authentication.