OAuth 2.0 Device Authorization Grant

Abstract

概要

The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.

OAuth 2.0 デバイス認可グラントは、ユーザーエージェントベースの認可を行うためのブラウザを持たないか、あるいは認可フロー中の認証のためにユーザーにテキスト入力を求めることが非現実的なほど入力が制約された、インターネット接続デバイス向けに設計されている。これにより、そのようなデバイス (スマート TV、メディアコンソール、デジタルフォトフレーム、プリンターなど) 上の OAuth クライアントが、別のデバイス上のユーザーエージェントを使って、保護されたリソースにアクセスするためのユーザー認可を取得できるようになる。

1.Introduction

1.はじめに

This OAuth 2.0 [RFC6749] protocol extension enables OAuth clients to request user authorization from applications on devices that have limited input capabilities or lack a suitable browser. Such devices include smart TVs, media consoles, picture frames, and printers, which lack an easy input method or a suitable browser required for traditional OAuth interactions. The authorization flow defined by this specification, sometimes referred to as the "device flow", instructs the user to review the authorization request on a secondary device, such as a smartphone, which does have the requisite input and browser capabilities to complete the user interaction.

この OAuth 2.0 [RFC6749] プロトコル拡張は、入力能力が限られているか適切なブラウザを持たないデバイス上のアプリケーションから、OAuth クライアントがユーザー認可を要求できるようにするものである。そのようなデバイスには、スマート TV、メディアコンソール、フォトフレーム、プリンターなどがあり、従来の OAuth のやり取りに必要な簡便な入力方法や適切なブラウザを欠いている。本仕様で定義する認可フローは「デバイスフロー」と呼ばれることもあり、ユーザーに対して、ユーザー操作を完了するのに必要な入力機能とブラウザ機能を備えたスマートフォンなどの副次的なデバイス上で認可リクエストを確認するよう指示する。

The device authorization grant is not intended to replace browser- based OAuth in native apps on capable devices like smartphones. Those apps should follow the practices specified in "OAuth 2.0 for Native Apps" [RFC8252].

デバイス認可グラントは、スマートフォンのような十分な能力を持つデバイス上のネイティブアプリにおけるブラウザベースの OAuth を置き換えることを意図したものではない。そうしたアプリは「OAuth 2.0 for Native Apps」[RFC8252] で規定されたプラクティスに従うべきである。

The operating requirements for using this authorization grant type are:

この認可グラントタイプを使用するための動作要件は次のとおりである。

(1) The device is already connected to the Internet.

(1) デバイスがすでにインターネットに接続されている。

(2) The device is able to make outbound HTTPS requests.

(2) デバイスが外向きの HTTPS リクエストを行える。

(3) The device is able to display or otherwise communicate a URI and code sequence to the user.

(3) デバイスが URI とコードの並びをユーザーに表示するか、または他の方法で伝えられる。

(4) The user has a secondary device (e.g., personal computer or smartphone) from which they can process the request.

(4) ユーザーが、リクエストを処理できる副次的なデバイス (例: パーソナルコンピューターやスマートフォン) を持っている。

As the device authorization grant does not require two-way communication between the OAuth client on the device and the user agent (unlike other OAuth 2 grant types, such as the authorization code and implicit grant types), it supports several use cases that cannot be served by those other approaches.

デバイス認可グラントは、デバイス上の OAuth クライアントとユーザーエージェントとの間の双方向通信を必要としないため (認可コードグラントやインプリシットグラントといった他の OAuth 2 グラントタイプとは異なる)、それら他の方式では対応できないいくつかのユースケースをサポートする。

Instead of interacting directly with the end user's user agent (i.e., browser), the device client instructs the end user to use another computer or device and connect to the authorization server to approve the access request. Since the protocol supports clients that can't receive incoming requests, clients poll the authorization server repeatedly until the end user completes the approval process.

デバイスクライアントは、エンドユーザーのユーザーエージェント (すなわちブラウザ) と直接やり取りする代わりに、エンドユーザーに対して別のコンピューターやデバイスを使って認可サーバーに接続し、アクセスリクエストを承認するよう指示する。このプロトコルは着信リクエストを受け取れないクライアントをサポートするため、クライアントはエンドユーザーが承認プロセスを完了するまで認可サーバーを繰り返しポーリングする。

The device client typically chooses the set of authorization servers to support (i.e., its own authorization server or those of providers with which it has relationships). It is common for the device client to support only one authorization server, such as in the case of a TV application for a specific media provider that supports only that media provider's authorization server. The user may not yet have an established relationship with that authorization provider, though one can potentially be set up during the authorization flow.

デバイスクライアントは通常、サポートする認可サーバーの集合を自ら選択する (すなわち、自身の認可サーバーか、関係を持つプロバイダーの認可サーバー)。特定のメディアプロバイダー向けの TV アプリケーションがそのメディアプロバイダーの認可サーバーだけをサポートする場合のように、デバイスクライアントが 1 つの認可サーバーだけをサポートすることはよくある。ユーザーはその認可プロバイダーとの関係をまだ確立していないかもしれないが、認可フローの中で関係を構築できる可能性もある。

The device authorization flow illustrated in Figure 1 includes the following steps:

図 1 に示すデバイス認可フローは、次のステップから成る。

2.Terminology

2.用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" および "OPTIONAL" は、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] の記述に従って解釈する。

3.Protocol

3.プロトコル

3.1.Device Authorization Request

3.1.デバイス認可リクエスト

This specification defines a new OAuth endpoint: the device authorization endpoint. This is separate from the OAuth authorization endpoint defined in [RFC6749] with which the user interacts via a user agent (i.e., a browser). By comparison, when using the device authorization endpoint, the OAuth client on the device interacts with the authorization server directly without presenting the request in a user agent, and the end user authorizes the request on a separate device. This interaction is defined as follows.

本仕様は新しい OAuth エンドポイントであるデバイス認可エンドポイントを定義する。これは [RFC6749] で定義され、ユーザーがユーザーエージェント (すなわちブラウザ) を介してやり取りする OAuth 認可エンドポイントとは別のものである。対照的に、デバイス認可エンドポイントを使用する場合、デバイス上の OAuth クライアントはリクエストをユーザーエージェントに提示することなく認可サーバーと直接やり取りし、エンドユーザーは別のデバイス上でリクエストを認可する。このやり取りは次のように定義される。

The client initiates the authorization flow by requesting a set of verification codes from the authorization server by making an HTTP "POST" request to the device authorization endpoint.

クライアントは、デバイス認可エンドポイントに HTTP "POST" リクエストを行い、認可サーバーに一組の検証コードを要求することで認可フローを開始する。

The client makes a device authorization request to the device authorization endpoint by including the following parameters using the "application/x-www-form-urlencoded" format, per Appendix B of [RFC6749], with a character encoding of UTF-8 in the HTTP request entity-body:

クライアントは、[RFC6749] の付録 B に従い、HTTP リクエストのエンティティボディに UTF-8 の文字エンコーディングで "application/x-www-form-urlencoded" 形式を用いて次のパラメーターを含めることで、デバイス認可エンドポイントにデバイス認可リクエストを行う。

client_id REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749]. The client identifier as described in Section 2.2 of [RFC6749].

client_id [RFC6749] の 3.2.1 節に記述されるとおりにクライアントが認可サーバーに対して認証を行わない場合は必須 (REQUIRED)。[RFC6749] の 2.2 節に記述されるクライアント識別子。

scope OPTIONAL. The scope of the access request as defined by Section 3.3 of [RFC6749].

scope 任意 (OPTIONAL)。[RFC6749] の 3.3 節で定義されるアクセスリクエストのスコープ。

For example, the client makes the following HTTPS request:

例えば、クライアントは次のような HTTPS リクエストを行う。

All requests from the device MUST use the Transport Layer Security (TLS) protocol [RFC8446] and implement the best practices of BCP 195 [RFC7525].

デバイスからのすべてのリクエストは Transport Layer Security (TLS) プロトコル [RFC8446] を使用し、BCP 195 [RFC7525] のベストプラクティスを実装しなければならない (MUST)。

Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters MUST NOT be included more than once.

値なしで送られたパラメーターは、リクエストから省略されたものとして扱わなければならない (MUST)。認可サーバーは認識できないリクエストパラメーターを無視しなければならない (MUST)。リクエストおよびレスポンスのパラメーターを複数回含めてはならない (MUST NOT)。

The client authentication requirements of Section 3.2.1 of [RFC6749] apply to requests on this endpoint, which means that confidential clients (those that have established client credentials) authenticate in the same manner as when making requests to the token endpoint, and public clients provide the "client_id" parameter to identify themselves.

[RFC6749] の 3.2.1 節のクライアント認証要件はこのエンドポイントへのリクエストにも適用される。つまり、コンフィデンシャルクライアント (クライアントクレデンシャルを確立しているクライアント) はトークンエンドポイントにリクエストを行う場合と同じ方法で認証を行い、パブリッククライアントは自身を識別するために "client_id" パラメーターを提供する。

Due to the polling nature of this protocol (as specified in Section 3.4), care is needed to avoid overloading the capacity of the token endpoint. To avoid unneeded requests on the token endpoint, the client SHOULD only commence a device authorization request when prompted by the user and not automatically, such as when the app starts or when the previous authorization session expires or fails.

このプロトコルはポーリングを行う性質上 (3.4 節で規定)、トークンエンドポイントの処理能力を圧迫しないように注意が必要である。トークンエンドポイントへの不要なリクエストを避けるため、クライアントはユーザーから促された場合にのみデバイス認可リクエストを開始すべきであり (SHOULD)、アプリの起動時や前回の認可セッションの期限切れ・失敗時などに自動的に開始すべきではない。

3.2.Device Authorization Response

3.2.デバイス認可レスポンス

In response, the authorization server generates a unique device verification code and an end-user code that are valid for a limited time and includes them in the HTTP response body using the "application/json" format [RFC8259] with a 200 (OK) status code. The response contains the following parameters:

レスポンスとして、認可サーバーは一意なデバイス検証コードとエンドユーザーコードを生成する。これらは限られた期間だけ有効であり、"application/json" 形式 [RFC8259] を用いて 200 (OK) ステータスコードとともに HTTP レスポンスボディに含められる。レスポンスは次のパラメーターを含む。

device_code REQUIRED. The device verification code.

device_code 必須 (REQUIRED)。デバイス検証コード。

user_code REQUIRED. The end-user verification code.

user_code 必須 (REQUIRED)。エンドユーザー検証コード。

verification_uri REQUIRED. The end-user verification URI on the authorization server. The URI should be short and easy to remember as end users will be asked to manually type it into their user agent.

verification_uri 必須 (REQUIRED)。認可サーバー上のエンドユーザー検証 URI。エンドユーザーはこの URI をユーザーエージェントに手で入力するよう求められるため、URI は短く覚えやすいものであるべきである。

verification_uri_complete OPTIONAL. A verification URI that includes the "user_code" (or other information with the same function as the "user_code"), which is designed for non-textual transmission.

verification_uri_complete 任意 (OPTIONAL)。"user_code" (または "user_code" と同じ機能を持つ他の情報) を含む検証 URI であり、テキスト以外の手段での伝達向けに設計されている。

expires_in REQUIRED. The lifetime in seconds of the "device_code" and "user_code".

expires_in 必須 (REQUIRED)。"device_code" と "user_code" の有効期間 (秒)。

interval OPTIONAL. The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint. If no value is provided, clients MUST use 5 as the default.

interval 任意 (OPTIONAL)。クライアントがトークンエンドポイントへのポーリングリクエストの間に待つべき (SHOULD) 最小時間 (秒)。値が提供されない場合、クライアントはデフォルトとして 5 を使用しなければならない (MUST)。

For example:

例:

In the event of an error (such as an invalidly configured client), the authorization server responds in the same way as the token endpoint specified in Section 5.2 of [RFC6749].

エラーの場合 (クライアントの設定が不正であるなど)、認可サーバーは [RFC6749] の 5.2 節で規定されるトークンエンドポイントと同じ方法で応答する。

3.3.User Interaction

3.3.ユーザー操作

After receiving a successful authorization response, the client displays or otherwise communicates the "user_code" and the "verification_uri" to the end user and instructs them to visit the URI in a user agent on a secondary device (for example, in a browser on their mobile phone) and enter the user code.

成功した認可レスポンスを受け取った後、クライアントは "user_code" と "verification_uri" をエンドユーザーに表示するか、あるいは他の方法で伝え、副次的なデバイス上のユーザーエージェント (例えば携帯電話のブラウザ) でその URI にアクセスしてユーザーコードを入力するよう指示する。

The authorizing user navigates to the "verification_uri" and authenticates with the authorization server in a secure TLS-protected [RFC8446] session. The authorization server prompts the end user to identify the device authorization session by entering the "user_code" provided by the client. The authorization server should then inform the user about the action they are undertaking and ask them to approve or deny the request. Once the user interaction is complete, the server instructs the user to return to their device.

認可を行うユーザーは "verification_uri" に移動し、TLS で保護された安全なセッション [RFC8446] の中で認可サーバーに対して認証する。認可サーバーは、クライアントから提供された "user_code" を入力することでデバイス認可セッションを特定するようエンドユーザーに促す。その後、認可サーバーはユーザーが行おうとしている操作について知らせ、リクエストを承認するか拒否するかを尋ねるべきである。ユーザー操作が完了したら、サーバーはユーザーにデバイスへ戻るよう指示する。

During the user interaction, the device continuously polls the token endpoint with the "device_code", as detailed in Section 3.4, until the user completes the interaction, the code expires, or another error occurs. The "device_code" is not intended for the end user directly; thus, it should not be displayed during the interaction to avoid confusing the end user.

ユーザー操作の間、デバイスは 3.4 節で詳述するとおり "device_code" を用いてトークンエンドポイントを継続的にポーリングし、ユーザーが操作を完了するか、コードが期限切れになるか、別のエラーが発生するまでそれを続ける。"device_code" はエンドユーザーに直接向けたものではないため、エンドユーザーを混乱させないよう、操作中に表示すべきではない。

Authorization servers supporting this specification MUST implement a user-interaction sequence that starts with the user navigating to "verification_uri" and continues with them supplying the "user_code" at some stage during the interaction. Other than that, the exact sequence and implementation of the user interaction is up to the authorization server; for example, the authorization server may enable new users to sign up for an account during the authorization flow or add additional security verification steps.

本仕様をサポートする認可サーバーは、ユーザーが "verification_uri" に移動することから始まり、操作のどこかの段階でユーザーが "user_code" を提供することへと続くユーザー操作シーケンスを実装しなければならない (MUST)。それ以外の点については、ユーザー操作の正確なシーケンスと実装は認可サーバーに委ねられる。例えば、認可サーバーは認可フローの中で新規ユーザーがアカウントを登録できるようにしたり、追加のセキュリティ検証ステップを加えたりしてもよい。

It is NOT RECOMMENDED for authorization servers to include the user code ("user_code") in the verification URI ("verification_uri"), as this increases the length and complexity of the URI that the user must type. While the user must still type a similar number of characters with the "user_code" separated, once they successfully navigate to the "verification_uri", any errors in entering the code can be highlighted by the authorization server to improve the user experience. The next section documents the user interaction with "verification_uri_complete", which is designed to carry both pieces of information.

認可サーバーが検証 URI ("verification_uri") にユーザーコード ("user_code") を含めることは推奨されない (NOT RECOMMENDED)。ユーザーが入力しなければならない URI の長さと複雑さが増すためである。"user_code" を分離しても、ユーザーが入力しなければならない文字数は同程度であるが、"verification_uri" への移動に成功した後であれば、コード入力時の誤りを認可サーバーが強調表示してユーザー体験を向上させることができる。次の節では、両方の情報を運ぶように設計された "verification_uri_complete" を用いたユーザー操作について説明する。

3.3.1.Non-Textual Verification URI Optimization

3.3.1.テキスト以外の検証 URI による最適化

When "verification_uri_complete" is included in the authorization response (Section 3.2), clients MAY present this URI in a non-textual manner using any method that results in the browser being opened with the URI, such as with QR (Quick Response) codes or NFC (Near Field Communication), to save the user from typing the URI.

認可レスポンス (3.2 節) に "verification_uri_complete" が含まれている場合、クライアントはユーザーが URI を入力する手間を省くために、QR (Quick Response) コードや NFC (Near Field Communication) など、その URI でブラウザが開かれる結果となる任意の方法を用いて、この URI をテキスト以外の形で提示してもよい (MAY)。

For usability reasons, it is RECOMMENDED for clients to still display the textual verification URI ("verification_uri") for users who are not able to use such a shortcut. Clients MUST still display the "user_code", as the authorization server will require the user to confirm it to disambiguate devices or as remote phishing mitigation (see Section 5.4).

ユーザビリティ上の理由から、そのような近道を使えないユーザーのために、クライアントはテキストの検証 URI ("verification_uri") も引き続き表示することが推奨される (RECOMMENDED)。認可サーバーはデバイスの区別やリモートフィッシング対策 (5.4 節参照) のためにユーザーに "user_code" の確認を要求するので、クライアントは "user_code" を引き続き表示しなければならない (MUST)。

If the user starts the user interaction by navigating to "verification_uri_complete", then the user interaction described in Section 3.3 is still followed, with the optimization that the user does not need to type in the "user_code". The server SHOULD display the "user_code" to the user and ask them to verify that it matches the "user_code" being displayed on the device to confirm they are authorizing the correct device. As before, in addition to taking steps to confirm the identity of the device, the user should also be afforded the choice to approve or deny the authorization request.

ユーザーが "verification_uri_complete" に移動してユーザー操作を開始した場合も、3.3 節で説明したユーザー操作は引き続き行われるが、ユーザーが "user_code" を入力する必要がないという最適化が加わる。サーバーはユーザーに "user_code" を表示し、正しいデバイスを認可していることを確認するために、それがデバイスに表示されている "user_code" と一致するか検証するよう求めるべきである (SHOULD)。前述のとおり、デバイスの同一性を確認する手順に加えて、ユーザーには認可リクエストを承認するか拒否するかの選択肢も与えられるべきである。

3.4.Device Access Token Request

3.4.デバイスアクセストークンリクエスト

After displaying instructions to the user, the client creates an access token request and sends it to the token endpoint (as defined by Section 3.2 of [RFC6749]) with a "grant_type" of "urn:ietf:params:oauth:grant-type:device_code". This is an extension grant type (as defined by Section 4.5 of [RFC6749]) created by this specification, with the following parameters:

ユーザーへの指示を表示した後、クライアントはアクセストークンリクエストを作成し、"grant_type" を "urn:ietf:params:oauth:grant-type:device_code" としてトークンエンドポイント ([RFC6749] の 3.2 節で定義) に送信する。これは本仕様が作成した拡張グラントタイプ ([RFC6749] の 4.5 節で定義) であり、次のパラメーターを持つ。

grant_type REQUIRED. Value MUST be set to "urn:ietf:params:oauth:grant-type:device_code".

grant_type 必須 (REQUIRED)。値は "urn:ietf:params:oauth:grant-type:device_code" に設定しなければならない (MUST)。

device_code REQUIRED. The device verification code, "device_code" from the device authorization response, defined in Section 3.2.

device_code 必須 (REQUIRED)。3.2 節で定義されるデバイス認可レスポンスの "device_code"、すなわちデバイス検証コード。

client_id REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749]. The client identifier as described in Section 2.2 of [RFC6749].

client_id [RFC6749] の 3.2.1 節に記述されるとおりにクライアントが認可サーバーに対して認証を行わない場合は必須 (REQUIRED)。[RFC6749] の 2.2 節に記述されるクライアント識別子。

For example, the client makes the following HTTPS request (line breaks are for display purposes only):

例えば、クライアントは次のような HTTPS リクエストを行う (改行は表示のためだけのものである)。

If the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1 of [RFC6749]. Note that there are security implications of statically distributed client credentials; see Section 5.6.

クライアントにクライアントクレデンシャルが発行されている (または他の認証要件が課されている) 場合、クライアントは [RFC6749] の 3.2.1 節に記述されるとおりに認可サーバーに対して認証しなければならない (MUST)。静的に配布されるクライアントクレデンシャルにはセキュリティ上の含意があることに注意すること。5.6 節を参照。

The response to this request is defined in Section 3.5. Unlike other OAuth grant types, it is expected for the client to try the access token request repeatedly in a polling fashion based on the error code in the response.

このリクエストに対するレスポンスは 3.5 節で定義される。他の OAuth グラントタイプとは異なり、クライアントはレスポンス中のエラーコードに基づいて、ポーリングの形でアクセストークンリクエストを繰り返し試行することが想定されている。

3.5.Device Access Token Response

3.5.デバイスアクセストークンレスポンス

If the user has approved the grant, the token endpoint responds with a success response defined in Section 5.1 of [RFC6749]; otherwise, it responds with an error, as defined in Section 5.2 of [RFC6749].

ユーザーがグラントを承認した場合、トークンエンドポイントは [RFC6749] の 5.1 節で定義される成功レスポンスを返す。そうでない場合は、[RFC6749] の 5.2 節で定義されるエラーを返す。

In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specified for use with the device authorization grant in token endpoint responses:

[RFC6749] の 5.2 節で定義されるエラーコードに加えて、デバイス認可グラントで用いるために、トークンエンドポイントのレスポンスにおける次のエラーコードを規定する。

authorization_pending The authorization request is still pending as the end user hasn't yet completed the user-interaction steps (Section 3.3). The client SHOULD repeat the access token request to the token endpoint (a process known as polling). Before each new request, the client MUST wait at least the number of seconds specified by the "interval" parameter of the device authorization response (see Section 3.2), or 5 seconds if none was provided, and respect any increase in the polling interval required by the "slow_down" error.

authorization_pending エンドユーザーがまだユーザー操作のステップ (3.3 節) を完了していないため、認可リクエストは保留中である。クライアントはトークンエンドポイントへのアクセストークンリクエストを繰り返すべきである (SHOULD) (この処理はポーリングとして知られる)。新しいリクエストを行う前に、クライアントは毎回、デバイス認可レスポンスの "interval" パラメーター (3.2 節参照) で指定された秒数、または指定がない場合は 5 秒以上待たなければならず (MUST)、"slow_down" エラーによって要求されるポーリング間隔の増加に従わなければならない。

slow_down A variant of "authorization_pending", the authorization request is still pending and polling should continue, but the interval MUST be increased by 5 seconds for this and all subsequent requests.

slow_down "authorization_pending" の変種であり、認可リクエストは保留中でポーリングを継続すべきであるが、このリクエストおよび以降のすべてのリクエストについて、間隔を 5 秒増やさなければならない (MUST)。

access_denied The authorization request was denied.

access_denied 認可リクエストは拒否された。

expired_token The "device_code" has expired, and the device authorization session has concluded. The client MAY commence a new device authorization request but SHOULD wait for user interaction before restarting to avoid unnecessary polling.

expired_token "device_code" が期限切れとなり、デバイス認可セッションは終了した。クライアントは新しいデバイス認可リクエストを開始してもよい (MAY) が、不要なポーリングを避けるため、再開前にユーザー操作を待つべきである (SHOULD)。

The "authorization_pending" and "slow_down" error codes define particularly unique behavior, as they indicate that the OAuth client should continue to poll the token endpoint by repeating the token request (implementing the precise behavior defined above). If the client receives an error response with any other error code, it MUST stop polling and SHOULD react accordingly, for example, by displaying an error to the user.

"authorization_pending" と "slow_down" のエラーコードは特に独特な振る舞いを定義している。これらは、OAuth クライアントがトークンリクエストを繰り返すことでトークンエンドポイントへのポーリングを継続すべきである (上で定義した正確な振る舞いを実装する) ことを示すためである。クライアントがそれ以外のエラーコードを持つエラーレスポンスを受け取った場合、ポーリングを停止しなければならず (MUST)、例えばユーザーにエラーを表示するなど、それに応じた対応をすべきである (SHOULD)。

On encountering a connection timeout, clients MUST unilaterally reduce their polling frequency before retrying. The use of an exponential backoff algorithm to achieve this, such as doubling the polling interval on each such connection timeout, is RECOMMENDED.

接続タイムアウトに遭遇した場合、クライアントは再試行する前に、自らポーリング頻度を下げなければならない (MUST)。これを実現するために、接続タイムアウトのたびにポーリング間隔を 2 倍にするといった指数バックオフアルゴリズムを用いることが推奨される (RECOMMENDED)。

The assumption of this specification is that the separate device on which the user is authorizing the request does not have a way to communicate back to the device with the OAuth client. This protocol only requires a one-way channel in order to maximize the viability of the protocol in restricted environments, like an application running on a TV that is only capable of outbound requests. If a return channel were to exist for the chosen user-interaction interface, then the device MAY wait until notified on that channel that the user has completed the action before initiating the token request (as an alternative to polling). Such behavior is, however, outside the scope of this specification.

本仕様の前提は、ユーザーがリクエストを認可する別のデバイスが、OAuth クライアントを持つデバイスに通信を返す手段を持たないということである。外向きリクエストしか行えない TV 上で動作するアプリケーションのような制約された環境でプロトコルの実現性を最大化するため、このプロトコルは一方向チャネルしか必要としない。選択したユーザー操作インターフェースに戻りチャネルが存在するのであれば、デバイスは (ポーリングの代替として) ユーザーが操作を完了したことがそのチャネルで通知されるまで待ってからトークンリクエストを開始してもよい (MAY)。ただし、そのような振る舞いは本仕様の範囲外である。

4.Discovery Metadata

4.ディスカバリメタデータ

Support for this protocol is declared in OAuth 2.0 Authorization Server Metadata [RFC8414] as follows. The value "urn:ietf:params:oauth:grant-type:device_code" is included in values of the "grant_types_supported" key, and the following new key value pair is added:

このプロトコルのサポートは、OAuth 2.0 Authorization Server Metadata [RFC8414] において次のように宣言する。値 "urn:ietf:params:oauth:grant-type:device_code" を "grant_types_supported" キーの値に含め、さらに次の新しいキーと値の組を追加する。

device_authorization_endpoint OPTIONAL. URL of the authorization server's device authorization endpoint, as defined in Section 3.1.

device_authorization_endpoint 任意 (OPTIONAL)。3.1 節で定義される、認可サーバーのデバイス認可エンドポイントの URL。

5.Security Considerations

5.セキュリティに関する考慮事項

5.1.User Code Brute Forcing

5.1.ユーザーコードのブルートフォース

Since the user code is typed by the user, shorter codes are more desirable for usability reasons. This means the entropy is typically less than would be used for the device code or other OAuth bearer token types where the code length does not impact usability. Therefore, it is recommended that the server rate-limit user code attempts.

ユーザーコードはユーザーが入力するため、ユーザビリティの観点からは短いコードのほうが望ましい。これはつまり、そのエントロピーが、コード長がユーザビリティに影響しないデバイスコードや他の OAuth ベアラートークン種別に用いられるものより一般に小さいということである。したがって、サーバーはユーザーコードの試行をレート制限することが推奨される。

The user code SHOULD have enough entropy that, when combined with rate-limiting and other mitigations, a brute-force attack becomes infeasible. For example, it's generally held that 128-bit symmetric keys for encryption are seen as good enough today because an attacker has to put in 2^96 work to have a 2^-32 chance of guessing correctly via brute force. The rate-limiting and finite lifetime on the user code place an artificial limit on the amount of work an attacker can "do". If, for instance, one uses an 8-character base 20 user code (with roughly 34.5 bits of entropy), the rate-limiting interval and validity period would need to only allow 5 attempts in order to get the same 2^-32 probability of success by random guessing.

ユーザーコードは、レート制限や他の緩和策と組み合わせたときにブルートフォース攻撃が現実的でなくなるだけの十分なエントロピーを持つべきである (SHOULD)。例えば、暗号化用の 128 ビット対称鍵が今日十分とみなされているのは、攻撃者がブルートフォースで正しく推測できる確率を 2^-32 にするためには 2^96 の作業を投入しなければならないからだと一般に考えられている。ユーザーコードに対するレート制限と有限の有効期間は、攻撃者が「行える」作業量に人為的な上限を設ける。例えば、8 文字の base 20 ユーザーコード (約 34.5 ビットのエントロピー) を使う場合、ランダムな推測による成功確率を同じ 2^-32 にするには、レート制限の間隔と有効期間で許容する試行回数を 5 回だけにする必要がある。

A successful brute forcing of the user code would enable the attacker to approve the authorization grant with their own credentials, after which the device would receive a device authorization grant linked to the attacker's account. This is the opposite scenario to an OAuth bearer token being brute forced, whereby the attacker gains control of the victim's authorization grant. Such attacks may not always make economic sense. For example, for a video app, the device owner may then be able to purchase movies using the attacker's account (though even in this case a privacy risk would still remain and thus is important to protect against). Furthermore, some uses of the device flow give the granting account the ability to perform actions that need to be protected, such as controlling the device.

ユーザーコードのブルートフォースが成功すると、攻撃者は自身のクレデンシャルで認可グラントを承認できるようになり、その後デバイスは攻撃者のアカウントに紐づいたデバイス認可グラントを受け取ることになる。これは、攻撃者が被害者の認可グラントの制御を得る OAuth ベアラートークンのブルートフォースとは逆のシナリオである。こうした攻撃が常に経済的に成り立つとは限らない。例えば動画アプリの場合、デバイスの所有者が攻撃者のアカウントを使って映画を購入できてしまうかもしれない (ただし、この場合でもプライバシー上のリスクは残るため、防御は重要である)。さらに、デバイスフローの用途によっては、グラントを与えたアカウントにデバイスの制御など保護が必要な操作を行う能力が与えられるものもある。

The precise length of the user code and the entropy contained within is at the discretion of the authorization server, which needs to consider the sensitivity of their specific protected resources, the practicality of the code length from a usability standpoint, and any mitigations that are in place, such as rate-limiting, when determining the user code format.

ユーザーコードの正確な長さとそれに含まれるエントロピーは認可サーバーの裁量に委ねられる。認可サーバーはユーザーコードの形式を決定する際に、自身の保護されたリソースの機微性、ユーザビリティの観点からのコード長の実用性、およびレート制限など導入されている緩和策を考慮する必要がある。

5.2.Device Code Brute Forcing

5.2.デバイスコードのブルートフォース

An attacker who guesses the device code would be able to potentially obtain the authorization code once the user completes the flow. As the device code is not displayed to the user and thus there are no usability considerations on the length, a very high entropy code SHOULD be used.

デバイスコードを推測した攻撃者は、ユーザーがフローを完了した時点で認可コードを取得できる可能性がある。デバイスコードはユーザーに表示されず、したがって長さに関するユーザビリティ上の考慮事項がないため、非常に高いエントロピーのコードを使用すべきである (SHOULD)。

5.3.Device Trustworthiness

5.3.デバイスの信頼性

Unlike other native application OAuth 2.0 flows, the device requesting the authorization is not the same as the device from which the user grants access. Thus, signals from the approving user's session and device are not always relevant to the trustworthiness of the client device.

他のネイティブアプリケーション向け OAuth 2.0 フローとは異なり、認可を要求するデバイスは、ユーザーがアクセスを許可するデバイスと同じではない。したがって、承認するユーザーのセッションおよびデバイスから得られるシグナルは、クライアントデバイスの信頼性にとって常に有効であるとは限らない。

Note that if an authorization server used with this flow is malicious, then it could perform a man-in-the-middle attack on the backchannel flow to another authorization server. In this scenario, the man-in-the-middle is not completely hidden from sight, as the end user would end up on the authorization page of the wrong service, giving them an opportunity to notice that the URL in the browser's address bar is wrong. For this to be possible, the device manufacturer must either be the attacker and shipping a device intended to perform the man-in-the-middle attack, or be using an authorization server that is controlled by an attacker, possibly because the attacker compromised the authorization server used by the device. In part, the person purchasing the device is counting on the manufacturer and its business partners to be trustworthy.

このフローで使用される認可サーバーが悪意を持っている場合、別の認可サーバーへのバックチャネルフローに対して中間者攻撃を行える可能性があることに注意すること。このシナリオでは、エンドユーザーが誤ったサービスの認可ページにたどり着くことになるため、中間者は完全には隠れておらず、ブラウザのアドレスバーの URL が誤っていることにユーザーが気づく機会がある。これが可能になるためには、デバイスの製造者自身が攻撃者であり中間者攻撃を行うことを意図したデバイスを出荷しているか、あるいは攻撃者がデバイスの使用する認可サーバーを侵害したなどの理由で、攻撃者の支配下にある認可サーバーを使用しているかのいずれかでなければならない。デバイスを購入する人は、製造者とそのビジネスパートナーが信頼できることを部分的に当てにしている。

5.4.Remote Phishing

5.4.リモートフィッシング

It is possible for the device flow to be initiated on a device in an attacker's possession. For example, an attacker might send an email instructing the target user to visit the verification URL and enter the user code. To mitigate such an attack, it is RECOMMENDED to inform the user that they are authorizing a device during the user- interaction step (see Section 3.3) and to confirm that the device is in their possession. The authorization server SHOULD display information about the device so that the user could notice if a software client was attempting to impersonate a hardware device.

デバイスフローは攻撃者の手元にあるデバイス上で開始されうる。例えば、攻撃者は標的ユーザーに検証 URL にアクセスしてユーザーコードを入力するよう指示するメールを送るかもしれない。そのような攻撃を緩和するため、ユーザー操作のステップ (3.3 節参照) において、ユーザーがデバイスを認可しようとしていることを知らせ、そのデバイスがユーザーの手元にあることを確認することが推奨される (RECOMMENDED)。認可サーバーは、ソフトウェアクライアントがハードウェアデバイスになりすまそうとしている場合にユーザーが気づけるように、デバイスに関する情報を表示すべきである (SHOULD)。

For authorization servers that support the "verification_uri_complete" optimization discussed in Section 3.3.1, it is particularly important to confirm that the device is in the user's possession, as the user no longer has to type in the code being displayed on the device manually. One suggestion is to display the code during the authorization flow and ask the user to verify that the same code is currently being displayed on the device they are setting up.

3.3.1 節で論じた "verification_uri_complete" による最適化をサポートする認可サーバーでは、ユーザーがデバイスに表示されているコードを手で入力する必要がなくなるため、デバイスがユーザーの手元にあることを確認することがとりわけ重要である。一つの提案として、認可フロー中にコードを表示し、設定中のデバイスに現在同じコードが表示されていることを検証するようユーザーに求める方法がある。

The user code needs to have a long enough lifetime to be useable (allowing the user to retrieve their secondary device, navigate to the verification URI, log in, etc.) but should be sufficiently short to limit the usability of a code obtained for phishing. This doesn't prevent a phisher from presenting a fresh token, particularly if they are interacting with the user in real time, but it does limit the viability of codes sent over email or text message.

ユーザーコードは、使用可能であるために十分長い有効期間 (ユーザーが副次的なデバイスを取り出し、検証 URI に移動し、ログインするなどの時間を許容する) を持つ必要があるが、フィッシングで取得されたコードの使用可能性を制限するために十分短くあるべきである。これは、特にフィッシャーがユーザーとリアルタイムにやり取りしている場合に新しいトークンを提示することを防ぐものではないが、メールやテキストメッセージで送られるコードの有効性を制限する。

5.5.Session Spying

5.5.セッションの覗き見

While the device is pending authorization, it may be possible for a malicious user to physically spy on the device user interface (by viewing the screen on which it's displayed, for example) and hijack the session by completing the authorization faster than the user that initiated it. Devices SHOULD take into account the operating environment when considering how to communicate the code to the user to reduce the chances it will be observed by a malicious user.

デバイスが認可待ちの間、悪意のあるユーザーがデバイスのユーザーインターフェースを物理的に覗き見て (例えばコードが表示されている画面を見て)、開始したユーザーよりも早く認可を完了することでセッションを乗っ取ることが可能かもしれない。デバイスは、悪意のあるユーザーに観察される可能性を減らすため、ユーザーにコードを伝える方法を検討する際に動作環境を考慮に入れるべきである (SHOULD)。

5.6.Non-Confidential Clients

5.6.非コンフィデンシャルクライアント

Device clients are generally incapable of maintaining the confidentiality of their credentials, as users in possession of the device can reverse-engineer it and extract the credentials. Therefore, unless additional measures are taken, they should be treated as public clients (as defined by Section 2.1 of [RFC6749]), which are susceptible to impersonation. The security considerations of Section 5.3.1 of [RFC6819] and Sections 8.5 and 8.6 of [RFC8252] apply to such clients.

デバイスを手にしたユーザーはそれをリバースエンジニアリングしてクレデンシャルを抽出できるため、デバイスクライアントは一般にクレデンシャルの機密性を維持できない。したがって、追加の対策が取られない限り、それらはなりすましの影響を受けやすいパブリッククライアント ([RFC6749] の 2.1 節で定義) として扱われるべきである。[RFC6819] の 5.3.1 節および [RFC8252] の 8.5 節と 8.6 節のセキュリティに関する考慮事項がそのようなクライアントに適用される。

The user may also be able to obtain the "device_code" and/or other OAuth bearer tokens issued to their client, which would allow them to use their own authorization grant directly by impersonating the client. Given that the user in possession of the client credentials can already impersonate the client and create a new authorization grant (with a new "device_code"), this doesn't represent a separate impersonation vector.

ユーザーは、自身のクライアントに発行された "device_code" や他の OAuth ベアラートークンを取得できる可能性もあり、それによりクライアントになりすまして自身の認可グラントを直接使用できてしまう。クライアントクレデンシャルを手にしたユーザーはすでにクライアントになりすまして (新しい "device_code" で) 新しい認可グラントを作成できることを考えると、これは別個のなりすましの経路にはあたらない。

5.7.Non-Visual Code Transmission

5.7.視覚以外によるコードの伝達

There is no requirement that the user code be displayed by the device visually. Other methods of one-way communication can potentially be used, such as text-to-speech audio or Bluetooth Low Energy. To mitigate an attack in which a malicious user can bootstrap their credentials on a device not in their control, it is RECOMMENDED that any chosen communication channel only be accessible by people in close proximity, for example, users who can see or hear the device.

ユーザーコードをデバイスが視覚的に表示しなければならないという要件はない。テキスト読み上げ音声や Bluetooth Low Energy など、他の一方向通信の方法も潜在的に利用できる。悪意のあるユーザーが自身の支配下にないデバイスに自身のクレデンシャルを紐づける攻撃を緩和するため、選択する通信チャネルは、デバイスを見たり聞いたりできるユーザーなど、近接した人だけがアクセスできるものにすることが推奨される (RECOMMENDED)。

6.Usability Considerations

6.ユーザビリティに関する考慮事項

This section is a non-normative discussion of usability considerations.

この節はユーザビリティに関する考慮事項の非規範的な議論である。

6.1.User Code Recommendations

6.1.ユーザーコードに関する推奨

For many users, their nearest Internet-connected device will be their mobile phone; typically, these devices offer input methods that are more time-consuming than a computer keyboard to change the case or input numbers. To improve usability (improving entry speed and reducing retries), the limitations of such devices should be taken into account when selecting the user code character set.

多くのユーザーにとって、最も身近なインターネット接続デバイスは携帯電話である。通常、これらのデバイスの入力方法では、大文字小文字の切り替えや数字の入力にコンピューターのキーボードより時間がかかる。ユーザビリティを向上させる (入力速度を上げ、再試行を減らす) ため、ユーザーコードの文字集合を選ぶ際にはそのようなデバイスの制約を考慮に入れるべきである。

One way to improve input speed is to restrict the character set to case-insensitive A-Z characters, with no digits. These characters can typically be entered on a mobile keyboard without using modifier keys. Further removing vowels to avoid randomly creating words results in the base 20 character set "BCDFGHJKLMNPQRSTVWXZ". Dashes or other punctuation may be included for readability.

入力速度を向上させる一つの方法は、文字集合を大文字小文字を区別しない A-Z の文字に限定し、数字を含めないことである。これらの文字は通常、モバイルキーボード上で修飾キーを使わずに入力できる。さらに、偶然に単語ができてしまうのを避けるために母音を除くと、base 20 の文字集合 "BCDFGHJKLMNPQRSTVWXZ" になる。読みやすさのためにダッシュやその他の句読点を含めてもよい。

An example user code following this guideline, "WDJB-MJHT", contains 8 significant characters and has dashes added for end-user readability. The resulting entropy is 20^8.

この指針に従ったユーザーコードの例 "WDJB-MJHT" は、8 文字の有効文字を含み、エンドユーザーの読みやすさのためにダッシュが追加されている。結果として得られるエントロピーは 20^8 である。

Pure numeric codes are also a good choice for usability, especially for clients targeting locales where A-Z character keyboards are not used, though the length of such a code needs to be longer to maintain high entropy.

純粋な数字のコードも、特に A-Z の文字キーボードが使われないロケールを対象とするクライアントにとっては、ユーザビリティの面で良い選択である。ただし、高いエントロピーを維持するにはそのようなコードの長さをより長くする必要がある。

An example numeric user code that contains 9 significant digits and dashes added for end-user readability with an entropy of 10^9 is "019-450-730".

9 桁の有効数字を含み、エンドユーザーの読みやすさのためにダッシュが追加された、エントロピー 10^9 の数字ユーザーコードの例は "019-450-730" である。

When processing the inputted user code, the server should strip dashes and other punctuation that it added for readability (making the inclusion of such punctuation by the user optional). For codes using only characters in the A-Z range, as with the base 20 charset defined above, the user's input should be uppercased before a comparison to account for the fact that the user may input the equivalent lowercase characters. Further stripping of all characters outside the chosen character set is recommended to reduce instances where an errantly typed character (like a space character) invalidates otherwise valid input.

入力されたユーザーコードを処理する際、サーバーは読みやすさのために自身が追加したダッシュやその他の句読点を取り除くべきである (ユーザーによるそれらの句読点の入力を任意にする)。上で定義した base 20 の文字集合のように A-Z の範囲の文字だけを使うコードでは、ユーザーが同等の小文字を入力する可能性を考慮して、比較の前にユーザーの入力を大文字化すべきである。さらに、誤って入力された文字 (空白文字など) が本来有効な入力を無効にしてしまう事例を減らすため、選択した文字集合に含まれないすべての文字を取り除くことが推奨される。

It is RECOMMENDED to avoid character sets that contain two or more characters that can easily be confused with each other, like "0" and "O" or "1", "l" and "I". Furthermore, to the extent practical, when a character set contains a character that may be confused with characters outside the character set, a character outside the set MAY be substituted with the one in the character set with which it is commonly confused; for example, "O" may be substituted for "0" when using the numerical 0-9 character set.

"0" と "O"、"1" と "l" と "I" のように、互いに混同されやすい文字を 2 つ以上含む文字集合は避けることが推奨される (RECOMMENDED)。さらに、文字集合に、集合外の文字と混同されうる文字が含まれる場合、実用的な範囲で、集合外の文字を、それと混同されやすい集合内の文字で置き換えてもよい (MAY)。例えば、数字 0-9 の文字集合を使う場合、"O" を "0" に置き換えてもよい。

6.2.Non-Browser User Interaction

6.2.ブラウザ以外によるユーザー操作

Devices and authorization servers MAY negotiate an alternative code transmission and user-interaction method in addition to the one described in Section 3.3. Such an alternative user-interaction flow could obviate the need for a browser and manual input of the code, for example, by using Bluetooth to transmit the code to the authorization server's companion app. Such interaction methods can utilize this protocol as, ultimately, the user just needs to identify the authorization session to the authorization server; however, user interaction other than through the verification URI is outside the scope of this specification.

デバイスと認可サーバーは、3.3 節で説明した方法に加えて、代替のコード伝達およびユーザー操作の方法をネゴシエートしてもよい (MAY)。そのような代替のユーザー操作フローは、例えば Bluetooth を使って認可サーバーのコンパニオンアプリにコードを送信することで、ブラウザとコードの手入力の必要性をなくせる可能性がある。結局のところユーザーは認可サーバーに対して認可セッションを特定するだけでよいため、そのような操作方法はこのプロトコルを活用できる。ただし、検証 URI を介する以外のユーザー操作は本仕様の範囲外である。

7.IANA Considerations

7.IANA に関する考慮事項

7.1.OAuth Parameter Registration

7.1.OAuth パラメーターの登録

This specification registers the following values in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].

本仕様は、[RFC6749] によって設立された IANA の「OAuth Parameters」レジストリ [IANA.OAuth.Parameters] に次の値を登録する。

7.2.OAuth URI Registration

7.2.OAuth URI の登録

This specification registers the following values in the IANA "OAuth URI" registry [IANA.OAuth.Parameters] established by [RFC6755].

本仕様は、[RFC6755] によって設立された IANA の「OAuth URI」レジストリ [IANA.OAuth.Parameters] に次の値を登録する。

URN: urn:ietf:params:oauth:grant-type:device_code Common Name: Device Authorization Grant Type for OAuth 2.0 Change Controller: IESG Specification Document: Section 3.4 of RFC 8628

URN: urn:ietf:params:oauth:grant-type:device_code 一般名: Device Authorization Grant Type for OAuth 2.0 変更管理者: IESG 仕様文書: RFC 8628 の 3.4 節

7.3.OAuth Extensions Error Registration

7.3.OAuth 拡張エラーの登録

This specification registers the following values in the IANA "OAuth Extensions Error Registry" registry [IANA.OAuth.Parameters] established by [RFC6749].

本仕様は、[RFC6749] によって設立された IANA の「OAuth Extensions Error Registry」レジストリ [IANA.OAuth.Parameters] に次の値を登録する。

7.4.OAuth Authorization Server Metadata

7.4.OAuth 認可サーバーメタデータ

This specification registers the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414].

本仕様は、[RFC8414] によって設立された IANA の「OAuth Authorization Server Metadata」レジストリ [IANA.OAuth.Parameters] に次の値を登録する。

8.Normative References

8.引用規格

Acknowledgements

謝辞

The starting point for this document was the Internet-Draft draft-recordon-oauth-v2-device, authored by David Recordon and Brent Goldman, which itself was based on content in draft versions of the OAuth 2.0 protocol specification removed prior to publication due to a then-lack of sufficient deployment expertise. Thank you to the OAuth Working Group members who contributed to those earlier drafts.

本文書の出発点は、David Recordon と Brent Goldman が執筆した Internet-Draft である draft-recordon-oauth-v2-device であり、それ自体は、当時十分な展開経験が不足していたために公開前に削除された OAuth 2.0 プロトコル仕様のドラフト版の内容に基づいていた。それら初期のドラフトに貢献した OAuth ワーキンググループのメンバーに感謝する。

This document was produced in the OAuth Working Group under the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig, with Benjamin Kaduk, Kathleen Moriarty, and Eric Rescorla serving as Security Area Directors.

本文書は、Rifaat Shekh-Yusef と Hannes Tschofenig を議長とする OAuth ワーキンググループにおいて、Benjamin Kaduk、Kathleen Moriarty、Eric Rescorla をセキュリティエリアディレクターとして作成された。

The following individuals contributed ideas, feedback, and wording that shaped and formed the final specification:

次の各氏は、最終的な仕様を形作ったアイデア、フィードバック、文言を提供した。

Ben Campbell, Brian Campbell, Roshni Chandrashekhar, Alissa Cooper, Eric Fazendin, Benjamin Kaduk, Jamshid Khosravian, Mirja Kuehlewind, Torsten Lodderstedt, James Manger, Dan McNulty, Breno de Medeiros, Alexey Melnikov, Simon Moffatt, Stein Myrseth, Emond Papegaaij, Justin Richer, Adam Roach, Nat Sakimura, Andrew Sciberras, Marius Scurtescu, Filip Skokan, Robert Sparks, Ken Wang, Christopher Wood, Steven E. Wright, and Qin Wu.

Ben Campbell、Brian Campbell、Roshni Chandrashekhar、Alissa Cooper、Eric Fazendin、Benjamin Kaduk、Jamshid Khosravian、Mirja Kuehlewind、Torsten Lodderstedt、James Manger、Dan McNulty、Breno de Medeiros、Alexey Melnikov、Simon Moffatt、Stein Myrseth、Emond Papegaaij、Justin Richer、Adam Roach、Nat Sakimura、Andrew Sciberras、Marius Scurtescu、Filip Skokan、Robert Sparks、Ken Wang、Christopher Wood、Steven E. Wright、Qin Wu。