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 general-purpose 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 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 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 only be verified by the home agency, PIV IdPs operated by third parties would need close integration with those issuing home agencies in order to be capable of verifying those authenticators.
The IdP SHALL issue an assertion within a valid session lifetime at the IdP, subject to the session management requirements of the IdP.
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 has not been terminated). To provide timely and accurate status information, home agency IdPs SHOULD derive this directly from the home agency’s authoritative records, such as its enterprise identity management system.
Note: for PIV IdPs using PKI-based PIV credentials as the only authenticators, the active status of the PIV identity account could be partially inferred from the validity of the certificate used for authentication. As long as revocation and expiration checks of the certificate are processed, a valid certificate is likely to indicate a valid PIV identity account. However, the 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. Additionally, the status of a certificate from a terminated PIV identity account may not be immediately reflected in the associated certificate revocation list, as Section 2.9.1 of [FIPS201] allows for 18 hours to complete the revocation process.
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:
The federated identifier SHOULD be stable over time for a PIV identity account at an IdP. To protect privacy, the IdP SHOULD use an unguessable value for the subject identifier, such as the output from an approved random-number generator or a value derived from an approved derivation method for the subject. 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 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].
\clearpage
When using a subscriber-controlled wallet, the PIV IdP SHALL follow all requirements for subscriber-controlled wallets as defined in [SP800-63C]. The following additional requirements also apply:
PIV RPs SHALL follow all of the requirements for RPs enumerated in [SP800-63C].
The RP SHALL verify that all assertions contain all required elements as 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 a federated login with a local account record. This record is defined as the RP subscriber account in [SP800-63C]. The RP subscriber account can contain things like access rights at the RP as well as a cache of identity attributes for the subscriber.
Each federated identifier, as described in Sec. 6.2.1, SHALL be associated with a single RP subscriber account. 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 RP MAY associate multiple federated identifiers with a single RP subscriber account to perform account binding as discussed in [SP800-63C]. The RP MAY allow access to the RP subscriber account with a locally-verified authenticator, but when such an action is taken, access to the RP is not considered PIV federation.
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.
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.