Skip to content
  • Workgroup: OpenID Connect
  • Published: 25 September 2025
  • Authors:
    • D. Hardt (Hellō)
    • K. McGuinness (Independent)

OpenID Provider Commands 1.0 - draft 02

Abstract

OpenID Connect は、エンドユーザが OpenID Provider (OP) を用いて Relying Party (RP) にログインし、ID Token を用いてエンドユーザに関する Claims を表明できるようにするプロトコルを定義する。RP は、ユーザに関する identity Claims を用いて、RP におけるユーザの Account を暗黙に（または明示的に）確立することが多い。

OpenID Provider Commands は、OP が RP におけるエンドユーザの Account を直接管理するための一連の Command を導入することで OpenID Connect を補完する。これらの Command により、OP はエンドユーザの Account を有効化、維持、停止、一時停止解除、アーカイブ、復元、削除、監査、無効化でき、さらに既存 Account の認証を移行できる。Command Token は OpenID Connect の ID Token のスキーマと検証を基盤としており、RP による採用を簡素化する。

Table of Contents

1. Introduction

OpenID Connect 1.0 は広く採用されているアイデンティティ・プロトコルであり、relying parties (RP) として知られるクライアントアプリケーションが、信頼できるサービスである OpenID Provider (OP) によって実行された認証に基づいて End-User の身元を検証できるようにする。OpenID Connect はまた、End-User に関する identity attributes、すなわち Claims を安全に取得する仕組みも提供し、これにより RP は体験を調整し、確信を持ってアクセス管理を行える。

OpenID Connect は、End-User が RP にログインしてリソースへのアクセスを認可できるようにするだけでなく、RP における Account を暗黙的または明示的に作成するためにも用いられる場合がある。しかし、Account の作成は Account ライフサイクルの始まりにすぎない。ライフサイクル全体を通じて、データの整合性、セキュリティ、規制遵守を確保するために、さまざまな操作が必要になる場合がある。

例えば、多くの法域では End-User に「right to be forgotten（忘れられる権利）」が認められており、Account と関連データの削除を要求できる。このような要求が発生した場合、OP は RP に対して End-User の Account を完全に削除し、関連するすべてのデータを除去するよう通知する必要があるかもしれない。これは規制上の義務と End-User のプライバシー選好の双方を尊重するためである。

悪意ある活動が検出された、または疑われる状況では、OP は End-User を保護する上で重要な役割を果たす。OP は、RP に対して認可を取り消す、または悪意ある行為者によって作成された Account を削除するよう指示する必要があるかもしれない。これは不正な行為の影響を封じ込め、侵害された Account のさらなる悪用を防ぐ助けとなる。

企業環境では、組織が労働者のアクセスを集中管理するため、OP は RP に存在する既存の従業員 Account を制御できるようにする必要がある。まず、OP は account resolution を通じて、自身の Account 識別子と RP の内部識別子との間に双方向の対応付けを確立し、両者が同一の特定 Account を参照できるようにしなければならない。この識別子解決が完了すると、企業は、従業員が以前に RP 管理の資格情報または他の認証方式で作成していた Account について、認証責任を移行できる。認証の制御と識別子対応付けが確立されれば、OP はライフサイクルの各段階における重要な Account 操作（有効化、維持、停止、一時停止解除、アーカイブ、復元、削除）を扱い、セキュリティと遵守を維持できる。

OpenID Provider Commands は、OP から RP へのリモート手続き呼び出しであり、既存の OP / RP 関係を基盤として Account ライフサイクルを管理することを可能にし、Account 管理要件の全領域をカバーする。

1.1. Requirements Notation and Conventions

この文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、{{RFC2119}} に記述されているとおりに解釈される。

キーワード「PROHIBITED」は「MUST NOT」として解釈される。

この仕様の .txt 版では、値が文字どおりに扱われることを示すために引用符で囲まれている。これらの値をプロトコルメッセージで使用する際、引用符を値の一部として用いてはならない（MUST NOT）。この仕様の HTML 版では、文字どおりに扱うべき値は固定幅フォントの使用によって示される。

1.2. Terminology

本仕様は以下の用語を定義する。

  • Account: RP の identity register における、ユーザに関する Claims。
  • Command: OP から RP への指示。同期的な request と response。
  • Synchronous Command: RP からの response が HTTP 200 Success response により OP に同期的に提供される Command。
  • Asynchronous Command: RP からの response が、最初に HTTP 202 Accepted response として OP に非同期に提供される Command。RP は Asynchronous Command の最終 response を OP の callback_endpoint に送信する。Asynchronous Commands の Command identifier は文字列 _async で終わる。
  • Command Token: OP が署名した JSON Web Token (JWT) であり、発行される Command に関する Claims を含む。
  • Command Endpoint: OP が Command Token を投稿する RP 上の URL。
  • Tenant: OP 内の論理的に分離されたエンティティであり、独立した組織的または管理上の境界を表す。OP は単一の Tenant を持つ場合もあれば、複数の Tenant を持つ場合もある。Tenant には、個人によって管理される Accounts を含めることもでき、組織によって管理される Accounts を含めることもできる。

1.3. Protocol Overview

本仕様は、OP から RP へ送信される Command Token を含む Command Request と、RP から OP へ返される Command Response を定義する。

+------+  Command request       +------+
|      |---- Command Token ---->|      |
|  OP  |                        |  RP  |
|      |<-----------------------|      |
+------+      Command response  +------+

OP は、RP が metadata や audit_tenant command のような command の送信を OP に要求するため、または非同期 command の結果を送信するために、callback endpoint と callback token を提供できる。

+------+             Callback   +------+
|      |<--- Callback Token ----|      |
|  OP  |                        |  RP  |
|      |----------------------->|      |
+------+  204 or error response +------+

1.4. Command Use Cases

OpenID Provider Commands は、複数の明確に異なるユースケースを支援し、それぞれ異なる command のシーケンスと要件を持つ。これらのユースケースを理解することで、実装者はどの commands をサポートすべきか、またそれらをどのように効果的に順序付けるべきかを判断しやすくなる。

1.4.1. Personal Applications

Personal applications は、自身の accounts を管理する個人ユーザに提供される。このシナリオでは、accounts は組織ではなく end-users によって作成・管理される。

  • Supported Commands: Metadata, Invalidate, Delete
  • Typical Command Sequence:
    1. Metadata Command - OP と RP の間で capabilities を確立する
    2. Invalidate Command - Account の侵害が疑われる場合に、すべての sessions と tokens を無効化する
    3. Delete Command - ユーザ要求（例: 「right to be forgotten」）に基づき、account とデータを削除する

1.4.2. Enterprise Application Migration

組織が新しい Identity Provider (IdP) を導入する場合や、合併・買収を行う場合、既存 accounts に対する認証責任を移行する必要がある。これは、個々のユーザが当初 RP 管理の資格情報で accounts を作成し、その後に組織が企業の IdP の下で認証を集中管理する必要が生じるケースで一般的に発生する。

  • Migration from RP-managed to OP-managed Authentication:
    1. Metadata Command - 対象 RP に対する OP capabilities を確立する
    2. Audit Tenant Command - 移行が必要な accounts を特定し、account resolution を確立する
    3. Migrate Command - 既存の RP-managed accounts に対する認証責任を引き受ける
    4. Account Lifecycle Commands - 移行された accounts をライフサイクルを通じて管理する

Account Resolution in Migration\ Account Resolution は、OP と RP がそれぞれの account identifier の間に双方向の対応付けを確立するプロセスである。OP が Audit などの commands に対する response として RP から aud_sub 値を受け取ると、OP はその account に対する RP の内部識別子を学習する。これにより OP は、後続の Command Tokens に aud_sub claim を含められるようになり、RP は OP の iss と sub 値に基づく外部キー関係を維持するのではなく、自身の識別子を用いて commands を実行できる。これは、外部識別子を保存・管理する必要を排除しつつ、システム間で accounts を関連付ける能力を維持することで、RP 実装を簡素化する。

Authentication Migration Process\ Authentication Migration は、Migrate Command を通じて OP が既存 accounts の認証提供者になることを可能にする。このプロセスは、組織移行、買収、または集中型アイデンティティ・ガバナンス方針を実施する際に不可欠である。Account Resolution は、Migrate Command により OP が account の認証提供者になることを促進する。

1.4.3. Enterprise Application Integration

組織の Identity Provider (IdP) と統合された enterprise applications では、従業員の入社、役割変更、退職に伴う継続的な account 管理が必要である。

  • Supported Commands: Metadata, Audit Tenant, Account Lifecycle Commands (Activate, Maintain, Suspend, Reactivate, Archive, Restore, Delete), Invalidate, Migrate
  • Typical Command Sequence:
    1. Metadata Command - capabilities を交換し、関係を確立する
    2. Audit Tenant Command - 既存 accounts を発見し、account resolution を確立する
    3. Account Lifecycle Commands - OP と RP の間で account 状態を同期する
    4. Periodic Audit Commands - 同期を維持し、ずれ（drift）を補正する

1.4.4. Compliance Auditing

Compliance シナリオでは、OP が account 管理責任を引き受けることなく、RP を監査して適切な account 管理と規制遵守を検証する。

  • Audit-Only Sequence:
    1. Metadata Command - 監査 capabilities を確立する
    2. Audit Tenant Command - account 状態と compliance posture を確認する
    3. Periodic Audit Commands - 継続的な compliance 監視

1.4.5. Security Incident Response

セキュリティ・インシデントが発生した場合、OP は潜在的な侵害を封じ込めるために、複数の RP にまたがって迅速にアクセスを取り消す必要があるかもしれない。

  • Incident Response:
    1. Invalidate Command - 侵害された account について、すべての sessions と tokens を直ちに無効化する
    2. Suspend/Archive Commands - 影響を受けた account を一時的または恒久的に無効化する

2. Claims and Properties

このセクションでは、本仕様で使用されるすべての claims と properties を定義する。

2.1. Claims in Command Tokens

  • aud_sub: Account に対する RP の内部識別子（account resolution により学習）。(iss,sub) ペアではなく RP のネイティブ識別子を用いて参照できるようにする。
  • aud: token の Audience。RP の Command Endpoint URL。
  • authentication_provider: どちらの当事者がユーザを認証できるかを示す文字列。値は次のとおり。
    • rp: RP のみがユーザを認証する
    • op: OP のみがユーザを認証する
    • op_migration: RP と OP の双方が認証できる（移行中の一時状態）
    • external: 認証は外部プロバイダによる
    • unknown: 認証提供者が不明、または非開示
  • callback_token: OP が生成する不透明な token。RP が非同期結果を送信する際、または metadata refresh を要求する際に使用する。
  • client_id: RP の client identifier。
  • command: RP が実行すべき command 名。標準値は Account Commands および Tenant Commands で定義される。追加の値は Extensibility により定義される場合がある。
  • exp: 有効期限（RFC 7519 に従う NumericDate）。
  • iat: 発行時刻（RFC 7519 に従う NumericDate）。
  • iss: OP の Issuer Identifier（OpenID Connect Core, Section 2 を参照）。
  • jti: token の一意識別子（OpenID Connect Core Section 9 に従う）。
  • metadata: Metadata Command において RP に伝達される OP 提供の metadata を表す JSON object。規範的スキーマは OP Metadata Object を参照。
  • sub: Account の Subject Identifier（OpenID Connect Core, Section 2 を参照）。
  • tenant: OP 内の Tenant 識別子。personal、organization、または複数 Tenant を持つ OP における OP 固有の安定識別子。iss と tenant の組み合わせにより Tenant が識別される。

2.2. Properties in Responses

  • account_state: 処理後の Account 状態。サポートされる状態は unknown、active、suspended、archived。
  • aud_sub_required: RP が Account Commands に aud_sub を要求するかどうかを示す真偽値。
  • aud_sub: 「Claims in Command Tokens」の定義を参照。
  • authentication_provider: 「Claims in Command Tokens」の定義と許容値を参照。
  • client_id: 「Claims in Command Tokens」の定義を参照。
  • command_endpoint: RP の Command Endpoint URL。
  • commands_supported: RP がサポートする command 名の配列。
  • context: response の文脈値（例: iss、tenant）を含む JSON object。
  • error_description: 人間が読めるエラー説明。
  • error: 発生したエラー種別を示すエラーコード。
  • last_access: 最終 account アクセス時刻の NumericDate（1970-01-01T00:00:00Z UTC からの秒）。
  • roles: role objects の配列。各要素は次を含む。
    • id: RP 固有の role identifier
    • display: 人間が読める role 名
    • description（optional）: role 説明
  • sub: 「Claims in Command Tokens」の定義を参照。
  • total_accounts: streaming response において送信された account-state events の総数。

各 claim/property の要件レベルは、個別の command または response ごとに、対応するセクションを参照すること。

3. Command Request

OP は登録済み Command Endpoint に対して HTTP POST を用い、Account Commands を RP に送信する。POST body は application/x-www-form-urlencoded エンコーディングを使用し、RP 向けの OP 発行 Command Token を含む command_token パラメータを含めなければならない。

POST body には command_token 以外の値を含めてもよい（MAY）。実装が理解できない値は無視しなければならない（MUST）。

以下は、そのような Command request の非規範的な例である（簡潔さのため Command Token の内容の多くは省略している）。

POST /commands HTTP/1.1
Host: rp.example.net
Content-Type: application/x-www-form-urlencoded

command_token=eyJhbGci ... .eyJpc3Mi ... .T3BlbklE ...

4. Command Response

Command が成功した場合、RP は HTTP 200 OK で応答しなければならない（MUST）。ただし、一部の Web フレームワークは HTTP body が空の場合に HTTP 200 OK の代わりに HTTP 204 No Content を返すことがある。したがって、OP は HTTP 204 No Content も成功 response として処理できるよう準備すべきである（SHOULD）。

RP の response には、将来の Command requests に干渉し得るキャッシュ済み response を防ぐため、Cache-Control HTTP response header field に no-store 値を含めなければならない（MUST）。例は次のとおり。

Cache-Control: no-store

response body がある場合、それは JSON でなければならず（MUST）、application/json media type を使用しなければならない（MUST）。

request が妥当でない場合、RP は error パラメータを返さなければならず（MUST）、error_description パラメータを含めてもよい（MAY）。エラー response で伝達される情報は、デプロイのデバッグを助けることを意図しており、実装が異なる error 値を用いて異なる実行時挙動を引き起こすことを意図していない点に注意すること。

4.1. Invalid Request Error

Command request の構文に問題があった、または Command Token が無効であった場合、RP は HTTP 400 Bad Request を返し、error パラメータに invalid_request 値を含めなければならない（MUST）。

4.2. Unrecognized Provider Error

RP が Command token の iss 値で識別される OP を認識しない場合、RP は HTTP 401 Unauthorized response を返し、error パラメータに unrecognized_provider 値を含めなければならない（MUST）。

4.3. Unsupported Command Error

RP が要求された Command をサポートしない場合、RP は HTTP 400 Bad Request を返し、error パラメータに unsupported_command 値を含めなければならない（MUST）。

RP は、ある OP には Commands をサポートするが別の OP にはサポートしない、またある Tenant にはサポートするが別の Tenant にはサポートしない、という場合がある点に注意すること。

4.4. Server Error

RP が妥当な request を処理できない場合、RP は RFC 9110 section 15.6 で定義される 5xx Server Error status code で応答しなければならない（MUST）。

5. Command Token

OP は、JSON Web Token (JWT) である Command Token を RP に送信して Commands を発行する。これは OpenID Connect の ID Token（{{OpenID.Core}} の Section 2 を参照）に類似するが、認証の表明ではなく command の意味論を運ぶ。

Command Token に現れ得るすべての claims は、Claims and Properties セクションで一度だけ定義される。定義の規範はそのセクションである。各 command セクションでは、その command に対してそれらの claims のどれが REQUIRED、OPTIONAL、PROHIBITED であるかを規範的に述べる。したがって本セクションは、後続での簡略表現として用いる基準の claim グルーピングのみを定義する。

  • Prohibition of nonce: Cross-JWT Confusion を防ぐため、Command Token に nonce Claim を含めてはならない（MUST NOT）。See Cross-JWT Confusion.

Baseline claim sets（command が追加を明示的に許可しない限り、列挙した claims のみが現れ得る）

  • Account Command baseline claims:
    • REQUIRED: iss, aud (Command Endpoint), client_id, iat, exp, jti, command, tenant, sub
    • OPTIONAL: aud_sub
    • OPTIONAL: callback_token — identifier が _async で終わる commands に限る
  • Tenant Command baseline claims:
    • REQUIRED: iss, aud (Command Endpoint), client_id, iat, exp, jti, command, tenant
    • PROHIBITED: sub, aud_sub
    • OPTIONAL: callback_token — command が明示的に指定する場合のみ

後で参照される command 固有の追加要素の例（網羅的ではない）:

  • metadata — Metadata Command では REQUIRED、それ以外では PROHIBITED
  • authentication_provider — Migrate Command では REQUIRED、それ以外では PROHIBITED

Command Token は署名されなければならない（MUST）。OP が ID Tokens に使用するものと同じ署名鍵が使用され、通常の OpenID Connect の仕組みにより鍵探索が可能である。

Command Tokens は、typ (type) JWS Header Parameter を含め、その値を正確に command+jwt として明示的に型付けしなければならない（MUST）。See Security Considerations for rationale.

Example JWS header (non-normative):

{
  "alg": "RS256",
  "kid": "2019-07-01-key",
  "typ": "command+jwt"
}

Activate Command のための Command Token の非規範的な例:

{
  "iss": "https://op.example.org",
  "aud": "https://rp.example.net/command",
  "client_id": "s6BhdRkqt3",
  "iat": 1734003000,
  "exp": 1734003060,
  "jti": "bWJq",
  "command": "activate",
  "sub": "248289761001",
  "given_name": "Jane",
  "family_name": "Smith",
  "email": "jane.smith@example.org",
  "email_verified": true,
  "groups": [
    "b0f4861d",
    "88799417"
  ]
}

Invalidate Command のための Command Token の非規範的な例:

{
  "iss": "https://op.example.org",
  "aud": "https://rp.example.net/command",
  "client_id": "s6BhdRkqt3",
  "iat": 1734004000,
  "exp": 1734004060,
  "jti": "bWJr",
  "command": "invalidate",
  "sub": "248289761001"
}

6. Account Commands

Account Commands は Account に対して動作する。いかなる Account Command のサポートも OPTIONAL である。Account Commands は、RP によって account resolution の際に提供された場合は Command Token の aud_sub claim により、提供されない場合は iss と sub claims により、RP の Account を識別して実行される。Account Commands には Lifecycle Commands、Invalidate Command、Migrate Command が含まれる。

各 Account Command について、Command Token は Command Token で定義された Account Command baseline claims を含めなければならない（MUST）。以下の各 command セクションは、command 固有の追加要素または例外のみを列挙する。ある command で REQUIRED または OPTIONAL として列挙された claims のみが存在し得て、それ以外は、特に指定がない限り PROHIBITED である。

6.1. Account Lifecycle States

Lifecycle Commands は、Section 3.4.5 で定義される RP の identity register における Accounts について、ISO 24760-1（2019-05 版）Section 7.2 で定義された各遷移に対して定義される。

Lifecycle Commands は Account を次の状態間で遷移させる。

  • unknown
  • active
  • suspended
  • archived

想定される状態遷移は次のとおり。

                      +--------------------------------------- reactivate ---+
                      |  +--- maintain --+                                   |
                      |  |               |                                   |
+---------+           |  |   +--------+  |                    +-----------+  |
|         |           |  +-> |        | -+                    |           | -+
| unknown |           + ---> | active | -------- suspend ---> | suspended | --------+
|         | --- activate --> |        | ----+                 |           | -+      |
+---------+              +-> |        | -+  |                 +-----------+  |      |
  ^  ^  ^                |   +--------+  |  |                                |      |
  |  |  |                |               |  |            +------ archive† ---+      |
  |  |  |                |               |  |            |                          |
  |  |  |                |               |  |            |     +-----------+        |
  |  |  |                |               |  |            +---> |           | ----+  |
  |  |  |                |               |  +--- archive ----> | archived  | -+  |  |
  |  |  |                |               |                     |           |  |  |  |
  |  |  |                |               |                     +-----------+  |  |  |
  |  |  |                |               |                                    |  |  |
  |  |  |                +---------------|----------------------- restore ----+  |  |
  |  |  |                                |                                       |  |
  |  |  +--------------------- delete ---+                                       |  |
  |  +------------------------ delete -------------------------------------------+  |
  +--------------------------- delete ----------------------------------------------+
†The transition from suspended to archived is an extension to the ISO standard.

6.2. Success Response

RP が Account Command を正常に処理した場合、RP は HTTP 200 OK response を返し、次の properties を含む JSON object を返す。

  • sub — REQUIRED — request で提供された sub
  • account_state — REQUIRED — 処理後の Account の状態
  • aud_sub — OPTIONAL — RP が metadata で aud_sub_required を設定している場合に含める

成功した Activate Command の非規範的な response body は次のとおり。

{
  "account_state": "active",
  "sub": "248289761001"
}

6.3. Incompatible State Response

Account Command に対して identity register 上の Account が非互換の状態にある場合、RP は HTTP 409 Conflict を返し、次を含む JSON object を返す。

  • account_state — REQUIRED — identity register における Account の現在状態
  • error — REQUIRED — 値 incompatible_state に設定
  • sub — REQUIRED — request で提供された sub

Account が suspended 状態であったため Restore Command が失敗した場合の非規範的な response は次のとおり。

{
  "account_state": "suspended",
  "error": "incompatible_state",
  "sub": "248289761001"
}

Activate Command が既に存在する Account に送られた場合、または他の Commands が存在しない Account に送られた場合、Account は incompatible state である点に注意すること。

active 状態の既存 Account に対する Activate Command が失敗した場合の非規範的な response は次のとおり。

{
  "account_state": "active",
  "error": "incompatible_state",
  "sub": "248289761001"
}

存在しない Account に対する Maintain Command が失敗した場合の非規範的な response は次のとおり。

{
  "account_state": "unknown",
  "error": "incompatible_state",
  "sub": "248289761001"
}

6.4. Asynchronous Response

RP が有効な Asynchronous Command を受け取り、その command を実行する上で account が互換状態にある場合、RP は HTTP 202 Accepted response を返す。Asynchronous Command の処理が完了した後、OP が metadata で callback_endpoint を提供し、かつ command に callback_token を含めていた場合、RP は処理結果を callback_endpoint に対して HTTP POST し、callback_token を HTTP Authorize header の Bearer token として含めなければならない（MUST）。

response body は、上記 Success Response で指定された properties を含めなければならない（MUST）。

POST /callback HTTP/1.1
Host: op.example.org
Authorization: Bearer eyjesudyxhjsjshjedshjdsaajhdsa
Content-Type: application/json
Accept: application/json
Cache-Control: no-cache

{
  "account_state": "active",
  "sub": "248289761001"
}

request が無効である、または callback_token が無効である場合、OP は RFC6750 に従ってエラーで応答しなければならない（MUST）。

6.5. Activate Command

Command Token の command Claim における activate または activate_async 値で識別される。

RP は、identity register に含まれる Claims を用いて Account を作成しなければならない（MUST）。Account は unknown 状態でなければならない（MUST）。正常処理後、Account は active 状態となる。

6.6. Maintain Command

Command Token の command Claim における maintain または maintain_async 値で識別される。

RP は、identity register 上の既存 Account を、含まれる Claims で更新しなければならない（MUST）。Account は active 状態でなければならない（MUST）。正常処理後も Account は active 状態のままである。

6.7. Suspend Command

Command Token の command Claim における suspend または suspend_async 値で識別される。

RP は Account に対して Invalidate Functionality を実行し、identity register 上で Account を一時的に利用不可として印を付けなければならない（MUST）。Account は active 状態でなければならない（MUST）。正常処理後、Account は suspended 状態となる。

6.8. Reactivate Command

Command Token の command Claim における reactivate または reactivate_async 値で識別される。

RP は、suspended な Account を identity register 上で active として印を付けなければならない（MUST）。Account は suspended 状態でなければならない（MUST）。正常処理後、Account は active 状態となる。RP は Suspend Command をサポートする場合、Reactivate Command もサポートすべきである（SHOULD）。

6.9. Archive Command

Command Token の command Claim における archive または archive_async 値で識別される。

RP は Account に対して Invalidate Functionality を実行し、identity register から Account を除去しなければならない（MUST）。Account は active または suspended のいずれかの状態でなければならない（MUST）。正常処理後、Account は archived 状態となる。

6.10. Restore Command

Command Token の command Claim における restore または restore_async 値で識別される。

RP は、archived な Account を identity register に復元し、active として印を付けなければならない（MUST）。Account は archived 状態でなければならない（MUST）。正常処理後、Account は active 状態となる。RP は Archive Command をサポートする場合、Restore Command もサポートすべきである（SHOULD）。

6.11. Delete Command

Command Token の command Claim における delete または delete_async 値で識別される。

RP は Account に対して Invalidate Functionality を実行し、Account に関連するすべてのデータを削除しなければならない（MUST）。Account は unknown を除く任意の状態でよい。正常処理後、Account は unknown 状態となる。

6.12. Audit Command

Command Token の command Claim における audit または audit_async 値で識別される。

RP は、Account の状態および、OP から提供され RP が保持している Account に関する任意の Claims を含めなければならない（MUST）。Account が見つからない場合、RP は unknown 状態を返す。

response には次を含めてもよい（MAY）。

  • last_access — OPTIONAL
  • authentication_provider — OPTIONAL

6.13. Invalidate Command

Command Token の command Claim における invalidate または invalidate_async 値で識別される。

RP は Account に対して Invalidate Functionality を実行しなければならない（MUST）。OP は、OP が発行した以前の OpenID Connect ID Token が悪意ある行為者に渡ったと疑う場合、ユーザのデバイスが侵害された場合、または account に関するその他のセキュリティ上の懸念がある場合に、この Command を送信してよい（MAY）。

Account は active 状態でなければならず（MUST）、Command 実行後も active 状態のままである。Account がそれ以外の状態にある場合、RP は Incompatible State Response を返さなければならない（MUST）。

Invalidate Command の機能は、Suspend、Archive、Delete Commands によっても実行され、suspended、archived、unknown 状態の Account がリソースにアクセスできないことを保証する。

6.14. Invalidate Functionality

RP は、sub で識別される Account リソースに対して付与されていた可能性のあるすべての sessions と tokens を取り消さなければならない（MUST）。これには、offline_access を含む、アプリケーションに付与された可能性のある authorization も含まれる。

6.15. Migrate Command

Command Token の command claim における migrate または migrate_async 値で識別される。

OP は、既存 Account の authentication provider になることを要求するためにこの Command を送る。Command Token は次の追加 claim を含めなければならない（MUST）。

  • authentication_provider — REQUIRED\ 要求される authentication provider 状態を示す JSON string。OP が Account の唯一の authentication provider になりたい場合は op に設定しなければならず（MUST）、RP と OP の双方が認証できる二重認証を有効にし、既存の認証方式も有効のままにしたい場合は op_migration に設定しなければならない（MUST）。

RP は、Account の現在の authentication provider 状態と組織方針に基づいて Migrate Command を処理する。

  • authentication_provider が op であり、かつ RP が移行を許可する場合、RP は Account の authentication provider 状態を op に更新し、他の認証方式を無効化する。
  • authentication_provider が op_migration であり、かつ RP が二重認証をサポートする場合、RP は OP を追加の authentication provider として追加しつつ、既存の認証方式を維持する。op_migration による二重認証は、認証提供者を RP から OP に移行する際の円滑な移行を提供するための一時的状態として用いるべきである（SHOULD）。

6.15.1. Access Denied Error

RP が OP による Account の認証移行を許可しない場合、RP は HTTP 403 Forbidden response を返し、error パラメータに access_denied 値を含めなければならない（MUST）。

6.15.2. Authentication Not Transferable Error

Account の現在の authentication provider が認証責任の変更を許可しない場合（例: 別の OP によって管理されている、または移転不可の方針を持つ外部システムで管理されている場合）、RP は HTTP 409 Conflict response を返し、error パラメータに authentication_not_transferable 値を含めなければならない（MUST）。

7. Tenant Commands

Tenant Commands は Tenant の文脈で実行される。RP は Metadata Command をサポートしなければならない（MUST）。他の Tenant Commands のサポートは optional である。Tenant Commands の Command Tokens は tenant claim を含まなければならず（MUST）、sub claim を含むことは PROHIBITED である。定義は Claims and Properties を参照。

Tenant の文脈で実行される Asynchronous Commands は定義されていない点に注意すること。

7.1. Metadata Command

Command Token の command claim における metadata 値で識別される。

Additional Command Token claims:

  • metadata — REQUIRED — OP が提供する metadata object
  • callback_token — OPTIONAL

OP はこの Command を送信し、RP と metadata を交換する。OP は Command Request に自身の metadata を含め、RP は Command Response に自身の metadata を含める。Metadata Command は、Command Request で OP が RP に提供した以前の metadata と、Command Response で RP が OP に提供した以前の metadata を置き換える。

7.1.1. OP Metadata Object

Metadata Command の metadata claim は、次の fields を持つ JSON object を含む。

  • callback_endpoint — OPTIONAL — RP が新しい command（例: metadata や audit_tenant）を要求するため、または async results を配信するために使用できる、OP callback endpoint の HTTPS URL。
  • domains — OPTIONAL — strings の配列。Tenant に関連付けられた Email または DNS domains（RP における discovery、相関付け、またはスコーピングのため）。
  • claims_supported — OPTIONAL — strings の配列。OP が Account Commands に含め得る、または responses で返されることを期待する Claim 名。
  • groups — OPTIONAL — group objects の配列。各 object は次を含む。
    • id — REQUIRED — OP 固有の group identifier
    • display — REQUIRED — 人間が読める group 名
    • description — OPTIONAL — group 説明

OAuth 2.0 Authorization Server Metadata RFC8414 で定義される fields を含む、追加の fields を含めてもよい（MAY）。未知の fields は受信者によって無視されなければならない（MUST）。

Metadata Command の Command Token における Claim set の非規範的な例は次のとおり。

{
  "iss": "https://op.example.org",
  "aud": "https://rp.example.net/command",
  "client_id": "s6BhdRkqt3",
  "iat": 1734006000,
  "exp": 1734006060,
  "jti": "bWJt",
  "command": "metadata",
  "tenant": "ff6e7c96",
  "callback_token": "eyhwixm236djs9shne9sjdnjs9dhbsk",
  "metadata": {
    "callback_endpoint": "https://op.example.org/callback",
    "groups": [
      {
        "id": "b0f4861d",
        "display": "Administrators",
        "description": "Application administrators"
      },
      {
        "id": "88799417",
        "display": "Finance",
        "description": "Everyone in corporate finance"
      }
    ],
    "domains": ["example.com"],
    "claims_supported": [
      "sub",
      "email",
      "email_verified",
      "name",
      "given_name",
      "family_name",
      "groups"
    ]
  }
}

7.2. Metadata Response

Command Token が有効である場合、RP は application/json media type で応答し、次を含めなければならない（MUST）。

  • context (REQUIRED): Command Token からの iss と tenant 値を含む JSON object。
  • commands_supported (REQUIRED): RP がサポートする Commands の JSON array。metadata 値を含めなければならない（MUST）。
  • command_endpoint (REQUIRED): RP の Command Endpoint。Command Token が送られた先の URL。
  • client_id (REQUIRED): RP の client_id。

response は次を含めてもよい（MAY）。

  • aud_sub_required (OPTIONAL): RP が後続の Account Commands で aud_sub 値を受け取ることを要求することを示す
  • roles (OPTIONAL): RP がサポートする roles を記述する objects の JSON array

response は、IANA 参照 TBD の OAuth Dynamic Client Registration Metadata を含めてもよい（MAY）。

RP は、iss または tenant 値により異なる response を提供してもよい（MAY）。

Metadata Command に対する Command Response の非規範的な例は次のとおり。

NOTE: Metadata Command の iss と tenant を Command Response に含めるのは、OP が RP からの response が正しい iss と tenant に対するものであることを把握できるようにするためである。将来 Command Response が署名される場合、最上位に OP iss を置くと、iss が RP になるため混乱を招くので、最上位には置きたくない。

{
  "context": {
    "iss": "https://op.example.org",
    "tenant": "73849284748493"
  },
  "command_endpoint": "https://rp.example.net/command",
  "commands_supported": [
    "audit_tenant",
    "unauthorize",
    "suspend",
    "reactivate",
    "delete",
    "audit"
  ],
  "claims_supported": [
    "sub",
    "email",
    "email_verified",
    "name",
    "roles"
  ],
  "roles": [
    {
      "id": "00001",
      "display": "Admins",
      "description": "All administrative"
    },
    {
      "id": "00002",
      "display": "Editors",
      "description": "Create, read, update, delete posts"
    },
    {
      "id": "00003",
      "display": "Reader",
      "description": "Read posts"
    }
  ],
  "client_id": "s6BhdRkqt3",
  "client_name": "Example RP",
  "logo_uri": "https://rp.example.net/logo.png",
  "policy_uri": "https://rp.example.net/privacy-policy.html",
  "tos_uri": "https://rp.example.net/terms-of-service.html",
  "jwks_uri": "https://rp.example.net/jwks",
  "initiate_login_uri": "https://rp.example.net/initiate-login",
  "redirect_uris": [
    "https://rp.example.net/response"
  ]
}

7.3. Metadata Refresh Request

OP が直近の metadata Command で callback_endpoint と callback_token を提供していた場合、RP は OP に新しい metadata command を実行するよう要求できる。RP がこの要求を行う動機の一つは、RP の metadata が変更された場合である。

RP は callback_endpoint に対して HTTP POST を行い、callback_token を HTTP Authorize header の bearer token として渡し、content-type を application/json とし、command_requested を metadata に設定した JSON string を送る。

非規範的な例は次のとおり。

POST /callback HTTP/1.1
Host: op.example.org
Authorization: Bearer eyhwixm236djs9shne9sjdnjs9dhbsk
Content-Type: application/json
Accept: application/json
Cache-Control: no-cache

{
  "command_requested": "metadata"
}

callback_token が有効である場合、OP は HTTP 204 No Content response を返さなければならない（MUST）。

callback_token が無効である、または request body の内容が無効である場合、OP は RFC6750 に従ってエラーで応答しなければならない（MUST）。

7.4. Streaming Request

Metadata Command を除くすべての Tenant Commands は、RP が Command Response を転送するために Server-Sent Events (SSE) を使用する。Streaming Request を実行する際、OP は Command Request 送信時に次の HTTP headers を含めなければならない（MUST）。

  • Server-Sent Events のサポートを示すため、Accept に text/event-stream 値を指定する。
  • 中継者に response をキャッシュしないよう示すため、Cache-Control に no-cache 値を指定する。
  • 接続を開いたままにするため、Connection に keep-alive 値を指定する。
  • Accept-Encoding は gzip または gzip, br を指定して response の圧縮を受け入れることが推奨される（RECOMMENDED）。

Streaming Request の非規範的な例は次のとおり（簡潔さのため Command Token の内容の多くは省略している）。

POST /commands HTTP/1.1
Host: rp.example.net
Content-Type: application/x-www-form-urlencoded
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
Accept-Encoding: gzip, br

command_token=eyJhbGci ... .eyJpc3Mi ... .T3BlbklE ...

7.5. Streaming Response

RP は Streaming Request に対して Streaming Response を送信する。Streaming Response では、RP は SSE を用いて Command Response を一連の events としてストリーミングする。RP が有効な Command を受信した場合、RP は HTTP 200 OK response を送信しなければならず（MUST）、続いて次の headers を送らなければならない（MUST）。

  • Content-Type: text/event-stream
  • Cache-Control: no-cache
  • Connection: keep-alive

OP が request で RP が理解できる圧縮の Content-Encoding header を送っていた場合、RP は OP が提供した値のいずれかで Content-Encoding header を含めてもよい（MAY）。

SSE に従い、body は一連の events である。必須 field 名 data に加え、各 event は各 event に対して一意の値を持つ id field と、account-state、command-complete、error のいずれかの値を持つ event field を含めなければならない（MUST）。

RP は Audit Tenant Command において、iss と、送られた場合は org に対する RP 上の各 Account について account-state event を送信する。すべての account-state events が送信されたら、RP は command-complete event を送信する。

処理中に回復不能なエラーが発生した場合、RP は error event を送るべきであり（SHOULD）、その data field は JSON で、JSON string property error_description を RP が決定する値に設定する。

  • account-state event の data パラメータは、sub と account_state を含めなければならない（MUST）。
  • account-state event の data パラメータは、Tenant Command で定義される他の Claims を含めてもよい（MAY）。
  • command-complete event の data パラメータは、RP が送信した account-state events の総数である total_accounts を含めなければならない（MUST）。
  • Tenant に対して RP 上に Accounts が存在しない場合、RP は total-accounts が 0 の command-complete event のみを返す。

Audit Tenant Command に対する Streaming Response の非規範的な例は次のとおり。

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip

id: 1
event: account-state
data: {
  "sub": "248289761001",
  "email": "janes.smith@example.com",
  "given_name": "Jane",
  "family_name": "Smith",
  "groups": [
    "b0f4861d-f3d6-4f76-be2f-e467daddc6f6",
    "88799417-c72f-48fc-9e63-f012d8822ad1"
  ],
  "account_state": "active",
  "last_access": 1746792000,
}

id: 2
event: account-state
data: {
  "sub": "98765412345",
  "email": "john.doe@example.com",
  "given_name": "John",
  "family_name": "Doe",
  "groups": [
    "88799417-c72f-48fc-9e63-f012d8822ad1"
  ],
  "account_state": "suspended"
}

id: 3
event: command-complete
data: {
  "total_accounts": 2
}

Streaming Response の途中で接続が失われた場合、OP は新しい Command Token を生成し、SSE に従って受信した最後の event id property を持つ Last-Event-Id HTTP header を含めて Streaming Request を送るべきである（SHOULD）。

接続喪失後に送信される Streaming Request の非規範的な例は次のとおり。

POST /commands HTTP/1.1
Host: rp.example.net
Content-Type: application/x-www-form-urlencoded
Accept: text/event-stream
Cache-Control: no-cache
Connection: keep-alive
Accept-Encoding: gzip, br
Last-Event-Id: 3

command_token=eyJhbGci ... .eyJpc3Mi ... .T3BlbklE ...

RP が Last-Event-Id HTTP header を受け取っても Streaming Response を再開できない場合、RP は HTTP 404 Not Found を返し、error パラメータに last-event-id-unavailable を含めなければならない（MUST）。

7.6. Audit Tenant Command

Streaming Request で送信され、Command Token の command Claim における audit_tenant 値で識別される。

OP は Audit Tenant Command を送信し、RP における Tenant の Accounts の状態を学習する。

Additional Command Token claims:

  • callback_token — OPTIONAL

Audit Tenant Command の Command Token における Claims Set の非規範的な例は次のとおり。

{
  "iss": "https://op.example.org",
  "aud": "https://rp.example.net/command",
  "client_id": "s6BhdRkqt3",
  "iat": 1734003000,
  "exp": 1734003060,
  "jti": "bWJz",
  "command": "audit_tenant",
  "callback_token": "eyhwixm236djs9shne9sjdnjs9dhbsk"
}

7.7. Audit Tenant Response

RP は有効な Audit Tenant Command を受け取った場合、Streaming Response を送信する。

RP は、OP によって提供され RP が保持している Account に関する任意の Claims を、event data パラメータの JSON string に含めなければならない（MUST）。RP で Claim values が変更されている場合、変更後の values を返すべきである。

RP は、last_access claim を含めてもよい（MAY）。これは NumericDate であり、1970-01-01T00:00:00Z UTC からの秒数を表す。値は整数でなければならず（MUST）、RFC7519 で定義される iat および exp claims と等価である。

Streaming Response Events:

  • account-state events MUST include: sub (REQUIRED), account_state (REQUIRED)
  • account-state events MAY include: last_access, authentication_provider, other retained Claims
  • A final command-complete event MUST include: total_accounts (REQUIRED)

7.8. Audit Tenant Refresh Request

OP が直近の audit_tenant Command で callback_endpoint と callback_token を提供していた場合、RP は OP に新しい audit_tenant command を実行するよう要求できる。RP がこの要求を行う動機の一つは、accounts に変更があった場合である。

RP は callback_endpoint に対して HTTP POST を行い、callback_token を HTTP Authorize header の bearer token として渡し、content-type を application/json とし、command_requested を audit_tenant に設定した JSON string を送る。

非規範的な例は次のとおり。

POST /callback HTTP/1.1
Host: op.example.org
Authorization: Bearer eyhwixm236djs9shne9sjdnjs9dhbsk
Content-Type: application/json
Accept: application/json
Cache-Control: no-cache

{
  "command_requested": "audit_tenant"
}

callback_token が有効である場合、OP は HTTP 204 No Content response を返さなければならない（MUST）。

callback_token が無効である、または request body の内容が無効である場合、OP は RFC6750 に従ってエラーで応答しなければならない（MUST）。

7.9. Suspend Tenant Command

Streaming Request で送信され、Command Token の command Claim における suspend_tenant 値で識別される。この Command を受信すると、RP は Command Token の tenant Claim で識別される Tenant について、active 状態のすべての Accounts を停止しなければならない（MUST）。

RP は有効な Suspend Tenant Command を受け取った場合、Streaming Response を送信する。

Streaming Response Events:

  • account-state events MUST include: sub (REQUIRED), account_state（値 suspended）
  • A final command-complete event MUST include: total_accounts (REQUIRED)

7.10. Archive Tenant Command

Streaming Request で送信され、Command Token の command Claim における archive_tenant 値で識別される。この Command を受信すると、RP は Command Token の tenant Claim で識別される Tenant について、active および suspended 状態のすべての Accounts を停止しなければならない（MUST）。

RP は有効な Archive Tenant Command を受け取った場合、Streaming Response を送信する。

Streaming Response Events:

  • account-state events MUST include: sub (REQUIRED), account_state（値 archived）
  • A final command-complete event MUST include: total_accounts (REQUIRED)

7.11. Delete Tenant Command

Streaming Request で送信され、Command Token の command Claim における delete_tenant 値で識別される。この Command を受信すると、RP は Command Token の tenant Claim で識別される Tenant のすべての Accounts を削除しなければならない（MUST）。

RP は有効な Delete Tenant Command を受け取った場合、Streaming Response を送信する。Delete Tenant Command が成功した場合、RP は data パラメータに JSON string {"total_accounts":0} を含む command-complete event のみを送信する。

Streaming Response Events:

  • A final command-complete event MUST include: total_accounts (REQUIRED)
  • すべての Accounts の削除が成功した場合、account-state events は送信されない。

7.12. Invalidate Tenant Command

Streaming Request で送信され、Command Token の command Claim における invalidate_tenant 値で識別される。この Command を受信すると、RP は Command Token の tenant Claim で識別される Tenant について、active 状態のすべての Accounts に対して Invalidate Functionality を実行しなければならない（MUST）。

RP は有効な Invalidate Tenant Command を受け取った場合、Streaming Response を送信する。

Streaming Response Events:

  • account-state events MUST include: sub (REQUIRED), account_state（値 active）
  • A final command-complete event MUST include: total_accounts (REQUIRED)

8. Extensibility

8.1. Defining New Commands

新しい Commands は、次のいずれかの方法で定義できる。

  1. OpenID Provider Commands registry に登録する
  2. 名前として一意な absolute URI を使用する

URI 名を利用する types は、一般に適用されない vendor 固有の実装に限定すべきであり（SHOULD）、それらは使用される Resource Server の実装詳細に固有である。

8.2. Defining New Tenant Metadata

作成予定。

8.3. Defining New Relying Party Metadata

作成予定。

9. OpenID Provider Command Support

OpenID Provider Commands をサポートする Relying Parties は、クライアント登録の一部として OP に Command Endpoint を登録する。

Command Endpoint は {{RFC3986}} Section 4.3 で定義される absolute URI でなければならない（MUST）。Command Endpoint は {{RFC3986}} Section 3.4 に従って application/x-www-form-urlencoded 形式の query component を含んでもよい（MAY）。Command Endpoint は fragment component を含んではならない（MUST NOT）。

RP が OpenID Connect Dynamic Client Registration 1.0 をサポートする場合、OpenID Provider Command Endpoint を登録するために次の metadata 値を使用する。

  • command_endpoint — OPTIONAL\ OP から OpenID Provider Commands を受信する RP URL。この URL は https scheme を使用しなければならず（MUST）、path および query parameter components を含んでもよい（MAY）。

10. Implementation Considerations

本仕様は、Relying Parties と、OpenID Provider Commands を実装することを選択する OpenID Providers の双方が使用する機能を定義する。これらの Relying Parties および OpenID Providers は、本仕様において「REQUIRED」として列挙される、または「MUST」で記述される機能をすべて実装しなければならない（MUST）。本仕様は、これ以外の OpenID Provider Commands の実装上の考慮事項を定義しない。

11. Security Considerations

署名された Command Token は、RP が Command Request が正当な当事者から来たことを検証できるようにすることで、サービス拒否攻撃を防ぐために Command Request で要求される。

OP は、Command Token の有効期限を短くすることが推奨され、望ましくは将来に最大でも 2 分程度とし、捕捉された Command Tokens が再利用される（replay）ことを防ぐ。

11.1. Cross-JWT Confusion

{{RFC8725}} Section 2.8 で述べられているとおり、攻撃者は、ある目的で発行された JWT を、その意図しない文脈で使用しようとする場合がある。これらの攻撃に対する緩和策は Command Tokens に適用できる。

攻撃者が Command Token を別用途に転用しようとする一つの方法は、それを ID Token として使用しようとすることである。Command Token で述べたとおり、Command Token への nonce Claim の包含は禁止されており、ID Token としての誤用を防ぐ。

Cross-JWT confusion を防ぐ別の方法は、{{!RFC8725}} Section 3.11 で述べられている明示的な型付けを用いることであり、[#command-token] で要求されているとおりである。

12. Privacy Considerations

作成予定。

13. IANA Considerations

すべてのエントリは追加済みではない。

13.1. JSON Web Token Claims

本仕様は、RFC7519 によって確立された IANA「JSON Web Token Claims」registry に、以下の JSON web token claim definitions を登録する。

13.1.1. Registry Contents

  • Claim Name: command
    • Claim Description: token の aud に対する iss からの指示。
    • Change Controller: OpenID Foundation
    • Specification Document(s): 本文書
  • Claim Name: tenant
    • Claim Description: token の iss で識別される当事者内の、論理的に分離されたエンティティ。
    • Change Controller: OpenID Foundation
    • Specification Document(s): 本文書
  • Claim Name: metadata
    • Claim Description: token の iss で識別される当事者に関する metadata。
    • Change Controller: OpenID Foundation
    • Specification Document(s): 本文書

13.2. OAuth Dynamic Client Registration Metadata Registration

本仕様は、RFC7591 により確立された IANA OAuth Parameters の「OAuth Dynamic Client Registration Metadata」registry に、以下の client metadata definitions を登録する。

13.2.1. Registry Contents

  • Client Metadata Name: command_endpoint
    • Client Metadata Description: OP から OpenID Provider Commands を受信する RP URL
    • Change Controller: OpenID Foundation
    • Specification Document(s): 本文書

13.3. Media Type Registration

本仕様は {{!RFC6838}} に従い application/command+jwt media type を登録する。

作成予定。

14. References

14.1. Normative References

  • [RFC2119] Bradner, S. “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119, March 1997.
  • [RFC3986] Berners-Lee, T., Fielding, R., and Masinter, L. “Uniform Resource Identifier (URI): Generic Syntax,” RFC 3986, January 2005.
  • [RFC6750] Jones, M., and Hardt, D., “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” RFC 6750, October 2012
  • [RFC7519] Jones, M., Bradley, J., and Sakimura, N. “JSON Web Token (JWT),” RFC 7519, May 2015.
  • [RFC7591] Jones, M., Bradley, J., and Sakimura, N. “OAuth 2.0 Dynamic Client Registration Protocol,” RFC 7591, March 2015.
  • [RFC8414] Jones, M., and Sakimura, N., “OAuth 2.0 Authorization Server Metadata,” RFC 8414, June 2018.
  • [RFC9110] Fielding, R. “HTTP Semantics,” RFC 9110, June 2022.
  • [RFC8725] Bromberg, L. “Security Considerations for JSON Web Tokens,” RFC 8725, June 2020.
  • [RFC6838] IANA. “Media Types,” RFC 6838, June 2013.
  • ISO/IEC 24760-1:2019, “IT Security – A framework for identity management – Part 1: Terminology and concepts.”
  • OpenID.Core – “OpenID Connect Core 1.0 incorporating errata set 2,” available at https://openid.net/specs/openid-connect-core-1_0.html.
  • OpenID.Enterprise – "OpenID Connect Enterprise Extensions 1.0," available at https://openid.net/specs/openid-connect-enterprise-extensions-1_0.html.

14.2. Informative References

  • IANA JSON Web Token Claims Registry, available at https://www.iana.org/assignments/jwt/jwt.xhtml.
  • IANA OAuth Parameters, available at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#client-metadata.

Appendix A. Acknowledgements

著者は、Tim Cappalli、Andrii Deinega、Pam Dingle、George Fletcher、Michael Jones、Jeff Lombardo、Aaron Parecki、Nat Sakimura、Dean Saxe、Rifaat Shekh-Yusef から提供された初期フィードバックに感謝する。

更新予定。

Appendix B. Notices

Copyright (c) 2025 The OpenID Foundation.

OpenID Foundation (OIDF) は、任意の Contributor、developer、implementer、その他の関心を持つ当事者に対し、非独占的、ロイヤルティフリー、全世界的な著作権ライセンスを付与し、この Implementers Draft、Final Specification、または Final Specification Incorporating Errata Corrections を複製し、派生著作物を作成し、配布し、上演し、表示することを許諾する。ただし、(i) 仕様の策定、および (ii) 当該文書に基づく Implementers Drafts、Final Specifications、Final Specification Incorporating Errata Corrections の実装の目的に限る。また、OIDF を素材の出所として帰属表示を行うことが条件であるが、その帰属表示は OIDF による推奨を示すものではない。

本仕様で記述される技術は、OpenID Foundation のメンバーやその他の提供元を含むさまざまなソースからの貢献により提供された。OpenID Foundation は、技術が配布可能であることを確保するための手順を講じてきたが、本仕様で記述される技術の実装または使用に関して主張され得る知的財産権またはその他の権利の有効性や範囲、ならびにそれらの権利の下でのライセンスが利用可能であるか否か、またどの程度利用可能であるかについて、いかなる立場も取らない。また、そのような権利を特定するために独自の努力を行ったことも表明しない。OpenID Foundation および本仕様への貢献者は、本仕様に関して、商品性、非侵害、特定目的適合性、権原に関する黙示の保証を含む、明示黙示その他いかなる保証も行わず（ここに明示的に否認する）、本仕様を実装することに伴うリスクの全ては implementer が負う。OpenID Intellectual Property Rights policy（openid.net に掲載）は、貢献者が、他の貢献者および implementers に対して特定の特許請求を主張しないための patent promise を提供することを要求する。OpenID は、当事者が本仕様を実践するために必要となり得る技術を対象とする著作権、特許、特許出願、その他の専有権がある場合、それらを OpenID に知らせることを歓迎する。

Appendix C. Document History

[[ 最終仕様から削除予定 ]]

-00

  • initial draft

-01

  • rename commands_uri to commands_endpoint
  • added audit account command
  • change aud to be the commands_endpoint and add client_id as a separate claim
  • add error as another event type in tenant SSE response
  • add async commands, callback_endpoint to OP metadata, and callback_token for async response and metadata request
  • add error messages for restarting a stream that cannot be restarted
  • add roles claims and roles metadata
  • add last_access claim for RP to communicate last time user accessed the resource off_line
  • minor edits and structural cleanup

-02

  • added aud_sub as claim in commands and property from RP in audit reponses
  • Metadata Response: Added aud_sub_required response property (OPTIONAL) normatively indicating RP requirement to receive aud_sub in subsequent Account Commands.
  • collected all normative claims and properties into new "Claims and Properties" section centralizing definitions of all Command Token claims and response properties
  • Command Token: Introduced normative baseline claim sets for Account vs Tenant Commands; clarified that only listed claims plus command-specific additions may appear (tightening allowed claims surface).

Authors' Addresses

  • Dick Hardt (Hellō)
    • Email: dick.hardt@gmail.com
  • Karl McGuinness (Independent)
    • Email: me@karlmcguinness.com