SSFの現在地 ― CAEP／RISCからAI Identityへ

Q&A・ご質問 OpenID Shared Signals Working Group ― 最新動向報告 SSFの現在地 ―
CAEP／RISCからAIdentityへ継続的なシグナル共有で、人・ワークロード・AIエージェントのアクセスを守る Tom Sato | MyAuberge K.K. / SOOS Project OpenID TechNight vol.24 ～ SSF × AIdentity 参考：イベントページ｜ OpenID SSWG ｜参考文献一覧（巻末）

SPEAKER 自己紹介 Q&A・ご質問 Tom Sato ｜ MyAuberge K.K. CEO ／
SOOS（Sovereign Object OS）作者経歴 ▪ Microsoft Japan にて Windows／SDK のプロダクトマネージャー ▪ VeriClouds（資格情報サイバーセキュリティ）COO ▪ AIDynamics（AutoML）ボードメンバー ▪ ロンドン・シリコンバレー・東京でのスタートアップ経験現在の活動 ▪ SOOS：エージェンティックAIのガバナンスに関するIETF Internet-Draft群の単独著者 ▪ OpenID SSWG定例会合に参加。WISE関連でJeff Lombardo氏（AWS）と共同検討 ▪ Activity Travel Protocol（ATP）創設者、ATPファウンデーション創設チェア連絡先：[email protected] ｜ linkedin.com/in/tomsato OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： LinkedIn ｜ SOOS Project 2

AGENDA 本日のアジェンダ Q&A・ご質問 1 なぜ今、SSFなのか — 継続的シグナルへ 5 WISE —
ワークロードIDへの拡張、シナリオと PHP 脆弱性の事例 2 SSFの基礎と、CAEP／RISCで何が伝わるか 6 AIエージェントへの広がり ― MLE とユースケース 3 CAEP／RISC のユースケース 4 CAEP Interoperability Profile — 進行中の論点 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考：参考文献一覧（巻末）｜ OpenID Shared Signals WG 3

なぜ今、SSFなのか「ログイン時の確認」から「継続的シグナル」へ Q&A・ご質問従来これから ▪ ログイン時にだけ、本人・端末・リスクを確認する ▪ IdP・端末管理・EDR・各SaaSが、状態変化をその場で標準形式で伝え合う
▪ その後の変化（退職、端末紛失、資格情報の漏えい等）はセッションに反映されない ▪ 各サービスが個別のポーリングや独自連携で対応し、ベンダーごとに実装がばらばら ▪ 受け取った側が、セッション終了や再認証など、自分のポリシーで即時に対応 ▪ 人だけでなく、サービス（ワークロード）やAIエージェントのIDにも同じ仕組みを拡張 → 多主体間で状態変化を常時伝達する共通の仕組みが必要。これがSSFの設計思想と一致する。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Shared Signals 概要（OIDF）｜ FIDO × SSF 白書｜ SSF 1.0 4

基礎確認 SSFアーキテクチャ（要点のみ） Q&A・ご質問 Stream（Push RFC8935 ／ Poll RFC8936） Transmitter Receiver
（イベント発行側）（イベント受信側）中身：SET ― Security Event Token（RFC 8417）主要プリミティブ ▪ SET（Security Event Token）— RFC 8417 に準拠した署名付きJWT ▪ Subject Identifier（RFC 9493）— イベントの対象を一意に特定 ▪ Stream管理API — Transmitter/Receiver間で、伝達するイベント種別を合意・管理 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSF 1.0 ｜ RFC 8417 SET ｜ RFC 8935 Push ｜ RFC 8936 Poll ｜ RFC 9493 5

SSFの仕組み（1/4）― 最初の接続最初の接続 ― Issuer URL から Stream 作成まで Q&A・ご質問
Receiver が知っているのは、Transmitter の Issuer URL ひとつだけ。そこから設定を取得し、Stream を作り、疎通を確認して運用に入る。接続の流れ（Receiver 側から見た手順） Discovery の応答（抜粋） ① Discovery：Issuer URL に /.well-known/ssf-configuration を付けて GET。 Transmitter の設定（endpoint・鍵・対応方式）を取得 GET https://tr.example.com/.well-known/ssf-configuration ▪ ② 認可：authorization_schemes に従い、管理 API 用の資格情報を取得（例：OAuth 2.0 の access token） ▪ ③ Stream 作成：設定の configuration_endpoint へ POST。受けたい events_requested と配信方式 delivery を指定 → 201 Created ▪ ④ 疎通確認：verification_endpoint へ POST。Verification Event が届けば、署名検証を含む end-to-end の配信が成立 ▪ ⑤ 運用開始：対象 Subject を追加（add_subject）し、イベントの受信・処理へ "spec_version": "1_0", "issuer": "https://tr.example.com", "jwks_uri": "https://tr.example.com/jwks.json", "delivery_methods_supported": [ "urn:ietf:rfc:8935", // Push "urn:ietf:rfc:8936"], // Poll "configuration_endpoint": ".../ssf/mgmt/stream", "status_endpoint": ".../ssf/mgmt/status", "add_subject_endpoint": ".../subject:add", "remove_subject_endpoint": ".../subject:remove", "verification_endpoint": ".../ssf/mgmt/verification", "authorization_schemes": [ {"spec_urn": "urn:ietf:rfc:6749"}], "default_subjects": "NONE" ▪ { } ※ Management API の実装は Transmitter にとって任意だが、Status と Verification は推奨。Issuer にパスがある場合（マルチテナント）は host と path の間に挿入する（/.well-known/ssfknown/ssf-configuration/issuer1）。旧 RISC は /risc-configuration も可。出典：SSF 1.0（Transmitter Configuration Discovery、Management API）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSF 1.0 ｜ RFC 8935 Push ｜ RFC 8936 Poll 6

SSFの仕組み（2/4）― イベントの届け方 Push と Poll ― 同じ SET を、どちら向きに運ぶか Q&A・ご質問
配信方式は Stream 作成時に delivery.method で選ぶ（省略時は Poll）。SET の中身は同じで、HTTP の向きが違う。 Push（RFC 8935）― Transmitter が送る Poll（RFC 8936）― Receiver が取りに行く ▪ method：urn:ietf:rfc:8935。endpoint_url は Receiver が指定（自分の受信 URL） ▪ method：urn:ietf:rfc:8936。endpoint_url は Transmitter が払い出す（Stream ごとに一意） ▪ 送信：Transmitter が HTTP POST（Content-Type: application/secevent+jwt）。 1 リクエスト 1 SET ▪ 取得：Receiver が POST。maxEvents、returnImmediately（false でロングポーリング）、ack（受領済み jti）を送る ▪ 応答：成功は 202 Accepted。失敗は 400 と err（invalid_key、invalid_issuer 、invalid_audience など） ▪ 応答：sets（jti → SET の対応表）と moreAvailable。ack するまで Transmitter は SET を保持 ▪ 認可：authorization_header を登録すると、Transmitter が毎回それを付けて送る ▪ 認可：Stream 管理 API と同じ authorization_schemes を、Poll の endpoint にも適用（SHOULD） ▪ 向く場面：低遅延で届けたい。注意点：Receiver が外部から到達可能な受信口を持つ必要がある ▪ 向く場面：Receiver 側に受信口を開けられない（社内網・FW 内）。注意点：ポーリング間隔が遅延になる ※ どちらの方式でも、Receiver は SET の署名・iss・aud を検証してから処理する（次々ページ参照）。Receiver は、処理できないイベントを err で Transmitter に通知できる。出典：SSF 1.0 ：SSF 1.0（Event Delivery）、RFC 8935、RFC 8936。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSF 1.0 ｜ RFC 8935 Push ｜ RFC 8936 Poll ｜ RFC 8417 SET 7

SSFの仕組み（3/4）― Stream の管理 Stream 管理 ― 設定・状態・対象・疎通 Q&A・ご質問 Stream は、Transmitter
と Receiver が共同で持つ「配信の契約」。Receiver は管理 API で、受けるイベントを選び、止め、対象を絞り、疎通を確かめる。管理 API（Receiver → Transmitter） Stream Configuration の主な項目 ▪ Configuration：POST 作成（201）／GET 取得／PATCH 部分更新／PUT 置換／DELETE 削除（204） ▪ stream_id・iss・aud：Transmitter が決める。aud は後から更新できない ▪ Status：GET／POST で状態を読む・変える。enabled（送信）／paused（保留）／disabled（停止・保留なし） ▪ events_supported：Transmitter が出せるイベント ▪ events_requested：Receiver が受けたいイベント（理解し、処理できるものだけを要求する） ▪ events_delivered：実際に届くイベント。supported と requested の重なりで、Receiver はこれに従って受信を設計する ▪ delivery：method と endpoint_url（Push／Poll） ▪ inactivity_timeout：Receiver の活動がない Stream を、 Transmitter が pause／disable／削除できる期限 ▪ Subject：add_subject／remove_subject。どの主体のイベントを受けるかを選ぶ（default_subjects が ALL か NONE かで初期値が変わる） ▪ Verification：POST（state を指定）→ Transmitter が Verification Event を送る。低頻度の Stream で、停止と無事の区別をつける ▪ Stream Updated：Transmitter 側の都合で pause／disable するときは、止める前に stream-updated イベントで通知する ※ 同じ Stream で複数の Subject を扱える。Stream 管理 API には標準的な HTTP 認証・認可を使い、Receiver を stream_id と aud に結び付ける。出典：SSF 1.0（Management API for SET Event for SET Event Streams）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSF 1.0 ｜ RFC 8935 Push ｜ RFC 8936 Poll 8

SSFの仕組み（4/4）― Issuer（iss） iss ― 「誰が発行したか」を 3 か所で突き合わせる Q&A・ご質問 SSF の信頼は
Issuer（iss）から始まる。同じ値が 3 か所に現れ、Receiver はそのすべてが、設定を取得した Issuer と一致することを確認する。 iss が現れる 3 か所 ▪ ① Transmitter Configuration の issuer：Discovery の取得元 URL そのもの。 https で、query・fragment は付けない ▪ ② Stream Configuration の iss：Stream の作成・取得・更新の応答ごとに確認する（MUST） ▪ ③ SET の iss クレーム：受け取るイベントごとに確認する（MUST） ▪ 不一致なら：その情報を使わず、処理を中止する。別の発行者のなりすましや設定の取り違えを防ぐ ▪ 追加の検証：typ が secevent+jwt ／署名は jwks_uri の鍵／ aud が自分／ exp と sub は付けない（主体は sub_id） SET の例（Verification Event） // typ ヘッダ：secevent+jwt { "jti": "123456", "iss": "https://tr.example.com", // ①②③と一致 "aud": "receiver.example.com", "iat": 1493856000, "sub_id": { "format": "opaque", "id": "f67e39a0a4d34d56b3aa1bc4cff0069f" }, // = stream_id "events": { "https://schemas.openid.net/secevent/ssf/ event-type/verification": { "state": "VGhpcyBpcyBhbi..." } } } ※ txn は、同じ原因から出た複数の SET を関連付ける（SHOULD）。出典：SSF 1.0（Security Event Token Profile、Transmitter Configuration Validation）、RFC 8417。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSF 1.0 ｜ RFC 8417 SET ｜ RFC 8725 JWT BCP 9

現状仕様ファミリーの現状 Q&A・ご質問 SSF 1.0 Shared Signals Framework本体（Transmitter/Receiverモデル、Stream管理）確定済 CAEP
1.0 セッション・デバイス・資格情報の変化を伝達（Continuous Access Evaluation）確定済 RISC 1.0 アカウントリスクの変化を伝達（Risk Incident Sharing）確定済実装実績： Okta ・ CrowdStrike（SOAR）・ Apple Business（Receiver）等で運用中／ Google は RISC 送信 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSF 1.0 ｜ CAEP 1.0 ｜ RISC 1.0 ｜相互運用テスト結果 10

SSFで運ぶ2種類のシグナル CAEPとRISC ― 何を伝える仕組みか Q&A・ご質問どちらも同じSSF（SET・Stream）で運ぶ。違いは「何の変化を知らせるか」。状態変化を検知した側が、関係するサービスへ即座に通知できる。 CAEP ― ログイン後の状態変化
▪ ログイン後の「セッション・資格情報・デバイス」の変化を通知 ▪ 問い：「いま、この主体に引き続きアクセスを許してよいか」 ▪ RPはトークン期限や次回ログインを待たず、その場でセッション終了・再認証要求ができる ▪ 例：セッション失効、資格情報の変更、端末のコンプライアンス変化 RISC ― アカウント自体のリスク・状態 ▪ アカウント自体の「リスク・ライフサイクル」の変化を通知 ▪ 問い：「このアカウントを、引き続き信頼してよいか」 ▪ RPはアカウント停止・パスワード変更要求・本人再確認などを実施できる。例：無効化、削除、資格情報の侵害 ※ CAEPとRISCはSSF 1.0とあわせて確定済み（10ページ参照）。送信側をTransmitter、受信側をReceiverと呼ぶ。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： CAEP 1.0 ｜ RISC 1.0 ｜ SSF 1.0 11

イベントの種類（1/2）― CAEP CAEP のイベント ― ログイン後の状態変化を 8 種で運ぶ Q&A・ご質問 CAEP
は、セッション・資格情報・端末・リスクの変化を伝える。どのイベントにも、任意で event_timestamp、initiating_entity、 reason_admin／reason_user を付けられる。セッションと資格情報 ▪ session-revoked：セッションの失効。固有の項目なし。subject でセッション ID などを指定（例：退職、強制ログアウト） ▪ ▪ ▪ 認証強度・端末・リスク・トークン ▪ session-established：新しいセッションの確立。fp_ua・acr・amr・ext_id（任意）。意図しないログインの検知、セッションの棚卸しに使う assurance-level-change：認証の保証レベルの上下。namespace（NISTAAL、RFC8176 など）と current_level が必須。previous_level・ change_direction は任意 ▪ session-presented：既存セッションの観測。fp_ua・ext_id（任意）。異常なアクティビティの検知に使う device-compliance-change：端末のコンプライアンス状態。 previous_status／current_status（compliant／not-compliant）が必須 ▪ credential-change：資格情報の作成・変更・失効・削除。credential_type（ password、fido2-platform、fido2-roaming、x509、phone-sms、app など）と change_type（create／revoke／update／delete）が必須 risk-level-change：リスクレベルの変化。principal（USER、DEVICE、 SESSION、TENANT など）と current_level（LOW／MEDIUM／HIGH）が必須。risk_reason は推奨 ▪ token-claims-change：トークン中のクレーム値の変化（ID トークン、SAML アサーション）。claims（新しい値）が必須 ※ イベント種別の URI は https://schemas.openid.net/secevent/caep/event-type/ の下に名前を付けたもの。Interop Profile では risk-level-change を必須から外す方向で議論中（27ページ以降参 27ページ以降参照）。出典：CAEP 1.0（Event Types）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： CAEP 1.0 ｜ SSF 1.0 ｜ CAEP Interop Profile 12

イベントの種類（2/2）― RISC RISC のイベント ― アカウント自体の状態とリスクを運ぶ Q&A・ご質問 RISC は、アカウント自体に起きた出来事（無効化・削除・侵害・識別子の変更・回復）を伝える。多くは固有の項目を持たず、 subject
とイベント名で意味が決まる。アカウントの状態と資格情報識別子・回復・オプトアウト ▪ account-disabled／account-enabled：アカウントの無効化と、その解除。 disabled には reason（hijacking／bulk-account）を任意で付けられる ▪ ▪ account-purged：アカウントの完全な削除。固有の項目なし identifier-changed：メールアドレスや電話番号の変更。subject に旧値、new-value に新値（任意）。その識別子の権限を持つ提供者が送る（SHOULD） ▪ account-credential-change-required：資格情報の変更が要求された（例：強制パスワード変更） ▪ identifier-recycled：識別子が別の利用者に再割り当てされた（ email／phone） ▪ credential-compromise：資格情報の侵害。credential_type が必須（CAEP の credential-change と同じ値）。reason_admin／reason_user は任意 ▪ recovery-activated／recovery-information-changed：回復フローの開始／回復用情報（回復メールなど）の変更 ▪ opt-in・opt-out-initiated・opt-out-cancelled・opt-out-effective： RISC への参加状態。opt-out は段階式にし、乗っ取り犯が即座に脱退できないようにしている ※ URI は https://schemas.openid.net/secevent/risc/event-type/ の下。旧 sessions-revoked は非推奨で、CAEP の session-revoked を使う。Google の RISC 実装が使う subject_type（format の旧名） subject_type（format の旧名）も新規実装では使わない。出典：RISC 1.0（Event Types）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： RISC 1.0 ｜ CAEP 1.0 ｜ SSF 1.0 13

全体像 CAEP／RISC シグナルは、こう流れる ― 検知から各サービスへ Q&A・ご質問 OpenID Shared Signals Framework
- SOOS Project / Tom Sato 参考： SSF 1.0 ｜ CAEP 1.0 ｜ RISC 1.0 14

ユースケース（1/3）退職・異動を、全サービスのセッションへ即時に反映する Q&A・ご質問退職者のアカウントを無効化しても、各SaaS側のログイン中セッションやトークンは、期限まで残りうる。シナリオ該当イベント（CAEP／RISC） ▪ 人事システムで退職・異動を登録し、IdPがアカウントを無効化 ▪ account-disabled
― 退職によるアカウント無効化（RISC） ▪ IdPは連携中のすべてのサービス（RP）へ、イベントを送信 ▪ ▪ 各サービスは、その利用者のセッションを即座に終了 session-revoked ― 進行中のセッションの失効、異動時の再認証要求（CAEP） ▪ 異動の場合は、セッションを失効させ、新しい権限で再認証を要求 ▪ account-enabled ― 休職からの復帰など、無効化の解除（ RISC） ※ 「次のログイン」や「トークンの有効期限」を待たずに効かせられる点が価値。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： CAEP 1.0 ｜ RISC 1.0 15

ユースケース（2/3）端末の紛失・状態悪化を、アクセス制御に反映する Q&A・ご質問端末管理（MDM）やEDRが異常を検知しても、その情報がアクセス制御に届かないことが多い。シナリオ該当イベント（CAEP／RISC） ▪ MDM／EDRが、端末の紛失や脅威の検知（コンプライアンス不適合）を把握 ▪
device-compliance-change ― 端末のコンプライアンス状態の変化（CAEP） ▪ SSFで、状態変化をIdPへ送信（IdPはReceiverとして受信） ▪ ▪ IdPは必要に応じて、利用中のサービスへセッション失効などを転送 session-revoked ― 当該端末からのセッションを失効（ CAEP） ▪ 端末が復旧・適合に戻れば、再びアクセスを許可 ▪ assurance-level-change ― 認証強度の引き下げ・再認証の要求（CAEP） ※ 送信できるイベントはIdPによって異なる（例：Oktaは Session Revoked／Credential Change の2種）。実例は22〜25ページ参照。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： CAEP 1.0 ｜ Jamf ｜ Okta Transmitter 16

ユースケース（3/3）資格情報の漏えいを、アカウント保護に直結させる Q&A・ご質問漏えいしたパスワード等が見つかっても、各サービスへ素早く伝える標準的な手段がない。シナリオ該当イベント（CAEP／RISC） ▪ 漏えい検知サービス等が、利用者の資格情報の流出を発見 ▪ credential-compromise
― 資格情報の侵害の通知（RISC） ▪ SSFで、IdPや各サービスへ「資格情報の侵害」を通知（RISC） ▪ ▪ 受信側は、パスワード変更の要求やアカウントの一時停止を実施 account-credential-change-required ― 資格情報の変更要求（RISC） ▪ 対応完了後、アカウントを再度有効化 ▪ account-disabled ／ account-enabled ― 一時停止とその解除（RISC） ※ RISCは、アカウント単位の「リスク」と「ライフサイクル」を扱う点がCAEPとの違い。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： RISC 1.0 ｜ CAEP 1.0 17

NIST SP 800-63C-4 との対応 NISTが「送るべき」とする信号は、SSFで運べる Q&A・ご質問 NIST SP 800-63C-4 は
Sec. 4.8 で、IdP と RP の間の「共有シグナリング」を定める。SSF・CAEP・RISC の名前は出ないが、挙げられた信号の多くは標準イベントで表せる。 IdP → RP （SHOULD） RP → IdP （SHOULD） ▪ アカウントの停止・無効化 → RISC：account-disabled ／ account-purged ▪ ▪ アカウントの侵害の疑い → RISC：credential-compromise ／ accountcredential-change-required アカウントの停止・無効化、侵害の疑い → RISC：accountdisabled ／ credential-compromise ▪ バインドされた認証器の追加・削除 → CAEP：credentialchange ▪ IdP は侵害の疑いを確認したら、その期間に使われた他の RP にも通知する（SHALL）。複数の Receiver への配信で実現できる ▪ 識別子など属性の変更 → RISC：identifier-changed ▪ 認証器の更新、IAL／AAL／FAL の範囲の変更 → CAEP：credential-change ／ assurance-level-change ※ 出典：NIST SP 800-63C-4 Sec. 4.8（Shared Signaling）。イベントへの対応は筆者の整理で、NIST の文書に SSF の記載はない。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： NIST 800-63C-4 Sec. 4.8 ｜ RISC 1.0 ｜ CAEP 1.0 18

プライバシー NISTのプライバシー要求に、SSFはどう応えるか Q&A・ご質問 Sec. 4.8 は、共有シグナリングを許される機能に限り、合意書（トラストアグリーメント）への記載とプライバシー審査を SHALL とする。SSF は部品を持つが、合意書の中身は仕様の外にある。 NISTの要求（SHALL）
▪ 信号を送るイベント、含める情報（個人情報を含む）、受信側の処理を合意書に明記し、プライバシー審査を受ける ▪ 個人情報は、アカウントを特定するのに必要な範囲だけ（アカウント ID など） ▪ IdP から RP への信号は、事前に結んだ合意書が前提 ▪ RP は、信号から利用者がリンクした IdP が分からないようにする SSFの答えと、残る課題 ▪ 答え：Stream の設定でイベントを限定し、不透明な識別子（iss_sub）を使う。相関できる識別子は避け、共有してよい情報か確認してから送る（SSF 9.2、10.1） ▪ 答え：Receiver の登録と認可が前提（例：Okta の ssf.manage ／ ssf.read）。存在確認への応答で、購読の有無を漏らさない（SSF 9.1） ▪ 課題：合意書の中身、reason の自由記述、メールアドレスや端末の指紋、リンク先 IdP の秘匿は仕様の外。運用で決める ※ 出典：NIST SP 800-63C-4 Sec. 3.10.1、Sec. 4.8、OpenID SSF 1.0 Sec. 9〜10、CAEP 1.0。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： NIST Sec. 3.10.1 ｜ NIST Sec. 4.8 ｜ SSF 1.0 ｜ CAEP 1.0 19

金融分野（展望）銀行・オープンバンキングでの使いどころ Q&A・ご質問本番導入の公表例はまだない。ただし英国のオープンバンキングは SET を使っており、OpenID Foundation は SSF 型の
API を金融分野に推奨している。すでにある土台考えられるユースケース ▪ 英国 Open Banking の Event Notification API は SET（RFC 8417）で、同意の取り消しなどを銀行から TPP へ Push／Poll で通知 ▪ 同意の取り消しを TPP へ ― 英国の Event Notification を、 SSF の Stream と subject 管理に載せ替える ▪ 銀行が独自のイベント種別を定義でき、実装は任意。SSF・CAEP・RISC は参照していない ▪ 乗っ取りの信号を金融機関の間で共有 ― RISC の credential-compromise ／ account-disabled ▪ OIDF は2025年10月、米財務省への意見書で、乗っ取りや個人情報漏えいの信号交換に SSF 型の API を推奨 ▪ 銀行アプリのセッション失効 ― CAEP の session-revoked。 FAPI 2.0 が守るアクセスの、その後の変化を伝える ▪ 同意見書は、SSF の採用は「まだ初期」と認めている（導入例は Apple ・Google・Cisco・Okta など） ※ 出典：Open Banking UK Event Notification API v3.1.2、OIDF 米財務省意見書（2025年10月）。ユースケースは筆者の提案で、導入の公表例はない。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Open Banking UK ｜ OIDF 財務省意見書｜ GENIUS Act ｜チリ 20

実装例の前提 Apple Business とは ― 組織向けの端末・アカウント管理 Q&A・ご質問 Apple Business（旧 Apple
Business Manager／Apple School Manager）は、企業や学校などの組織が、Apple端末とアカウントを一括で管理するWebサービス。管理者ができること対象とアカウント ▪ ユーザー・グループ・ロールを管理し、ドメインを検証してIdPと連携（フェデレーション） ▪ 対象は組織。利用者は、組織が作成・管理する「 Managed Apple Account」でサインインする ▪ 端末を登録し、MDM（外部またはApple内蔵）へ割り当てる ▪ ▪ アプリ・書籍のライセンスを取得し、配布する個人（コンシューマー）のApple Accountは対象外 ― 以降のSSF連携も組織のアカウントに限られる ▪ Shared iPad（1台を複数人で共用する運用）を設定する ▪ IdPと連携すると、既存のIDとパスワードで iPhone・iPad ・Mac・Apple Vision Pro・Shared iPad にサインインできる ※ 出典：Apple Business ユーザガイド（support.apple.com）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Apple Business ユーザガイド｜フェデレーション認証 21

実装例（Receiver側） Apple Business × IdP ― 実装例に見るSSF Q&A・ご質問 Apple Businessは、組織のIdPからのSSFイベントを受け取るReceiverとして動作する（個人のApple
Accountは対象外）。Streamの作成はApple側から行う。しくみ実装から見えること ▪ IdPのSSF設定URL（/.well-known/ssf-configuration）をApple Businessに登録 ▪ ▪ Appleがメタデータを読み、IdP上にStreamを作成（Receiver起点） Okta Transmitter は CAEP 2種（Session Revoked／Credential Change）のみ対応。Keycloak（実験的）は devicecompliance-change 等にも対応 ▪ Stream管理APIはOAuthスコープ ssf.manage／ssf.read で保護 ▪ ▪ IdP側のイベント（例：セッション失効、資格情報の変更）をAppleが受信 OktaもKeycloakも「1クライアントにつき1Stream」 ― Stream管理の実運用上の制約 ▪ Apple側が受信後に何をするか（再認証等）は公開情報が限られ、実機での検証が必要 ※ 出典：Apple Business ユーザガイド、Okta ドキュメント、Keycloak公式ブログ（2026年7月）。Google Workspace連携は、現状SSFでなく監査レポートAPIで同様の効果を実現している（ている（Workspaceの SSF 受信はクローズドベータ、24ページ参照）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Apple ｜ Okta × Apple ｜ Okta サポート｜ Apple Business API ｜ Keycloak 22

実装例（Transmitter ／ Receiver） Okta × SSF ― 送信と受信の両面 Q&A・ご質問 Okta
は SSF の Transmitter（CAEP を送信）と Receiver（Identity Threat Protection）の両方を持つ。前ページの Apple Business への送信は、前者の一例。 Transmitter として送る ▪ 送信は CAEP の2種：Session Revoked（user.session.end）と Credential Change（パスワード・MFA 要素の追加・削除・リセット等 8 種のOkta イベント） ▪ SET の subject は iss_sub（Okta のユーザー ID）。公開例に複合 Subject や端末 subject はない。Credential Change には credential_type ／ change_type を付与 ▪ 設定：管理者が OIDC アプリを作り ssf.manage ／ ssf.read を付与。 Receiver が /.well-known/ssf-configuration から Stream を作成 ▪ 運用：管理コンソールで Stream を検証・削除。System Log に作成・削除、Event Hook に配信失敗が残る Receiver として受ける ▪ 対応パートナーは CrowdStrike・Zscaler・Netskope・Jamf 等の十数社と、カスタム Transmitter ▪ 管理コンソールに Well-known URL（または Issuer と JWKS の URL）を登録。受信イベントはリスクエンジンに入り、ポリシーが Workflows・セッション失効・Universal Logout を実行 ▪ 受け付けるイベントの種類は各パートナーの資料に委ねられ、Okta 側に一覧はない。ITP は Adaptive MFA 環境向けの限定サポート ※ 出典：Okta ドキュメント（Configure a shared signal transmitter ／ Configure Okta as an SSF receiver ／ SET payload structures ／ Shared Signals Framework）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Transmitter ｜ Receiver ｜ SET payload ｜ SSF 概要 23

実装例（Transmitter ／ Receiver） Google × SSF ― 2つの入口 Q&A・ご質問 Google
には性格の異なる2つの仕組みがある。稼働中の RISC 送信（Google Sign-In 向け）と、SSF の Receiver として開発中の Workspace（クローズドベータ）。送る側：Cross-Account Protection（RISC）受ける側：Google Workspace（クローズドベータ） ▪ Google アカウントのイベントを、Google Sign-In を使うアプリへ Push で送信（sessions-revoked・tokens-revoked・account-disabled／enabled 等） ▪ 2025年7月に発表、9月にクローズドベータ開始。 Enterprise Plus のみ、申請制で参加は保証されない ▪ subject は iss-sub（Google アカウント ID）。対象は profile／email を許可したユーザーで、Workspace ユーザーは現時点で対象外 ▪ ▪ 受信側の登録は Google 独自の API（stream:update、v1beta）で行う公開されているのは CAEP Session Revoked のみ（subject は email）。IdP・EDR のリスク検知や資格情報変更で、 Workspace のセッションを失効させる想定 ▪ 2025年10月の OpenID 相互運用テストで Transmitter（Push）として合格。Receiver の結果は公表されていない ▪ 追加イベントや一般提供の時期は未公表。公開資料は 2025年時点のため、最新状況の確認が必要 ※ 出典：Google for Developers（Cross-Account Protection ／ Workspace Shared Signals）、Workspace Updates（2025年9月）、OpenID Foundation（2025年10月）。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Workspace ｜ SSF ガイド（β）｜ Cross-Account Protection ｜ Updates 24

実装例（Transmitter 側） CrowdStrike × SSF ― EDRから、ID側へ Q&A・ご質問 CrowdStrike は、端末・脅威の検知結果を
IdP に送る側。2026年は SGNL の買収と OpenID への参加で、継続的アクセス評価に踏み込んだ。今日動いている連携（Okta 向け）これから：SGNL と継続的アクセス評価 ▪ Falcon Fusion SOAR がエンドポイントの脅威を検知すると、ワークフローから Okta へリスクの変化を送信 ▪ 2026年1月に SGNL の買収を発表、2月に完了。CAEP 駆動のアクセス制御を Falcon Fusion SOAR に統合する方針 ▪ Okta はリスクを High／Medium／Low で扱う。High は Universal Logout 、Medium は Workflow で管理者に通知 ▪ IdP の外側（SaaS・クラウド）でも失効でき、対象は人・非人間 ID・AI エージェント。WISE が扱う領域と重なる ▪ 復旧は、CrowdStrike が「低」を再送すると Okta がリスクを下げる（信号で元に戻す） ▪ 6月に OpenID Foundation へ参加し SSF／CAEP／AuthZEN 対応を表明。実装テスト用の caep.dev も運営 ▪ 端末姿勢（Zero Trust Assessment スコア）は SSF ではなく、Okta Verify 経由で連携 ※ 出典：CrowdStrike プレスリリース（2026年1月）、OpenID Foundation（2026年6月）、Okta ドキュメント、Okta–CrowdStrike ソリューションブリーフ。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SGNL 買収｜ OIDF 加盟｜ Okta 連携｜ caep.dev 25

OIDCとの違い OIDCバックチャネルログアウトとの違い Q&A・ご質問バックチャネルログアウトは「ログアウト」をRPに伝える仕組み。SSFはこれを一般化し、内容と相手を広げる。バックチャネルログアウト SSF（CAEP／RISC） ▪ IdPからRPへ、Logout Token（JWT）でセッション終了を通知 ▪
▪ 対象は「OIDCのRP」と「ログアウト」に限られるセッション以外も扱う：資格情報・端末・アカウントの状態変化など多数のイベント種別 ▪ 通知先・通知内容の管理は、クライアント登録の設定に依存 ▪ 送信側・受信側はOIDCのOP／RPに限らない（EDR、MDM 、人事システム等も参加できる） ▪ 例：IdPでログアウトした利用者を、各RPでもログアウトさせる ▪ Stream管理APIで、伝えるイベントや配信方式（Push／Poll ）を合意・管理 ※ 置き換えではなく拡張の関係。OIDCのセッション管理と併用する構成も考えられる。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Back-Channel Logout 1.0 ｜ SSF 1.0 26

CAEP INTEROPERABILITY PROFILE （1/2）議論中署名アルゴリズムをめぐる論点 Q&A・ご質問現行仕様検討中の方向性 ▪
PS256 ／ ES256 ／ EdDSA も許容する方向へすべてのイベントは RS256（2048bit以上）のみで署名を必須とする ▪ 本質的な課題は「アルゴリズム交換」— 現状Receiverに指定手段がなく事実上RS256必須（Kawasaki氏＝Authlete指摘） ▪ 代替案：デプロイ単位の合意＋RFC 8725準拠に委ねる案も浮上（最も収束しやすい論点）。PQC対応も将来論点として接続 FAPI系エコシステムはRS256を回避する傾向。ただし弱点は暗号化用途に限定され、署名用途では実際の脆弱性はないとの指摘（ Joseph Heenan氏） ▪ 提案（PR #355）：Transmitter側で公開＋Stream側で Receiverが希望を指定 ― 双方向ネゴシエーション方式 → 実装側では、RS256固定を前提としない抽象化層を設けておくことを推奨 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Issue #350 ｜ PR #355 ｜ RFC 8725 ｜ Interop Profile 27

CAEP INTEROPERABILITY PROFILE （2/2）議論中 Complex Subjects — 対象特定の精度 Q&A・ご質問
方向性：email + iss + sub 水準のComplex Subject指定を、Transmitter/Receiver双方に必須化する方向で収束中なぜ重要か ▪ 例：「セッション失効」イベントを、ユーザーの全セッションではなく「この1つ」に限定して伝達したいという要求 ▪ たとえば「社内PCのセッション一件」と「モバイルアプリのセッション一件」を区別して失効できるか、という問題 ▪ 複数のチャネル（Web・モバイル・店頭端末など）を持つサービスにとって、この精度は設計上の核心課題になり得る → Subject/Session識別子の設計は、この方向性を見据えて今から精密化しておくべき OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Issue #351 ｜ Interop Profile ｜ RFC 9493 28

CAEP INTEROPERABILITY PROFILE 適合性テストとInterop Profileの計画 Q&A・ご質問仕様（Interop Profile）とテスト（Certification Tests）は分離 ―
仕様は許容範囲を広く取り、テストは合意が取れた範囲から段階的に拡張する設計（テスト追加のたびに仕様を改版せずに済む）現在の適合性テスト範囲今後のテスト拡張計画 ▪ 対象イベント：session-revoked／risk-level-change／devicecompliance-change／credential-change の4種 ▪ risk-level-change：必須イベントから除外する方向 → テスト対象も縮小 ▪ 署名アルゴリズム：RS256のみを検証対象とする ▪ 署名アルゴリズム：PS256／ES256／EdDSA対応の追加を検討（主要実装者への意向確認が前提） ▪ Verification応答：実務上ほぼ全実装が1分以内に応答（現行のデファクト基準） ▪ Complex Subjects：email+iss+sub水準の指定をテスト要件に追加する方向 ▪ Verification SLA：固定値でなく、メタデータ宣言ベースの検証に移行する可能性現状：レビュー期間の再開は決定済みだが、仕様本文・テスト計画とも9/20時点で未更新 ― 実装者は現行のテスト範囲を出発点に、上記の拡張方向を見据えて設計を OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSF 適合性テスト｜ Interop Profile ｜相互運用テスト結果 29

Keycloak 標準のSSF対応（実験的機能） Keycloak標準のSSF対応 ― 活用できる点と、残る論点 Q&A・ご質問 Keycloak本体にSSF Transmitterが実験的機能として追加された（2026年7月・nightly版）。OSSのIdPが標準でSSFを話せるようになる動きとして注目される。活用できる点
残る論点・留意点 ▪ CAEP 3種（session-revoked等）とRISC（account-disabled等）に標準対応 ▪ ▪ SOC等の外部ツールからイベントを投入できるREST／独自イベント用 SPIを提供 ― インシデント通知に活用可署名はレルム共通のOIDC鍵（専用SSF鍵は計画中）／ Receiverの認証はOIDCクライアント＋アクセストークン方式 ▪ 配信はPush／Poll（RFC 8935／8936）、ストリーム管理APIとRP別のイベント絞り込みを標準装備 ▪ Receiver役とWISE（ワークロード層）のイベントは未対応 ― 別途実装が必要 ▪ risk-level-change は未対応 ― Interop Profileで必須から外す方向の議論と整合 ▪ 実験的機能（nightly版・既定でOFF）、security review未了 ― 本番採用は成熟度の確認が前提 ※ 出典：Keycloak公式ブログ「Experimental SSF support」（2026年7月）。署名アルゴリズムは記事に明記なし。最新の状況はKeycloakのドキュメント・リリースで確認のこと。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Keycloak ブログ 30

セキュリティ上の留意点 SSFの前提条件 — 資格情報レイヤーの健全性 Q&A・ご質問継続的評価モデル（CAEP等）は、その土台となる資格情報発行レイヤーが健全であることを前提とする。偽造された保有者資格情報は、それ自体が異常に見えなければ継続的リスク評価では検知できない。参考事例：CVE-2026-0257（2026年、実悪用） ▪ Palo
Alto GlobalProtect 認証バイパス（CWE-565） ▪ 根本原因：認証Cookieを「復号成功」のみで信頼 — 発行者と紐づける鍵付き整合性検証（HMAC）がない ▪ 助長要因：公開TLSサービスとCookie暗号化が同一証明書を共用 — 通常のTLS通信で鍵材料を取得され偽造が可能に ▪ 対策：鍵付きHMAC検証の追加＋証明書の用途分離実装者への示唆 ▪ デバイス証明書・セッションCookie・モバイルアプリ認証トークンなど、SSF基盤に資格情報を供給する全コンポーネントを点検 ▪ ① 復号とは独立した鍵付き整合性検証を持つか ▪ ② 証明書の用途分離（公開TLS鍵を別機能に流用していないか） ※ CVE-2026-0257はPalo Alto Networksが公表し、実悪用も報告されている事例。ここでは「資格情報レイヤーの脆弱性クラス」の一例として紹介する。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： Palo Alto アドバイザリ 31

拡張プロファイル SSWG採択済 WISE — ワークロードIDへの拡張 Q&A・ご質問 OpenID Shared Signals Framework
- SOOS Project / Tom Sato 参考： WISE Profile ｜ SSWG 32

WISE EVENT CATALOG （1/2） · DRAFT 04 資格情報／ワークロードのライフサイクルイベント Q&A・ご質問資格情報ライフサイクル（4種類）
ワークロードライフサイクル（4種類） ▪ credential-issued ― 新規発行 ▪ ▪ credential-rotated ― ローテーション・更新。status は succeeded／ failed（失敗時は failure_reason で理由を示す） workload-disabled ― 一時停止（新規発行停止＋既存資格情報の失効） ▪ workload-enabled ― 稼働中（新規起動・再開のいずれも） ▪ credential-revoked ― 有効期限前の失効（compromise／ key_compromise／superseded／cessation／policy_violation） ▪ workload-trust-level-change ― 信頼レベルの変更（full／reduced／ restricted／minimal、上げ下げ両方向） ▪ credential-compromised ― 侵害の「疑い」を知らせる advisory 信号（ revoked に先行・併発しうる） ▪ workload-purged ― 完全削除・不可逆ポイント：revoked は確定的な取り消しアクション、compromised は侵害の「疑い」を知らせる advisory 信号 ― 前者の引き金になり得るが、常に伴うとは限らない OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE draft 04 33

WISE EVENT CATALOG （2/2） · DRAFT 04 信頼・ポリシー・姿勢・実行時・サプライチェーン Q&A・ご質問信頼・ポリシー（7）
姿勢・実行時（4） ▪ trust-anchor-added／rotated／revoked ― 信頼アンカー（CA証明書・JWKS）の追加／更新／失効 ▪ posture-evaluated ― 姿勢評価の結果（succeeded／failed、不合格時は理由付き） ▪ trust-domain-federation-established／updated／revoked ― トラストドメイン間フェデレーションの確立／更新／解消 ▪ workload-execution-environment-changed ― 移行・スケーリング・再デプロイ・ノード変更 ▪ policy-changed ― ポリシー変更（policy_type：issuance／posture_evaluation／ validation） ▪ workload-compromised ― 実行時検知による侵害の確信（高深刻度） ▪ anomalous-behavior-detected ― 異常行動の観測（advisory） draft 04 で統合されたイベントサプライチェーン（2） ▪ renewal-failure → credential-rotated（failed） ▪ workload-provenance-changed ― SBOM／ビルド来歴の変化 ▪ degraded／restored → workload-trust-level-change ▪ workload-vulnerability-status-changed ― 脆弱性状況の変化（VEXモデル） ▪ ポリシー3種 → policy-changed ▪ posture failed／succeeded → posture-evaluated ▪ baseline-changed → execution-environment-changed workload-compromised はワークロード自体の侵害（実行時検知）― 1つの資格情報に関する credential-compromised とは区別される OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE draft 04 34

WISE 活用シナリオ（1/4）段階的対応 ― 全停止せずに済む設計 Q&A・ご質問 RPのバックエンドに異常な挙動が見られた場合、今は「遮断」か「静観」の二択になりがちである。WISEはその中間を扱える。シナリオ ▪ あるRPのバックエンドで不審なアクセスパターンを検知
▪ 直ちに全停止するのではなく、信頼レベルを段階的に引き下げ ▪ ▪ 該当WISEイベント ▪ workload-trust-level-change ― 信頼レベルの段階的引き下げ（reduced／restricted／minimal）例：検証のみ許可し新規発行は停止する「制限モード」に移行 ▪ workload-trust-level-change（full） ― 完全復帰調査完了後、正常な信頼レベルに復帰 ▪ サービスを止めずに調査できる設計 ※ 「遮断か静観か」の二択を避けられることは、止められないサービスにとって特に価値が高い。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE Profile 35

WISE 活用シナリオ（2/4）資格情報侵害の「事前」検知 ― CVE-2026-0257型への備え Q&A・ご質問本資料31ページで取り上げた資格情報レイヤーの脆弱性クラスは、WISEのイベントで侵害前に検知できた可能性がある。シナリオ該当WISEイベント ▪
RPのバックエンドが既知脆弱性を含むライブラリを使用 ▪ ▪ 定期的な姿勢評価（posture evaluation）で設定不備を検出 workload-vulnerability-status-changed ― VEXモデルで affected／fixed等を通知 ▪ 例：認証Cookieを復号成功のみで信頼する設計（CWE-565相当） ▪ posture-evaluated（failed） ― 設定不備など姿勢評価の不合格を通知 ▪ 実際の侵害が起きる前に、対象ワークロードを制限または隔離 ▪ workload-compromised ― 実行時検知による侵害確信時の高優先度シグナル ※ 31ページのCVE事例は「侵害後にどう検知するか」。本スライドは、同じ脆弱性クラスを侵害前に検知する仕組みを示す。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE Profile ｜ Palo Alto アドバイザリ 36

WISE 活用シナリオ（3/4）署名アルゴリズムの追加を自動通知 ― 手動調整からの脱却 Q&A・ご質問 27ページで取り上げた署名アルゴリズムの論点は、WISEの仕組みで実装レベルの解決に近づく。シナリオ該当WISEイベント ▪
OPがRS256に加えてES256等の新しいアルゴリズムに対応 ▪ trust-anchor-added ― 新しい信頼アンカーの追加を通知 ▪ 従来は個別調整やメール連携でRP側に周知 ▪ ▪ WISEでは新しい信頼アンカー追加イベントとして自動配信 key_details（kty／alg／crv）― 対応アルゴリズムの詳細を併せて通知 ▪ RP側システムは受信したイベントを基に対応状況を更新 ▪ CAEP本体の議論（27ページ）より一歩先を行く、WISEで既に実装済みの仕組み ※ 個別調整なしでアルゴリズム移行を進められる ― 実装者にとって再利用可能な基盤の価値を示す例。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE Profile ｜ Issue #350 ｜ RFC 8725 37

WISE 活用シナリオ（4/4）証明書失効による障害を、起きる前に検知する Q&A・ご質問証明書の自動更新が静かに失敗し、実際に失効してから初めて障害に気づく、というのはよくある運用上の課題である。シナリオ該当WISEイベント ▪ RPバックエンドの証明書自動更新処理が失敗 ▪
▪ 従来は証明書が実際に失効し検証エラーが発生して初めて判明 credential-rotated（failed） ― 自動更新プロセスの失敗を通知 ▪ WISEでは更新失敗の時点で即座にシグナルを送信 ▪ 障害発生前の「予兆」として機能する ▪ 実際の障害が発生する前に、運用チームが対応可能 ▪ 深夜の障害対応（いわゆる3時のアラート）を減らす、運用上の地味だが実務的な価値 ※ 派手さはないが、現場のエンジニアが最も価値を感じやすい実務的ユースケース。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE Profile 38

WISE 事例 · ホスティング連鎖（1/3）ホストの PHP 脆弱性が、取引先まで連鎖する Q&A・ご質問ホスティング事業者は、数千の顧客のために PHP
などのツールを運用している。その1つに CVE が出たら、警告・修正・安全宣言は、顧客のさらに先の取引先にも届く必要がある。 Stream 1 Stream 2 ホスティング事業者サーバーアプリ（テナント）取引先のサーバーアプリ多数のテナントの PHP 等を運用。どのテナントがどのバージョンかを把握している。ホストから受信。自社サービスについて、自社の取引先へ通知する。サーバーアプリを呼び出す取引先。ホストとの Stream は持たない。各ホップは自分のことだけを語る証拠は手元に、結論だけが伝わるサーバーアプリはホストのイベントを転送しない。自社サービスについての自社のイベントを、自社の鍵で署名して送る。 CVE ID とアドバイザリのリンクが、2つのホップをつなぐ。実行環境や来歴の詳細は、ホストからテナントへ流れる。取引先に届くのは結果（affected、次に fixed）だけ。インフラの詳細は、それを必要とする関係の中にとどまる。前提として Stream が必要：テナントはホスティングの管理画面で購読し、サーバーアプリとその取引先は業務契約の中で Stream を合意する。Web サイトの訪問者は Receiver にならない。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE draft 04 ｜ PHP2Shell アドバイザリ（Patchstack） 39

WISE 事例 · ホスティング連鎖（2/3）警告・修正・安全宣言 ― ステップごとの流れ Q&A・ご質問 H ＝
ホスティング事業者、A ＝サーバーアプリ（テナント）、C ＝取引先のサーバーアプリステップ 1 CVE 公開 H が影響バージョンを使うテナントを確認 2 A が取引先へ警告 A 自身のサービスについて 3 H がパッチ適用・再デプロイ A が PHP を自前で同梱する場合は A が信 4 安全宣言、またはエスカレーションパッチ前に悪用されたか？イベント受信側の対応 H → A： workload-vulnerability-status-changed（affected、critical、ジョンが不明な間は under_investigation を使う。 A は脆弱な機能を使っているか確認し、緩和策（WAF ルール機能の無効化）を入れ、取引先へ通知するか判断する。 A → C： workload-vulnerability-status-changed、必要に応じて workload-trust-level-change（restricted）。not_affected ならここで終了。 C は影響を抑えるが、A を遮断はしない：トークン有効期間の短縮、機微データの制限、監視の強化。 H → A： workload-execution-environment-changed（redeployment、イメージスト）→ workload-provenance-changed（updated、新しい SBOM）→ workload-vulnerability-status-changed（fixed） A は SBOM を取得し、ダイジェストが稼働中のものと一致すか確認し、自社のテストを実行する。いいえ：A → C： workload-vulnerability-status-changed（fixed）＋ workload-trust-level-change（full、remediated）はい： workload-compromised ＋ credential-revoked、続いていいえ：C は制限を解除し、記録を残す。はい：C は A に発行したセッションとトークンを失効させ、共有シークレットをローテーションする。太字：WISE draft 04 で定義されたイベント。同じ Transmitter 内では1つのインシデントのイベントが txn を共有し、ホップをまたぐと CVE ID が結合キーになる。 OpenID Shared Signals Framework -SOOS Project / Tom Sato 参考： WISE draft 04 40

WISE 事例 · ホスティング連鎖（3/3）ホスティング連鎖から見えた draft 04 の課題 Q&A・ご質問 1つの
CVE を3つの組織に通してみると、draft 04 に3つのギャップが見つかり、提出済みの2つの Issue の裏付けにもなる。 draft 04 のギャップ ▪ 「上流からの中継」を示すリンクがない：A のイベントから H のイベントを参照できない。原因の参照があれば、連鎖を監査できる ▪ workload-trust-level-change には脆弱性を理由とする値がない。 posture_degraded が最も近いだけ ▪ ホスティングのファンアウト：テナントごと（uri）か、成果物ごと（ ni:// ダイジェスト）か？テナントが行動できるのは前者のみ 10月27日提出の Issue との関係と、問いかけ ▪ VEX の justification：なぜ not_affected なのか ▪ 悪用状況：PHP2Shell のような「現在悪用中」 ▪ 論点：ホストとテナントが同じトラストドメインにいるとき、テナントのワークロードの Transmitter は誰か？この事例は終始 advisory：WISE は各当事者に何が変わったかを伝え、何を制限するかは各 Receiver が自分のポリシーで決める。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE draft 04 ｜ PHP2Shell アドバイザリ（Patchstack） 41

エージェンティックAIへの橋渡し Q&A・ご質問同じレールの上で、語彙を拡張する CAEP WISE Mandate Lifecycle Events 人間セッションイベントワークロード／エージェントIDイ
ベントエージェント権限（Mandate）イイベント新しいシステムではなく、同じ「継続的シグナル基盤」の語彙拡張である参考：IETF Practical Cyber Security会合（Vienna, 2026）でも「不正エージェントのアクセス失効」が論点として提起済み（OPSEC WG再開の動き） OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE ｜ MLE ｜ CAEP 1.0 ｜ IETF 126 42

MANDATE のギャップエージェントは同じ。ただ、もう許されていない Q&A・ご質問 AI エージェントが調達責任者に代わり、5万ドルまでの仕入先契約を交渉している。四半期の途中で予算が削減され、責任者はその権限を取り下げた。何が起きるかエージェントだと何が悪化するか ▪
エージェントの資格情報・鍵・ワークロード ID は変わらない ▪ ▪ WISE・CAEP・RISC の Stream には何も流れない：ID のイベントは起きていない委任：サブエージェントが子 Mandate を持ち、子孫すべてを止める必要がある ▪ 不可逆性：次の一手が署名や支払いかもしれない ▪ タスクからの独立：目的は変わらず、許可だけが消えている ▪ 仕入先の契約システムには、また1件カウンターオファーが届く ▪ そのオファーを裏付ける人がもういない、という信号はどこにもないこれまで認証と認可は一緒に変わった。エージェントでは違う：権限は資格情報より速く変わる。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE ｜ WISE 43

用語案 Mission は「何を」、Mandate は「してよいか」 Q&A・ご質問ワークロード ID Mission／意図 Mandate
資格情報エージェントが誰か（WISE）何をしようとしているか何をしてよいか（MLE）呼び出しごとに提示する証明作業定義プリンシパルからワークロードへの、範囲と期限を限った権限の委任。Mission とも、その下で発行される資格情報とも別のもの。 → 1つの Mandate から多くの資格情報（opaque、JWT、トランザクション単位のアクセストークン）を発行できる。Mandate を失効させると次の発行が止まるが、発行済みのものは回収されない。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE ｜ Transaction Tokens 44

MLE EVENT CATALOG Mandate のライフサイクル全体を 11 のイベントで扱う Q&A・ご質問ライフサイクル（CRUD）異常・保留・クロージャー
▪ mandate-requested ― ワークロードがプリンシパルに Mandate を要求 ▪ ▪ mandate-granted／mandate-denied ― ルートまたは子 Mandate の付与／拒否の決定 mandate-violation-detected ― 範囲外の行動、または親を超える権限を主張する子（advisory） ▪ mandate-executed ― 資格情報の発行（opaque／jwt／ txn_access_token／txn_token）。SET はその資格情報の txn を運ぶ mandate-suspended*／mandate-resumed* ― 失効させずに審査のため一時停止、その後解除 ▪ mandate-rotated ― 後継への置き換え（change_class：renewal／ narrowed／expanded）* mandate-revocation-enforced† ― 各 Receiver が、失効した Mandate を受け付けなくなったことを確認（Receiver → 発行者） ▪ mandate-revoked ― 期限前の取り下げ（revocation_type：direct／ cascade） mandate-revocation-closure† ― 発行者が closed／partial／failed／ unknown を報告 ▪ * 2026年10月14日追加 † 2026年10月30日追加（draft-watts の revocation closure を受けて） ▪ ▪ ▪ ワークロードは WISE の wimse:// URI を再利用。人間のプリンシパルは pairwise で不透明な識別子とし、必要な Receiver にだけ渡す。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE（soosproject/MLE）｜ Txn-AT ｜ Revocation closure 45

MLE 活用シナリオ · 権限の付与（1/2） AI エージェントへの支出上限を、記録に残して与える Q&A・ご質問調達責任者が、今四半期は5万ドルまでの仕入先契約を AI エージェントに交渉させる。後日、誰がいつ何を許可したかを問われる
ことになる。 MLE がない場合 ▪ 権限は設定ファイルやチャットのメッセージの中にある ▪ 後から、誰が上限を承認したか説明できない ▪ 仕入先は、エージェントの権限を確認する手段がない MLE がある場合 ▪ エージェントの権限要求が記録される → mandate-requested ▪ 承認が、上限・承認者・有効期限とともに記録される → mandate-granted ▪ 仕入先は、エージェントの背後にある権限を確認できる → scope_ref 太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 46

MLE 活用シナリオ · 権限の付与（2/2）拒否も、記録に残す Q&A・ご質問エージェントが、金額無制限の契約締結権限を求める。社内ポリシーではエージェントの上限は5万ドル。さらにサブエージェントが、親より大きな権限を自分に与えようとする。 MLE がない場合
▪ 拒否は1つのシステムの中で黙って行われる ▪ エージェントは別の場所で再挑戦するかもしれない ▪ セキュリティ部門は、権限逸脱のパターンに気づけない MLE がある場合 ▪ 拒否が理由とともに記録される → mandate-denied（ policy_denied） ▪ 親が持つ以上を求めたサブエージェントは拒否される → mandate-denied（insufficient_authority） ▪ 繰り返される拒否が、セキュリティ部門のレビュー対象として見える太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 47

MLE 活用シナリオ · 権限の行使（1/2）すべての行動を、その根拠となる権限までたどれる Q&A・ご質問出張手配の AI エージェントが、社員の航空券とホテルを予約する。予約ごとに、その1件の取引だけで使える短命のパスを使う。 MLE
がない場合 ▪ 航空会社には有効なパスが見えるが、誰の権限に基づくかは見えない ▪ 問題のある予約を担当者までたどるのに何週間もかかる MLE がある場合 ▪ 各予約が、それを行った根拠の権限に結び付く → mandate-executed ▪ パスの種類と取引 ID が示される → txn_access_token、txn ▪ 監査で、1つの承認の下で行われた行動をすべて列挙できる太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE ｜ Txn-AT 48

MLE 活用シナリオ · 権限の行使（2/2）すでに進行中の行動を止める Q&A・ご質問決済エージェントの権限が取り下げられたとき、複数の支払いが処理中だった。手元のパスは、技術的にはあと数分有効なまま。 MLE がない場合 ▪
処理中の支払いはそのまま通ってしまう ▪ 止めると決めた後に、お金が動く MLE がある場合 ▪ 取引先は、どのパスがこの権限から発行されたかを事前に把握している → mandate-executed（txn） ▪ 権限が取り下げられると、それらのパスを即座に拒否する → mandate-revoked ▪ 取り下げられた権限の下では、新しいパスは発行されない（Txn-AT のエラー transaction_denied）太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE ｜ Txn-AT 49

MLE 活用シナリオ · 権限の変更（1/2）予算削減を、やり直しなしで反映する Q&A・ご質問四半期の途中で調達予算が削減された。エージェントは交渉を続けてよいが、上限は5万ドルから2万ドルになる。 MLE がない場合 ▪
エージェントを完全に止めるか、古い上限が残り続けるか ▪ 仕入先は、5万ドルまでのオファーを受け付け続ける MLE がある場合 ▪ 上限を下げた後継の権限が通知される → mandate-rotated （narrowed） ▪ 仕入先は、2万ドルを超えるものを直ちに受け付けなくなる ▪ エージェントは、新しい上限の範囲で仕事を続ける太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 50

MLE 活用シナリオ · 権限の変更（2/2）通常の更新は静かに、権限の拡大には証明を Q&A・ご質問四半期末に、エージェントの権限が変更なしで更新される。次の四半期には、大型案件のため上限が10万ドルに引き上げられる。 MLE がない場合 ▪
更新のたびに、取引先へ通知が殺到する ▪ 「権限が増えた」という偽の通知が信じられてしまうおそれ MLE がある場合 ▪ 変更のない更新は社内にとどめる → mandate-rotated（ renewal） ▪ 権限の拡大も、社内にだけ通知する → mandate-rotated（ expanded） ▪ 取引先は、発行元で確認してから、引き上げた上限を受け入れる → scope_digest、scope_ref 太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 51

MLE 活用シナリオ · 権限の取り下げ（1/2）署名される前に、取引を止める Q&A・ご質問調達責任者がエージェントの権限を取り下げた。仕入先の契約システムは、エージェントの最新オファーに今まさに副署しようとしている。 MLE がない場合
▪ エージェントのログインは有効なままなので、オファーは正当に見える ▪ 仕入先は、誰も裏付けていない契約に副署してしまう MLE がある場合 ▪ 仕入先に、権限が取り下げられたことが通知される → mandate-revoked（principal_revoked） ▪ 仕入先は副署する前に、エージェントからのオファーの受付を止める ▪ エージェントのログインはそのまま。終わるのはこの権限だけ太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 52

MLE 活用シナリオ · 権限の取り下げ（2/2）エージェントのチーム全体を、一度に止める Q&A・ご質問交渉エージェントは、タスクの一部を調査エージェントと価格エージェントに任せていた。元の権限が終われば、3つとも止まらなければならない。 MLE がない場合
▪ 止まるのは最上位のエージェントだけ ▪ 補助エージェントは、もう存在しない権限で動き続ける MLE がある場合 ▪ 親の権限とともに、補助エージェントすべての権限が取り下げられる → mandate-revoked（cascade） ▪ 各通知には、取り下げられた元の権限が示される → cascade_root_mandate_id ▪ 取引先には、無関係なイベントの羅列ではなく1つの決定として見える → txn 太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 53

MLE 活用シナリオ · 権限の一時停止（1/2）まず止めて、判断は後で Q&A・ご質問セキュリティベンダーから、エージェントの資格情報が漏えいデータに含まれていたと報告があった。まだ確認できないが、待つこともできない。 MLE がない場合
MLE がある場合 ▪ 噂の段階で失効させるか、そのまま続けて様子を見るかの二択 ▪ ▪ もっともらしい報告を出せば、誰でもエージェントを止められてしまう判断が出るまで、権限を即座に一時停止する → mandate-suspended（reported_compromise） ▪ 仕入先は進行中の取引を、取り消さずに保留する ▪ 続いて判断：停止を解除、または完全に取り下げ → mandate-resumed／mandate-revoked 太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 54

MLE 活用シナリオ · 権限の一時停止（2/2）審査の間は保留にする Q&A・ご質問経理部門が、エージェントによる一連の購入に疑問を持ち、審査を求めた。審査が終わるまで、権限は終了させずに凍結すべきである。 MLE がない場合
▪ 選択肢は、失効させて後で付与し直すことだけ ▪ エージェントを止められる人は、再開もできてしまう MLE がある場合 ▪ 経理の審査中、権限は保留される → mandate-suspended （pending_review） ▪ 審査が通れば、元のとおりに復元される → mandate-resumed ▪ 保留を解除できる人を、保留をかけられる人より厳しく絞れる → initiating_entity 太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 55

MLE 活用シナリオ · 権限逸脱の検知エージェントが権限を超えようとしたとき Q&A・ご質問上限5万ドルのエージェントが、仕入先に7.5万ドルの契約を提示する。別の場面では、補助エージェントが親の持っていなかった権限を主張する。 MLE がない場合
▪ 仕入先がそのままオファーを受け入れるかもしれない ▪ 監査まで、誰もそのパターンに気づかない MLE がある場合 ▪ その試みが取引先に報告される → mandate-violation-detected（scope_exceeded） ▪ 親を超える権限を主張した補助エージェントを検知 → mandate-violation-detected (narrowing_violation) ▪ どう対応するかは各取引先が決める。イベントは advisory 太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE 56

MLE 活用シナリオ · 停止の証明「エージェントを止めたことを証明してください」 Q&A・ご質問権限の取り下げ後、規制当局や監査人から、すべての取引先が実際に受付を止めたことを示すよう求められる。 MLE がない場合 ▪
「通知は送りました」が精一杯の答え ▪ すべての取引先が対応したかは誰にも分からない MLE がある場合 ▪ 各取引先が、停止したこと、またはできなかったことを確認応答する → mandate-revocation-enforced ▪ 会社は closed／partial／failed を証拠とともに報告する → mandate-revocation-closure ▪ 応答のない取引先は unknown 扱い。closed とはみなさない太字：MLE ドラフト（soosproject/MLE）で定義されたイベント・フィールド。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： MLE ｜ draft-watts 57

レイヤーの分離 Mandate は WISE の資格情報ではない Q&A・ご質問両プロファイルは1つの Transmitter を共有できるが、各事実は必ずどちらか一方で運ぶ。ここを誤ると、1つの Mandate
の終了でエージェントがあらゆる場所から遮断されてしまう。 WISE：ワークロードの ID MLE：1つの Mandate の権限 ▪ credential-revoked ― ワークロード自身の資格情報（WIT／WIC）の失効 ▪ mandate-revoked ― 1つの権限付与の取り下げ ▪ Receiver はそれを拒否し、確立済みの接続も切断すべき（SHOULD） ▪ ▪ ワークロードが持つすべての Mandate に影響するエージェントの認証は有効なまま。他の Mandate は引き続き機能する ▪ SOOS では：カーネル自身の鍵とアテステーション（KIA） ▪ 1つの Mandate を絞っても、ワークロードの信頼は下がらない。SOOS では：Mandate の発行と失効（MJWT）唯一の組み合わせケース：発行者自身の署名鍵が侵害された場合は、WISE の credential-revoked（key_compromise）と、その鍵で署名した各 Mandate の MLE mandate-revoked（compromise compromise）を、共通の txn で送る。 OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： WISE Profile ｜ MLE 58

CLOSING まとめと次のステップ Q&A・ご質問 SSF ／ CAEP ／ RISC 本体確定済
CAEP Interoperability Profile 議論中 WISE（ワークロード／エージェントID）採択済 IITP（インフラ層）提案段階 Mandate Lifecycle Events（提案）提案段階次のステップご意見・ご協力のお願い：日本の実装者の視点（署名アルゴリズム、ユースケース、WISE）をOpenID SSWGへ届けたい。連絡先：[email protected] ｜ linkedin.com/in/tomsato OpenID Shared Signals Framework - SOOS Project / Tom Sato 参考： SSWG ｜ WISE ｜ MLE ｜ IITP ｜メール｜ LinkedIn 59

参考文献参考文献（1/4）― OpenID・IETF の仕様と議論 Q&A・ご質問クリックで開けます。各ページ下部の「参考」と同じリンクです（2026年10月時点で確認）。 OpenID Foundation GitHub・IETF OpenID
Shared Signals Framework 1.0 openid/sharedsignals リポジトリ https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html https://github.com/openid/sharedsignals CAEP 1.0 Issue #350 ― 署名アルゴリズムを RS256 に限るか https://openid.net/specs/openid-caep-1_0-final.html https://github.com/openid/sharedsignals/issues/350 RISC 1.0 Issue #351 ― Complex Subjects https://openid.net/specs/openid-risc-1_0-final.html https://github.com/openid/sharedsignals/issues/351 CAEP Interoperability Profile（作業中ドラフト） PR #355 ― 署名アルゴリズムのネゴシエーション提案 https://openid.github.io/sharedsignals/openid-caep-interoperability-profile-1_0.html https://github.com/openid/sharedsignals/pull/355 Shared Signals Working Group RFC 8417 ― Security Event Token（SET） https://openid.net/wg/sharedsignals/ https://www.rfc-editor.org/rfc/rfc8417 SSF 適合性テスト（OpenID Certification） RFC 8935 ― SET の Push 配信 https://openid.net/certification/ssf_testing/ https://www.rfc-editor.org/rfc/rfc8935 Shared Signals: Enhanced Security for All（2024年4月） RFC 8936 ― SET の Poll 配信 https://openid.net/shared-signals-enhanced-security-for-all/ https://www.rfc-editor.org/rfc/rfc8936 OpenID Connect Back-Channel Logout 1.0 RFC 9493 ― Subject Identifiers for SETs https://openid.net/specs/openid-connect-backchannel-1_0.html https://www.rfc-editor.org/rfc/rfc9493 RFC 8725 ― JWT Best Current Practices https://www.rfc-editor.org/rfc/rfc8725 OpenID Shared Signals Framework - SOOS Project / Tom Sato 60

参考文献参考文献（2/4）― WISE・Mandate・規格と事例 Q&A・ご質問クリックで開けます。各ページ下部の「参考」と同じリンクです（2026年10月時点で確認）。 WISE・Mandate・関連提案規格・ガイドライン・事例 WISE Profile（openid/ssf-wise-profile） N
IS T S P 800- 63C - 4（Fed eration and A ssertio ns） https://github.com/openid/ssf-wise-profile http s://p ag es.nist.g ov/800- 63- 4/sp 800- 63c.htm l WISE Profile 仕様本文（draft 03） N IS T 800- 63C - 4 S ec. 4.8 S hared S ig naling https://github.com/openid/ssf-wise-profile/blob/main/openid-wise-profile-1_0.md http s://p ag es.nist.g ov/800- 63- 4/sp 800- 63c.htm l# shared - sig nals WISE 初期リポジトリ（identitymonk/openid-wise） N IS T 800- 63C - 4 S ec. 3.10.1 Transm itting S ub scriber Info rm ation https://github.com/identitymonk/openid-wise http s://p ag es.nist.g ov/800- 63- 4/sp 800- 63c.htm l# transm it- subscrib er- info Mandate Lifecycle Events（soosproject/MLE） N IS T S P 800- 63 FA Q （Q - C 02） https://github.com/soosproject/MLE http s://p ag es.nist.g ov/800- 63- FA Q / IITP（Internet Infrastructure Threat Profile） FID O A lliance ―FID O and the S hared S ig nals Fram ework https://github.com/derrumbe/openid-iitp http s://fid oalliance.org /wp - content/up load s/2025/10/fid o - and - the- shared - sig nalsfram ework.p d f SOOS Project https://soosproject.ai/ WISE Profile draft 04（events-rework、作業中） https://openid.github.io/ssf-wise-profile/events-rework/ PHP2Shell アドバイザリ（Patchstack） Palo A lto N etwo rks ―C V E- 2026- 0257 アドバイザリ http s://security.p aloaltonetworks.com /C V E- 2026- 0257 IETF 126 V ienna ―Pro ceeding s http s://d atatracker.ietf.org /m eeting /126/p roceed ing s https://patchstack.com/articles/php-major-vulnerability-alert-10-2026/ Transactional Access Tokens（draft-tulshi、-00） https://datatracker.ietf.org/doc/draft-tulshi-oauth-transactional-access-tokens/ Revocation Closure（draft-watts、-01） https://datatracker.ietf.org/doc/draft-watts-oauth-agent-revocation-closure/ OpenID Shared Signals Framework - SOOS Project / Tom Sato 61

参考文献参考文献（3/4）― Apple・Okta・Keycloak Q&A・ご質問クリックで開けます。各ページ下部の「参考」と同じリンクです（2026年10月時点で確認）。 Apple Business Okta・Keycloak Apple Business
ユーザガイド Okta ― Configure a shared signal transmitter https://support.apple.com/guide/business/welcome/web https://help.okta.com/oie/en-us/content/Topics/apps/configure-shared-signal-transmitter.htm A p p le Business ―Id P によるフェデレーション認証 Okta ― Configure a shared signal receiver http s://sup p ort.ap ple.com /g uid e/b usiness/axm fcab 66783/web https://help.okta.com/oie/en-us/content/topics/itp/configure-shared-signal-provider.htm A p p le Business A PI Okta ― Shared Signals Framework http s://d evelop er.ap p le.com /d ocum entation/app leb usinessap i https://help.okta.com/oie/en-us/content/Topics/itp/shared-signals.htm O kta ―A p p le Business との連携設定 Okta Developer ― SSF Transmitter SET payload structures http s://help .okta.com /oie/en - us/content/Top ics/ap ps/config ure - ap p le- b usiness- m anag er.htm https://developer.okta.com/docs/reference/ssf-transmitter-sets/ O kta サポート ―A p p le Business の S S F 設定取得エラー Okta Developer ― Configure an SSF receiver http s://sup p ort.okta.com /help /s/article/ssf- ap ple- b usiness- sso- integ rations- fails- to- retrieve- the- ssfconfig uration?lang uag e= en_U S https://developer.okta.com/docs/guides/configure-ssf-receiver/main/ Okta ― Security events provider reported risk https://help.okta.com/oie/en-us/content/Topics/itp/detections-security-events-provider-reported.htm Keycloak ― Experimental SSF support（2026年7月） https://www.keycloak.org/2026/07/experimental-ssf-support OpenID Shared Signals Framework - SOOS Project / Tom Sato 62

参考文献参考文献（4/4）― Google・CrowdStrike・金融分野 Q&A・ご質問クリックで開けます。各ページ下部の「参考」と同じリンクです（2026年10月時点で確認）。 Google・Jamf・相互運用テスト CrowdStrike・金融分野 Google Workspace Shared
Signals CrowdStrike ― SGNL の買収発表（2026年1月） https://developers.google.com/workspace/shared-signals https://www.crowdstrike.com/en-us/press-releases/crowdstrike-to-acquire-sgnl-to-transform-identity-securityfor-ai-era/ Google Workspace SSF 連携ガイド（クローズドベータ） https://developers.google.com/workspace/shared-signals/api/ssf-api Google Cross-Account Protection（RISC） https://developers.google.com/identity/protocols/risc Google Workspace Updates（2025年9月） https://workspaceupdates.googleblog.com/2025/09/enhancing-security-outcomes-shared-signals-framework-beta.html Google Workspace ブログ（2025年7月） https://workspace.google.com/blog/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-anddbsc Jamf ― SSF and CAEP https://developer.jamf.com/jamf-security/docs/shared-signals-framework-and-continuous-access-evaluation-protocol OpenID ― 相互運用テスト結果（2025年10月） https://openid.net/top-firms-test-interoperability-of-final-ssf-and-caep/ OpenID ― CrowdStrike の加盟（2026年6月） https://openid.net/crowdstrike-joins-the-oidf-as-a-sustaining-corporate-member/ Okta ― CrowdStrike ITP ソリューションブリーフ https://www.okta.com/sites/default/files/2025-10/Okta-CrowdStrike-ITP-Solution-Brief-2025.pdf caep.dev https://caep.dev/ Open Banking UK ― Event Notification API v3.1.2 https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1077806617/Event+Notification+API+Specification++v3.1.2 OIDF ― 米財務省への意見書（2025年10月） https://openid.net/wp-content/uploads/2025/10/Letter-OIDF-_TREAS-DO-2025-0070-0001.pdf OIDF ― GENIUS Act 向けの標準ロードマップ https://openid.net/oidf-offers-standards-roadmap-for-genius-act/ OIDF ― チリオープンファイナンス向けワークショップ https://openid.net/outreach-workshop-open-banking-chile/ OpenID Shared Signals Framework - SOOS Project / Tom Sato 63

SSFの現在地 ― CAEP／RISCからAI Identityへ

SSFの現在地 ― CAEP／RISCからAI Identityへ

More Decks by OpenID Foundation Japan

Other Decks in Technology

Featured

Transcript