NIST Digital Identity Guideline 800-63-4 and OpenIDF Shared Signal Framework Discussion on Trust Agreement requirement for SSF

By Tom Sato

Nov 10th, 2025

The NIST Digital Identity Guideline 800-63-4 provides a comprehensive set of standards for the US Government suppliers whose software or services involve users' digital identities. The final version was released in August 2025. Around that time, the OpenIDF Shared Signal working group finalized their Shared Signal Framework (SSF) specifications. NIST 800-63-4 encourages the implementation of shared signals, and with the official SSF specification now available, the industry is focusing on building production-ready systems and conducting conformance and interoperability testing. SSF plays a critical role in safeguarding user accounts from credential compromise and breaches, which is why NIST strongly advocates its adoption.

NIST SP 800‑63C‑4 (“Federation & Assertions”) requires a Trust Agreement between Credential Service Providers (CSPs) and Relying Parties (RPs). This legal agreement defines how parties operate within federated identity transactions and sets limits on digital identity usage. As systems become more complex, such agreements should be multilateral, enabling industry-wide collaboration. Implementing SSF requires careful adherence to trust agreement terms, as SSF’s primary purpose is to protect digital identities and user accounts securely and dynamically.

NIST serves as a standards authority and provides recommendations regarding the contents of a Trust agreement; however, this document should not be considered a template or draft agreement for industry adoption. If NIST were to produce a legal document, it would likely require submission to Congress. Furthermore, this guideline is intended as a general overview and does not address the detailed technical specifications found in standards such as SSF. Nor does it prescribe operational practices for businesses, which must adhere to their own requirements. Its primary focus is establishing standards for business practices that safeguard end user privacy and offer protection against account takeover and data breaches.

Industry players often struggle to reach consensus on trust agreements, especially when companies like Microsoft, Apple, and Google each have their own technologies and interests. Similar efforts have failed before.

A neutral third party drafting a legal document for the industry could help create a standard draft that is agreeable by industry adopters. However, the OpenID Foundation focuses on technology, not legal standards, and I have not encountered any lawyers or related discussions in their working groups.

However, I anticipate that this trust agreement may present challenges for many organizations implementing SSF and adhering to NIST standards for government contracts.

Putting together a draft of this trust agreement will be a complex task.

Let’s see, the steps.

1.       Map out trust agreement requirements according to industry technical standards.

2.       Analyze typical business and operational requirements to comply with the Guidelines.

3.       Research existing corporate EULA and other IAM related agreements.

4.       Put together draft legal document

5.       Review by corporations and edit according to industry requirements.

6.       Publish final draft legal document with operational policy recommendations.

The NIST 800 63-4 covers variety of technical standards and by no means SSF is only technical standards adopters needs to cover. Verifiable Credentials and Open Wallet Specifications needs to address this guideline and well as existing identity federation specs.

As I have a reasonable understanding of SSF, I have written the second part of this document describing how NIST 800-63-4 covers SSF.

This document is by no means definitive guide and may contain mistakes and miss representation of these standards and guidelines. I welcome input, comments, recommendations and I shall be happy to correct and edit as appropriate.

Part 2 Creating NIST 800 63-4 compliant trust agreement for Shared Signal Framework

What is a Trust Agreement?

A Trust Agreement defines the terms by which parties in a federated identity transaction—such as an account provider, Identity Provider (IdP), and Relying Party (RP)—set their rights, responsibilities, and expectations for working together within the federation.

In the document it states:

“All federation transactions SHALL be defined by one or more trust agreements … The trust agreement SHALL establish a trust relationship between the RP and … the CSP, or the IdP, or both.”

Also: “Trust agreements establish the terms for federation transactions between the parties … including things like the allowed xALs and the intended purposes of identity attributes exchanged in the federation transaction.”

In other words: before or during federation, the parties agree “we will trust each other to behave in these ways, for these users, doing these kinds of identity/assertion exchanges”.

Key Elements/Requirements of a Trust Agreement

According to SP 800-63C-4, a Trust Agreement should cover a number of items. Some of the mandatory (“SHALL”) or strongly expected (“SHOULD”) items include:

• The population of subscriber accounts to which the agreement applies (e.g., all subscribers of IdP X, or only those of a certain class).
• The allowed/expected assurance levels (Identity Assurance Level – IAL; Authenticator Assurance Level – AAL; Federation Assurance Level – FAL) that will govern the relationship. (“Trust agreements SHALL establish terms regarding expected and acceptable IALs and AALs …” )
• The set of attributes or attribute-bundles that the IdP is permitted (or the RP is permitted to request) to send to the RP. (What identity information will be shared)
• The purposes for which those identity attributes may be used by the RP. (Purpose limitation)
• Data-handling and data-retention policies applicable to attribute data exchanged (e.g., how long will the RP retain them, how will deletion be handled)
• The mechanism(s) for redress: how complaints, error cases, subscriptions account issues, dispute management will be handled among the parties. (“… define necessary mechanisms and materials to coordinate redress and issues between the different participants…” )
• Usability and equity commitments: The trust agreement “SHALL establish customer experience requirements for the federation transaction” and consider fairness/usability.
• The proofing and enrollment processes used by the CSP/IdP for the subscriber accounts covered by this agreement, including any compensating controls or exceptions.
• Disclosure of the trust-agreement terms to the subscriber in clear understandable language. (“… the terms of the trust agreement need to be made available to subscribers in clear and understandable language.”)

Types of Trust Agreements

The document distinguishes at least two major types of trust agreements:

1. Bilateral Trust Agreement

• A direct agreement between two parties (e.g., IdP ↔ RP) without a separate federation authority.
• The parties manage onboarding, terms, etc themselves.

2. Multilateral Trust Agreement

• Involves a “federation authority” that manages vetting of parties and maintains a framework under which many IdPs and many RPs may operate.
• The federation authority sets the criteria, participants are vetted, and then operate within that framework (possibly with many bilateral connections derived).
• Can include “interfederation” (federation of federations) when one federation authority trusts another.

Subscriber-Driven Trust Agreement

• At the lowest level (FAL1) the trust agreement may be established by the subscriber during the federation transaction (rather than pre-established).

Where in the Assurance Levels Does It Matter?

The trust agreement requirement is tied to the Federation Assurance Level (FAL). For example:

• At FAL1, the trust agreement may be established by the subscriber during the transaction (i.e., dynamic) or pre-established.
• At FAL2 and FAL3, the trust agreement must be pre-established (i.e., the parties must have agreed ahead of time). At FAL2: “a trust agreement SHALL be established prior to the federation transaction taking place (i.e., a ‘pre-established’ trust agreement).” At FAL3: similar requirement; plus stronger controls.

So the higher the assurance required for the federation transaction, the stronger the requirement for a formal, pre-established trust agreement.

Practical Implications and Tips

Here are some things to watch out for from an implementation or organizational perspective:

• Define the scope clearly: Who are the subscriber accounts covered? What IdP(s) and RP(s) are involved? If you allow multiple IdPs → multiple RPs, you may need multiple trust agreements or one umbrella.
• Assurance levels matter: If the RP expects high confidence (e.g., FAL3) you cannot rely on a “just-in-time” user consent model; you must have set up a formal trust agreement in advance.
• Attribute mapping & purpose: Trust agreements should document what identifiers/attributes will be shared and why. Avoid surprise sharing.
• Transparency to the end‐user (subscriber): Even though the subscriber is not party to the agreement as a signatory, they are impacted by its terms. The agreement terms (in simplified form) need to be disclosed to them in a way they can understand.
• Redress & governance: Who handles subscriber complaints? What happens if one party fails its obligations? The trust agreement should define escalation, auditing, and termination conditions.
• Lifecycle management: Trust agreements should include review cycles (“periodically reviewed to ensure still fit for purpose”), termination conditions, and data retention/deletion policies.
• Technical registration / key exchange tie-in: While the trust agreement defines the “policy” level terms, there also needs to be a Registration/Identifier & Key Establishment step (i.e., exchanging identifiers, keys, certificates) so that subsequent federation transactions can be authenticated. The trust agreement should reference or enable this.
• Usability & equity: The guideline highlights fairness, accessibility, usability. The trust agreement should include commitments (or at least provisions) to ensure the federation process doesn’t exclude particular populations or create undue burden.
• Dynamic vs static agreements: At lower assurance levels, there is more flexibility (subscriber-driven, dynamic). But at higher assurance levels, you must treat the trust agreement like a contract — pre-agreements, defined populations, vetting, etc.

A trust agreement under SP 800-63C-4 is the foundational contract that governs how an IdP (and possibly a CSP) and an RP will work together in a federated identity scenario. It sets out what is trusted, how the trust is achieved, what attributes and assurances are acceptable, how users will experience the system, how data is handled, and how failures will be managed. The higher the assurance you need, the more rigorous the trust agreement must be.

PART 3 What is “Shared Signaling”?

In a federated identity setup (for example, an identity provider (IdP) and a relying party (RP) working together), “shared signaling” refers to the exchange of state change messages or notifications outside of the standard assertion or authentication flow. In other words, beyond “IdP issues assertion → RP consumes it,” there may be signals like “subscriber account terminated,” “session compromised,” “authenticator bound,” etc., that one party informs the other about.

Explanation of OpenIDF SSF (Shared Signals Framework)

Shared Signals Framework is a three set of protocols, SSF which defines the communication framework to send messages securely using security event token format. The challenge is that many systems base decisions purely at login time; SSF enables continuous ongoing/real-time event sharing. CAEP (Continuous Access Evaluation Profile) defines event types specifically related to session/device lifecycle and continuous access decisions. RISC (Risk Incident Sharing & Coordination) focus on account lifecycle and security incidents (e.g., credential compromise, account disable/enable, identifier changed) and is used for sharing risk/incident signals across systems.

PART 4 How the Trust Agreement Must Address Shared Signaling

If your federation relationship includes shared signaling (outside the standard assertion path) then your trust agreement must clearly define what triggers a signal, what the signal contains, who sends/receives it and how the recipient will respond — and you must assess the privacy implications of sending such signals.

NIST 800-63C-4 treats “shared signaling” as a governance/policy commitment inside the trust agreement, and the OpenID specs (SSF, CAEP, RISC, CAEP Interop) are the technical rails that implement those commitments. Below is a practical, developer-and-counsel friendly breakdown.

1) What 63C-4 requires the trust agreement to say about shared signaling

NIST is explicit that if you use shared signaling, your trust agreement must cover:

• Triggers (events) that cause a signal — e.g., account termination/suspension, suspected compromise, authenticator binding changes, attribute/identifier changes, or changes in available xALs.
• Signal contents and format — what goes in the message (and what must not). NIST says shared signals shall not include personal information beyond what’s required to identify the account (e.g., an account identifier), and the expected processing by the receiver must be documented.
• Who may signal whom and under what trust — IdP → RP signaling requires a pre-established trust agreement (i.e., not created ad-hoc at runtime). NIST allows other directions (e.g., RP→IdP) more flexibly but still within the trust agreement’s terms.
• Privacy review — use of shared signaling SHALL undergo a privacy review under the trust agreement; include minimization, retention, and onward-sharing limits.
• Federation authority / multilateral model — in multilateral federations the trust agreement (or framework) establishes the common signaling channel and onboarding rules so any IdP/RP can report issues about an account to the rest of the members.

2) How the OpenID specs implement what NIST asks for

OpenID’s Shared Signals Framework 1.0 (SSF) is the general “bus”; CAEP 1.0 and RISC 1.0 are event profiles that ride on it, and the CAEP Interoperability Profile 1.0 nails down practical interop. In short:

• SSF 1.0 — Defines how to share events between peers using Security Event Tokens (SET, RFC 8417), subject principals/claims, event typing, and delivery patterns. Think: the envelope, addressing, and base event model.
• CAEP 1.0 — Defines continuous session-state updates (e.g., token revoked, device posture changed) to enable near-real-time access attenuation.
• CAEP Interop Profile 1.0 — Tightens CAEP for plug-and-play (naming, endpoints, discovery, error semantics, etc.) so different vendors interoperate out-of-the-box.
• RISC 1.0 — Defines risk/incident event types (account takeover suspected, credential leaked, etc.) on SSF/SET.

3) Trust-agreement clauses you need (and how the OpenID specs satisfy them)

4) CAEP + RISC + SSF event-to-NIST-trust-agreement matrix

5) Policy Domains (how each applies to trust agreement)

Trust-Agreement Requirement (NIST 63C-4)

Applied to Signals

Purpose Limitation

Each signal must have an explicit purpose stated in the agreement (“used only for security and session integrity, not for profiling”).

Data Handling Policy

Define per-signal data elements allowed, retention time (e.g., ≤ 90 days), storage controls, and deletion process.

Redress Mechanism

Subscriber must have a means to appeal a false signal (e.g., “contact support within X days to reopen account”).

Usability & Equity

Ensure signals don’t unfairly lock out users or require steps beyond reasonable burden; provide clear messages.

Privacy Protection

Shared signals must carry only event metadata and minimal IDs (“no payload of behavioral data or PII”).

Receiver Behavior

For each event, agreement must specify expected action within defined SLA (e.g., “RP shall terminate session within 60 seconds of session-revoked signal”).

Audit & Review

Regular review to ensure events are used consistently with policy and signals are effective.

6) Checklist for agreement draft

1. Scope & roles: Identify Transmitters/Receivers (IdPs, RPs, federation authority); include endpoints, keys, and environments.
2. Event catalog & mappings: For each business trigger, cite the CAEP or RISC event type and payload claims you will use; include version pins (e.g., SSF 1.0, CAEP 1.0, RISC 1.0).
3. Authorized party & directionality: State which directions are allowed (IdP→RP requires pre-established trust) and who is allowed to transmit which events.
4. Receiver actions & SLAs: Define required actions (e.g., revoke session), time targets, and escalation paths; require idempotent processing.
5. Privacy controls: Limit payload to identifiers and essentials; forbid extraneous PII; document retention and access; attach DPIA/PIA.
6. Security & integrity: Require HTTPS + signed SETs (JWS); outline key rotation, replay protection, rate limiting, and anomaly monitoring aligned to SSF.
7. Discovery/registration: Define metadata discovery (JWKS, endpoints), conformance to CAEP Interop where applicable, and break-glass procedures.
8. Governance: If under a federation authority, specify onboarding, testing, change control, and ejection; reference the authority-managed shared signaling channel.
9. Audit & redress: Mutual audit rights for signaling controls; subscriber complaint and correction routes; incident reporting timelines.
10. Versioning: Pin spec versions (SSF/CAEP/RISC) and define upgrade/change-management windows.

7) Some Additional Points & Good Practices

• While signalling from the IdP to the RP requires a pre-established (static) trust agreement, signalling from RP → IdP may be allowed in both pre-established and subscriber-driven (dynamic/trust-at-use-time) models.
• The guideline lists typical events the IdP should signal, such as: account termination/suspension, suspected compromise, attribute value changes (including identifiers), changes in the range of IAL/AAL/FAL for the account.
• For the RP signalling to IdP: examples include account termination, suspected compromise, bound authenticator added or removed. If the IdP receives a compromise signal, it must review possible issues and may then signal other RPs the subscriber used.
• Implementers should treat shared signaling as a supplement to the primary assertion/attribute exchange, not a replacement. That means the trust agreement should reflect where signaling is used and how it complements the core federation flows.
• From a governance and operational view: treat these signals like part of the “lifecycle” of the federated identity — not just one-time proofing: you’re managing changes, risk, compromise, de-provisioning across parties.

8) Implementation notes & pitfalls

• Don’t over-share: NIST’s minimization rule means no rich PII in the signal—stick to identifiers and event metadata; put details behind authenticated APIs if needed.
• Pre-established for IdP→RP: At higher assurance (FAL2/3), your IdP→RP signaling must sit on pre-established trust—don’t rely on ad-hoc runtime consent.
• Interop matters: If you mix vendors, CAEP Interoperability Profile prevents “near-miss” integrations—codify adherence to it.
• Federation-scale ops: In multilateral setups, write down who can broadcast which events and how abuse is prevented (throttling, attestation, removal). NIST’s example endorses a federation-managed channel.
• Lifecycle hooks: Align signaling with account lifecycle (enrollment, binding, suspension, termination), and explicitly map authenticator events (add/remove/breach) to RISC/CAEP types.

9) Example End-to-End Scenarios

1. Credential Compromise Signal Trigger: IdP detects password breach. RP Action: Immediately invalidate sessions, flag account for review, require password reset and MFA check, notify user and record event. Policy Note: Trust agreement requires use solely for security; retain log 90 days; provide redress path for false flag.
2. Recovery Activated Signal Trigger: Account owner initiates recovery flow. RP Action: Restrict high-value transactions until identity re-verified; notify security and user; log for audit. Policy Note: Use only to protect against fraud; no extra PII; retain record 30 days.
3. Device Compliance Change Trigger: Endpoint goes out of compliance (e.g., jail-broken OS). RP Action: Limit or deny access from device; present instructions to remediate. Policy Note: Fair access requirement → allow alternate compliant device paths.
4. Session Revoked / Logout Trigger: User logs out at IdP or security event. RP Action: Terminate session, clear cookies, redirect to logout page. Policy Note: Usability emphasis → graceful UX and clear notice.

END

NOTE

Written by Tom Sato Nov 10th 2025 With some help from OpenAI ChatGPT