Skip to content

OpenID Provider Commands 1.0 - draft 02

Workgroup:
OpenID Connect

Published:
25 September 2025

Authors:
D. Hardt
Hellō
K. McGuinness
Independent

Abstract

OpenID Connect は、End-User が OpenID Provider (OP) を用いて Relying Party (RP) にログインし、ID Token を用いて End-User に関する Claims を提示するためのプロトコルを定義する。RP はしばしば、ユーザーに関する identity Claims を用いて、RP におけるユーザーの Account を暗黙的（または明示的）に確立する。

OpenID Provider Commands は、OP が RP における End-User の Account を直接管理するための一連の Commands を導入することで OpenID Connect を補完する。これらの Commands により、OP は End-User の Account を有効化、維持、停止、再有効化、アーカイブ、復元、削除、監査、無効化でき、既存アカウントの認証の移行も可能になる。Command Tokens は OpenID Connect の ID Token スキーマと検証を基盤としており、RP による採用を容易にする。

Table of Contents

1. Introduction

OpenID Connect 1.0 は広く採用されている identity プロトコルであり、relying parties (RPs) と呼ばれるクライアントアプリケーションが、信頼されたサービスである OpenID Provider (OP) によって行われた認証に基づいて End-User の本人性を検証できるようにする。OpenID Connect はまた、End-User に関する identity attributes（Claims）を安全に取得する仕組みも提供し、RP が体験を最適化し、確信を持ってアクセス管理を行うのに役立つ。

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

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

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

企業環境では、組織が従業員のアクセスを中央管理するため、OP は RP における既存の従業員アカウントを制御下に置く必要がある。まず OP は、account resolution を通じて、自身の account identifiers と RP の内部 identifiers の間に双方向のマッピングを確立し、両者が同一の特定アカウントを参照できるようにする。この identifier resolution が完了すると、企業は、従業員が過去に RP 管理の資格情報や他の認証方法で作成していた Accounts について、認証責任を移行できる。認証制御と identifier mapping が確立された後、OP はライフサイクルの各段階にわたって重要な Account 操作（有効化、維持、停止、再有効化、アーカイブ、復元、削除）を扱い、セキュリティと遵守を維持できる。

OpenID Provider Commands は、OP から RP への remote procedure call であり、既存の 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 版では、値が文字どおりに解釈されることを示すために引用符で囲む。これらの値をプロトコルメッセージで使用する場合、引用符は値の一部として使用してはならない。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 identifiers は文字列 _async で終わる。
  • Command Token: OP によって署名された JSON Web Token (JWT) で、発行される Command に関する Claims を含む。
  • Command Endpoint: OP が Command Tokens を POST する RP 上の URL。
  • Tenant: OP 内の論理的に分離されたエンティティであり、組織上または管理上の境界を表す。OP は単一の Tenant を持つ場合も、複数の Tenants を持つ場合もある。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 のように OP から command を送信するよう依頼するため、または asynchronous command の結果を送信するために、callback endpoint と callback token を提供してもよい。

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

1.4. Command Use Cases

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

1.4.1. Personal Applications

Personal applications は、自身の accounts を管理する個人ユーザー向けである。このシナリオでは、accounts は組織ではなく End-User によって作成され、管理される。

Supported Commands: Metadata, Invalidate, Delete

Typical Command Sequence:

  1. Metadata Command - OP と RP 間の capabilities を確立する
  2. Invalidate Command - account の侵害が疑われる場合、すべての sessions と tokens を無効化する
  3. Delete Command - ユーザーの要求（例: 「忘れられる権利」）により account とデータを削除する

1.4.2. Enterprise Application Migration

組織が新しい identity providers を導入する場合や、合併・買収を行う場合、既存 accounts の認証責任を移行する必要がある。これは一般に、個人ユーザーが最初に RP 管理の資格情報で accounts を作成し、後に組織が企業の identity provider の下で認証を集中化する必要が生じるときに発生する。

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 identifiers の間で双方向のマッピングを確立するプロセスである。OP が Audit のような commands への response として RP から aud_sub 値を受け取ると、OP は当該 account に対する RP の内部 identifier を学習する。これにより OP は、後続の Command Tokens に aud_sub claim を含めることができ、RP は OP の iss と sub の値に基づく foreign key 関係を維持するのではなく、自身の identifiers を用いて commands を実行できる。これは、RP が外部 identifiers を保存・管理する必要をなくしつつ、システム間で accounts を関連付ける能力を維持できるため、RP の実装を簡素化する。

Authentication Migration Process: Authentication Migration は、Migrate Command を通じて OP が既存 accounts の authentication provider になることを可能にする。このプロセスは、組織移行、買収、または中央集権的な identity governance ポリシーの実施において不可欠である。Account Resolution は、OP が Migrate Command によりある account の authentication provider になることを容易にする。

1.4.3. Enterprise Application Integration

組織の identity providers と統合された 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 states を同期する
  4. Periodic Audit Commands - 同期を維持し、差分（drift）を是正する

1.4.4. Compliance Auditing

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

Audit-Only Sequence:

  1. Metadata Command - 監査 capabilities を確立する
  2. Audit Tenant Command - account states と 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 内部 identifier（account resolution により学習）。検索において、(iss,sub) の組ではなく RP のネイティブ identifier を使用できるようにする。
  • aud: token の audience。RP の Command Endpoint URL。
  • authentication_provider: どちらの当事者がユーザーを認証できるかを示す文字列。値は次を含む。
    • rp: RP のみが認証する
    • op: OP のみが認証する
    • op_migration: RP と OP の双方が認証できる（移行の一時状態）
    • external: 外部 provider による認証
    • unknown: authentication provider が不明または非開示
  • callback_token: OP が生成する不透明な token。RP が asynchronous 結果を送信したり 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 の一意 identifier（OpenID Connect Core Section 9 による）。
  • metadata: Metadata Command において OP が RP に提供する metadata を伝える JSON object。正規スキーマは [OP Metadata Object] を参照。
  • sub: Account の Subject Identifier（OpenID Connect Core, Section 2 を参照）。
  • tenant: OP 内の Tenant の identifier。値は personal、organization、または multi-tenant OP のための OP 固有の安定 identifier。iss と tenant の組み合わせで Tenant を識別する。

2.2. Properties in Responses

  • account_state: 処理後の Account の状態。サポートされる状態は unknown、active、suspended、archived。
  • aud_sub_required: RP が Account Commands において aud_sub を要求するかどうかを示す boolean。
  • 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 access の NumericDate（1970-01-01T00:00:00Z UTC からの秒数）。
  • roles: role objects の配列。各 object は次を持つ。
    • id: RP 固有の role identifier
    • display: 人間可読な role 名
    • description（optional）: role の説明
  • sub: [Claims in Command Tokens] の定義を参照。
  • total_accounts: streaming response で送信された account-state events の総数。

特定の command または response における各 claim/property の requirement levels については、本仕様の対応するセクションを参照すること。

3. Command Request

OP は、登録済みの Command Endpoint に対して HTTP POST を用い、RP に Account Commands を送信する。POST body は application/x-www-form-urlencoded の encoding を使用し、RP 向けに OP が発行した Command Token を含む command_token parameter を必ず含めなければならない。

POST body には command_token に加えて他の値を含めてもよい。実装が理解できない値は無視しなければならない。

以下は、そのような 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 を返さなければならない。ただし、一部の Web frameworks は、HTTP body が空のときに HTTP 200 OK の代わりに HTTP 204 No Content response を返すことがある点に注意すること。したがって OP は、HTTP 204 No Content response も成功 response として処理できるよう備えるべきである。

RP の response には、response がキャッシュされるのを防ぎ、キャッシュ済み response が将来の Command requests に干渉することを防止するため、Cache-Control の HTTP response header field に no-store 値を含めなければならない。例は次のとおりである。

Cache-Control: no-store

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

request が有効でない場合、RP は error parameter を返さなければならず、error_description parameter を含めてもよい。エラー response に含められる情報はデプロイのデバッグを助けることを目的としており、実装が異なる error 値に基づいて異なる runtime behaviors を起動することを意図していない点に注意すること。

4.1. Invalid Request Error

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

4.2. Unrecognized Provider Error

RP が Command token 内の iss 値によって識別される OP を認識しない場合、RP は HTTP 401 Unauthorized response を返し、error parameter を値 unrecognized_provider で含めなければならない。

4.3. Unsupported Command Error

RP が要求された Command をサポートしない場合、RP は HTTP 400 Bad Request を返し、error parameter を値 unsupported_command で含めなければならない。

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

4.4. Server Error

RP が有効な request を処理できない場合、RP は RFC 9110 section 15.6 で定義される 5xx Server Error status code を返さなければならない。

5. Command Token

OP は、JSON Web Token (JWT) である Command Token を RP に送信することで Commands を発行する。これは OpenID Connect ID Token（{{OpenID.Core}} の Section 2 を参照）に類似しているが、認証 assertion ではなく command semantics を担う。

Command Token に現れ得るすべての claims は [Claims and Properties] セクションで一度だけ定義される。このセクションはその定義に関して規範的である。本仕様の各 command セクションは、その command に対してどの claims が REQUIRED、OPTIONAL、または PROHIBITED であるかを規範的に述べる。したがって本セクションは、以降での簡便表現として用いられる baseline claim groupings のみを定義する。

nonce の禁止: cross-JWT confusion を防ぐため、Command Token には nonce claim が存在してはならない。[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 は署名されなければならない。OP が ID Token に使用するのと同じ署名鍵が用いられ、通常の OpenID Connect の仕組みにより鍵の発見が可能となる。

Command Tokens は、JWS Header Parameter の typ（type）に正確に command+jwt を含めることで明示的に型付けされなければならない。根拠は [Security Considerations] を参照。

Example JWS header（非規範的）:

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

Activate Command の Command Token の JWT Claims Set の非規範的な例を次に示す。

{
  "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 の JWT Claims Set の非規範的な例を次に示す。

{
  "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 の際に提供した aud_sub claim（提供されている場合）、または iss と sub claims によって、Command Token 内で識別される RP Account に対して実行される。Account Commands には Lifecycle Commands、Invalidate Command、Migrate Command が含まれる。

各 Account Command において、Command Token は [Command Token] で定義される Account Command baseline claims を含まなければならない。以下の各 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 ----------------------------------------------+

† suspended から archived への遷移は ISO 標準に対する拡張である。

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 の対象となる Account が identity register において互換性のない状態にある場合、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"
}

既存の Account に対して Activate Command を送信した場合、または存在しない Account に対して他の Commands のいずれかを送信した場合、その Account は互換性のない状態である点に注意すること。

既存の Account が active 状態にある場合の、成功しない 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 を受け取り、かつ account がその command を実行するのに互換な状態にある場合、RP は HTTP 202 Accepted response を返す。Asynchronous Command の処理が完了し、OP が metadata に callback_endpoint を提供し、かつ command に callback_token を提供していた場合、RP は callback_endpoint に対して処理結果を HTTP POST し、HTTP Authorize header にて callback_token を Bearer token として含めなければならない。

response body は、上記の Success Response に指定された properties を含まなければならない。

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] に従ってエラーを返さなければならない。

6.5. Activate Command

Command Token の command claim における activate または activate_async 値によって識別される。

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

6.6. Maintain Command

Command Token の command claim における maintain または maintain_async 値によって識別される。

RP は、含まれる Claims を用いて identity register 内の既存 Account を更新しなければならない。Account は active 状態でなければならない。処理成功後も Account は active 状態のままである。

6.7. Suspend Command

Command Token の command claim における suspend または suspend_async 値によって識別される。

RP は Account に対して [Invalidate Functionality] を実行し、identity register でその Account を一時的に利用不可としてマークしなければならない。Account は active 状態でなければならない。処理成功後、Account は suspended 状態となる。

6.8. Reactivate Command

Command Token の command claim における reactivate または reactivate_async 値によって識別される。

RP は、停止されている Account を identity register で active としてマークしなければならない。Account は suspended 状態でなければならない。処理成功後、Account は active 状態となる。RP は Suspend Command をサポートする場合、Reactivate Command もサポートすべきである。

6.9. Archive Command

Command Token の command claim における archive または archive_async 値によって識別される。

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

6.10. Restore Command

Command Token の command claim における restore または restore_async 値によって識別される。

RP は archived Account を identity register に復元し、active としてマークしなければならない。Account は archived 状態でなければならない。処理成功後、Account は active 状態となる。RP は Archive Command をサポートする場合、Restore Command もサポートすべきである。

6.11. Delete Command

Command Token の command claim における delete または delete_async 値によって識別される。

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

6.12. Audit Command

Command Token の command claim における audit または audit_async 値によって識別される。

RP は Account の状態と、OP から提供され RP が保持している Account のすべての Claims を含めなければならない。Account が見つからない場合、RP は unknown 状態を返す。

response は次を含めてもよい。

  • last_access — OPTIONAL
  • authentication_provider — OPTIONAL

6.13. Invalidate Command

Command Token の command claim における invalidate または invalidate_async 値によって識別される。

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

Account は active 状態でなければならず、Command 実行後も active 状態のままである。Account が他のいずれかの状態にある場合、RP は [Incompatible State Response] を返さなければならない。

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

6.14. Invalidate Functionality

RP は、sub によって識別される Account リソースについて、offline_access を含め、アプリケーションに付与されていた可能性のある authorization を含むすべての sessions と tokens を取り消さなければならない。

6.15. Migrate Command

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

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

  • authentication_provider
    REQUIRED.
    要求される authentication provider 状態を示す JSON 文字列。OP が Account の唯一の authentication provider になりたい場合は op に設定し、OP と既存の認証方法の双方を有効なままにする dual authentication を有効化したい場合は op_migration に設定しなければならない。

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

  • authentication_provider が op で、かつ RP が移行を許可する場合、RP は Account の authentication provider 状態を op に更新し、他の認証方法を無効化する。
  • authentication_provider が op_migration で、かつ RP が dual authentication をサポートする場合、RP は OP を追加の authentication provider として追加しつつ、既存の認証方法を維持する。op_migration による dual authentication は、RP から OP へ authentication provider を移行する際にシームレスな移行を提供するための一時状態として用いられるべきである。

6.15.1. Access Denied Error

RP が OP による Account の認証移行を許可しない場合、RP は HTTP 403 Forbidden response を返し、error parameter を値 access_denied で含めなければならない。

6.15.2. Authentication Not Transferable Error

Account の現在の authentication provider が認証責任の変更を許可しない場合（例: 別の OP または non-transferable ポリシーを持つ external system により管理されている場合）、RP は HTTP 409 Conflict response を返し、error parameter を値 authentication_not_transferable で含めなければならない。

7. Tenant Commands

Tenant Commands は Tenant の文脈で実行される。RP は Metadata Command をサポートしなければならない。他の Tenant Commands のサポートは optional である。Tenant Commands の Command Tokens は tenant claim を必ず含まなければならず、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 — RPs が新しい command（例: metadata または audit_tenant）を要求するため、または async 結果を配信するために使用できる OP callback endpoint の HTTPS URL。
  • domains — OPTIONAL — 文字列の配列。Tenant に関連付けられた email または DNS domains（RP における discovery、correlation、または scoping のため）。
  • claims_supported — OPTIONAL — 文字列の配列。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 を含めてもよい。未知の fields は受領者によって無視されなければならない。

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 で次を必ず含む response を返す。

  • context (REQUIRED): Command Token の iss と tenant の値を含む JSON object。
  • commands_supported (REQUIRED): RP がサポートする Commands の JSON array。metadata 値は必ず含めなければならない。
  • command_endpoint (REQUIRED): RP の Command Endpoint。これは Command Token が送信された URL である。
  • client_id (REQUIRED): RP の client_id。

response は次を含めてもよい。

  • aud_sub_required (OPTIONAL): RP が後続の Account Commands において aud_sub 値の提供を要求することを示す。
  • roles (OPTIONAL): RP がサポートする roles を記述する objects の JSON array。

response は、OAuth Dynamic Client Registration Metadata TBD IANA reference を含めてもよい。

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

Metadata Command に対する Command Response の非規範的な例を次に示す。

NOTE: Metadata Command の iss と tenant を Command Response に含めたいのは、OP が RP からの response が本当に正しい iss と tenant のためのものだと分かるようにするためである。トップレベルに OP の iss を置くのは望ましくない。将来 Command Response が署名されるようになった場合、トップレベルの 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 がこの要求を行う動機の 1 つは、RP の metadata が変更された場合である。

RP は、content-type を application/json とし、command_requested を metadata に設定した JSON 文字列を用いて、callback_endpoint に HTTP POST しなければならない。このとき HTTP Authorize header で callback_token を bearer token として渡す。

非規範的な例を次に示す。

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 を返さなければならない。

callback_token が有効でない、または request body の内容が有効でない場合、OP は [RFC6750] に従ってエラーを返さなければならない。

7.4. Streaming Request

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

  • Accept に text/event-stream を指定し、Server-Sent Events のサポートを示す。
  • Cache-Control に no-cache を指定し、中継者に response をキャッシュしないことを示す。
  • Connection に keep-alive を指定し、接続を開いたままにする。

OP は、Accept-Encoding HTTP header に gzip または gzip, br を指定して response の compression を受け入れることが推奨される。

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 を送信し、続けて次の headers を送信しなければならない。

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

OP が request で、RP が理解できる compression を Content-Encoding header で送信していた場合、RP は OP が提供した値のいずれかを Content-Encoding header に含めてもよい。

SSE に従い、response body は events の系列である。必須の field 名 data に加えて、各 event は各 event ごとに一意の値を持つ id field と、値が account-state、command-complete、または error のいずれかである event field を含めなければならない。RP は、Audit Tenant Command において送信された iss と、送信されていれば org に対して、RP に存在する各 Account について account-state event を送信する。すべての account-state events が送信されたら、RP は command-complete event を送信する。処理中に回復不能なエラーが発生した場合、RP は error event を送信すべきであり、その data field は JSON で、JSON 文字列 property error_description を RP が決定した値に設定する。

account-state event の data parameter は、sub と account_state を含まなければならない。

data parameter は、Tenant Command により定義される他の Claims を含めてもよい。

command-complete event の data parameter は、RP が送信した account-state events の総数として total_accounts を含まなければならない。

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 は SSE に従い、受信した最後の event の id property を指定して HTTP header Last-Event-Id を含め、新しい Command Token を生成して Streaming Request を送信すべきである。

接続が失われた後に送信される 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 parameter に last-event-id-unavailable を含めなければならない。

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 parameter の JSON 文字列に含めなければならない。RP で Claim values が変更されている場合、変更後の値を返すべきである。

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

Streaming Response Events:

  • account-state events は必ず含める: sub（REQUIRED）、account_state（REQUIRED）
  • account-state events は含めてもよい: last_access、authentication_provider、その他の保持されている Claims
  • 最終 command-complete event は必ず含める: total_accounts（REQUIRED）

7.8. Audit Tenant Refresh Request

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

RP は、content-type を application/json とし、command_requested を audit_tenant に設定した JSON 文字列を用いて、callback_endpoint に HTTP POST しなければならない。このとき HTTP Authorize header で callback_token を bearer token として渡す。

非規範的な例を次に示す。

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 を返さなければならない。

callback_token が有効でない、または request body の内容が有効でない場合、OP は [RFC6750] に従ってエラーを返さなければならない。

7.9. Suspend Tenant Command

Streaming Request で送信され、Command Token の command claim における suspend_tenant 値によって識別される。この Command を受領すると、RP は Command Token の tenant claim により識別される Tenant において active 状態にあるすべての Accounts を suspended にしなければならない。

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

Streaming Response Events:

  • account-state events は必ず含める: sub（REQUIRED）、account_state（値 suspended）
  • 最終 command-complete event は必ず含める: 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 を archived にしなければならない。

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

Streaming Response Events:

  • account-state events は必ず含める: sub（REQUIRED）、account_state（値 archived）
  • 最終 command-complete event は必ず含める: total_accounts（REQUIRED）

7.11. Delete Tenant Command

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

RP は、有効な Delete Tenant Command を受領した場合、Streaming Response を送信する。Delete Tenant Command が成功した場合、RP は data parameter に JSON 文字列 {"total_accounts":0} を含む command-complete event のみを送信する。

Streaming Response Events:

  • 最終 command-complete event は必ず含める: 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] を実行しなければならない。

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

Streaming Response Events:

  • account-state events は必ず含める: sub（REQUIRED）、account_state（値 active）
  • 最終 command-complete event は必ず含める: total_accounts（REQUIRED）

8. Extensibility

8.1. Defining New Commands

新しい Commands は次の 2 つの方法のいずれかで定義できる。すなわち、OpenID Provider Commands registry に登録する方法、または一意の absolute URI をその名前として使用する方法である。

URI 名を使用する types は、一般に適用されにくく、使用される resource server の実装詳細に特有である vendor-specific 実装に限定されるべきである。

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 でなければならない。Command Endpoint は {{RFC3986}} の Section 3.4 に従い、application/x-www-form-urlencoded 形式の query component を含めてもよい。Command Endpoint は fragment component を含んではならない。

RP が [OpenID Connect Dynamic Client Registration 1.0] をサポートしている場合、この metadata 値を使用して OpenID Provider Command Endpoint を登録する。

  • command_endpoint
    OPTIONAL.
    OP から OpenID Provider Commands を受け取る RP の URL。この URL は https scheme を使用しなければならず、path および query parameter components を含めてもよい。

10. Implementation Considerations

本仕様は、OpenID Provider Commands を実装することを選択する Relying Parties と OpenID Providers の双方が使用する機能を定義する。これらの Relying Parties と OpenID Providers は、本仕様で「REQUIRED」として列挙されている、または「MUST」で記述されている機能を必ず実装しなければならない。本仕様は、OpenID Provider Commands の実装に関する他の implementation considerations を定義しない。

11. Security Considerations

正当な当事者からの Command Request であることを RP が検証できるようにして denial of service attacks を防ぐため、Command Request では署名済み Command Token が必要である。

OP は、捕捉された Command Tokens が再利用（replay）されることを防ぐため、Command Tokens において短い expiration times（望ましくは将来最大 2 分以内）を使用することが推奨される。

11.1. Cross-JWT Confusion

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

攻撃者が Command Token を流用しようとする 1 つの方法は、それを 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 定義を登録する。

13.1.1. Registry Contents

  • Claim Name: command

Claim Description: token の iss から aud への指示。

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 Dynamic Client Registration Metadata」registry（[IANA OAuth Parameters]）に、次の client metadata 定義を登録する。

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. 「RFC における要求レベルを示すキーワード」, RFC 2119, 1997 年 3 月。
  • [RFC3986] Berners-Lee, T., Fielding, R., Masinter, L. 「Uniform Resource Identifier (URI): Generic Syntax」, RFC 3986, 2005 年 1 月。
  • [RFC6750] Jones, M., Hardt, D. 「The OAuth 2.0 Authorization Framework: Bearer Token Usage」, RFC 6750, 2012 年 10 月。
  • [RFC7519] Jones, M., Bradley, J., Sakimura, N. 「JSON Web Token (JWT)」, RFC 7519, 2015 年 5 月。
  • [RFC7591] Jones, M., Bradley, J., Sakimura, N. 「OAuth 2.0 Dynamic Client Registration Protocol」, RFC 7591, 2015 年 3 月。
  • [RFC8414] Jones, M., Sakimura, N. 「OAuth 2.0 Authorization Server Metadata」, RFC 8414, 2018 年 6 月。
  • [RFC9110] Fielding, R. 「HTTP Semantics」, RFC 9110, 2022 年 6 月。
  • [RFC8725] Bromberg, L. 「Security Considerations for JSON Web Tokens」, RFC 8725, 2020 年 6 月。
  • [RFC6838] IANA. 「Media Types」, RFC 6838, 2013 年 6 月。
  • 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」, 参照先: https://openid.net/specs/openid-connect-core-1_0.html。
  • OpenID.Enterprise – 「OpenID Connect Enterprise Extensions 1.0」, 参照先: https://openid.net/specs/openid-connect-enterprise-extensions-1_0.html。

14.2. Informative References

  • IANA JSON Web Token Claims Registry, 参照先: https://www.iana.org/assignments/jwt/jwt.xhtml。
  • IANA OAuth Parameters, 参照先: 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、またはその他の関心を持つ当事者に対しても、(i) 仕様策定、ならびに (ii) これらの文書に基づく Implementers Drafts、Final Specifications、および Final Specification Incorporating Errata Corrections の実装の目的に限り、この Implementers Draft、Final Specification、または Final Specification Incorporating Errata Corrections を複製し、派生著作物を作成し、頒布し、実演し、表示するための、非独占・ロイヤルティフリー・全世界有効の著作権ライセンスを付与する。ただし、OIDF を資料の出所として帰属表示することを条件とし、その帰属表示は OIDF の承認を示すものではない。

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

Appendix C. Document History

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

-00

initial draft

-01

  • commands_uri を commands_endpoint に改名
  • audit account command を追加
  • aud を commands_endpoint とし、client_id を別の claim として追加
  • tenant SSE response に別の event type として error を追加
  • async commands、OP metadata に callback_endpoint、async response と metadata request のための callback_token を追加
  • 再開できない stream の再起動に関するエラーメッセージを追加
  • roles claims と roles metadata を追加
  • ユーザーが off_line でリソースにアクセスした最終時刻を RP が伝えるための last_access claim を追加
  • 軽微な編集と構造の整理

-02

  • commands に claim として aud_sub を追加し、audit responses における RP からの property も追加
  • Metadata Response: 後続の Account Commands で aud_sub を受け取る必要があることを示す aud_sub_required response property（OPTIONAL）を規範的に追加
  • すべての Command Token claims と response properties の定義を集中させる新しい「Claims and Properties」セクションに、すべての規範的 claims と properties を集約
  • Command Token: Account と Tenant Commands の規範的 baseline claim sets を導入し、列挙された claims と command 固有の追加のみが現れ得ることを明確化（許容 claims 面を絞り込み）

Authors' Addresses

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