BaselineWatch
Desk

3.5.2 Multilateral Trust Agreements

NIST PIV and digital identity SP 800-63C-4 against SP 800-63C
All changes in this version
added 3 Common Federation Requirements part of 3.5

Title changed

Before · SP 800-63C

After · SP 800-63C-4

Multilateral Trust Agreements

Control changed

Before · SP 800-63C

After · SP 800-63C-4

In a multilateral trust agreement, the federated parties look to a federation authority to assist in establishing the trust agreement between parties. In this model, the federation authority facilitates the inclusion of CSPs, IdPs, and RPs under the trust agreement.

When onboarding a party in any role, the federation authority conducts vetting on that party to verify its compliance with the terms of the trust agreement, as shown in Fig. 2 . The level of vetting is unique to the use cases and models employed within the federation, and details are outside of the scope of this document. As with many other functions, the federation authority can outsource the vetting process to another party, but the federation authority is ultimately responsible for the results of the vetting process.

The trust agreement SHALL enumerate the required practices for vetting all parties and SHALL indicate the party or parties that are responsible for performing the vetting process.

At a minimum, the vetting of CSPs, IdPs, and RPs SHALL establish that:

• CSPs identity proof subscriber accounts in accordance with [SP800-63A] .

• CSPs onboard subscriber accounts (including attributes, derived attribute values, and attribute bundles) to IdPs in a secure fashion in adherence to the requirements in Sec. 4.1 or Sec. 5.1 , as applicable.

• The authenticators used to authenticate the subscriber at the IdP (during a federation transaction) or CSP (while issuing attribute bundles to a subscriber- controlled wallet) are used in accordance with [SP800-63B] .

• The assertions generated by IdPs adhere to the requirements in Sec. 4.9 or Sec. 5.8 , as applicable.

• RPs adhere to requirements for handling subscriber attribute data, such as retention, aggregation, deletion, and disclosure to third parties.

• RP and IdP systems use agreed-upon profiles of federation protocols, as specified by the federation authority.

The federation authority MAY provide a programmatic means for parties under the trust agreement to verify the membership of other parties in the trust agreement. For example, a federation authority could provide a discovery API that provides the vetted capabilities of an IdP for providing identities to RPs within the system. Alternatively, the IdP or Wallet Vetting

IAL 1 AAL 1 FAL 1 Requires:

RP w

IdP b IAL AAL FAL 1 2 IdP a IAL AAL FAL 1 1 1

IdP d IdP c IAL AAL FAL RP y IAL 3 AAL 3 FAL 3 Requires: IAL 1 AAL 2 FAL 2 Requires:

RP x Federation Authority

1 2 1 2