OpenID Connect Dynamic Client Registration 1.0

Abstract

OpenID Connect 1.0 は、OAuth 2.0 プロトコル上に構築されたシンプルなアイデンティティレイヤーです。これにより Client は、Authorization Server が実施した認証に基づいて End-User の本人性を検証でき、さらに End-User の基本的なプロフィール情報を相互運用可能かつ REST 風の方法で取得できます。

この仕様は、OpenID Connect Relying Party が End-User の OpenID Provider に対して動的登録を行う方法を定義します。Relying Party は自身に関する情報を OpenID Provider に提供し、それを利用するために必要な情報（この Relying Party 用の OAuth 2.0 client_id を含む）を取得できます。

1. Introduction

OpenID Connect 1.0 は OAuth 2.0 プロトコル上のシンプルなアイデンティティレイヤーです。これにより Client は、Authorization Server が実施した認証に基づいて End-User の本人性を検証でき、さらに End-User の基本プロフィール情報を相互運用可能かつ REST 風の方法で取得できます。

OpenID Connect Relying Party が End-User に対して OpenID Connect サービスを利用するには、OP に登録し、自身に関する情報を提供するとともに、OAuth 2.0 client_id を含む利用に必要な情報を取得する必要があります。本仕様は、RP が OP に登録する方法、および RP の登録情報を取得する方法を説明します。

この仕様の以前の版は以下です。

OpenID Connect Registration 1.0 incorporating errata set 1 [OpenID.Registration.Errata1]
OpenID Connect Registration 1.0 (final) [OpenID.Registration.Final]

1.1. Requirements Notation and Conventions

この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、"OPTIONAL" は、RFC 2119 [RFC2119] で定義される意味で解釈されます。

本仕様の .txt 版では、値がリテラルであることを示すために引用符が用いられます。これらの値をプロトコルメッセージで使用する際、引用符を値の一部として使用してはなりません。HTML 版では、リテラルとして扱う値は等幅フォントで示されます。

本仕様における JSON Web Signature (JWS) [JWS] と JSON Web Encryption (JWE) [JWE] のデータ構造の利用は、JWS Compact Serialization または JWE Compact Serialization を使用します。JWS JSON Serialization と JWE JSON Serialization は使用しません。

1.2. Terminology

本仕様では、OAuth 2.0 [RFC6749] で定義される "Access Token"、"Authorization Code"、"Authorization Endpoint"、"Authorization Server"、"Client"、"Client Authentication"、"Client Identifier"、"Client Secret"、"Grant Type"、"Protected Resource"、"Redirection URI"、"Refresh Token"、"Response Type"、"Token Endpoint"、JSON Web Token (JWT) [JWT] で定義される "JSON Web Token (JWT)" および "Nested JWT"、JSON Web Signature (JWS) [JWS] で定義される "Base64url Encoding"、および OpenID Connect Core 1.0 [OpenID.Core] で定義される用語を使用します。

本仕様はさらに以下の用語を定義します。

Client Registration Endpoint

Client を Authorization Server に登録するための OAuth 2.0 Protected Resource。

Client Configuration Endpoint

登録済み Client の登録情報を管理するための OAuth 2.0 Endpoint。この Endpoint の URL は、Authorization Server が Client Information Response で返します。

Registration Access Token

Client Registration Endpoint 経由で Authorization Server が発行する OAuth 2.0 Bearer Token。Client Configuration Endpoint で Client の登録情報にアクセスする呼び出し元を認証するために使用されます。この Access Token は特定の登録済み Client に関連付けられます。

Initial Access Token

Authorization Server が Client Registration Endpoint へのアクセスを許可するために任意で発行する OAuth 2.0 Access Token。この token の内容はサービス固有であり、本仕様の対象外です。Authorization Server がこの token を発行する方法、および Registration Endpoint がこれを検証する方法も本仕様の対象外です。

読者への重要な注意: この節の用語定義は本仕様の規範部分であり、実装に要件を課します。本仕様本文中の "Client Registration Endpoint" のような先頭大文字の語は、ここで定義された用語を参照します。読者はそれらに遭遇した場合、この節の定義に従わなければなりません。

2. Client Metadata

Client は Authorization Server 上で一意な client_id に紐づく Metadata を持ちます。これには、Client 名のような人間向け表示文字列から、有効な redirect_uri 一覧のようにプロトコルのセキュリティへ影響する項目まで含まれます。

Client Metadata の値は次の 2 つの方法で使用されます。

登録リクエストの入力値として
登録レスポンスおよび読み取りレスポンスの出力値として

OpenID Connect で使用される Client Metadata 値は以下です。

redirect_uris

REQUIRED。Client が使用する Redirection URI 値の配列。登録された Redirection URI 値のうち 1 つは、各 Authorization Request で使われる redirect_uri パラメータ値と完全一致しなければなりません。一致判定は RFC3986 Section 6.2.1 の Simple String Comparison で行います。

response_types

OPTIONAL。Client が使用を制限することを宣言する OAuth 2.0 response_type 値の一覧を含む JSON 配列。省略時のデフォルトは、Client が code Response Type のみを使用することです。

grant_types

OPTIONAL。Client が使用を制限することを宣言する OAuth 2.0 Grant Type の一覧を含む JSON 配列。OpenID Connect で使用する Grant Type 値は以下です。

authorization_code: OAuth 2.0 Section 4.1 の Authorization Code Grant Type

implicit: OAuth 2.0 Section 4.2 の Implicit Grant Type

refresh_token: OAuth 2.0 Section 6 の Refresh Token Grant Type

Client が使用する response_type 値と、登録済み grant_types リストに含めるべき grant_type 値の対応は以下です。

code: authorization_code

id_token: implicit

id_token token: implicit

code id_token: authorization_code, implicit

code token: authorization_code, implicit

code id_token token: authorization_code, implicit

省略時のデフォルトは、Client が authorization_code Grant Type のみを使用することです。

application_type

OPTIONAL。アプリケーション種別。省略時のデフォルトは web です。定義済み値は native または web です。OAuth Implicit Grant Type を使用する Web Client は、redirect_uris として https スキームの URL のみを登録しなければならず、hostname に localhost を使用してはなりません。Native Client は、カスタム URI スキーム、または http スキームのループバック URL のみを redirect_uris として登録しなければなりません。ループバック URL の hostname は localhost、127.0.0.1、[::1] のいずれかです。Authorization Server は Native Client に追加制約を課してよく、Native Client のループバック以外の http スキーム Redirection URI を拒否してよいです。Authorization Server は、登録された全 redirect_uris がこれら制約を満たすことを検証しなければなりません。これは異なる種類の Client 間で client_id が共有されることを防ぎます。

contacts

OPTIONAL。この Client の責任者のメールアドレス配列。一部の Provider では、Web UI から Client 情報を変更できるようにする目的で使用される場合があります。

client_name

OPTIONAL。End-User に提示する Client 名。必要に応じて、異なる言語・スクリプトでの表現は Section 2.1 で定義する方法で表します。

logo_uri

OPTIONAL。Client アプリケーションのロゴを参照する URL。存在する場合、サーバーは承認時にこの画像を End-User に表示すべきです。このフィールド値は有効な画像ファイルを指さなければなりません。必要に応じて、異なる言語・スクリプトでの表現は Section 2.1 の方法で表します。

client_uri

OPTIONAL。Client のホームページ URL。このフィールド値は有効な Web ページを指さなければなりません。存在する場合、サーバーは End-User が辿れる形でこの URL を表示すべきです。必要に応じて、異なる言語・スクリプトでの表現は Section 2.1 の方法で表します。

policy_uri

OPTIONAL。Relying Party Client が End-User に提供する、プロフィールデータの利用方法を説明する URL。このフィールド値は有効な Web ページを指さなければなりません。与えられた場合、OpenID Provider はこの URL を End-User に表示すべきです。必要に応じて、異なる言語・スクリプトでの表現は Section 2.1 の方法で表します。

tos_uri

OPTIONAL。Relying Party の利用規約を End-User が参照するために Relying Party Client が提供する URL。このフィールド値は有効な Web ページを指さなければなりません。与えられた場合、OpenID Provider はこの URL を End-User に表示すべきです。必要に応じて、異なる言語・スクリプトでの表現は Section 2.1 の方法で表します。

jwks_uri

OPTIONAL。Client の JWK Set [JWK] ドキュメントの URL。https スキームを使用しなければなりません。Client が Server へ送るリクエストに署名する場合、Server がその署名を検証するための署名鍵を含みます。JWK Set には、Server が Client 向けレスポンスを暗号化するために使う暗号鍵を含めてもかまいません。署名鍵と暗号鍵の両方を公開する場合、参照先 JWK Set 内のすべての鍵に use（public key use）値を必須とし、用途を明示しなければなりません。同じ鍵を署名と暗号化の両方に使えるアルゴリズムもありますが、セキュリティ上推奨されません。JWK の x5c パラメータを用いて鍵の X.509 表現を提供してもかまいませんが、その場合でも生の鍵値は存在しなければならず、証明書中の値と一致しなければなりません。JWK Set に private key や symmetric key の値を含めてはなりません。

jwks

OPTIONAL。Client の JWK Set [JWK] ドキュメントを値渡しで指定します。jwks_uri と意味は同じですが、参照ではなく値そのものを渡します。このパラメータは、例えば native application のように JWK Set 内容をホストする場所を持てず、jwks_uri を使えない Client 向けです。Client が jwks_uri を使える場合、jwks を使ってはなりません。jwks の大きな欠点として、鍵ローテーションを実現できません（jwks_uri は OpenID Connect Core 1.0 Section 10 の方法で実現可能）。jwks_uri と jwks を同時使用してはなりません。JWK Set に private key や symmetric key の値を含めてはなりません。

sector_identifier_uri

OPTIONAL。OP が Pseudonymous Identifier を計算する際に使用する https URL。redirect_uri 値の JSON 配列を 1 つだけ含むファイルを参照します。Section 5 を参照してください。pairwise sub 値を使う Provider は、pairwise identifier の Subject Identifier 計算に提供された sector_identifier_uri 値を利用すべきです。

subject_type

OPTIONAL。この Client 向けレスポンスで要求される subject_type。Discovery パラメータ subject_types_supported は OP が対応する subject_type 値一覧を含みます。有効値は pairwise と public です。

id_token_signed_response_alg

OPTIONAL。この Client に発行する ID Token の署名に必要な JWS alg アルゴリズム [JWA]。Client が Authorization Endpoint から ID Token を返さない Response Type のみを使用する場合（Authorization Code Flow のみ使用する場合など）を除き、none を ID Token alg として使ってはなりません。省略時デフォルトは RS256。署名検証に使う公開鍵は、OpenID Connect Discovery 1.0 [OpenID.Discovery] の jwks_uri 要素が参照する JWK Set を取得して得ます。

id_token_encrypted_response_alg

OPTIONAL。この Client に発行する ID Token の暗号化に必要な JWE alg アルゴリズム [JWA]。これを要求した場合、レスポンスは署名後に暗号化され、結果は Nested JWT（[JWT] 定義）になります。省略時デフォルトは暗号化なしです。

id_token_encrypted_response_enc

OPTIONAL。この Client に発行する ID Token の暗号化に必要な JWE enc アルゴリズム [JWA]。id_token_encrypted_response_alg が指定された場合、デフォルト値は A128CBC-HS256。id_token_encrypted_response_enc を含める場合、id_token_encrypted_response_alg も提供しなければなりません。

userinfo_signed_response_alg

OPTIONAL。UserInfo Response の署名に必要な JWS alg アルゴリズム [JWA]。指定した場合、レスポンスは [JWT] 形式でシリアライズされ、JWS で署名されます。省略時デフォルトでは、UserInfo Response は UTF-8 [RFC3629] エンコードの JSON object（application/json）として Claims を返します。

userinfo_encrypted_response_alg

OPTIONAL。UserInfo Response の暗号化に必要な JWE alg アルゴリズム [JWA]。署名と暗号化の両方が要求された場合、レスポンスは署名後に暗号化され、Nested JWT になります。省略時デフォルトは暗号化なしです。

userinfo_encrypted_response_enc

OPTIONAL。UserInfo Response の暗号化に必要な JWE enc アルゴリズム [JWA]。userinfo_encrypted_response_alg が指定された場合のデフォルト値は A128CBC-HS256。userinfo_encrypted_response_enc を含める場合、userinfo_encrypted_response_alg も提供しなければなりません。

request_object_signing_alg

OPTIONAL。OP へ送る Request Object の署名に使用しなければならない JWS alg アルゴリズム [JWA]。この Client からの Request Object がこのアルゴリズムで署名されていなければ、すべて拒否しなければなりません。Request Object は OpenID Connect Core 1.0 Section 6.1 で説明されています。このアルゴリズムは Request Object を値渡し（request）する場合にも参照渡し（request_uri）する場合にも使用しなければなりません。Server は RS256 をサポートすべきです。none を使ってもかまいません。省略時デフォルトでは、OP と RP がサポートする任意のアルゴリズムを使えます。

request_object_encryption_alg

OPTIONAL。RP が OP へ送る Request Object の暗号化に使用する可能性があると宣言する JWE alg アルゴリズム [JWA]。対称暗号を使用する場合はこのパラメータを含めるべきです。これにより、通常は返されない可能性のある client_secret 値（対称鍵導出元）が必要であることを OP に示せます。このパラメータがある場合でも、RP は他の対応暗号化アルゴリズムを使用してよく、暗号化しない Request Object を送ってもかまいません。署名と暗号化の両方が要求された場合、Request Object は署名後に暗号化され、Nested JWT になります。省略時デフォルトでは、RP は Request Object を暗号化するかどうかを宣言しません。

request_object_encryption_enc

OPTIONAL。RP が OP へ送る Request Object の暗号化に使用する可能性があると宣言する JWE enc アルゴリズム [JWA]。request_object_encryption_alg が指定された場合、デフォルト値は A128CBC-HS256。request_object_encryption_enc を含める場合、request_object_encryption_alg も提供しなければなりません。

token_endpoint_auth_method

OPTIONAL。Token Endpoint で要求する Client Authentication 方法。選択肢は client_secret_post、client_secret_basic、client_secret_jwt、private_key_jwt、none です（OpenID Connect Core 1.0 Section 9）。拡張で他の認証方式を定義してもかまいません。省略時のデフォルトは client_secret_basic（OAuth 2.0 Section 2.3.1 の HTTP Basic 認証方式）です。

token_endpoint_auth_signing_alg

OPTIONAL。private_key_jwt および client_secret_jwt 認証方式で、Token Endpoint での Client 認証に使う JWT [JWT] 署名に使用しなければならない JWS alg アルゴリズム [JWA]。この Client からこれら認証方式で送られる Token Request は、JWT がこのアルゴリズムで署名されていなければすべて拒否しなければなりません。Server は RS256 をサポートすべきです。none は使用してはなりません。省略時デフォルトでは、OP と RP がサポートする任意のアルゴリズムを使えます。

default_max_age

OPTIONAL。Default Maximum Authentication Age。指定秒数より前に End-User が認証されている場合、End-User を能動的に再認証しなければならないことを示します。max_age リクエストパラメータはこのデフォルト値を上書きします。省略時はデフォルト値未指定です。

require_auth_time

OPTIONAL。ID Token 内の auth_time Claim が REQUIRED かどうかを示す boolean。true の場合は REQUIRED です（false の場合でも OpenID Connect Core 1.0 Section 5.5.1 の claims パラメータで個別 Claim として動的要求は可能）。省略時デフォルトは false です。

default_acr_values

OPTIONAL。デフォルト要求 Authentication Context Class Reference 値。Client からのリクエスト処理で OP に使用を要求する既定 acr 値の文字列配列（優先順）。実施された認証で満たされた Authentication Context Class は、発行された ID Token の acr Claim 値として返されます。このパラメータによる acr Claim 要求は Voluntary Claim です。Discovery 要素 acr_values_supported は OP が対応する acr 値一覧を含みます。acr_values リクエストパラメータまたは個別 acr Claim 要求がある場合、これらデフォルト値を上書きします。

initiate_login_uri

OPTIONAL。第三者が RP によるログインを開始するために使える https URI（OpenID Connect Core 1.0 Section 4）。この URI は GET と POST の両方を受け付けなければなりません。Client は login_hint と iss パラメータを理解し、target_link_uri パラメータをサポートすべきです。

request_uris

OPTIONAL。RP が OP で使用するため事前登録する request_uri 値の配列。これら URL は、対象 Request Object が OP により検証可能な方法で署名される場合を除き、https を使用しなければなりません。Server はこれら URI が参照するファイル内容をキャッシュし、実リクエスト時に再取得しなくてもかまいません。OP は Discovery パラメータ require_request_uri_registration により、使用する request_uri 値の事前登録を要求できます。

request ファイルの内容が将来変わり得る場合、これら URI 値は URI フラグメントとして、その URI が参照するファイル内容の base64url エンコード済み SHA-256 ハッシュ値を含むべきです。URI のフラグメント値が変わった場合、Server に対し旧フラグメント値付き URI のキャッシュが無効になったことを示します。

追加の Client Metadata パラメータを使用してもかまいません。一部は他仕様（例: OpenID Connect RP-Initiated Logout 1.0 [OpenID.RPInitiated]）で定義されています。

2.1. Metadata Languages and Scripts

人間可読な Client Metadata 値、および人間可読値を参照する Client Metadata 値は、複数の言語とスクリプトで表現してもかまいません。例えば client_name、tos_uri、policy_uri、logo_uri、client_uri のような値は、Client 登録によってはロケール別の複数値を持つ場合があります。

言語とスクリプトを指定するために、BCP47 [RFC5646] の言語タグを # 文字区切りで Client Metadata メンバー名へ追加します。Client Metadata の言語・スクリプト表現には、OpenID Connect Core 1.0 Section 5.2（Claims Languages and Scripts）で Claims に使うのと同じ構文を使用します。

この種の人間可読フィールドが言語タグなしで送信された場合、それを利用する当事者は文字列値の言語、文字集合、スクリプトを仮定してはならず、UI で表示する際は文字列値をそのまま使用しなければなりません。相互運用性を高めるため、言語タグなしで送る人間可読フィールドには、幅広いシステムで表示に適した値を入れることを推奨します。

3. Client Registration Endpoint

Client Registration Endpoint は、新規 Client 登録を要求できる OAuth 2.0 Protected Resource です。OpenID Provider は、認可済み Client または開発者だけに登録要求を制限するため、帯域外（本仕様の対象外）で払い出した Initial Access Token を要求してもかまいません。Client Registration Endpoint は、JavaScript Client やその他 Browser-Based Client がアクセスできるよう、CORS および/または適切な他手段をサポートすべきです。

オープンな Dynamic Registration をサポートするため、Client Registration Endpoint は OAuth 2.0 Access Token なしの登録要求を受け付けるべきです。これら要求には、Client Registration Endpoint への DoS 攻撃防止のため、レート制限などの制限を課してもかまいません。Client 登録に Initial Access Token が必要な場合、Client Registration Endpoint は OAuth 2.0 Bearer Token Usage [RFC6750] に記載の方法でこれら Access Token を受け付けられなければなりません。

3.1. Client Registration Request

Authorization Server で新しい Client を登録するため、Client は Client Registration Endpoint へ HTTP POST を送り、登録時に自身で指定する Client Metadata パラメータを含めます。Authorization Server はこの Client に一意の client_id を割り当て、必要に応じて client_secret を割り当て、要求で与えられた Metadata をその client_id に関連付けます。Authorization Server は Client Metadata で省略された項目にデフォルト値を設定してもかまいません。

Client は、ルート JSON object のトップレベルメンバーとしてパラメータを表現した application/json の HTTP POST を Client Registration Endpoint へ送ります。

以下は規範ではない登録リクエスト例です（表示のため値内で改行しています）。

POST /connect/register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.eyJ ...

{
 "application_type": "web",
 "redirect_uris":
   ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example",
 "client_name#ja-Jpan-JP":
   "クライアント名",
 "logo_uri": "https://client.example.org/logo.png",
 "subject_type": "pairwise",
 "sector_identifier_uri":
   "https://other.example.net/file_of_redirect_uris.json",
 "token_endpoint_auth_method": "client_secret_basic",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "userinfo_encrypted_response_alg": "RSA-OAEP-256",
 "userinfo_encrypted_response_enc": "A128CBC-HS256",
 "contacts": ["ve7jtb@example.org", "mary@example.org"],
 "request_uris":
   ["https://client.example.org/rf.txt
     #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
}

3.2. Client Registration Response

登録成功時、Client Registration Endpoint は新しく作成された client_id と、該当する場合は client_secret を返します。加えて、Authorization Server 自身が設定したフィールドを含む、この Client に関するすべての登録済み Metadata を返します。Authorization Server は、redirect_uris を除き、Client が要求したフィールド値を拒否または置換して適切な値に差し替えてもかまいません。その場合、Authorization Server はそのフィールドをレスポンスへ含めなければなりません。Authorization Server は Client 提供値を無視してもかまわず、理解できないフィールドは必ず無視しなければなりません。

レスポンスには、生成された Client 登録に対する後続操作で Client が使える Registration Access Token を含めてもかまいません。

成功レスポンスは HTTP 201 Created を使用し、以下のフィールドと Client Metadata パラメータをルート JSON object のトップレベルメンバーとして含む application/json の JSON 文書を返すべきです。

client_id

REQUIRED。一意な Client Identifier。現在有効な他の登録済み Client に割り当てられていてはなりません。

client_secret

OPTIONAL。Client Secret。同一の Client Secret 値を複数 Client に割り当ててはなりません。この値は、Confidential client が Token Endpoint で認証するため（OAuth 2.0 Section 2.3.1）、および対称暗号鍵値の導出（OpenID Connect Core 1.0 Section 10.2）のために使用されます。token_endpoint_auth_method が private_key_jwt の Client では、対称暗号を使わない限り不要です。

registration_access_token

OPTIONAL。Client Configuration Endpoint で Client 登録に対する後続操作に使用できる Registration Access Token。

registration_client_uri

OPTIONAL。Registration Access Token を使って後続操作を行う Client Configuration Endpoint の場所。https スキームを使用しなければなりません。実装は、Client Configuration Endpoint と Registration Access Token の両方を返すか、どちらも返さないかのいずれかにしなければなりません。

client_id_issued_at

OPTIONAL。Client Identifier を発行した時刻。UTC 基準の 1970-01-01T00:00:00Z から当該日時までの秒数を表す JSON number です。

client_secret_expires_at

client_secret が発行される場合 REQUIRED。client_secret の失効時刻、または失効しない場合は 0。値は UTC 基準の 1970-01-01T00:00:00Z から当該日時までの秒数を表す JSON number です。

以下は規範ではない登録レスポンス例です（表示のため値内で改行しています）。

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store

{
 "client_id": "s6BhdRkqt3",
 "client_secret":
   "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
 "client_secret_expires_at": 1577858400,
 "registration_access_token":
   "this.is.an.access.token.value.ffx83",
 "registration_client_uri":
   "https://server.example.com/connect/register?client_id=s6BhdRkqt3",
 "token_endpoint_auth_method":
   "client_secret_basic",
 "application_type": "web",
 "redirect_uris":
   ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example",
 "client_name#ja-Jpan-JP":
   "クライアント名",
 "logo_uri": "https://client.example.org/logo.png",
 "subject_type": "pairwise",
 "sector_identifier_uri":
   "https://other.example.net/file_of_redirect_uris.json",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "userinfo_encrypted_response_alg": "RSA-OAEP-256",
 "userinfo_encrypted_response_enc": "A128CBC-HS256",
 "contacts": ["ve7jtb@example.org", "mary@example.org"],
 "request_uris":
   ["https://client.example.org/rf.txt
     #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
}

3.3. Client Registration Error Response

OAuth エラー条件が発生した場合、Client Registration Endpoint は OAuth 2.0 Bearer Token Usage [RFC6750] Section 3 で定義された Error Response を返します。

登録エラー条件が発生した場合、Client Registration Endpoint はレスポンス本文にエラー内容を記述した JSON object を含め、HTTP 400 Bad Request を返します。

エラーを記述する JSON object は 2 つのメンバーを含みます。

error

エラーコード。

error_description

デバッグ用の追加エラー説明テキスト。

他のメンバーを使用してもかまいません。

本仕様は以下のエラーコードを定義します。

invalid_redirect_uri

1 つ以上の redirect_uris 値が不正。

invalid_client_metadata

Client Metadata フィールドのいずれかの値が不正であり、サーバーがこのリクエストを拒否した。Authorization Server は Client Metadata の要求値について、有効値へ置き換える選択をしてもかまわないことに注意してください。

他のエラーコードを使用してもかまいません。

以下は規範ではないエラーレスポンス例です。

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
 "error": "invalid_redirect_uri",
 "error_description": "One or more redirect_uri values are invalid"
}

4. Client Configuration Endpoint

Client Configuration Endpoint は OAuth 2.0 Protected Resource であり、特定の Client が登録情報を参照・更新できるよう、サーバーが用意してもかまいません。Client はこの endpoint へのすべての呼び出しで Registration Access Token を OAuth 2.0 Bearer Token [RFC6750] として使用しなければなりません。JavaScript Client やその他 Browser-Based Client がアクセスできるよう、Client Configuration Endpoint は CORS および/または適切な他手段をサポートすべきです。

この endpoint の操作は HTTP メソッド [RFC7231] の違いで切り替えます。本仕様がこの endpoint で定義する利用可能メソッドは HTTP GET のみです。

4.1. Forming the Client Configuration Endpoint URL

Client の初期登録で Client Configuration Endpoint と Registration Access Token が返る場合、Authorization Server は Client Registration Response の registration_client_uri 要素で完全修飾 URL を Client へ提供しなければなりません（Section 3.2）。Authorization Server は、Client がこの URL を自力で構築または発見することを期待してはなりません。Client はサーバー提供の URL をそのまま使わなければならず、要素を組み立てて URL を構築してはなりません。

デプロイ特性によって、Client Configuration Endpoint URL の形は様々です。Client Registration Endpoint の URL と発行済み client_id をサーバーが結合して生成した URL 文字列（後者を path parameter または query parameter とする）を使うことを推奨します。例えば client_id が s6BhdRkqt3 の Client に https://server.example.com/register/s6BhdRkqt3（path parameter）または https://server.example.com/register?client_id=s6BhdRkqt3（query parameter）を渡せます。いずれの場合も Client は与えられた URL をそのまま使用します。

これら一般的パターンは、Server がリクエスト対象 Client を容易に特定するのに役立ちます。特定した Client は Registration Access Token 発行先 Client と一致しなければなりません。必要に応じて Server は、Client Registration Endpoint URL をそのまま Client Configuration Endpoint URL として返し、Registration Access Token が提供する認証コンテキストに応じて挙動を変えてもかまいません。

4.2. Client Read Request

Client の初期登録で Client Configuration Endpoint と Registration Access Token が返っている場合、Authorization Server 上の Client 現在設定は、Registration Access Token を伴う HTTP GET を Client Configuration Endpoint に送ることで読み取れます。この操作は idempotent であるべきで、Client 設定の変更を起こすべきではありません。

以下は規範ではない読み取りリクエスト例です。

GET /connect/register?client_id=s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer this.is.an.access.token.value.ffx83

4.3. Client Read Response

読み取り操作が成功した場合、Authorization Server は Authorization Server 自身が設定したフィールドを含む、この Client のすべての登録済み Metadata を返すべきです。client_secret など一部値は初期登録後に更新されている場合があります。更新機構は本仕様の対象外です。ただし Read 操作は idempotent を意図しているため、Client Read Request 自体が Client 登録 Metadata 値の変更を引き起こすべきではありません。

registration_access_token または registration_client_uri が更新されていない限り、Authorization Server はこのレスポンスにそれらを含める必要はありません。

成功レスポンスは HTTP 200 OK を使用し、Client Metadata 値をルート JSON object のトップレベルメンバーとして含む application/json の JSON 文書を返すべきです。

以下は規範ではない読み取りレスポンス例です（表示のため値内で改行しています）。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
 "client_id": "s6BhdRkqt3",
 "client_secret":
   "OylyaC56ijpAQ7G5ZZGL7MMQ6Ap6mEeuhSTFVps2N4Q",
 "client_secret_expires_at": 17514165600,
 "registration_client_uri":
   "https://server.example.com/connect/register?client_id=s6BhdRkqt3",
 "token_endpoint_auth_method":
   "client_secret_basic",
 "application_type": "web",
 "redirect_uris":
   ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example",
 "client_name#ja-Jpan-JP":
   "クライアント名",
 "logo_uri": "https://client.example.org/logo.png",
 "subject_type": "pairwise",
 "sector_identifier_uri":
   "https://other.example.net/file_of_redirect_uris.json",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "userinfo_encrypted_response_alg": "RSA-OAEP-256",
 "userinfo_encrypted_response_enc": "A128CBC-HS256",
 "contacts": ["ve7jtb@example.org", "mary@example.org"],
 "request_uris":
   ["https://client.example.org/rf.txt
     #qpXaRLh_n93TTR9F252ValdatUQvQiJi5BDub2BeznA"]
}

4.4. Client Read Error Response

このリクエストに使われた Registration Access Token が無効な場合、サーバーは OAuth Bearer Token Usage [RFC6750] に従ってエラー応答しなければなりません。

Client がサーバー上に存在しない、Client が無効、または Registration Access Token が無効な場合、サーバーは HTTP 401 Unauthorized を返さなければなりません。Client にレコード読み取り権限がない場合、サーバーは HTTP 403 Forbidden を返さなければなりません。総当たり攻撃の抑止というセキュリティ上の理由から、endpoint は HTTP 404 Not Found を返してはなりません。

以下は規範ではないエラーレスポンス例です。

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token",
  error_description="The access token expired"
Cache-Control: no-store

5. "sector_identifier_uri" Validation

sector identifier list は、OpenID Connect Core 1.0 Section 8.1 で説明されるとおり、単一管理下の Web サイト群に対してドメイン名に依存しない一貫した pairwise sub 値を提供する方法です。また、Client が全ユーザー再登録なしに redirect_uri ドメインを変更する手段も提供します。

sector_identifier_uri の値は、redirect_uri 値配列を含む JSON ファイルを参照する https URL でなければなりません。redirect_uris に登録された値はこの配列要素に含まれていなければならず、含まれない場合登録は失敗しなければなりません。これは登録時に検証しなければなりません。OP がこの JSON ファイル内容を保持したり、将来再取得・再検証したりする要件はありません。

以下は規範ではない sector_identifier_uri への要求と応答例です。

GET /file_of_redirect_uris.json HTTP/1.1
Accept: application/json
Host: other.example.net

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

[ "https://client.example.org/callback",
  "https://client.example.org/callback2",
  "https://client.other_company.example.net/callback" ]

6. String Operations

一部 OpenID Connect メッセージの処理では、メッセージ中の値を既知値と比較する必要があります。例えば Client 登録レスポンスのメンバー名を client_id など特定メンバー名と比較する場合です。ただし Unicode [UNICODE] 文字列の比較には重大なセキュリティ上の含意があります。

そのため JSON 文字列と他の Unicode 文字列の比較は次のように実施しなければなりません。

JSON で適用されたエスケープを除去し、Unicode code point 配列を生成する。
Unicode Normalization [USA15] を JSON 文字列にも比較対象文字列にも、いかなる時点でも適用してはならない。
2 つの文字列比較は Unicode code point 単位の等価比較として実行しなければならない。

7. Validation

本仕様で定義された検証手順のいずれかが失敗した場合、正しく検証できなかった情報を必要とする処理はすべて中止しなければならず、検証失敗した情報を使用してはなりません。

8. Implementation Considerations

本仕様は、Dynamic Client Registration を実装することを選択した Relying Party と OpenID Provider の両方で使われる機能を定義します。これら Relying Party と OpenID Provider は、本仕様で "REQUIRED" と記載された機能、または "MUST" で説明された機能を実装しなければなりません。

本仕様は OAuth 2.0 Dynamic Client Registration Protocol [RFC7591] と互換です。実装は、ユースケース促進のために software_statement など RFC7591 で定義される追加 Client Metadata 値を使用してもかまいません。Update など OAuth 2.0 Dynamic Client Registration Management Protocol [RFC7592] が定義する追加操作をサポートしたい実装は、その仕様を利用できますが、当該仕様が実験的であることに注意が必要です。

8.1. Compatibility Notes

注: 本仕様の初版で記載されていた潜在的な互換性問題は、その後対処済みです。

8.2. Implementation Notes on Stateless Dynamic Client Registration

一部デプロイでは、Authorization Server が Client 状態を保存しなくても、Client が Authorization Server とやり取りするために必要な情報（client_id など）を取得できるようにすることが有利です。本仕様で定義するインターフェースは stateless dynamic client registration に利用できます。

その実現手段の 1 つは、Client の初期登録で返す client_id 値に、Client に関する必要な登録情報をエンコードすることです。これにより情報保持主体は Authorization Server ではなく Client になります。具体的なエンコード方式は Authorization Server ごとに異なります。

Authorization Server が stateless dynamic client registration を使う場合、Registration Access Token 発行に Client ごとの状態が必要になる可能性があるため、Read 操作はできないことが多くなります。その場合、Client 初期登録で Client Configuration Endpoint や Registration Access Token は返されません。

9. Security Considerations

Client Registration Endpoint へのリクエストでは平文資格情報（HTTP リクエスト/レスポンス内）が送信されるため、Registration Endpoint との通信はすべて TLS を使用しなければなりません。TLS 利用の詳細は Section 9.3 を参照してください。

9.1. Impersonation

悪意ある RP が、なりすまそうとしている正当 RP のロゴを使う可能性があります。ロゴによりユーザーが正当 RP にログインしていると誤認する恐れがあるため、OP はこのフィッシングリスクを軽減する対策を講じる必要があります。例えば、ロゴのドメイン/サイトが登録済み Redirection URI のドメイン/サイトと一致しない場合に警告できます。また、特に動的登録され、OP 上でこれまでにユーザーから信頼されておらず、ロゴ機能を使おうとする RP には、一般的に警告を出すことも可能です。

Authorization Server がオープンな Client 登録をサポートする場合、End-User に表示される Client 提供 URL（例: logo_uri や policy_uri）の扱いには極めて注意が必要です。悪意ある Client は policy_uri に drive-by download を指す参照を含む登録要求を指定する可能性があります。Authorization Server は logo_uri と policy_uri のホストが redirect_uris 配列で定義されるホストと同じかを確認すべきです。

9.2. Native Code Leakage

実装者は、iOS ではカスタム URI スキームを使って native application に情報が返される一方、同じ URI スキームを複数 application が登録可能である点に注意すべきです。この場合、どの application が情報を受け取るかは決定的ではありません。結果として Authorization Code が誤った application へ漏えいする恐れがあります。この問題に対する複数の解決策が提案され、IETF OAuth WG で議論されています。標準解決策が策定されることが期待されており、その時点で OpenID Connect へ適用方法を記述した拡張仕様が公開される可能性があります。

9.3. TLS Requirements

実装は TLS をサポートしなければなりません。実装すべきバージョンは時期により変化し、実装時点での普及状況や既知脆弱性に依存します。実装は BCP 195 [RFC8996] [RFC9325] のガイダンスに従うべきです。これらは TLS を使う配備済みサービスのセキュリティ向上に関する推奨事項と要件を提供します。

情報漏えいと改ざんを防ぐため、機密性と完全性を提供する cipher suite を用いた TLS による機密性保護を適用しなければなりません。

TLS を使う場合は常に RFC6125 [RFC6125] に従って TLS サーバー証明書検証を実施しなければなりません。

10. IANA Considerations

10.1. OAuth Dynamic Client Registration Metadata Registration

本仕様は、RFC7591 で確立された IANA "OAuth Dynamic Client Registration Metadata" レジストリ [IANA.OAuth.Parameters] に、次の client metadata 定義を登録します。

10.1.1. Registry Contents

Client Metadata Name: application_type
Client Metadata Description: アプリケーション種別（"native" または "web"）
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: sector_identifier_uri
Client Metadata Description: OP が Pseudonymous Identifier 計算に用いる https URL
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: subject_type
Client Metadata Description: この Client 向けレスポンスで要求される subject_type（"pairwise" または "public"）
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: id_token_signed_response_alg
Client Metadata Description: この Client に発行する ID Token の署名に REQUIRED な JWS alg
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: id_token_encrypted_response_alg
Client Metadata Description: この Client に発行する ID Token の暗号化に REQUIRED な JWE alg
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: id_token_encrypted_response_enc
Client Metadata Description: この Client に発行する ID Token の暗号化に REQUIRED な JWE enc
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: userinfo_signed_response_alg
Client Metadata Description: UserInfo Response の署名に REQUIRED な JWS alg
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: userinfo_encrypted_response_alg
Client Metadata Description: UserInfo Response の暗号化に REQUIRED な JWE alg
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: userinfo_encrypted_response_enc
Client Metadata Description: UserInfo Response の暗号化に REQUIRED な JWE enc
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: request_object_signing_alg
Client Metadata Description: OP に送る Request Object 署名で MUST 使用の JWS alg
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: request_object_encryption_alg
Client Metadata Description: RP が OP に送る Request Object 暗号化に使用し得ると宣言する JWE alg
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: request_object_encryption_enc
Client Metadata Description: RP が OP に送る Request Object 暗号化に使用し得ると宣言する JWE enc
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: token_endpoint_auth_signing_alg
Client Metadata Description: private_key_jwt および client_secret_jwt 方式で Token Endpoint での Client 認証に使う JWT 署名に MUST 使用の JWS alg
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: default_max_age
Client Metadata Description: Default Maximum Authentication Age
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: require_auth_time
Client Metadata Description: ID Token の auth_time Claim が REQUIRED かを示す boolean 値
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: default_acr_values
Client Metadata Description: デフォルトで要求する Authentication Context Class Reference 値
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: initiate_login_uri
Client Metadata Description: 第三者が RP ログイン開始に使用できる https URI
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

Client Metadata Name: request_uris
Client Metadata Description: OP で使用するため RP が事前登録する request_uri 値配列
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): 本仕様 Section 2 (Client Metadata)

10.2. OAuth Token Endpoint Authentication Methods Registration

本仕様は、RFC7591 で確立された IANA "OAuth Token Endpoint Authentication Methods" レジストリ [IANA.OAuth.Parameters] に、次の token endpoint authentication method を登録します。

10.2.1. Registry Contents

Token Endpoint Authentication Method Name: client_secret_jwt
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): OpenID Connect Core 1.0 Section 9 [OpenID.Core]

Token Endpoint Authentication Method Name: private_key_jwt
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net
Specification Document(s): OpenID Connect Core 1.0 Section 9 [OpenID.Core]

11. References

11.1. Normative References

参照	内容
[CORS]	Opera Software ASA, "Cross-Origin Resource Sharing," July 2010.
[IANA.OAuth.Parameters]	IANA, "OAuth Parameters."
[JWA]	Jones, M., "JSON Web Algorithms (JWA)," RFC 7518, May 2015.
[JWE]	Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)," RFC 7516, May 2015.
[JWK]	Jones, M., "JSON Web Key (JWK)," RFC 7517, May 2015.
[JWS]	Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)," RFC 7515, May 2015.
[JWT]	Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)," RFC 7519, May 2015.
[OpenID.Core]	Sakimura, N., et al., "OpenID Connect Core 1.0," December 2023.
[OpenID.Discovery]	Sakimura, N., et al., "OpenID Connect Discovery 1.0," December 2023.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," March 1997.
[RFC3629]	Yergeau, F., "UTF-8, a transformation format of ISO 10646," November 2003.
[RFC3986]	Berners-Lee, T., et al., "Uniform Resource Identifier (URI): Generic Syntax," January 2005.
[RFC5646]	Phillips, A. and M. Davis, "Tags for Identifying Languages," September 2009.
[RFC6125]	Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity ...," March 2011.
[RFC6749]	Hardt, D., "The OAuth 2.0 Authorization Framework," October 2012.
[RFC6750]	Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage," October 2012.
[RFC7231]	Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content," June 2014.
[RFC8259]	Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format," December 2017.
[RFC8996]	Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1," March 2021.
[RFC9325]	Sheffer, Y., et al., "Recommendations for Secure Use of TLS and DTLS," November 2022.
[UNICODE]	The Unicode Consortium, "The Unicode Standard."
[USA15]	Whistler, K., "Unicode Normalization Forms," August 2023.

11.2. Informative References

参照	内容
[OpenID.RPInitiated]	Jones, M., et al., "OpenID Connect RP-Initiated Logout 1.0," September 2022.
[OpenID.Registration.Errata1]	Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1," November 2014.
[OpenID.Registration.Final]	Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 (final)," February 2014.
[RFC7591]	Richer, J., et al., "OAuth 2.0 Dynamic Client Registration Protocol," July 2015.
[RFC7592]	Richer, J., et al., "OAuth 2.0 Dynamic Client Registration Management Protocol," July 2015.

Appendix A. Acknowledgements

OpenID Community は、この仕様への貢献に対して次の方々に感謝します。

Amanda Anganes (aanganes@mitre.org), MITRE

John Bradley (ve7jtb@ve7jtb.com), Yubico (was at Ping Identity)

Brian Campbell (bcampbell@pingidentity.com), Ping Identity

Vladimir Dzhuvinov (vladimir@connect2id.com), Connect2id (was at Nimbus Directory Services)

George Fletcher (gffletch@aol.com), Capital One (was at AOL)

Roland Hedberg (roland@catalogix.se), independent (was at University of Umeå)

Edmund Jay (ejay@mgi1.com), Illumila

Michael B. Jones (michael_b_jones@hotmail.com), Self-Issued Consulting (was at Microsoft)

Torsten Lodderstedt (torsten@lodderstedt.net), independent (was at Deutsche Telekom)

Justin Richer (justin@bspk.io), Bespoke Engineering (was at MITRE)

Nat Sakimura (nat@nat.consulting), NAT.Consulting (was at NRI)

Appendix B. Notices

OpenID Foundation (OIDF) は、あらゆる Contributor、開発者、実装者、その他の関心当事者に対し、この Implementers Draft または Final Specification を複製、派生著作物作成、配布、実演および表示するための非独占的・無償・全世界的著作権ライセンスを付与します。目的は (i) 仕様策定、および (ii) その文書に基づく Implementers Draft と Final Specification の実装に限られます。素材出典として OIDF への帰属表示は必要ですが、その表示は OIDF の支持を意味しません。

この仕様で記述される技術は、OpenID Foundation メンバーを含む様々な提供元からの貢献により利用可能となりました。OpenID Foundation は当該技術が配布可能であることを確保するための措置を講じていますが、この仕様に記述された技術の実装または利用に関して主張され得る知的財産権その他の権利の有効性または範囲について、いかなる立場も取りません。また、そのような権利に基づくライセンス提供可否についても表明しません。さらに、OpenID Foundation がそれら権利を特定する独自調査を行ったことを表明するものでもありません。OpenID Foundation および本仕様への貢献者は、本仕様に関して、商品性、非侵害性、特定目的適合性、権原を含むいかなる保証（明示・黙示その他）も行わず、ここに明示的に否認します。本仕様実装に関する全リスクは実装者が負います。OpenID の知的財産権ポリシーでは、貢献者に対し、他の貢献者および実装者に対して特定の特許クレームを主張しない特許約束の提供を求めています。OpenID Foundation は、本仕様の実施に必要となり得る技術を対象とする著作権、特許、特許出願その他の専有権について、関係情報の連絡を歓迎します。

Authors' Addresses

	Nat Sakimura
	NAT.Consulting
Email:	nat@nat.consulting
URI:	https://nat.sakimura.org/

	John Bradley
	Yubico
Email:	ve7jtb@ve7jtb.com
URI:	http://www.thread-safe.com/

	Michael B. Jones
	Self-Issued Consulting
Email:	michael_b_jones@hotmail.com
URI:	https://self-issued.info/