🐣
今更ながら Shared Signals Framework に入門する

2025/09/16に公開
 この記事を書いたきっかけOpenID TechNight vol.21 ~ Shared Signal Framework に参加して興味を持ったもののなかなか時間を取れず...

満を持して読み始めたので、ひとまずまとめていこうと思います。

こちらの記事にてご興味を持たれた方は、是非 TechNight の録画をご覧いただければと思います。

※本記事でも Tom Sato 様のスライドを引用させていただきます。
https://youtu.be/jfhUmgVnUF4?si=fdN08gOkVt25gWXM

 Shared Signals Framework (SSF) とは何か？今日ではクラウド技術の発達とともに認証技術も発達し、様々な場所/様々な端末からログイン等が可能になっています。

シングルサインオン (SSO) は最たるもので、ユーザは一度の認証で様々なアプリ・サービスを利用することができます。
OpenID の Shared Signals Working Group では、一度認証された後も継続して本人が利用しているのかモニタリングされていないことに課題意識を持っています。

『認証操作をした時は本人の操作だったかもしれないが、そのあとにセッションが奪取されていたとしたら気付けない』というわけです。
(参照) 20240516 OpenID TechNight Vol.21 「OIDFシェアードシグナルフレームワーク（ID2）を利用してリアルタイムでセキュリティシグナルを共有するための最新情報」
The Shared Signals Framework (SSF) improves API efficiency and security by providing privacy-protected, secure webhooks. It is in use by some of the largest cloud services to communicate security alerts and status changes of users, continuously and securely to prevent and mitigate security breaches. It is currently leveraged by two applications – the Continuous Access Evaluation Protocol (CAEP) and Risk Incident Sharing and Coordination (RISC) to achieve this result.[1]
そこで Shared Signals Framework (SSF) は異なるサービスやアプリケーション間でセッションなどの情報を共有することでアクセス制御を強化することを目的とし、送信者 Transmitter と 受信者 Receiver の間でイベントのリアルタイムな双方向通信を行う Webhook 標準化として、以下の2つを規定しています。
Continuous Access Evaluation Protocol (CAEP): セッション状態および管理に関わるイベントの共有
Risk Incident Sharing and Coordination (RISC): アカウント状態および管理に関わるイベントの共有
※HTTP で Push/Poll を行います。筆者は当初「リアルタイム」「双方向」から WebSocket なのかなと思っていました。。。

※ Shared Signals Working Group は、OpenID の RISC Working Group と Google が提案した CAEP が祖になっている様です。

※ CAEP のイメージは以下。SET は Security Event Token のこと。
(参照) sgnl - CAEP Use Case: Increase Token Lifetime

 どんなユースケースが考えられる？双方向性を持つため、IdP とアプリ (RP) のいずれからも起点として情報を伝達することができます。
(参照) 20240516 OpenID TechNight Vol.21 「OIDFシェアードシグナルフレームワーク（ID2）を利用してリアルタイムでセキュリティシグナルを共有するための最新情報」
TechNight vol.21 ではいくつかのユースケースが紹介されていました。
IdP がログイン済みユーザの情報漏洩を検知して、アプリにセッション破棄を指示する。
サイバーセキュリティがパスワードの漏洩を検知して IdP に通知し、IdP がアプリにセッション破棄を指示する。
アプリがユーザの異常行動を検知して、IdP にセッション破棄を指示する。
IdP でのアカウント管理によって削除されたことをアプリに通知して、余計な重要情報をアプリ側での削除を指示する。
また、セッション破棄をしても良いケースについては事前にポリシーを合意しておくことが重要な点についても触れられていました。

例えば、漏洩したパスワードが過去のものであったとしたら現在のセッションは安全であるはずなのに破棄される or アカウントが停止される等が行われることは本意ではない、ということです。
このポリシー合意が非常に難しく、現行のアカウントライフサイクルや権限管理の方法に対してどのように SSF を取り込んでいくのか、あるいは今後 SSF と組み合わせて実装したい技術 (後述する AuthZEN 認可等) に対してどういう線引きをするのか、じっくりと考える必要があることがわかります。

 AuthZEN (認可) との違いは？認証後のユーザの操作を制限する、と考えるとまず真っ先に思い浮かべるのが認可だと思います。

認可の仕様の標準化は OpenID の AuthZEN Working Group で進められています。

OpenID では「CAEPとAuthZENは互いに競合しているのか」という問いに対して、補間的な関係であるとの回答が述べられています。
PDPは即座に決定を下す必要がありますが、ローカルで利用可能な情報が古くなっている可能性があります。これには、ユーザーが管理対象デバイスからサービスにアクセスしているかどうか、ユーザーのセッションがまだ有効かどうか、ユーザーが現在、要求されたリソースにアクセスすることの業務上の必要性があるかどうかなどのセッションの状態が含まれます。これらの情報はそれぞれ異なるクラウドサービスにある可能性があるため、ユーザーが要求されたリソースにアクセスしようとしているときにこれらすべてを取得すると、クラウドサービスのレイテンシーと可用性に深刻な影響が及びます。
そこで登場するのがCAEPです。CAEP を使用すると、アクセスの決定に必要な情報を考慮に入れる必要がある任意のクラウドサービスに、必要な情報を非同期的に配信できます。アクセス決定自体は、PEP と PDP の間で AuthZEN を使用できます。SSF は、誰がどの情報を購読でき、どの主体について登録できるかを決定するための堅牢なフレームワークを提供します。CAEP は、アクセスの決定に影響を与える可能性のあるセッション状態の情報を提供します。[2]
つまり AuthZEN の観点では
PxP 認可アーキテクチャでは即レスポンス性を求められるため、実運用を考えると判定に利用できるデータの範囲は限られてしまう。
セッションコントロールを CAEP に任せることで、認可判定に使う情報粒度を調整可能。
と読めます。
AuthZEN に沿った認可プロダクトとしては Open Policy Agent (OPA) があります。

Open Policy Agent の認可アーキテクチャとしては、判定時に必要なデータを取得しにいく方法や、PEP (API ゲートウェイ等) にデータ処理を任せる方法等によって、様々な情報をソースに判定を行い処理の OK/NG を出すことができます。[3]

※例えば、接続元の IP や ブラウザの変更などは PEP で検知し、PEP でブロックすることも OPA に情報を流して NG を返してもらうことも可能。
ただし、これらを作りこむことでレスポンス遅延のほかにも構成・ポリシーの複雑化等の課題がありました。[4]

そこで、全てを OPA に任せるのではなく (セッションコントロールの範囲については特に) 仕分けて別の仕組みに任せることができると考えると、親和性は高いように感じます。
また、AuthZEN ではアカウントコントロールがスコープに入っていない点は SSF (RISC) との明確な違いになります。

 どれくらい広がっているのか？TechNight vol.21 では Entra ID や Okta での実装、また政府関係者が関わってきていることについて言及がありました。


(参照) 20240516 OpenID TechNight Vol.21 「OIDFシェアードシグナルフレームワーク（ID2）を利用してリアルタイムでセキュリティシグナルを共有するための最新情報」

 Entra ID での実装例Entra ID では CAEP に基づく CAE にてアクセス評価を行うこと、また Exchange, Teams, SharePoint Online に重点が置かれていることが名言されています。
ポリシー違反やセキュリティの問題にタイムリーに対応するには、トークン発行元 (Microsoft Entra) と証明書利用者 (対応のアプリ) の間で "対話" を行う必要があります。
(中略)
この対話のメカニズムは、Open ID Continuous Access Evaluation Profile (CAEP) に基づく業界標準である、継続的アクセス評価 (CAE) です。 重大なイベント評価の目標は、ほぼリアルタイムに応答することですが、イベントの伝搬時間のために最大 15 分の遅延が発生する可能性があります。ただし、IP の場所のポリシーは即時に適用されます。[5]
Exchange, Teams, SharePoint Online では2種類のシナリオ (①重大なイベントの評価、②条件付きアクセスポリシー)で CAE をサポートしているようです。

※CAE に対応するようにアプリを準備しても、CAE をサポートしていない API が制限されるわけではないことに注意。[6]
① 重大なイベントの評価
ユーザーアカウントが削除または無効化された
ユーザーのパスワードが変更またはリセットされた
ユーザーに多要素認証が有効化された
管理者が、ユーザーのすべての更新トークンを明示的に取り消した
高いユーザー リスクが Microsoft Entra ID 保護によって検出された
→ 重大なイベントが発生してから数分以内に、Microsoft 365 クライアント アプリから組織の SharePoint Online ファイル、電子メール、予定表、タスク、および Teams にアクセスできなくなる。
② 条件付きアクセスポリシー
ネットワークの場所が変更された場合はただちに、Microsoft 365 クライアント アプリまたは SharePoint Online からファイル、Email、予定表、タスクにアクセスできなくなる。

※ただし、全ての組み合わせでサポートされているわけではないので注意。
条件付きアクセスポリシーについて、公式で紹介されている例が以下です。
許可された IP レンジ内からアクセストークンを発行したユーザが、許可レンジ外からトークンを用いてリソースにアクセスするとき、アクセスは拒否 (401) されて要求チャレンジを求められます。

要求チャレンジは WWW-Authenticate ヘッダ (error という値を持つ insufficient_claims パラメータと claims パラメータを持つ) に含まれます。
HTTP 401; Unauthorized

Bearer authorization_uri="https://login.windows.net/common/oauth2/authorize",
  error="insufficient_claims",
  claims="eyJhY2Nlc3NfdG9rZW4iOnsibmJmIjp7ImVzc2VudGlhbCI6dHJ1ZSwgInZhbHVlIjoiMTYwNDEwNjY1MSJ9fX0="
アプリは上の条件に合致したレスポンスを受け取ったとき、claims を Base64 デコードし clientCapabilities プロパティ (CP1) を追加 (※) して再認証要求します。

※アプリが CAE 対応可能であることを Micrsoft Identity に伝えるため。

 Okta での実装例Okta では Identity Threat Protection with Okta AI の機能の一部として Okta を Receiver 設定することで、SSF 活用した Okta ユーザ保護を行うことができることが記されています。

また、Okta 製品に加えて以下の製品のシグナルを受信できると記載があります。[7]

※設定は Admin Console より行う。


セキュリティプロバイダー
アプリ


AppOmni
全製品

Cloudflare
Cloudflare One Enterprise

CrowdStrike Falcon
Okta Verify

Jamf
Jamf Security Cloud（Jamf Radar）

Netskope
Netskope Cloud Exchange

Omnissa（Workspace ONE）
Omnissa Access、Omnissa Intelligence、Workspace ONE

Palo Alto Networks
Cortex XDR + Cloud Identity Engine

Rubrik
Rubrik Security Cloud（RSC）

SGNL
全製品

SquareX
SquareX Enterprise

Widefield Security
全製品

Windowsセキュリティセンター
Okta Verify

Zimperium
Mobile Threat Defense（旧称「zIPS」）

Zscaler
Advanced Deception

以下の CAEP 相当イベントは CAEP 標準（後述）通り events に記載されます。[8]
device-risk-change
ip-change
user-risk-change
device-compliance-change
session-revoked
identifier-changed
# ip-change の場合
{
  "aud": "https://receiverexample.okta.com/",
  "events": {
    "https://schemas.okta.com/secevent/okta/event-type/ip-change": {
      "current_ip_address": "123.4.5.6",
      "event_timestamp": 1702448550,
      "initiating_entity": "admin",
      "previous_ip_address": "123.45.67.8",
      "reason_admin": {
        "en": "Event message example"
      },
      "reason_user": {
        "en": "Event message example"
      },
      "subject": {
        "format": "iss_sub",
        "iss": "https://transmitter.okta.com",
        "sub": "okta-user-id1"
      }
    }
  },
  "iat": 1702448550,
  "iss": "https://transmitter.example.com",
  "jti": "24c63fb56f ... a9fa24"
}

 仕様を覗いてみるSSF, CAEP および RISC は IETF の標準化の上に成り立っています。

よって、既存の JSON Web Token 仕様等に従って実装されています。
(参照) 20240516 OpenID TechNight Vol.21 「OIDFシェアードシグナルフレームワーク（ID2）を利用してリアルタイムでセキュリティシグナルを共有するための最新情報」
2025/9/2 には最終仕様 (1.0) が承認されています。
OpenID Shared Signals Framework Specification 1.0
OpenID Continuous Access Evaluation Profile 1.0
OpenID RISC Profile Specification 1.0
以下で日本語訳しながら内容を少し見てみます。

 OpenID Shared Signals Framework Specification 1.0Subject Principals
Subject Principal は、SSF内でイベントが関連する対象となるエンティティを指す。

SSF の目的は、これらの主体に関するセキュリティイベントを共有すること。
Subject Members in SSF Events
Subject Members は、イベント内でSubject Principalを識別するために使用されるクレーム。
Simple Subject Members: 単一の識別子 (例：メールアドレスや sub クレーム) で主体を表現。
Complex Subject Members: 複数の識別子 (例：ユーザーIDとデバイスIDの組み合わせ) を組み合わせて表現。
Events
各イベントは Security Event Token (SET) と呼ばれる JWT（JSON Web Token）としてフォーマット。

イベントの種類 (イベントタイプ) は URI で識別される。

イベントペイロードには、関連する主体に関する情報やイベントの詳細が含まれる。
Event Delivery
Transmitter から Receiver へイベントを配信する方法
Push-Based: Transmitter によって即座に Receiver に送信。リアルタイム性が重要となるシナリオ。
Poll-Based: Receiver が定期的に Transmitter にイベントの有無を問い合わせる。受信者が自律的にイベント取得のタイミングをコントロールするシナリオ。
Transmitter Configuration Discovery
Transmitter は /.well-known/ssf-configuration を準備してエンドポイントを公開。

Receiver は上記からメタデータを理解して接続を設定する。
Management API for SET Event Streams
Event Stream Management API は Transmitter が提供する、Receiver がイベントストリームを管理するためのエンドポイント。
+------------+                +------------+
|            | Stream Config  |            |
| Event      <----------------+ Event      |
| Stream     |                | Receiver   |
| Management | Stream Status  |            |
| API        <----------------+            |
|            |                |            |
|            | Add Subject    |            |
|            <----------------+            |
|            |                |            |
|            | Remove Subject |            |
|            <----------------+            |
|            |                |            |
|            | Stream Updated |            |
|            +---------------->            |
|            |                |            |
|            | Verification   |            |
|            <----------------+            |
|            |                |            |
+------------+                +------------+

 OpenID Continuous Access Evaluation Profile 1.0
 任意のイベントクレームevent_timestamp
イベントが発生した時刻。
initiating_entity
イベントを発生させたエンティティ。
admin (管理者アクション)
user (エンドユーザアクション)
policy (ポリシー評価)
system (システムトリガ)

reason_admin
ログ・監査目的の管理メッセージ。
言語タグを付ける。
reason_user
エンドユーザに表示するメッセージ。
言語タグを付ける。

 イベントタイプ基本形
{
    "iss": "https://idp.example.com/123456789/",
    "jti": "24c63fb56e5a2d77a6b512616ca9fa24",
    "iat": 1615305159,
    "aud": "https://sp.example.com/caep",
    "txn": "8675309",
    "sub_id": {
        "format": "complex",
        "session": {
          "format": "opaque",
          "id": "dMTlD|1600802906337.16|16008.16"
        },
        "user": {
          "format": "iss_sub",
          "iss": "https://idp.example.com/123456789/",
          "sub": "99beb27c-c1c2-4955-882a-e0dc4996fcbc"
        },
        "tenant": {
          "format": "opaque",
          "id": "123456789"
        }
    },
    "events": {
        "https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
            "initiating_entity": "policy",
            "reason_admin": {
                "en": "Landspeed Policy Violation: C076E82F"
            },
            "reason_user": {
                "en": "Access attempt from multiple regions.",
                "es-410": "Intento de acceso desde varias regiones."
            },
            "event_timestamp": 1615304991
        }
    }
}
セッションの破棄
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/session-revoked
セッションが破棄された場合。
セッションが破棄された理由は reason_admin, reason_user で記載するとよい。

event_timestamp を含む場合は、セッション破棄が行われた時間を記載する。
トークンクレームの変更
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/token-claims-change
トークン内のクレームが変更された場合。
変更されたクレームと新しい値は claims に記載 (必須)。
クレーム変更が発生した理由は reason_admin, reason_user で記載するとよい。

event_timestamp を含む場合は、トークンのクレームが変更された時間を記載する。
{
    "iss": "https://idp.example.com/987654321/",
    "jti": "9afce1e4e642b165fcaacdd0e7aa4903",
    "iat": 1615305159,
    "aud": "https://sp.example2.net/caep",
    "txn": "8675309",
    "sub_id": {
        "format": "jwt_id",
        "iss": "https://idp.example.com/987654321/",
        "jti": "f61t6e20zdo3px56gepu8rzlsp4c1dpc0fx7"
    },
    "events": {
        "https://schemas.openid.net/secevent/caep/event-type/token-claims-change": {
            "event_timestamp": 1615304991,
            "claims": {
                "role": "ro-admin"
            }
        }
    }
}
クレデンシャルの変更
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/credential-change
ユーザの資格情報（パスワード、多要素認証設定など）の作成・変更・削除などが行われた場合。

変更されたクレデンシャルは credential_type に記載 (必須)。

※ Transmitter と Receiver で共通となる。
変更方式 (create, revoke, update, delete) は change_type に記載 (必須)。
クレデンシャルの通称は friendly_name に記載 (任意)。
X.509 証明書の発行者は x509_issuer に記載 (任意)。
X.509 証明書のシリアルナンバーは x509_serial に記載 (任意)。
FIDO2 Authenticator Attestation GUID は fido2_aaguid に記載 (任意)。
クレデンシャル変更が発生した理由は reason_admin, reason_user で記載するとよい。

event_timestamp を含む場合は、資格情報が変更された時間を記載する。
Assurance レベルの変更
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/assurance-level-change
ユーザの認証方法が変更された (多要素認証が有効化された、等) 場合。(強固になった場合も、脆弱になった場合も)

変更管理用 namespace を namespace に記載 (必須)。
RFC8176, RFC6711, ISO-IEC-29115, NIST-IAL, NIST-AAL, NIST-FAL 等を記載。

※ Transmitter と Receiver で共通となる。

現在のレベルを current_level に記載 (必須)。
変更前のレベルを previous_level に記載 (任意)。
変更が強固になった (increase) か脆弱になった (decrease) かを change_direction に記載 (任意)。
Assurance レベルの変更が発生した理由は reason_admin, reason_user で記載するとよい。

event_timestamp を含む場合は、Assurance レベルが変更された時間を記載する。
{
    "iss": "https://idp.example.com/3456789/",
    "jti": "07efd930f0977e4fcc1149a733ce7f78",
    "iat": 1615305159,
    "aud": "https://sp.example2.net/caep",
    "txn": "8675309",
    "sub_id": {
        "format": "iss_sub",
        "iss": "https://idp.example.com/3456789/",
        "sub": "jane.smith@example.com"
    },
    "events": {
        "https://schemas.openid.net/secevent/caep/event-type/assurance-level-change": {
            "namespace": "NIST-AAL",
            "current_level": "nist-aal2",
            "previous_level": "nist-aal1",
            "change_direction": "increase",
            "initiating_entity": "user",
            "event_timestamp": 1615304991
        }
    }
}
デバイスコンプライアンスの変更
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/device-compliance-change
ユーザが使用しているデバイスのコンプライアンス準拠状態が変更された場合。
変更前の準拠状況 (compliant, not-compliant) を previous_status に記載 (必須)。
現在の準拠状況 (compliant, not-compliant) を current_status に記載 (必須)。
デバイスコンプライアンスの変更が発生した理由は reason_admin, reason_user で記載するとよい。

event_timestamp を含む場合は、デバイスのコンプライアンス準拠状態が変更された時間を記載する。
{
    "iss": "https://idp.example.com/123456789/",
    "jti": "24c63fb56e5a2d77a6b512616ca9fa24",
    "iat": 1615305159,
    "aud": "https://sp.example.com/caep",
    "txn": "8675309",
    "sub_id": {
        "format": "complex",
        "device": {
            "format": "iss_sub",
            "iss": "https://idp.example.com/123456789/",
            "sub": "e9297990-14d2-42ec-a4a9-4036db86509a"
        },
        "tenant": {
            "format": "opaque",
            "id": "123456789"
        }
    },
    "events": {
        "https://schemas.openid.net/secevent/caep/event-type/device-compliance-change": {
            "current_status": "not-compliant",
            "previous_status": "compliant",
            "initiating_entity": "policy",
            "reason_admin": {
                "en": "Location Policy Violation: C076E8A3"
            },
            "reason_user": {
                "en": "Device is no longer in a trusted location."
            },
            "event_timestamp": 1615304991
        }
    }
}
セッション発行
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/session-established
Transmitter で新しいセッションが発行された場合。
ユーザエージェント Fingerprint を fp_ua に記載 (任意)。
認証コンテキストクラス参照 (authentication context class reference) を acr に記載 (任意)。

※OpenID Connect ID Token に準拠。
認証方法参照 (authentication methods reference) を amr に記載 (任意)。

※OpenID Connect ID Token に準拠。
外部セッション識別子を ext_id に記載 (任意)。

event_timestamp を含む場合は、セッションが発行された時間を記載する。
{
    "iss": "https://idp.example.com/123456789/",
    "jti": "24c63fb56e5a2d77a6b512616ca9fa24",
    "iat": 1615305159,
    "aud": "https://sp.example.com/caep",
    "txn": "8675309",
    "sub_id": {
      "format": "email",
      "email": "someuser@somedomain.com"
    },
    "events": {
        "https://schemas.openid.net/secevent/caep/event-type/session-established": {
          "fp_ua": "abb0b6e7da81a42233f8f2b1a8ddb1b9a4c81611",
          "acr": "AAL2",
          "amr": ["otp"],
          "event_timestamp": 1615304991
        }
    }
}
セッション提示
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/session-presented
Transmitter でセッションが検証された場合。※再認証無しのセッション確立
ユーザエージェント Fingerprint を fp_ua に記載 (任意)。
外部セッション識別子を ext_id に記載 (任意)。

event_timestamp は、セッションを検証した時間を記載する。
リスクレベルの変更
イベントタイプ URI: https://schemas.openid.net/secevent/caep/event-type/risk-level-change
Transmitter でリスクレベルが更新された場合。

※通常と異なる場所からのアクセス、パスワードの漏洩、承認されていないソフトウェアのインストールなど。
リスクレベルが変更された理由を risk_reason に記載 (推奨)。
リスクレベル変更に含まれるエンティティ (USER, DEVICE, SESSION, TENANT, ORG_UNIT, GROUP等) を principal に記載 (必須)。
現在のリスクレベル (LOW, MEDIUM, HIGH) を current_level に記載 (必須)。
変更前のリスクレベルを previous_level に記載 (任意)。

event_timestamp は、リスクレベルが更新された時間を記載する。
{
    "iss": "https://idp.example.com/123456789/",
    "jti": "24c63fb56e5a2d77a6b512616ca9fa24",
    "iat": 1615305159,
    "aud": "https://sp.example.com/caep",
    "txn": "8675309",
    "sub_id": {
      "format": "iss_sub",
      "iss": "https://idp.example.com/3456789/",
      "sub": "jane.doe@example.com"
    },
    "events":{
      "https://schemas.openid.net/secevent/caep/event-type/risk-level-change":{
         "current_level": "LOW",
         "previous_level": "HIGH",
         "event_timestamp": 1615304991,
         "principal": "USER",
         "risk_reason": "PASSWORD_FOUND_IN_DATA_BREACH"
      }
   }
}

 OpenID RISC Profile Specification 1.0
 イベントタイプ基本形
{
  "iss": "https://idp.example.com/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1508184845,
  "aud": "636C69656E745F6964",
  "sub_id": {
    "format": "iss_sub",
    "iss": "https://idp.example.com/",
    "sub": "7375626A656374"
  },
  "events": {
    "https://schemas.openid.net/secevent/risc/event-type/account-credential-change-required": {}
  }
}
アカウントの資格情報の変更
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/account-credential-change-required
ユーザのパスワードがリセットされたり、秘密鍵が変更されたりした場合。
アカウントのパージ
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/account-purged
ユーザのアカウントが削除された場合。
アカウントの無効化
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/account-disabled
アカウントが一時的に無効化された場合。
なぜ無効化されたかについては reason クレームに記載 (任意)。
{
  "iss": "https://idp.example.com/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1508184845,
  "aud": "636C69656E745F6964",
  "sub_id": {
    "format": "iss_sub",
    "iss": "https://idp.example.com/",
    "sub": "7375626A656374",
  },
  "events": {
    "https://schemas.openid.net/secevent/risc/event-type/account-disabled": {
      "reason": "hijacking"
    }
  }
}
アカウントの有効化
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/account-enabled
無効化されたアカウントが再度有効化された場合。

reason クレームは記載しない。
識別子の変更
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/identifier-changed
ユーザの識別子が変更され、その古い識別子が別のアカウントに再利用された場合。
識別子は email または phone である。
古い識別子を必ず記載する。
新しい識別子は new-value クレームに記載 (任意)。

識別子の発行元からイベントを発行することを推奨。

例) メールアドレスの変更。example.com からイベントを発行する。
{
  "iss": "https://idp.example.com/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1508184845,
  "aud": "636C69656E745F6964",
  "sub_id": {
    "format": "email",
    "email": "john.doe@example.com"
  },
  "events": {
    "https://schemas.openid.net/secevent/risc/event-type/identifier-changed": {
      "new-value": "john.roe@example.com"
    }
  }
}
識別子の再利用
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/identifier-recycled
識別子が別のユーザに移った場合。
識別子は email または phone である。
{
  "iss": "https://idp.example.com/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1508184845,
  "aud": "636C69656E745F6964",
  "sub_id": {
    "format": "email",
    "email": "foo@example.com"
  },
  "events": {
    "https://schemas.openid.net/secevent/risc/event-type/identifier-recycled": {}
  }
}
資格情報の漏洩
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/credential-compromise
ユーザの資格情報が外部に漏洩した可能性がある場合。

漏洩した資格情報の種類は credential_type クレームに記載 (必須)。
Transmitter が発見した時間は event_timestamp クレームに記載 (任意)。
漏洩した原因は reason_admin (管理者視点)、reason_user (エンドユーザ視点) クレームに記載 (任意)。
{
  "iss": "https://idp.example.com/3456790/",
  "jti": "756E69717565206964656E746966696572",
  "iat": 1508184845,
  "aud": "https://sp.example2.net/caep",
  "sub_id": {
    "format": "iss_sub",
    "iss": "https://idp.example.com/3456790/",
    "sub": "joe.smith@example.com"
  },
  "events": {
    "https://schemas.openid.net/secevent/risc/event-type/credential-compromise": {
      "credential_type": "password"
    }
  }
}

 opt-in/opt-out+--------+  opt-out-initiated  +-------------------+
|        +--------------------->                   |
| opt-in |                     | opt-out-initiated |
|        |  opt-out-cancelled  |                   |
|        <---------------------+                   |
+---^----+                     +----------+--------+
    |                                     |
    | opt-in                              | opt-out-effective
    |                                     |
    |                          +----------V--------+
    |                          |                   |
    +--------------------------| opt-out           |
                               |                   |
                               +-------------------+
Opt In
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/opt-in
RISC イベントが有効化された場合。
Opt Out Initiated
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/opt-out-initiated
一次的に RISC イベントが無効化された場合。※opt-in から直接 opt-out としない。
Opt Out Cancelled
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/opt-out-cancelled
RISC イベントの一次的な無効化が解除された場合。
Opt Out Effective
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/opt-out-effective
RISC イベントが無効化された場合。
Recovery Activated
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/recovery-activated
リカバリが完了した場合。※パスワードのリセットやロックの解除が相当。
Recovery Information Changed
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/recovery-information-changed
リカバリ情報 (リカバリメールアドレス等) が更新された場合。
Sessions Revoked
イベントタイプ URI: https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
セッションを破棄する場合。

非推奨であり、利用しない。 ※CAEP の対応範囲であるため。

 Google 互換性Google 既存の RISC 実装は format の代わりに subject_type を利用している。

subject_type は非推奨とする。

 最近の動きは？
 2025/9/5 最終仕様承認https://openid.net/three-shared-signals-final-specifications-approved/

 2025/10/13-15 Authenticate 2025 にてテストイベント開催https://authenticatecon.com/event/authenticate-2025/
OpenID Foundationのオープンソーステストの最終段階として行われる。

※参加者募集中の模様。

脚注
https://openid.net/wg/sharedsignals/ ↩︎
https://www.openid.or.jp/blog/2025/06/authzenshared-signals-caep-3.html ↩︎
https://qiita.com/caunu-s/items/e5d29088bd391c47824f ↩︎
https://qiita.com/caunu-s/items/a11f081811918d176515 ↩︎
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-continuous-access-evaluation ↩︎
https://learn.microsoft.com/ja-jp/entra/identity-platform/app-resilience-continuous-access-evaluation?tabs=JavaScript#implementation-considerations ↩︎
https://help.okta.com/oie/ja-jp/content/topics/itp/configure-shared-signal-provider.htm ↩︎
https://developer.okta.com/docs/api/openapi/okta-management/management/tag/SSFSecurityEventToken/#tag/SSFSecurityEventToken ↩︎
セキュリティプロバイダー	アプリ
AppOmni	全製品
Cloudflare	Cloudflare One Enterprise
CrowdStrike Falcon	Okta Verify
Jamf	Jamf Security Cloud（Jamf Radar）
Netskope	Netskope Cloud Exchange
Omnissa（Workspace ONE）	Omnissa Access、Omnissa Intelligence、Workspace ONE
Palo Alto Networks	Cortex XDR + Cloud Identity Engine
Rubrik	Rubrik Security Cloud（RSC）
SGNL	全製品
SquareX	SquareX Enterprise
Widefield Security	全製品
Windowsセキュリティセンター	Okta Verify
Zimperium	Mobile Threat Defense（旧称「zIPS」）
Zscaler	Advanced Deception
この記事を書いたきっかけ

Shared Signals Framework (SSF) とは何か？

どんなユースケースが考えられる？

AuthZEN (認可) との違いは？

どれくらい広がっているのか？

Entra ID での実装例

Okta での実装例

仕様を覗いてみる

OpenID Shared Signals Framework Specification 1.0

OpenID Continuous Access Evaluation Profile 1.0

任意のイベントクレーム

イベントタイプ

OpenID RISC Profile Specification 1.0

イベントタイプ

opt-in/opt-out

Google 互換性

最近の動きは？

2025/9/5 最終仕様承認

2025/10/13-15 Authenticate 2025 にてテストイベント開催

Discussion
