commerce-canon/research/authentication-federation/shared-signals-caep-risc.md

# Shared Signals, CAEP, and RISC

## Source Type

Standard and profile. OpenID Shared Signals Framework 1.0, CAEP (Continuous
Access Evaluation Profile), and RISC (Risk Incident Sharing and Coordination).

## Domain

Security event sharing, session lifecycle, account state propagation, and
continuous access evaluation across federated systems.

## Why This Source Matters

OpenID Shared Signals, CAEP, and RISC suggest that canonical identity models
should anticipate dynamic security and lifecycle events.

Federation is not static. Shared Signals define how issuers push account
compromise, credential change, session revocation, and user profile update
events to relying parties — requiring lifecycle-aware identity modeling.

## Key Concepts

- **Shared Signals Framework (SSF)**: transport and envelope for delivering
  security events between transmitter and receiver.
- **Transmitter**: entity (typically IdP) sending events about subjects.
- **Receiver**: entity (typically RP) consuming events and updating local state.
- **Subject in event**: identifies the affected party, often by `sub` and `iss`
  or equivalent.
- **CAEP events**: session-revoked, token-claims-change, credential-change,
  assurance-level-change, and related continuous evaluation signals.
- **RISC events**: account-credential-compromise, account-disabled,
  account-enabled, identifier-changed, and recovery-related events.
- **SET (Security Event Token)**: JWT-format event payload.
- **Stream configuration**: receiver registers endpoint; transmitter manages
  delivery and retry.
- **Verification**: receivers validate SET signatures from transmitter.

## Relevant Terminology

| Term | Source meaning |
| --- | --- |
| Transmitter | Event source (usually OP/IdP). |
| Receiver | Event consumer (usually RP). |
| SET | Security Event Token (JWT). |
| Subject (event) | Identifies affected user at transmitter. |
| Session revoked | Active sessions should be terminated at receiver. |
| Credential change | Password/key rotation; may require re-auth. |
| Account disabled | Subject account suspended at transmitter. |
| Identifier changed | Subject ID or attribute materially changed. |
| Assurance level change | IAL/AAL/FAL or equivalent changed. |
| Stream | Configured event delivery channel. |

## Modeling Assumptions

- **Identity state changes over time** and RPs must react without polling.
- **Subject in events maps to prior federation binding** (`iss`+`sub` or
  equivalent).
- **Lifecycle events are issuer-authoritative** for issuer-managed accounts.
- **Receivers maintain local session/account state** that must reconcile with
  events.
- **Not all state changes imply synonymity changes**; identifier-changed may
  require rebinding.
- **Events are evidence** for downstream state transitions.

## Identity-Canon Implications

- SSF events map to **Evidence Source** events triggering **Lifecycle State**
  transitions on Account, Session projection, or Synonymity Assertion.
- **Account disabled/enabled** maps to Lifecycle State change on Account or
  Identity Record.
- **Credential change** maps to Credential lifecycle event; may invalidate
  sessions.
- **Session revoked** affects session projection, not canonical Account.
- **Identifier changed** may require superseding **Identifier Binding** or
  Synonymity Assertion with new target.
- **Assurance level change** maps to updated **Assurance Level** metadata.
- Reinforces **P8** (preserve source/evidence) and invariant that lifecycle
  applies to relationships and assertions, not only accounts.
- Supports S02 (multi-account lifecycle), S13 (link revocation), federation
  scenarios requiring continuous evaluation.

## Terminology Conflicts

- **Subject**: event subject is issuer identifier; not authorization subject.
- **Account**: event "account disabled" means issuer-side record; RP may have
  separate local account.
- **Session vs. Account**: session revocation ≠ account deletion.
- **Identifier changed vs. Synonymity**: identifier migration is not automatic
  same-as merge.
- **Continuous access vs. Authorization**: CAEP informs access evaluation but
  is not a policy engine.

## Candidate Canonical Mappings

| SSF/CAEP/RISC concept | Candidate canonical concept |
| --- | --- |
| SET event | Evidence Source (event) |
| Transmitter | Issuer Scope |
| Receiver | Relying party Scope |
| Event subject | Identifier reference |
| Account disabled/enabled | Lifecycle State transition |
| Credential change | Credential Lifecycle State |
| Session revoked | Session projection lifecycle |
| Identifier changed | Identifier Binding supersession |
| Assurance level change | Assurance Level update |
| Token claims change | Claim set modification event |

## Open Questions

- Should SET event types be enumerated in canon as standard Evidence Source
  categories?
- How should identifier-changed events interact with existing Synonymity
  Assertions (supersede vs. revoke vs. chain)?
- Should receivers model event processing state as Relationship between
  Receiver Scope and Transmitter Scope?
- Are session projections worth a minimal canonical mention given SSF
  prevalence?

## References

- OpenID Shared Signals Framework 1.0 — https://openid.net/specs/openid-sharedsignals-framework-1_0.html
- OpenID CAEP 1.0 — https://openid.net/specs/openid-caep-1_0.html
- OpenID RISC 1.0 — https://openid.net/specs/openid-risc-1_0.html
- RFC 8417: Security Event Token (SET) — https://datatracker.ietf.org/doc/html/rfc8417