BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

3 Trust Agreements 574

NIST PIV and digital identity SP 800-217 (Draft)
All changes in this version
first version loaded 3 Trust Agreements 574

Title

Trust Agreements 574

Control

575

576 577 578 579

580 581 582

583 584 585 586

587 588 589

590 591

592

593

594

595 596

597

598 599

600

601

602

603 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 single, specific IdP as the PIV IdP for a population of PIV identity accounts, as described in Sec. 2.2.1 . The RP trusts this IdP to provide valid assertions for accounts within that population.

In many cases, the population is defined by the home agency of the PIV identity accounts, and the trust agreement defines a single PIV IdP for each home 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 only accept assertions from PIV IdPs identified by its trust agreements. An RP SHALL reject assertions that do not comply with these trust agreements.

In addition to the requirements for trust agreements defined in [SP800-63C] , trust agreements in PIV federation SHALL contain the following:

• A population of PIV identity accounts, including agency identifiers;

• A list of PIV IdPs or a process by which a PIV IdP is established by the home agency;

• The means for mapping a specific PIV identity account to a specific PIV IdP;

• The location of home agency IdP records for all agencies covered by the trust agreement, if applicable;

• The interoperable technical profile of the federation protocol in use; and

• The list of shared signals agreed to by all parties and the actions to be taken in response to receiving those signals.

When establishing a trust agreement, the RP SHALL disclose:

• The list of attributes requested and the purpose of use for each attribute,

• The population of PIV identity accounts associated with the IdP, and

• The possible range of AAL and FAL required to access the RP. When establishing a trust agreement, the IdP SHALL disclose: 604

605

606

607 608

609

610

611 612 613 614 615

616 617 618 619 620 621 622

623

624

625 626

627 628

629 630 631 632

633 634 635 636 637
• The list of attributes that can be provided to an RP,

• The possible range of AAL and FAL supported by the IdP,

• Whether the IdP is the home agency IdP for the population PIV identity accounts (see Sec. 3.5 ), and

• The sources of attributes for the PIV identity accounts.

Since all PIV accounts are IAL3, this attribute does not need to be otherwise disclosed.

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.

The trust agreement SHALL establish a deterministic process by which the RP can determine whether a given PIV identity account is included in the population of PIV identity accounts covered by a trust agreement and, therefore, whether the RP should accept an assertion from the IdP for that PIV identity account. The means for this determination are out of scope for these guidelines, but common mapping policies include mapping a single PIV IdP to PIV identity accounts that have the following attributes:

• All accounts from a single home agency, regardless of other attributes

• All accounts with a set of organizational affiliations

• All accounts with a particular job classification, such as full-time employees or contractors

• A specific set of accounts with known human-facing account identifiers, such as email addresses or phone numbers

The trust framework MAY stipulate that this mapping be made available through a queryable interface. For example, a federation authority can provide an interface that allows an RP to look up which IdP within the trust agreement to contact given a subscriber’s input to the RP.

The result of this process is a clear indication of which PIV identity accounts are served by which PIV IdP within the trust agreement. 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 for a different agency, and the RP 638 639 640

641 642 643 644

645 646 647

648 649 650

651 652 653 654

655 656

657 658 659 660 661 662 663 664 665 666

667 668 669 670 671

672 673 receives an assertion from IdP B for a subscriber from Agency X, the RP would reject that assertion because it has determined that IdP A is the PIV IdP for Agency X.

Any changes to the parameters of the trust agreement SHALL be documented and disclosed to affected parties. If the identified 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 following sections.