View this document as: a single page | multiple pages.

ABSTRACT

FIPS 201 defines the requirements and characteristics of government-wide interoperable identity credentials used by federal employees and contractors. It also calls for the federated use of those credentials. These guidelines provide technical requirements for federal agencies implementing digital identity services for federal employees and contractors and are not intended to constrain the development or use of standards outside of this purpose. This document focuses on the use of federated PIV identity and the use of assertions to implement PIV federations backed by PIV identity accounts and PIV credentials. Federation allows a PIV identity account to be used by relying parties outside the PIV identity account’s home agency.

Keywords

assertions; authentication; credential service provider; digital authentication; electronic authentication; electronic credentials; federations; PIV credentials; PIV federation; identity providers; relying parties.

Note to Reviewers

The family of PIV credentials includes a variety of form factors and authenticator types – as envisioned in OMB Memoranda M-19-22 and M-22-09 and subsequently outlined in FIPS 201-3. The cross-domain and interagency use of these credentials is provided by federation protocols outlined in this public draft SP 800-217 Guidelines for PIV Federation. The companion document, SP 800-157r1 Guidelines for Derived PIV Credentials, details the authenticators themselves. Both documents are closely aligned with draft release SP 800-63-4 Digital Identity Guidelines. NIST hopes that the draft document enable a close alignment with new and emerging digital identity and federation technologies employed in the federal government, while maintaining a strong security posture.

NIST is specifically interested in comments on and recommendations for the following topics:

Home Agency Attributes:

PIV Federation:

Reviewers are encouraged to comment on all or part of both SP 800-157r1 and SP 800-217. NIST requests that all comments be submitted by 11:59pm Eastern Time on March 24, 2023. Please submit your comments to piv_comments@nist.gov. NIST will review all comments and make them available at the NIST Computer Security Resource Center website. Commenters are encouraged to use the comment template provided with the document announcement.

Introduction

This section is informative.

PIV Cards and derived PIV credentials allow for a very high level of trust in a PIV identity account thanks to the requirements and processes used in the issuance of the PIV identity account, the features of the associated PIV Card, and the binding of derived PIV credentials to the PIV identity account. This document seeks to make the benefits of the PIV identity account available to federated relying parties (RPs) through the use of identity providers (IdPs) that verify PIV credentials and provide federated assertions representing the PIV identity account. Federation technologies can facilitate the connection of these PIV identity accounts across different security domains, allowing a subscriber to leverage the trust and strength of their PIV identity account at agencies other than the agency that issued the credentials.

Background

This document is a companion document to [FIPS201], providing specific details for implementing PIV federation for PIV identity accounts. [FIPS201] defines standards for the use of PIV credentials, including the establishment of the PIV identity account, the issuance of the PIV Card, authentication using the PIV Card, management of derived PIV credentials, and other aspects of the PIV identity account. FIPS 201 provides basic requirements for the use of federation and defers to the guidelines provided in this publication to define details of what a PIV-based federation system would entail.

[SP800-63C] and its companion document suite of [SP800-63] provide general guidelines for the use of federation technologies and assertions within Federal Government use cases. These guidelines are intended to be used across a wide variety of account types, authenticators, and deployment patterns. The SP 800-63 suite is not specific to PIV identity accounts.

This document, SP 800-217, specifically applies the guidelines of [SP800-63C] to the PIV identity account defined in [FIPS201] to outline the details of PIV federation. This document provides a set of processes and technical guidelines for deployers of PIV federation with Federal Government use cases in both IdP and RP roles.

Note that this document is not intended to be sufficient for a full technical interoperability profile. In addition to this document and its prerequisites ([FIPS201] and [SP800-63C]), a PIV federation deployment will need a technical profile that is suitable for the federation protocol being used. For example, while this document requires that the federated identifier be included in the assertion, a technical profile would specify the field name within the assertion to house both the subject identifier and issuer identifier, as well as any data formatting needed for the value.

Purpose and Scope

This document focuses on the use of federation technologies with PIV identity accounts for federal employees and contractors. This document does not discuss citizen-facing use cases covered in [SP800-63C]. This document does not address creation or lifecycle of PIV identity accounts as covered in [FIPS201], nor does this document account for the issuance and management of derived PIV credentials in PIV identity accounts as covered in [SP800-157]. While the guidelines within this document could be generally useful in other circumstances, application to any additional use cases are outside the scope of this document.

Federation Use Cases

In a direct authentication, the claimant presents their authenticator to a verifier, which is tightly coupled with the RP and often the Credential Service Provider (CSP). The verifier conducts an authentication process. This process sometimes uses an external service, such as when public key infrastructure is used to validate a certificate.

PIV credentials are intended for use with direct authentication via the mechanisms listed in [FIPS201] and [SP800-157]. However, there are many situations in which direct authentication is not viable or desirable.

For example, non-PKI-based derived PIV credentials are bound and validated at the home agency. Federation allows these credentials to be used for accessing systems outside of the home agency by having the subscriber present the derived credential to the IdP, which can validate the credential and assert to the RP that the validation has taken place.

In a federated authentication, the verifier is not tightly associated with RP and is instead operated by a separate but trusted entity, the IdP. The PIV Card or derived PIV credential is used to authenticate the PIV cardholder to the IdP of a federation system. The IdP creates an assertion that represents the authentication event of the subscriber. The IdP sends this assertion to the RP using a federation protocol, and the RP verifies the assertion upon receipt.

Since the IdP needs to perform the role of verifier, usually the IdP is a service directly provided by the CSP. This tight coupling allows the IdP a direct view of the status of the PIV identity account and all associated PIV credentials. However, there are several mechanisms for an IdP to be run by a party other than the CSP. For example, the CSP could outsource the IdP functionality and synchronize the state of its PIV identity accounts using a provisioning protocol or similar system. Alternatively, the use of PKI-based PIV credentials allows an IdP to be run by a party other than the CSP. In this scenario, the validity of the PIV identity account is inferred from the validity of the credential presented to the third-party IdP.

Federation Considerations

The use of a federation protocol allows RPs to be shielded from the complexities and requirements of managing individual authenticators. When a new authentication technology is adopted, only the IdP needs to be updated in order for the entire network to benefit. The home agency has the option to bind and manage any number of valid PIV credentials to the PIV identity account. The lifecycle of adding and removing authenticators to the PIV identity account does not affect the RP, which implements only the federation protocol.

Federation allows an RP to access PIV identity accounts that originate from different agencies on different networks. This connection allows an agency to leverage the identity infrastructure of another agency without needing to replicate the PIV identity account management process.

The subject identifier asserted by the IdP to the RP is stable to the PIV identity account over time and across different authenticators, including different certificates and attribute changes such as email address or name changes. The subject identifier can also be generated in a pairwise fashion for use cases that require a higher degree of privacy between multiple RPs while still providing a smooth user experience for the subscriber who only has to manage one set of credentials.

Many RPs need access to attributes about the subscriber, such as a display name or contact information. The fixed set of attributes included in a PIV certificate are presented as a whole to all RPs at which the certificate is presented, and some derived PIV credentials carry no attributes at all. In contrast, the attributes released during a federation transaction can vary depending on a variety of factors, including the nature of access required and the parameters of the RP. These attributes can include information in the PIV identity account that is not carried in any specific authenticator. In fact, these attributes are made available to the RP separate from the subscriber’s use of any particular authenticator.

An RP may want to verify that the PIV identity account is still active and has not been terminated, but in many circumstances, the RP will not have direct access to the PIV identity account. With federated protocols, the IdP is the authority for the accounts it asserts, allowing RPs to trust that these accounts are in good and current standing according to the IdP. When a PIV identity account is terminated at the IdP, that account can no longer be used at any connected RPs.

In advanced circumstances, the IdP and RP can engage in shared signaling about security events concerning accounts, agencies, and applications. These signals can inform a party about suspicious behavior with a given account or proactively indicate significant changes in an account’s status, such as termination, without the need for action on the subscriber’s part.

The RPs in a federation relationship transitively benefit from the security practices of the IdP. Instead of relying on all RPs to manage authenticators and accounts for many users over time, the IdP can act as a dedicated identity management device within the network.

This also means that an IdP would be aware of the usage of a given PIV identity account under its control at different RPs within its trust networks. While this has positive benefits for security, it does pose a privacy tradeoff wherein the IdP needs to be trusted with this usage information.

Audience

This document is intended for stakeholders who are responsible for procuring, designing, implementing, and managing deployments of PIV federation in both the IdP and RP roles.

Notations

This Standard uses the following typographical conventions in text:

Document Structure

This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory).

Architecture

This section is informative.

PIV federation is the process by which a subscriber uses their PIV identity account to access an RP using an IdP for that account. As shown in Figure 1, the subscriber uses their PIV credentials (either a PIV Card or a derived PIV credential) to authenticate to the IdP and access the PIV identity account. The authentication event is then conveyed to the RP using an assertion that contains a set of attributes about the authentication event and the PIV identity account.

Figure 1. PIV Federation

Diagram of a PIV Federation showing the PIV identity account authenticating to the IdP and being asserted to the RP.

For PIV federation to occur, all of the following conditions apply:

If any of these items are not true, such as the use of a non-PIV identity account at a PIV-enabled IdP or the authentication of a PIV identity account through an IdP that is not the PIV IdP for the account, then the transaction does not meet the requirements of PIV federation, and therefore the definitions and requirements in this document do not apply.

A successful PIV federation transaction is, roughly, as follows:

  1. The subscriber starts in an unauthenticated state at the RP.
  2. The RP requests a federated login at the IdP.
  3. The subscriber authenticates to the IdP using a PIV credential (i.e., a PIV Card or derived PIV credential).
  4. The IdP generates an assertion that represents the subscriber’s PIV identity account to the RP.
  5. The RP receives the assertion and processes it.
  6. The RP creates an authenticated session for the subscriber. At the establishment of this session, the subscriber is logged in to the RP.

PIV Identity Account

A PIV identity account, as established in [FIPS201], is the digital account of a PIV cardholder, a party also known as the subject or subscriber in [SP800-63]. This account contains a set of identity attributes for the subscriber, bindings to all PIV credentials for the account, metadata about the account’s creation, and identification of the home agency for the account.

The PIV identity account is the definitive source of PIV cardholder information in the context of PIV federation transactions, whether this information is communicated directly from that source to an RP (see home IdP in Sec. 2.2.1) or from another entity trusted by an RP to have accurate and timely information aligned with the PIV identity account records (see PIV IdP in Sec. 2.2.2). The strong identity proofing used in establishing this account, along with the processes used to manage the attributes and authenticators bound to this account, provide the foundation for trust in PIV identity assertions.

While the systems involved in PIV federation may also manage non-PIV accounts, the use of these accounts is outside the scope of this specification.

Identity Providers

As described in [SP800-63C], the IdP is a service of the Credential Service Provider (CSP) that issues and maintains the PIV identity account. In a federation transaction, the IdP acts as the verifier for the authenticator held by the subscriber. In the case of PIV federation, this means that the IdP verifies the PIV credential bound to the PIV identity account, as discussed in Sec. 2.3.

The IdP sends a cryptographically verifiable message called an assertion to the RP that identifies the PIV identity account being authenticated. The assertion contains attributes associated with that PIV identity account and details about the authentication event, as discussed in Sec. 6.2. The IdP can also make PIV identity account attributes available through a protected identity API alongside the assertion, as discussed in Sec. 6.5.

The home IdP (see Sec. 2.2.1) is the IdP operated by or on behalf of the issuer of a PIV identity account, which is typically expected to be the agency employing a federal employee or contractor. As a consequence, the home IdP has a direct view of the management of the PIV identity account and PIV credentials associated with the account, including PKI-based and non-PKI-based authenticators. Because there may be multiple IdPs capable of issuing assertions for a PIV cardholder, some of whom may not be directly linked to the PIV identity account, each issuer will need to identify the home IdP for the cardholders they serve, as discussed in Sec 3.5.

A PIV IdP is the IdP trusted by an RP to issue assertions for a given PIV identity account. From the perspective of the RP, all PIV federation transactions involve a PIV IdP. A PIV IdP is trusted by the RP to issue accurate and timely assertions regarding a PIV identity account. When the PIV IdP is not the home IdP, the account status can be ascertained by other means, such as querying the PIV identity account issuer or inferring account status from the status of the PKI-based PIV credential used to authenticate to the PIV IdP.

The Federation Assurance Level (FAL) of a federation transaction places requirements on the parties of the transaction, as defined in [SP800-63C]. At FAL2 and FAL3, the PIV IdP trusted by the RP has to be the home IdP for the PIV identity account in question, as discussed in Sec. 4. Additional requirements for the home IdP are discussed in Sec. 3.5. At FAL1, the IdP could be operated or controlled by an entity other than the agency responsible for the PIV identity account. Some forms of PIV credential (such as PKI-based authenticators) can support such third-party operation of an IdP by allowing the authenticator to be verified across domains, which enables a PIV IdP to exist apart from the issuing agency’s identity management systems.

Home IdP

When an issuing agency officially endorses a specific PIV IdP for the PIV identity accounts that the agency issues, that IdP is known as the home IdP for that population of PIV identity accounts. The home IdP is often run by the issuing agency, but operations can be outsourced to a third party through a variety of technical means.

As discussed in Sec. 3.5, a home IdP has direct access to the PIV identity account. This tight coupling allows the home IdP be a highly trusted authority for the PIV identity account in question.

Not all use cases require a home IdP, but RPs can discover the home IdP for a given agency through the published home IdP record, as discussed in Sec. 3.5.

Note that the use of a home IdP is the only means of making non-PKI-based derived PIV credentials available across security domain boundaries due to the nature of the authenticators, as discussed in [SP800-157].

PIV IdP

The PIV IdP is the PIV IdP identified in a trust agreement to provide federated assertions for a population of PIV identity accounts for an RP. Establishment of the PIV IdP is discussed in greater detail in Sec. 3.

In most cases, the RP’s determination of the PIV IdP depends on the agency that issues the PIV identity account. Therefore, an RP will only accept assertions of PIV identity accounts of a particular agency from a specific IdP. However, it is possible for the RP to be more specific and determine the PIV IdP on a per-account basis, subject to the trust agreements in place.

It is possible for an RP’s definition of the PIV IdP for a given PIV identity account to change over time as the federation relationship changes for a variety of reasons, including reorganization of the PIV identity account’s issuing agency or redeployment of the IdP.

PIV Credentials

PIV identity accounts are protected using one or more PIV credentials that are bound to the account. PIV credentials can take the form of different kinds of authenticators, each kind suitable for different purposes and use cases.

The primary credential for a PIV identity account is the PIV Card, which is issued to the subscriber, as defined in [FIPS201].

A PIV identity account can also have multiple derived PIV credentials associated with it, as described in [SP800-157].

Relying Parties

In the context of a PIV federation, a subscriber logs into the RP using the federation protocol to use the RP’s services and functionality. The nature of the services provided by the RP and the nature of the RP’s deployment are outside the scope of this document. General requirements for the RP in a PIV federation are discussed in Sec. 5.2, and general requirements for RPs in all federation contexts are discussed in [SP800-63C].

In PIV federation, the RP does not directly verify the authentication of the PIV credential, nor does the RP manage the PIV identity account. The RP’s only view into the contents and status of the PIV identity account comes through its interactions with the IdP. The RP can manage its own local reference to the PIV identity account, known as the RP subscriber account, as discussed in Sec. 5.2.2.

At FAL3, the RP is responsible for verifying the presentation of the bound authenticator, as discussed in [SP800-63C]. Note that the bound authenticator could also be a PIV credential, but it is not necessary for it to be one (see Sec. 4.1.3 for more information about bound authenticators).

Trust Agreements

This section is normative.

The federation process defined in [SP800-63C] requires the establishment of a trust agreement between the RP and the IdP for the purpose of federated login, wherein the RP agrees to accept assertions from the IdP, and the IdP agrees to provide assertions and attributes to the RP.

In any PIV federation, the RP SHALL establish a specific IdP as the PIV IdP for a population of PIV identity accounts, as described in Sec. 2.2.2. The RP SHALL trust this IdP to provide valid assertions for accounts within that population. In many cases, the population is defined by the issuing agency of the PIV identity accounts, and the trust agreement defines a single PIV IdP for each issuing agency’s accounts. It is possible—though uncommon—for an RP to have a distinct trust agreement established with an IdP for a single PIV identity account.

An RP in a PIV federation SHALL accept assertions only from PIV IdPs identified by its trust agreements. An RP SHALL accept assertions only within the bounds of its established trust agreements. An RP SHALL reject assertions that do not comply with these trust agreements.

Trust agreements in PIV federation SHALL consist of the following:

When establishing a trust agreement, the RP SHALL disclose to the PIV IdP or federation authority:

When establishing a trust agreement, the IdP SHALL disclose to the RP or federation authority:

For example, an RP has established a trust agreement with IdP A as the PIV IdP for all subscribers from Agency X. If the RP then receives an assertion from IdP A for a subscriber from Agency Y, the RP would reject the assertion because the IdP is not trusted as the PIV IdP for Agency Y. Likewise, if the same RP also has an established trust agreement with IdP B, and the RP receives an assertion from IdP B for a subscriber from Agency X, the RP would reject that assertion because it has established IdP A as the PIV IdP for this agency.

Trust agreements between an RP and an IdP do not preclude different agreements being established with other parties. For example, an RP can have an agreement to accept IdP A as the PIV IdP for Agency X but have a separate agreement to accept IdP B as the PIV IdP for Agency Y. Both of these IdPs can likewise have trust agreements with many other RPs with potentially different parameters.

Any changes to the parameters of the trust agreement SHALL be documented and disclosed to affected parties. If the PIV IdP changes for one or more PIV identity accounts, the RP SHALL document any mappings made between federated identifiers for affected PIV identity accounts.

The trust agreement SHALL be established in either a bilateral fashion (See Sec. 3.1) directly between the parties or a multilateral fashion (See Sec. 3.2) through a federation authority, as described in the sections below.

Bilateral Agreements

An RP MAY establish the PIV IdP directly with the IdP in a bilateral fashion, as discussed in [SP800-63C].

When the PIV IdP is the home IdP for an agency, the PIV IdP operator SHALL make available its home IdP record to the connected RP, as described in Sec. 3.5. The RP operator SHALL make the home IdP record available to authenticated subscribers from that IdP, upon request.

The IdP SHOULD make its discovery and registration available in a machine-readable format to facilitate configuration of the RP, as discussed in [SP800-63C].

Multilateral Agreements

An RP MAY establish the PIV IdP through the use of a trusted third party known as a federation authority, as discussed in [SP800-63C]. This creates a multilateral agreement between different PIV IdPs and RPs under the PIV federation authority. In such systems, the federation authority decides which PIV IdPs and RPs are allowed to participate based on the trust agreement provided by the authority. The federation authority SHALL declare which IdP is the PIV IdP for any given population of PIV identity accounts within the trust agreement. The federation authority SHALL establish and declare whether each PIV IdP is the home IdP for any given PIV identity account within the trust agreement.

The federation authority SHALL vet all PIV IdPs and RPs within the federation to ensure that all parties are acting within the terms of the agreements.

The federation authority SHALL disclose to all connected RPs whether a particular IdP is the home IdP for an agency in question. Federation authorities SHALL make all home IdP records (defined in Sec. 3.5) available to participants within the federation using a machine-readable format appropriate for the federation protocol standards in use.

The federation authority SHALL make lists of all member IdPs and RPs available to other members within the scope of the federation agreement. IdPs within a federation authority SHOULD enable dynamic registration of new RPs, as discussed in [SP800-63C], subject to the rules of the federation authority, the desired federation assurance level, and the capabilities of the federation protocol in use.

The federation authority SHALL document the full set of attributes to be provided by each IdP and allowed to be requested by RPs within the federation. The federation authority SHALL collect the attributes requested by RPs joining the federation and SHALL document the RP’s justification and use for these attributes.

Identity Proxies and Brokers

An identity proxy (also known as an identity broker) takes in federated authentications from one domain and asserts them outbound to another domain. Identity proxies are discussed in [SP800-63C], and all requirements for proxies enumerated therein apply to identity proxies in a PIV federation.

In many cases, it is natural for a proxy to act as a federation authority for all connected parties due to the proxy’s nature as a common connection point between IdPs and RPs. However, bilateral agreements are still possible and allowable through a proxy, with each IdP and RP making a pairwise agreement to the proxy itself.

For each federated transaction with an RP, the proxy SHALL determine the appropriate upstream PIV IdP that is appropriate for each PIV identity account it proxies to a downstream RP.

\clearpage

In addition to its other requirements as part of a trust agreement, an identity proxy in a PIV federation context acting as an IdP SHALL disclose to the RP or federation authority:

Assertions created by a proxy SHALL include the identifier of the upstream IdP. Note that this is separate from the required issuer field, which identifies the proxy itself. Since the proxy is the issuer of federated assertions to its downstream RPs, these downstream RPs SHALL view the proxy as the PIV IdP for accounts asserted through the proxy.

Shared Signaling

In addition to sharing account information for the purposes of federated login, additional signals can be shared between the IdP and RP for the specific uses described in [SP800-63C].

The IdP SHOULD inform the RP of significant status changes in a PIV identity account that has been used at an RP, including:

When the RP receives such status changes, the RP SHOULD update its RP subscriber account, as appropriate for the nature of the signal.

The IdP MAY additionally inform the RP of significant changes to the PIV identity account’s information, including:

The RP SHOULD inform the IdP of significant status changes in the RP subscriber account, including:

When the IdP receives such status changes, the IdP SHOULD terminate, disable, or update the PIV identity account or the RP’s access to the account as appropriate to the nature of the signal.

Home IdPs

Only the agency responsible for issuing PIV identity accounts SHALL declare the home IdP for those accounts. Operation of the home IdP MAY be outsourced to a third party.

A home IdP SHALL have access to relevant information for the PIV identity accounts that it asserts, including the following:

The effect of these requirements is that the home IdP needs to be coupled to the management of the PIV identity accounts that it represents. This can be accomplished with a variety of technological means, such as attachment to the issuing agency’s enterprise identity and access management system or the use of a provisioning protocol to synchronize account state with the IdP system.

The issuing agency responsible for declaring its home IdP SHALL publish its home IdP information in a publicly available location to allow for discovery and configuration by RPs. The home IdP publication record SHALL include all of the following:

The format for this record and the means by which it is published are out of scope for this specification and subject to technical profiles and federation trust agreements.

Federation Assurance Level (FAL)

This section is normative.

The federation assurance level, or FAL, is defined in [SP800-63C] as a set of requirements for the federation process. A higher FAL indicates a greater degree of trust that the RP can place in the results of the federation process—namely, that the subscriber present at the RP is the subscriber identified in the federation protocol.

As discussed in [SP800-63C], federation provides a means of conveying the proofing and authentication processes associated with the lifecycle of the subscriber account. For PIV federation, the PIV identity account is proofed at IAL3, and all PIV credentials are either AAL2 or AAL3, depending on the type of credential. PIV federation MAY be conducted at any FAL, depending on the requirements of the use case.

Reaching Different FALs in PIV Federation

The FAL classification of a PIV federation transaction primarily depends on several aspects of the federation process, including the establishment of the trust agreement, as discussed in Sec. 3. [SP800-63C] defines general requirements for FALs, and this section defines requirements specific to PIV federation.

FAL1

FAL1 allows federation in a wide variety of situations, particularly where the results of a risk assessment show that the value of making the federated connection outweighs the complexities of implementing higher FALs. The establishment of the trust agreement and the determination of the PIV IdP MAY happen dynamically. The PIV IdP SHOULD be the home IdP for the agency if known by the RP. The RP SHOULD audit and review all accepted PIV IdPs.

As defined in [SP800-63C], at FAL1, the IdP MAY use front-channel presentation of the assertion. However, if the assertion contains private or sensitive information and is presented over the front-channel, an encrypted assertion SHALL be used.

FAL2

All of the requirements for FAL1 apply at FAL2 except where overridden by more specific or stringent requirements in this section.

As defined in [SP800-63C], FAL2 requires the assertion presentation to be protected against injection by an attacker at the RP. To accomplish this, PIV federation at FAL2 SHALL use back-channel presentation methods.

The establishment of the trust agreement and determination of the PIV IdP at FAL2 SHALL be done through a trusted process whereby the RP ensures that the PIV IdP is the official home IdP that represents the population of accounts in question. This process MAY be augmented by automated processes, including dynamic discovery and registration of the identifiers and key material for the IdP and RP in the federation protocol.

FAL3

All of the requirements for FAL1 and FAL2 apply at FAL3 except where overridden by more specific or stringent requirements in this section.

Trust establishment of the PIV IdP at FAL3 SHALL be done through a trusted process whereby the RP ensures that the PIV IdP is the official home IdP that represents the agencies and accounts in question. The establishment of identifiers and key material for the IdP and RP in the federation protocol SHALL occur through a static process between the IdP and RP.

As defined in [SP800-63C], FAL3 requires the establishment of a bound authenticator, which the subscriber presents directly to the RP alongside the federation assertion from the IdP. Though most PIV credentials can be used as bound authenticators at FAL3, the nature of the binding depends on the type of authenticator, its use, and its phishing resistance qualities.

PKI-based credentials, such as the PIV authentication certificate on the PIV Card, MAY be used as an IdP-managed bound authenticator, as shown in Figure 2. When a certificate is used in this fashion, the assertion SHALL contain the Distinguished Name of the certificate as an attribute in the assertion to identify the specific certificate used as an authenticator. If the RP uses a just-in-time provisioning method for the RP subscriber account (as defined in [SP800-63C]), the RP SHALL compare the attributes of the certificate’s Distinguished Name with other attributes from the federation transaction when first associating a Distinguished Name with a federated identifier. For example, if the certificate includes one email address and the federation transaction gives the RP a different email address, the RP needs to decide if the transaction should be rejected or if this specific discrepancy is expected for its use case and security profile.

Figure 2. IdP-Managed Bound Authenticators

Diagram of a PIV Card being used as an IdP-managed bound authenticator

Non-PKI-based derived PIV credentials and authenticators other than PIV credentials MAY be used as RP-managed bound authenticators, as shown in Figure 3, provided the authenticators meet the phishing resistance requirements in [SP800-63C]. Note that with RP-managed bound authenticators, the IdP does not see the authenticator directly. The RP SHALL conduct an appropriate binding ceremony, as defined in [SP800-63C].

Figure 3. RP-Managed Bound Authenticators

Diagram of a non-PKI-based authenticator being used as an RP-managed bound authenticator

In their use as bound authenticators at FAL3, authenticators from PIV credentials do not function as PIV credentials at the RP. However, the same authenticator MAY be used as both a derived PIV authenticator at the IdP and a bound authenticator at the RP in a single transaction provided that both the IdP and RP separately verify the authenticator.

In the case of a lost bound authenticator, the RP SHALL provide mechanisms for unbinding old authenticators and binding a new authenticator at FAL3.

Selecting FAL

Agencies SHALL select the FAL appropriate for a given RP using the digital identity risk management process specified in [SP800-63]. Notwithstanding the results of that process specifying a higher assurance level, agencies SHOULD use federation protocols, architectures, and processes compliant with FAL2 or higher to maximize the assurance provided by the management of the PIV identity accounts.

When not practical to deploy federation at FAL2 in low-impact use cases, agencies MAY elect to use FAL1 technologies and processes, in accordance with their digital identity risk management process. In such cases, the risk assessment SHALL consider the potential impact of risks associated with the FAL1 mechanisms that will be used. This could include assertion injection attacks associated with front-channel presentation mechanisms or acceptance of outdated attributes associated with use of PIV IdPs that are not the subjects’ home IdPs.

Requirements of IdPs and RPs

This section is normative.

This section details the requirements for IdPs and RPs in a PIV federation context.

IdP Requirements

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.

Authentication Requirements

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.

PIV Identity Account Identification

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.

Session Management

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.

RP Requirements

PIV RPs SHALL follow all of the requirements for RPs enumerated in [SP800-63C].

Assertion Processing

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.

RP Subscriber Accounts

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.

Session Management

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].

Changing the Federated Identifier

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.

Protocol Requirements

This section is normative.

A federation protocol connects the IdP and RP together with a series of messages. These messages include assertions, which are passed between the IdP and RP to represent the federated authentication event, and the contents of identity APIs, which convey additional attribute information about the subscriber. This section enumerates requirements for these common components but is not intended to provide sufficient detail for any specific federation protocol.

Required Attributes

A PIV IdP SHALL make the following mandatory attributes available to all RPs for each PIV identity account, as required by the trust agreement:

A PIV IdP SHALL make the following core identity attributes available to RPs, subject to the trust agreement:

A PIV IdP SHOULD make the following optional identity attributes available to RPs, subject to the trust agreement:

Any given RP does not necessarily have access to all attributes made available by an IdP. The subject identifier (and therefore the federated identifier), issuing agency, organizational affiliations, and last updated timestamp SHALL be disclosed as part of all trust agreements in PIV federations. All other subscriber account attributes are subject to the trust agreement in place between the IdP and RP, including disclosures of use between the parties.

Except as otherwise stated in Sec. 6.2, the IdP SHOULD disclose attributes through an identity API rather than through the assertion itself. For example, in OpenID Connect, while it is possible to include subscriber attributes such as name and email within the ID token (the assertion), it is preferable to make such attributes available from the UserInfo Endpoint (an identity API). When attributes are available for a given account through more than one method at an IdP, the attribute values SHALL match.

A PIV IdP SHOULD allow for selective disclosure of attributes to different RPs, as determined by the authorized party listed in the trust agreement.

Assertion Contents

As specified in [SP800-63C], the successful validation of a federated assertion is required to begin an authenticated session at the RP. The assertion contains a combination of attributes about the subscriber as well as attributes about the authentication event that the assertion represents.

At minimum, the assertion in PIV federation SHALL contain the following attributes of the PIV identity account:

As an assertion is a short-lived message from the IdP to the RP, the assertion itself SHOULD contain only the minimum attributes required for its processing. To preserve privacy and minimize the information sent with each request, the assertion SHOULD NOT contain non-required or stable attributes from the PIV identity account, such as email address or display name. Additional attributes SHOULD be available to the RP through a standard identity API.

At minimum, the assertion in PIV federation SHALL contain the following attributes of the authentication event:

For FAL3 assertions in PIV federation, the assertion SHALL contain either:

The mapping of these required attributes to specific fields within a given federation protocol is out of scope for this specification.

Federated Identifier

The assertion created by a PIV IdP includes a federated identifier for the PIV identity account, as defined in [SP800-63C]. The federated identifier consists of the logical combination of both a local subject identifier for the PIV identity account and a global issuer identifier for the IdP.

The subject identifier SHALL be unique to the PIV identity account at the IdP such that no identifier is the same for any two PIV identity accounts at an IdP. The subject identifier MAY be generated by the IdP in a pairwise fashion for a specific RP, as discussed in [SP800-63C]. If such a pairwise identifier is used, it SHALL be used consistently with a given RP and SHALL NOT be used for multiple RPs except as allowed by [SP800-63C].

The issuer identifier SHALL be globally unique for the IdP. This identifier is usually the URL of the IdP, but it can be a unique key identifier or other globally unique value that can be verified by the RP as part of the assertion.

The federated identifier SHALL NOT include any personally identifiable or private information, such as username, identifier, the distinguished name of the PIV authentication certificate, email addresses, or UUIDs for the PIV Card or cardholder.

The RP SHALL use this federated identifier to uniquely associate the PIV identity account with the RP subscriber account, as defined in [SP800-63C]. The RP SHALL NOT use other attributes alone for this purpose, including email addresses, certificate subject names, or PIV cardholder UUIDs.

Authorization and Access Rights

The assertion MAY contain indicators for the authorizations and access rights that the subscriber has at the RP, such as a set of roles within an organization. The RP SHALL trust these only as subject to the details of the trust agreements between the IdP and RP.

As the point of enforcement, the RP MAY override these authorizations by additionally restricting access as necessary.

Discovery and Registration

The IdP SHALL publish its configuration information in a standard machine-readable format and location appropriate to the federation protocol in use. The information in the configuration document SHALL be sufficient to allow for the automated configuration of an RP contacting the IdP even when the RP is statically registered.

IdPs operating at FAL2 and below SHOULD allow RPs to register dynamically, as described in [SP800-63C]. Assertions issued to dynamically registered RPs SHALL contain pairwise subject identifiers.

Assertion Presentation

The IdP SHALL support back-channel assertion presentation, if possible within the federation protocol. All back-channel presentation methods SHALL require authentication of the RP.

At all FALs, RPs SHOULD use back-channel presentation to fetch the assertion directly from the IdP, where available.

If front-channel presentation is used, the contents of the assertion SHALL be encrypted to a key specific to the RP, as described in [SP800-63C].

Attribute APIs

The IdP SHALL make identity attributes for the subscriber available through a standard identity API, if possible within the federation protocol in use. The identity API SHALL require protected access from the RP.

The IdP SHALL allow limited disclosure of attributes through this API, such that federation agreements that connect the IdP and RP (including runtime decisions by an authorized party) can dictate which attributes are disclosed to the RP for a given request.

The RP SHALL use the account update timestamp to manage its cache of attribute information in the RP subscriber account, particularly when using a just-in-time provisioning model. That is, if the account update timestamp in the assertion is later than the last cache update value, the RP knows that it should fetch updated information from the identity API. If the timestamp is not later than the cache time, the RP can determine that an additional call to the identity API would be redundant.

The IdP MAY provide a provisioning API to the RP, subject to a trust agreement. When a provisioning API is used, the trust agreement SHALL include a justification for the intended use of all attributes provided to the RP by the provisioning API.

Identity Proxies and Brokers

An identity proxy acting in a PIV federation context SHALL disclose the IdPs used as sources of attributes to the downstream RP. For example, if an assertion contains attributes for a PIV identity account from IdP A and IdP B, the proxy will list both IdPs as sources within the assertion. Note that the proxy, in its role as an IdP to downstream RPs, is still the issuer of the assertion and will identify itself as such.

See Sec. 3.3 for more information about the trust agreement requirements of identity proxies.

References

[FIPS201] National Institute of Standards and Technology (2022) Personal Identity Verification (PIV) of Federal Employees and Contractors. (U.S. Department of Commerce, Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-3 [or as amended]. https://doi.org/10.6028/NIST.FIPS.201-3

[SP800-63] Temoshok D, Proud-Madruga D, Choong YY, Galluzzo R, Gupta S, LaSalle C, Lefkovitz N, Regenscheid A (2022) Digital Identity Guidelines. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63-4 ipd, 2022 [or as amended]. https://doi.org/10.6028/NIST.SP.800-63-4.ipd

[SP800-63B] Temoshok D, Fenton JL, Choong YY, Lefkovitz N, Regenscheid A, Richer JP (2022) Digital Identity Guidelines: Authentication and Lifecycle Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63B-4 ipd, 2022 [or as amended]. https://doi.org/10.6028/NIST.SP.800-63b-4.ipd

[SP800-63C] Temoshok D, Richer JP, Choong YY, Fenton JL, Lefkovitz N, Regenscheid A (2022) Digital Identity Guidelines: Federation and Assertions. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63C-4 ipd, 2022 [or as amended]. https://doi.org/10.6028/NIST.SP.800-63c-4.ipd

[SP800-87] Ferraiolo H (2018) Codes for the Identification of Federal and Federally-Assisted Organizations, (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-87r2 [or as amended]. https://doi.org/10.6028/NIST.SP.800-87r2

[SP800-157] Ferraiolo H, Regenscheid AR, Fenton J (2023) Guidelines for Derived Personal Identity Verification (PIV) Credentials. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-157 Revision 1 [or as amended]. https://doi.org/10.6028/NIST.SP.800-157r1-ipd

Glossary of Terms

This section is informative.

Home Agency
The agency responsible for the issuance and management of a PIV identity account.
Home IdP
The officially sanctioned IdP of the home agency for a PIV identity account.
Identity Provider (IdP)
The party that verifies the credentials of a subscriber account and issues assertions to an RP based on that account for federation.
PIV Credential
A PIV Card or derived PIV credential.
PIV Federation
A federation process that presents a PIV identity account from a PIV IdP. The subscriber is authenticated at the IdP using PIV credentials.
PIV IdP
An IdP that accepts PIV credentials as authenticators for PIV identity accounts as part of PIV federation. The IdP trusted by the RP to create assertions for a PIV identity account.
Relying Party (RP)
The party that accepts an assertion from an IdP to allow the federated login of a PIV identity account.

Abbreviations

This section is informative.

AAL
Authentication Assurance Level
API
Application Programming Interface
CSP
Credential Service Provider
FAL
Federation Assurance Level
FASC-N
Federal Agency Smart Credential Number
IAL
Identity Assurance Level
IdP
Identity Provider
PKI
Public Key Infrastructure
PIV
Personal Identity Verification
RP
Relying Party

Examples

This appendix is informative.

This appendix contains several example scenarios of PIV federation in various environments and applications to show different kinds of trust establishment, account management, and authenticator usage. The details of the federation transactions within each scenario all follow the common patterns discussed in [SP800-63C] and adhere to the requirements in this document.

The scenarios in this section are for illustrative purposes and do not convey additional requirements beyond those imposed by this specification.

Direct Connection to the Home IdP

Agency A, which issues and manages PIV identity accounts, sets up an OpenID Connect IdP in order to make its PIV identity accounts available online through a federation process. The agency publishes its home IdP record from its publicly available website with all required information for RPs to consume.

The RP enters into a pairwise trust agreement with the IdP to accept assertions for Agency A. The RP declares the set of attributes that it needs from the IdP as part of this agreement. The RP uses a just-in-time provisioning system to establish an RP subscriber account only once the subscriber logs in for the first time. The RP has other pairwise agreements with other IdPs to accept assertions for different agencies but will reject any assertions for accounts at Agency A that come from any other IdP.

The IdP generates a pairwise federated identifier for the PIV identity account for each RP that it is in contact with by hashing the identifier for the RP along with a randomly generated value stored with the PIV identity account at the IdP. This way, each new RP that signs on to the IdP gets a different federated identifier for a single account, but a consistent federated identifier is used for each RP with that account.

Per the terms of the trust agreement, the subscriber is prompted by the IdP the first time they log on to the RP. The IdP asks for the subscriber’s consent at runtime to share attributes with the RP. The IdP also prompts the subscriber to allow the IdP to remember this consent decision. This stored decision causes the IdP to act on the stored consent in a future request and not prompt the subscriber if the same RP requests the same attributes.

Multilateral Federation Network

Agencies A, B, and C each have a home IdP running OpenID Connect for their PIV identity accounts. All three agencies join a multilateral federation in which the federation authority independently verifies that each home IdP represents the agency in question. The federation authority publishes the home IdP records for all agencies that are part of the multilateral federation. This publication allows RPs within the federation to discover which IdP is to be used to access accounts for a given agency under the rules of the federation agreement.

RPs X and Y wish to allow logins from agencies A, B, and C, and the RPs declare their intent and a list of required attributes to the federation authority. The federation authority assesses both RP requests and adds them to the multilateral federation. This allows both RPs to register at each of the three separate IdPs as needed for each agency.

Both RPs interface directly with each of the three IdPs and not through a federation proxy. When a new IdP or RP is added to the multilateral federation agreement, the existing IdPs and RPs are notified of the new component and its parameters.

The IdPs and RPs establish a shared signaling channel under the auspices of the federation authority. This allows any IdP and any RP to report suspicious or malicious behavior that involves a specific account to the rest of the members under the federation authority.

Enterprise Application

The home IdP establishes a pairwise agreement with an RP to provide an enterprise-class service to the subjects of the agency’s PIV identity accounts. As part of this trust agreement, the home IdP allows access to a provisioning API for the RP. The provisioning API pushes a set of federated identifiers and associated attributes to the RP that allow the RP to pre-provision RP subscriber accounts for every PIV identity account at the IdP.

The existence of these RP subscriber accounts allows the RP to offer things like access rights, sharing, and messaging to all accounts on the system, whether or not the specific account has logged in to the RP yet.

Under the terms of the trust agreement, the RP is placed on an allowlist. Consequently, subscribers are not prompted for consent at runtime because the agency consented to use the service on behalf of all accounts at the time the RP was onboarded. This gives subscribers a seamless single sign-on experience, even though a federation protocol is being used across security domain boundaries.

The RP subscriber accounts are synchronized using the provisioning API. When a new PIV identity account is created, modified, or deleted at the IdP, the IdP updates the status of the RP subscriber account using the provisioning API. This allows the RP to always have an up-to-date status for each PIV identity account. For example, when the RP subscriber account is terminated at the IdP, the provisioning API signals to the RP that the RP subscriber account is to be terminated immediately. The RP removes all locally cached attributes for the account in question, except for the identifiers and references in audit and access logs.

PKI-Based Federation Gateway

A service provider that does not issue any PIV identity account of its own sets up a SAML IdP that accepts PKI-based PIV credentials as its only authentication method. These accounts are provisioned at the IdP using the attributes in the certificates when the subscriber first presents the certificate. The IdP collects no additional attributes from the subscriber in the process.

The IdP generates federated identifiers for the accounts by computing a hash of the authentication certificate and encoding that hash in Base64. This process fulfills the requirements of this document for federated identifiers, but it is specific to this IdP and need not be known or understood by any RP connecting through the IdP. Note that if the subscriber changes any attributes in the certificate, such as their name, then a new federated identifier will be created as a result. As a result, this IdP does not necessarily provide a stable subject identifier across authenticator updates.

The RP enters into a pairwise trust agreement with the IdP to accept assertions for any agency with PIV credentials. The RP does not have any other IdPs that it speaks to directly, and so the only way to log in to the RP is through this gateway. Since the IdP accepts a broad range of PKI-based credentials, this allows the RP access to any account based on those credentials.

This setup does not allow the PIV identity accounts to use non-PKI-based derived PIV credentials since the IdP portion of the gateway is not the home IdP for any of the accounts in question. The RP is also not able to receive any attributes other than those available directly to the IdP through subscriber certificates. To ensure account continuity, an RP would need to have an out-of-band process to bind their new federated identifier to the existing RP subscriber account if the certificate and attributes change over time.

The IdP is not acting as a federation proxy because the inbound credential is not a federated assertion but rather a PKI-based credential that the gateway processes directly as a verifier.

PIV Federation Proxy as a Federation Authority

A federation proxy is set up within a multilateral federation. The proxy is run by the federation authority. All IdPs under the multilateral agreement register the proxy as an RP. The RPs within the federation authority connect to the proxy as their only IdP. All federation transactions within the multilateral federation flow through the proxy.

The federation authority discloses the nature of the proxy to all parties, so the IdPs know that this particular RP is a proxy, and the RPs know that their IdP is a proxy. Furthermore, the proxy lists all of the upstream IdPs and their associated populations of PIV identity accounts to all RPs connecting through the proxy.

The proxy discloses to the RPs which upstream IdPs participated in the authentication of the PIV identity account to the proxy, allowing the downstream RPs to validate that the source of the federation transaction through the proxy is appropriate for the PIV identity account in question.

The proxy is not regarded as a home IdP for any RP in the system, even if the IdPs connecting in to the proxy are themselves home IdPs.

FAL3 With a PIV Card

The PIV Card and certain PKI-based derived PIV credentials can be used as IdP-managed bound authenticators for use at FAL3. The home IdP authenticates the PIV identity account using an authenticator bound to the account and then creates an assertion that is flagged as FAL3. The assertion also contains the certificate common name (CN) and thumbprint of the certificate to be used as a bound authenticator.

When the RP receives the assertion, it processes it as usual and sees the FAL3 flag and the certificate attributes. The RP matches the CN against attributes in the RP Subscriber Account to ensure that the certificate being identified is appropriate for the PIV identity account being represented. The RP then prompts the subscriber to authenticate using a certificate and compares that certificate against the provided CN and thumbprint, ensuring that they match. When the certificate has been validated, the RP creates a secure session at FAL3. From this point forward in the session, the RP no longer requires presentation of the certificate in order to access the RP’s services.

FAL3 With an RP-Bound Authenticator

The home IdP authenticates the PIV identity account using an authenticator bound to the account, and then creates an assertion that is flagged as FAL3 and using an RP-bound authenticator.

When the RP receives the assertion, it processes it as usual and sees the FAL3 flag. The RP looks up the bound authenticator associated with the RP Subscriber Account and prompts the subscriber for this authenticator. When the authenticator has been verified, the RP creates a secure session at FAL3.