3.5 Trust Agreements

Before · SP 800-63C

After · SP 800-63C-4

Trust Agreements

Before · SP 800-63C

After · SP 800-63C-4

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