+3.5 Trust Agreements
---+3.5.1 Bilateral Trust Agreements
---+3.5.2 Multilateral Trust Agreements
---+3.5.3 Redress Requirements

3.5 Trust Agreements

Trust agreements are a construct that represent the set of trust relationships established to support parties in a federation transaction. A trust agreement SHALL address one or more of the following relationships:

IdP to CSP:
The IdP trusts the CSP to provide access to attributes in subscriber accounts, through either an IdP onboarding process or the issuance of attribute bundles. The IdP trusts the CSP’s identity proofing processes used in the establishment of the subscriber account.
CSP to IdP:
The CSP trusts the IdP to accurately represent subscriber identity attributes to RPs and to not disclose identity attributes outside of agreed-upon functionality. The CSP trusts the IdP to protect the release of attributes, such as requiring authentication of the subscriber or the presentation of an activation factor before attributes are released.
RP to IdP:
The RP trusts the IdP to accurately represent subscriber identity attributes as provided by the CSP. The RP trusts the IdP to authenticate or identify the subscriber when representing an authentication event.
IdP to RP:
The IdP trusts the RP to only use the requested attributes for its stated purposes.
RP to CSP:
The RP trusts the CSP to provide access to subscriber identity attributes through IdPs. The RP trusts that the CSP has identity-proofed the subscriber and is managing the subscriber account.

All federation transactions SHALL be governed by the terms of one or more trust agreements between the applicable parties. Different relationships MAY be established at different times and by different processes. For example, a CSP and IdP entering into a trust agreement is generally separate from an RP and IdP entering into a trust agreement, but the overall set of terms for a federation transaction under these parties is drawn from both sets of relationships.

Different scenarios will require different combinations of trust in order to function, and these combinations can vary based on the federation model in use. The combination of individual trust agreements that are applicable to a federation transaction fulfills the requirements of these guidelines. Trust agreements can take different forms, including formal contractual agreements, informal dynamic user agreements, and other documented bilateral or multilateral trust decisions by the parties in the federation. In many cases, trust agreements can be implemented using a trust framework, which formalizes a set of rules for parties to connect with each other. Trust frameworks are often used by federation authorities to formalize the rules for the federation being managed by the federation authority.

For example, consider the case of subscriber-controlled wallets in which an RP might accept assertions without a direct or complete trust agreement with the CSP. As described in Sec. 5.3, provisions of the relevant trust agreements might be determined unilaterally by the RP through the evaluation of publicly available information about CSPs and their processes for issuing attribute bundles. The CSP does not need to know about the RP in order for this part of the trust relationship to be established. In order to fulfill the requirement to disclose the RP’s purpose for using attributes, the RP can disclose these purposes to the subscriber at runtime without informing the CSP.

Trust agreements establish the terms for federation transactions between the parties they affect, including the allowed xALs and the intended purposes of identity attributes exchanged in the federation transaction. The trust agreement SHALL establish customer experience requirements for the federation transaction, as discussed in Sec. 8. The trust agreement SHALL include details of the proofing process used at the CSP for subscribers covered by the trust agreement, including any compensating controls and exception handling processes.

All trust agreements SHALL define a specific population of subscriber accounts to which the agreement is applicable. The exact means of defining this population are out of scope for this document. In many cases, the population is defined as the full set of subscriber accounts that the CSP manages and makes available through an IdP. In other cases, the population is a demarcated subset of accounts that are available through an IdP. It is also possible for an RP to have a distinct trust agreement established with an IdP for a single subscriber account, such as in a subscriber-driven trust agreement.

During the course of a single federation transaction, it is important for the policies and expectations of all parties to be unambiguous. Therefore, there SHOULD only be one set of trust agreements in effect for a given transaction. This will usually be determined by the unique combination of CSP, IdP, and RP that are participating in the transaction. However, these agreements could vary in other ways, such as different populations of subscribers being governed by different trust agreements. If more than one trust agreement is applicable to a federation transaction, the combined set of terms of all applicable trust agreements SHALL constitute the effective trust agreement of that transaction.

The existence of a trust agreement between parties does not preclude the existence of other agreements for each party with other parties. For example, an IdP can have independent agreements with multiple RPs simultaneously, and an RP can likewise have independent agreements with multiple IdPs simultaneously. The IdP and RP need not disclose the existence or terms of trust agreements to parties outside of or not covered by the agreement in question.

Trust agreements SHALL establish terms regarding expected and acceptable IALs, AALs, and FALs in connection with the federated relationship.

Trust agreements SHALL define necessary mechanisms and materials to coordinate redress and issues between the different participants in the federation, as discussed in Sec. 3.5.3.

Trust agreements SHALL declare the data retention policies expected of all parties.

Even though subscribers are not generally directly involved in the trust agreement’s terms, subscribers are affected by the terms of the trust agreement and the resulting federation transactions. As such, the relevant terms of the trust agreement SHALL be made available to subscribers in clear and understandable language. The terms of the trust agreement SHALL be reviewed by all parties (e.g., the CSP, IdP, RP, or a federation authority) that are responsible for informing the subscriber of the terms of the trust agreement before the disclosure to the subscriber occurs in order to avoid revealing sensitive security information.

The means by which the subscriber can access these terms and the party responsible for informing the subscriber vary based on the means of establishing the trust agreement and the terms of the trust agreement itself. Common methods for disclosure include:

Providing a subscriber-accessible web page with relevant trust agreement terms
Sending a notice to the subscriber
Displaying a summarization of terms during a runtime decision with an option to review the full terms

The establishment of a trust agreement is required for all federation transactions, even those for which the roles and applications exist within a single security domain or shared legal ownership, such as an enterprise system. In these cases, the establishment of the trust agreement can be an internal process and does not need to involve a formal agreement. Even in such cases, the organization must still document and disclose the terms of the trust agreement to the subscriber upon request.

The subscriber’s user agent is not usually party to the trust agreement, unless it is acting in one of the roles of the federation transaction (e.g., a subscriber-controlled wallet running in the subscriber’s browser software).

1. Преглед

3.5.1 Bilateral Trust Agreements

In a bilateral trust agreement, the establishment of the trust agreement occurs directly between the federated parties, and the trust agreement is not managed or facilitated by a separate party. Bilateral trust agreements allow for a point-to-point connection to be established between organizations that wish to provide federated identity access to services. Bilateral connections can take many forms, including large enterprise applications with static contracts or subscriber-driven dynamic connections to previously unknown RPs. In all cases, the CSP, IdP, and RP directly manage their policies regarding the federated connection.

Bilateral trust agreements conform to the stated requirements for all trust agreements. However, since these trust agreements do not involve additional parties, there are no additional normative requirements for their establishment and management, such as those mandated for multi-lateral trust agreements (see Sec. 3.5.2).
3.5.2 Multilateral Trust Agreements

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.

Fig. 2. Federation authority

Diagram of a federation authority facilitating trust agreement terms for a variety of parties under the federation authority.

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 federation authority could provide a signed attestation for RPs to present to IdPs during a registration step.

Federation authorities SHALL periodically reevaluate members for compliance with terms disclosed in the trust agreement.

A multilateral trust agreement MAY establish trust based on other trust agreements that are managed by other entities by creating an interfederation agreement. For example, IdP1 has been vetted under a multilateral agreement with federation authority A1, and RP2 has been vetted under a multilateral agreement with federation authority A2. In order to facilitate connection between IdP1 and RP2, a new federation authority A3 can provide a multilateral agreement that accepts IdPs from A1 and RPs from A2. If IdP1 and RP2 accept the authority of A3, the federation connection can continue under the auspices of this interfederation agreement.
3.5.3 Redress Requirements

Federation transactions occur between multiple parties that are often controlled by multiple entities, and different stages of the federation transaction can lead to situations in which a subscriber would need to seek redress from the other parties.

As the recipient of a subscriber’s identity attributes, the RP is the subscriber’s primary view into the federated system. In some instances, the subscriber may be unaware that an IdP is involved with their use of the RP. Therefore, it falls to the RP to provide the subscriber with a clear and accessible method of contacting the RP to request redress. For matters that involve the RP subscriber account (including any attributes stored in the account), RP functionality, bound authenticators, RP allowlists, and other items under the RP’s control, the RP SHALL provide a clear and accessible means of redress to the subscriber. For matters that involve the IdP or CSP, the RP SHALL provide the subscriber with a means of initiating the redress process with the IdP or CSP, as appropriate.

For matters that involve the use of the subscriber account in federation transactions, including attribute values and derived attribute values made available over federation transactions, IdP functionality, holder-of-key authenticators, IdP allowlists, and other items in the IdP’s control, the IdP SHALL provide a clear and accessible means of redress to the subscriber. For matters that also involve a particular RP, the IdP SHALL provide the subscriber with a means of initiating the redress process with the RP. For matters that involve a subscriber account that has been made available to the IdP, the IdP SHALL provide the subscriber with a means of initiating the redress process with the CSP.

For matters that involve the subscriber account, including identity attributes and authenticators in the subscriber account, the CSP SHALL provide the subscriber with a clear and accessible means of redress.

See Sec. 3.6 of [SP800-63] for more requirements on providing redress.

1.1 Препратки

1.2 Идентифицирани изисквания

1.3 Свързани регулации

2. Идентифицирани изисквания

Изисквания

3. Свързани регулации

Регулации
  • NIST -

    EN: Publications of the National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, from their electronic versions (OSCAL; SP 800-63-4 from its HTML version, https://pages.nist.gov/800-63-4/). Works of NIST employees are not subject to copyright protection in the United States (17 U.S.C. § 105); the OSCAL content is dedicated to the public domain worldwide (CC0 1.0); outside the United States NIST grants the right to reprint its technical series publications in all formats (NIST copyright statement). Republished courtesy of the National Institute of Standards and Technology; each document names its citation. Divided into sections and converted into the GRCA format, the wording unchanged. Only the versions published by NIST are authoritative.

    DE: Veröffentlichungen des National Institute of Standards and Technology (NIST), U.S. Department of Commerce, https://www.nist.gov/, aus ihren elektronischen Fassungen (OSCAL; SP 800-63-4 aus ihrer HTML-Fassung, https://pages.nist.gov/800-63-4/). Werke von NIST-Beschäftigten sind in den USA urheberrechtlich nicht geschützt (17 U.S.C. § 105); die OSCAL-Inhalte sind weltweit gemeinfrei gestellt (CC0 1.0); außerhalb der USA räumt das NIST das Recht ein, seine Technical-Series-Publikationen in allen Formaten neu zu veröffentlichen (Copyright-Hinweis des NIST). „Republished courtesy of the National Institute of Standards and Technology“; jedes Dokument nennt seine Zitierangabe. In Abschnitte aufgeteilt und in das GRCA-Format umgewandelt, der Wortlaut unverändert. Maßgeblich sind allein die vom NIST veröffentlichten Fassungen.