OAuth 2.0 Token Exchange

Abstract

概要

This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation.

本仕様は、OAuth 2.0 認可サーバーからセキュリティトークンを要求し取得する方法を定めることで、HTTP と JSON に基づくセキュリティトークンサービス (STS) のプロトコルを定義する。これには、なりすまし (impersonation) および委任 (delegation) を用いるセキュリティトークンも含まれる。

1.Introduction

1.はじめに

A security token is a set of information that facilitates the sharing of identity and security information in heterogeneous environments or across security domains. Examples of security tokens include JSON Web Tokens (JWTs) [JWT] and Security Assertion Markup Language (SAML) 2.0 assertions [OASIS.saml-core-2.0-os]. Security tokens are typically signed to achieve integrity and sometimes also encrypted to achieve confidentiality. Security tokens are also sometimes described as assertions, such as in [RFC7521].

セキュリティトークンとは、異種環境間またはセキュリティドメインをまたいで、アイデンティティおよびセキュリティ情報の共有を容易にする情報の集合である。セキュリティトークンの例には、JSON Web Token (JWT) [JWT] や Security Assertion Markup Language (SAML) 2.0 アサーション [OASIS.saml-core-2.0-os] がある。セキュリティトークンは、完全性を得るために通常は署名され、機密性を得るために暗号化されることもある。セキュリティトークンは、[RFC7521] におけるように、アサーションと呼ばれることもある。

A Security Token Service (STS) is a service capable of validating security tokens provided to it and issuing new security tokens in response, which enables clients to obtain appropriate access credentials for resources in heterogeneous environments or across security domains. Web Service clients have used WS-Trust [WS-Trust] as the protocol to interact with an STS for token exchange. While WS-Trust uses XML and SOAP, the trend in modern Web development has been towards RESTful (Representational State Transfer) patterns and JSON. The OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Tokens [RFC6750] have emerged as popular standards for authorizing third-party applications' access to HTTP and RESTful resources. The conventional OAuth 2.0 interaction involves the exchange of some representation of resource owner authorization for an access token, which has proven to be an extremely useful pattern in practice. However, its input and output are somewhat too constrained as is to fully accommodate a security token exchange framework.

セキュリティトークンサービス (STS) とは、提示されたセキュリティトークンを検証し、それに応じて新しいセキュリティトークンを発行できるサービスであり、これによりクライアントは異種環境間またはセキュリティドメインをまたいで、リソースに対する適切なアクセスクレデンシャルを取得できる。Web サービスのクライアントは、トークン交換のために STS とやり取りするプロトコルとして WS-Trust [WS-Trust] を用いてきた。WS-Trust は XML と SOAP を用いるが、現代の Web 開発の潮流は RESTful (Representational State Transfer) パターンと JSON に向かっている。OAuth 2.0 認可フレームワーク [RFC6749] と OAuth 2.0 Bearer トークン [RFC6750] は、サードパーティアプリケーションによる HTTP および RESTful リソースへのアクセスを認可する標準として広く普及した。従来の OAuth 2.0 のやり取りは、リソースオーナーの認可を何らかの形で表現したものをアクセストークンと交換するものであり、実際に極めて有用なパターンであることが実証されている。しかし、その入力と出力は、セキュリティトークン交換フレームワークを完全に収容するにはそのままではやや制約が強すぎる。

This specification defines a protocol extending OAuth 2.0 that enables clients to request and obtain security tokens from authorization servers acting in the role of an STS. Similar to OAuth 2.0, this specification focuses on client developer simplicity and requires only an HTTP client and JSON parser, which are nearly universally available in modern development environments. The STS protocol defined in this specification is not itself RESTful (an STS doesn't lend itself particularly well to a REST approach) but does utilize communication patterns and data formats that should be familiar to developers accustomed to working with RESTful systems.

本仕様は、STS の役割を担う認可サーバーからクライアントがセキュリティトークンを要求し取得できるようにする、OAuth 2.0 を拡張したプロトコルを定義する。OAuth 2.0 と同様に、本仕様はクライアント開発者にとっての簡潔さに重点を置き、現代の開発環境でほぼ普遍的に利用できる HTTP クライアントと JSON パーサーのみを必要とする。本仕様で定義する STS プロトコル自体は RESTful ではない (STS は REST のアプローチにあまりなじまない) が、RESTful なシステムを扱い慣れた開発者にとって馴染みのある通信パターンとデータ形式を利用している。

A new grant type for a token exchange request and the associated specific parameters for such a request to the token endpoint are defined by this specification. A token exchange response is a normal OAuth 2.0 response from the token endpoint with a few additional parameters defined herein to provide information to the client.

本仕様では、トークン交換要求のための新しいグラント種別と、トークンエンドポイントへのそのような要求に関連する固有のパラメーターを定義する。トークン交換応答は、トークンエンドポイントからの通常の OAuth 2.0 応答に、クライアントへ情報を提供するために本書で定義するいくつかの追加パラメーターを加えたものである。

The entity that makes the request to exchange tokens is considered the client in the context of the token exchange interaction. However, that does not restrict usage of this profile to traditional OAuth clients. An OAuth resource server, for example, might assume the role of the client during token exchange in order to trade an access token that it received in a protected resource request for a new token that is appropriate to include in a call to a backend service. The new token might be an access token that is more narrowly scoped for the downstream service or it could be an entirely different kind of token.

トークンの交換を要求するエンティティは、トークン交換のやり取りの文脈においてはクライアントとみなされる。ただし、これは本プロファイルの利用を従来の OAuth クライアントに限定するものではない。例えば、OAuth リソースサーバーが、保護リソース要求で受け取ったアクセストークンを、バックエンドサービスの呼び出しに含めるのに適した新しいトークンと交換するために、トークン交換の際にクライアントの役割を担うことがある。新しいトークンは、下流のサービス向けにより狭いスコープを持つアクセストークンであることもあれば、まったく異なる種類のトークンであることもある。

The scope of this specification is limited to the definition of a basic request-and-response protocol for an STS-style token exchange utilizing OAuth 2.0. Although a few new JWT claims are defined that enable delegation semantics to be expressed, the specific syntax, semantics, and security characteristics of the tokens themselves (both those presented to the authorization server and those obtained by the client) are explicitly out of scope, and no requirements are placed on the trust model in which an implementation might be deployed. Additional profiles may provide more detailed requirements around the specific nature of the parties and trust involved, such as whether signing and/or encryption of tokens is needed or if proof-of- possession-style tokens will be required or issued. However, such details will often be policy decisions made with respect to the specific needs of individual deployments and will be configured or implemented accordingly.

本仕様の範囲は、OAuth 2.0 を利用した STS 形式のトークン交換のための基本的な要求応答プロトコルの定義に限定される。委任のセマンティクスを表現できるようにするいくつかの新しい JWT クレームを定義してはいるが、トークン自体 (認可サーバーに提示されるものと、クライアントが取得するものの双方) の具体的な構文、セマンティクス、およびセキュリティ特性は明示的に範囲外であり、実装が配備されうるトラストモデルについても何の要件も課さない。追加のプロファイルが、トークンの署名や暗号化が必要かどうか、あるいは所有証明形式のトークンが要求または発行されるかどうかなど、関係する当事者や信頼の具体的な性質についてより詳細な要件を定めることがある。しかし、そのような詳細は多くの場合、個々の配備の具体的なニーズに応じて下されるポリシー上の決定であり、それに応じて設定または実装される。

The security tokens obtained may be used in a number of contexts, the specifics of which are also beyond the scope of this specification.

取得されたセキュリティトークンは多くの文脈で利用されうるが、その詳細も本仕様の範囲外である。

1.1.Delegation vs. Impersonation Semantics

1.1.委任となりすましのセマンティクス

One common use case for an STS (as alluded to in the previous section) is to allow a resource server A to make calls to a backend service C on behalf of the requesting user B. Depending on the local site policy and authorization infrastructure, it may be desirable for A to use its own credentials to access C along with an annotation of some form that A is acting on behalf of B ("delegation") or for A to be granted a limited access credential to C but that continues to identify B as the authorized entity ("impersonation"). Delegation and impersonation can be useful concepts in other scenarios involving multiple participants as well.

STS の一般的なユースケースの一つ (前節で触れたもの) は、リソースサーバー A が要求元ユーザー B に代わってバックエンドサービス C を呼び出せるようにすることである。サイトのローカルポリシーと認可基盤によっては、A が自身のクレデンシャルを用いて C にアクセスし、A が B に代わって行動しているという何らかの形の注記を添えること (「委任」) が望ましい場合もあれば、A に C への限定されたアクセスクレデンシャルが付与されるが、それは引き続き B を認可されたエンティティとして識別するもの (「なりすまし」) が望ましい場合もある。委任となりすましは、複数の参加者が関わる他のシナリオでも有用な概念となりうる。

When principal A impersonates principal B, A is given all the rights that B has within some defined rights context and is indistinguishable from B in that context. Thus, when principal A impersonates principal B, then insofar as any entity receiving such a token is concerned, they are actually dealing with B. It is true that some members of the identity system might have awareness that impersonation is going on, but it is not a requirement. For all intents and purposes, when A is impersonating B, A is B within the context of the rights authorized by the token. A's ability to impersonate B could be limited in scope or time, or even with a one- time-use restriction, whether via the contents of the token or an out-of-band mechanism.

プリンシパル A がプリンシパル B になりすます場合、A はある定められた権利の文脈において B が持つすべての権利を与えられ、その文脈では B と区別がつかない。したがって、プリンシパル A がプリンシパル B になりすます場合、そのようなトークンを受け取るいかなるエンティティにとっても、実際に相手にしているのは B である。アイデンティティシステムの一部の構成要素がなりすましが行われていることを認識していることはありうるが、それは要件ではない。事実上、A が B になりすましている間、トークンによって認可された権利の文脈において A は B である。A が B になりすます能力は、トークンの内容または帯域外の仕組みによって、スコープや時間を限定されたり、一回限りの使用に制限されたりすることがある。

Delegation semantics are different than impersonation semantics, though the two are closely related. With delegation semantics, principal A still has its own identity separate from B, and it is explicitly understood that while B may have delegated some of its rights to A, any actions taken are being taken by A representing B. In a sense, A is an agent for B.

委任のセマンティクスはなりすましのセマンティクスとは異なるが、両者は密接に関連している。委任のセマンティクスでは、プリンシパル A は引き続き B とは別の自身のアイデンティティを持ち、B が自身の権利の一部を A に委任したかもしれないが、行われるいかなる行為も B を代表する A によって行われていることが明示的に理解されている。ある意味で、A は B のエージェントである。

Delegation and impersonation are not inclusive of all situations. When a principal is acting directly on its own behalf, for example, neither delegation nor impersonation are in play. They are, however, the more common semantics operating for token exchange and, as such, are given more direct treatment in this specification.

委任となりすましがあらゆる状況を包含するわけではない。例えば、プリンシパルが自身のために直接行動している場合、委任もなりすましも関係しない。しかし、これらはトークン交換において作用するより一般的なセマンティクスであり、それゆえ本仕様ではより直接的に扱われる。

Delegation semantics are typically expressed in a token by including information about both the primary subject of the token as well as the actor to whom that subject has delegated some of its rights. Such a token is sometimes referred to as a composite token because it is composed of information about multiple subjects. Typically, in the request, the "subject_token" represents the identity of the party on behalf of whom the token is being requested while the "actor_token" represents the identity of the party to whom the access rights of the issued token are being delegated. A composite token issued by the authorization server will contain information about both parties. When and if a composite token is issued is at the discretion of the authorization server and applicable policy and configuration.

委任のセマンティクスは通常、トークンの主たるサブジェクトと、そのサブジェクトが権利の一部を委任した行為者 (actor) の双方に関する情報をトークンに含めることで表現される。このようなトークンは、複数のサブジェクトに関する情報から構成されるため、複合トークン (composite token) と呼ばれることがある。通常、要求において "subject_token" はトークンが要求される対象となる当事者 (その当事者に代わって要求される) のアイデンティティを表し、"actor_token" は発行されるトークンのアクセス権が委任される先の当事者のアイデンティティを表す。認可サーバーが発行する複合トークンには、双方の当事者に関する情報が含まれる。複合トークンをいつ発行するか、またそもそも発行するかどうかは、認可サーバーおよび適用されるポリシーと設定の裁量による。

The specifics of representing a composite token and even whether or not such a token will be issued depend on the details of the implementation and the kind of token. The representations of composite tokens that are not JWTs are beyond the scope of this specification. The "actor_token" request parameter, however, does provide a means for providing information about the desired actor, and the JWT "act" claim can provide a representation of a chain of delegation.

複合トークンの表現の詳細、さらにはそのようなトークンが発行されるかどうかさえも、実装の詳細とトークンの種類に依存する。JWT でない複合トークンの表現は本仕様の範囲外である。ただし、"actor_token" 要求パラメーターは、望ましい行為者に関する情報を提供する手段を提供し、JWT の "act" クレームは委任の連鎖の表現を提供できる。

1.2.Requirements Notation and Conventions

1.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] に記述されたとおりに解釈される。

1.3.Terminology

1.3.用語

This specification uses the terms "access token type", "authorization server", "client", "client identifier", "resource server", "token endpoint", "token request", and "token response" defined by OAuth 2.0 [RFC6749], and the terms "Base64url Encoding", "Claim", and "JWT Claims Set" defined by JSON Web Token (JWT) [JWT].

本仕様は、OAuth 2.0 [RFC6749] で定義された「アクセストークン種別」「認可サーバー」「クライアント」「クライアント識別子」「リソースサーバー」「トークンエンドポイント」「トークン要求」「トークン応答」の用語、および JSON Web Token (JWT) [JWT] で定義された「Base64url エンコーディング」「クレーム」「JWT クレームセット」の用語を用いる。

2.Token Exchange Request and Response

2.トークン交換の要求と応答

2.1.Request

2.1.要求

A client requests a security token by making a token request to the authorization server's token endpoint using the extension grant type mechanism defined in Section 4.5 of [RFC6749].

クライアントは、[RFC6749] の 4.5 節で定義された拡張グラント種別の仕組みを用いて、認可サーバーのトークンエンドポイントにトークン要求を行うことでセキュリティトークンを要求する。

Client authentication to the authorization server is done using the normal mechanisms provided by OAuth 2.0. Section 2.3.1 of [RFC6749] defines password-based authentication of the client, however, client authentication is extensible and other mechanisms are possible. For example, [RFC7523] defines client authentication using bearer JSON Web Tokens (JWTs) [JWT]. The supported methods of client authentication and whether or not to allow unauthenticated or unidentified clients are deployment decisions that are at the discretion of the authorization server. Note that omitting client authentication allows for a compromised token to be leveraged via an STS into other tokens by anyone possessing the compromised token. Thus, client authentication allows for additional authorization checks by the STS as to which entities are permitted to impersonate or receive delegations from other entities.

認可サーバーに対するクライアント認証は、OAuth 2.0 が提供する通常の仕組みを用いて行われる。[RFC6749] の 2.3.1 節はクライアントのパスワードベース認証を定義しているが、クライアント認証は拡張可能であり、他の仕組みも可能である。例えば、[RFC7523] は Bearer JSON Web Token (JWT) [JWT] を用いたクライアント認証を定義している。サポートするクライアント認証方式、および認証されていないクライアントや識別されていないクライアントを許可するかどうかは、認可サーバーの裁量による配備上の決定である。クライアント認証を省略すると、漏洩したトークンを所持する誰もが、STS を介してそのトークンを他のトークンへと活用できてしまうことに注意すること。したがって、クライアント認証により、STS はどのエンティティが他のエンティティになりすましたり委任を受けたりすることを許可されているかについて、追加の認可チェックを行えるようになる。

The client makes a token exchange request to the token endpoint with an extension grant type using the HTTP "POST" method. The following parameters are included in the HTTP request entity-body using the "application/x-www-form-urlencoded" format with a character encoding of UTF-8 as described in Appendix B of [RFC6749].

クライアントは、HTTP "POST" メソッドを用い、拡張グラント種別でトークンエンドポイントにトークン交換要求を行う。以下のパラメーターは、[RFC6749] の付録 B に記述されているとおり、UTF-8 の文字エンコーディングを用いた "application/x-www-form-urlencoded" 形式で HTTP 要求のエンティティボディに含める。

grant_type REQUIRED. The value "urn:ietf:params:oauth:grant-type:token- exchange" indicates that a token exchange is being performed.

grant_type 必須 (REQUIRED)。値 "urn:ietf:params:oauth:grant-type:token-exchange" は、トークン交換が行われていることを示す。

resource OPTIONAL. A URI that indicates the target service or resource where the client intends to use the requested security token. This enables the authorization server to apply policy as appropriate for the target, such as determining the type and content of the token to be issued or if and how the token is to be encrypted. In many cases, a client will not have knowledge of the logical organization of the systems with which it interacts and will only know a URI of the service where it intends to use the token. The "resource" parameter allows the client to indicate to the authorization server where it intends to use the issued token by providing the location, typically as an https URL, in the token exchange request in the same form that will be used to access that resource. The authorization server will typically have the capability to map from a resource URI value to an appropriate policy. The value of the "resource" parameter MUST be an absolute URI, as specified by Section 4.3 of [RFC3986], that MAY include a query component and MUST NOT include a fragment component. Multiple "resource" parameters may be used to indicate that the issued token is intended to be used at the multiple resources listed. See [OAUTH-RESOURCE] for additional background and uses of the "resource" parameter.

resource 任意 (OPTIONAL)。クライアントが要求したセキュリティトークンを使用する予定の対象サービスまたはリソースを示す URI。これにより認可サーバーは、発行するトークンの種類や内容、トークンを暗号化するかどうかやその方法の決定など、対象に応じたポリシーを適用できる。多くの場合、クライアントはやり取りするシステムの論理的な構成を知らず、トークンを使用する予定のサービスの URI しか知らない。"resource" パラメーターにより、クライアントは、そのリソースにアクセスする際に用いるのと同じ形式で、通常は https URL として、その場所をトークン交換要求に含めることで、発行されたトークンをどこで使用する予定かを認可サーバーに示すことができる。認可サーバーは通常、リソース URI の値から適切なポリシーへ対応付ける機能を持つ。"resource" パラメーターの値は [RFC3986] の 4.3 節で規定される絶対 URI でなければならず (MUST)、クエリ構成要素を含んでもよいが (MAY)、フラグメント構成要素を含んではならない (MUST NOT)。発行されたトークンが列挙された複数のリソースで使用されることを意図していることを示すために、複数の "resource" パラメーターを用いてもよい。"resource" パラメーターの追加の背景と用途については [OAUTH-RESOURCE] を参照すること。

audience OPTIONAL. The logical name of the target service where the client intends to use the requested security token. This serves a purpose similar to the "resource" parameter but with the client providing a logical name for the target service. Interpretation of the name requires that the value be something that both the client and the authorization server understand. An OAuth client identifier, a SAML entity identifier [OASIS.saml-core-2.0-os], and an OpenID Connect Issuer Identifier [OpenID.Core] are examples of things that might be used as "audience" parameter values. However, "audience" values used with a given authorization server must be unique within that server to ensure that they are properly interpreted as the intended type of value. Multiple "audience" parameters may be used to indicate that the issued token is intended to be used at the multiple audiences listed. The "audience" and "resource" parameters may be used together to indicate multiple target services with a mix of logical names and resource URIs.

audience 任意 (OPTIONAL)。クライアントが要求したセキュリティトークンを使用する予定の対象サービスの論理名。これは "resource" パラメーターと同様の目的を果たすが、クライアントが対象サービスの論理名を提供する点が異なる。この名前を解釈するには、その値がクライアントと認可サーバーの双方が理解できるものである必要がある。OAuth クライアント識別子、SAML エンティティ識別子 [OASIS.saml-core-2.0-os]、OpenID Connect 発行者識別子 [OpenID.Core] は、"audience" パラメーターの値として用いられうるものの例である。ただし、ある認可サーバーで用いられる "audience" の値は、意図した種類の値として正しく解釈されることを保証するため、そのサーバー内で一意でなければならない。発行されたトークンが列挙された複数のオーディエンスで使用されることを意図していることを示すために、複数の "audience" パラメーターを用いてもよい。"audience" パラメーターと "resource" パラメーターを併用して、論理名とリソース URI を混在させた複数の対象サービスを示してもよい。

scope OPTIONAL. A list of space-delimited, case-sensitive strings, as defined in Section 3.3 of [RFC6749], that allow the client to specify the desired scope of the requested security token in the context of the service or resource where the token will be used. The values and associated semantics of scope are service specific and expected to be described in the relevant service documentation.

scope 任意 (OPTIONAL)。[RFC6749] の 3.3 節で定義された、空白区切りで大文字小文字を区別する文字列のリストであり、トークンが使用されるサービスまたはリソースの文脈において、要求したセキュリティトークンの望ましいスコープをクライアントが指定できるようにする。スコープの値とそれに関連するセマンティクスはサービス固有であり、該当するサービスの文書に記述されることが期待される。

requested_token_type OPTIONAL. An identifier, as described in Section 3, for the type of the requested security token. If the requested type is unspecified, the issued token type is at the discretion of the authorization server and may be dictated by knowledge of the requirements of the service or resource indicated by the "resource" or "audience" parameter.

requested_token_type 任意 (OPTIONAL)。要求するセキュリティトークンの種類を示す、3 節に記述された識別子。要求する種類が指定されない場合、発行されるトークンの種類は認可サーバーの裁量によるものであり、"resource" または "audience" パラメーターで示されたサービスまたはリソースの要件に関する知識によって決定されることがある。

subject_token REQUIRED. A security token that represents the identity of the party on behalf of whom the request is being made. Typically, the subject of this token will be the subject of the security token issued in response to the request.

subject_token 必須 (REQUIRED)。要求がその当事者に代わって行われている、その当事者のアイデンティティを表すセキュリティトークン。通常、このトークンのサブジェクトが、要求に応じて発行されるセキュリティトークンのサブジェクトとなる。

subject_token_type REQUIRED. An identifier, as described in Section 3, that indicates the type of the security token in the "subject_token" parameter.

subject_token_type 必須 (REQUIRED)。"subject_token" パラメーターに含まれるセキュリティトークンの種類を示す、3 節に記述された識別子。

actor_token OPTIONAL. A security token that represents the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject.

actor_token 任意 (OPTIONAL)。行為者である当事者のアイデンティティを表すセキュリティトークン。通常、これは要求したセキュリティトークンの使用を認可され、サブジェクトに代わって行動する当事者である。

actor_token_type An identifier, as described in Section 3, that indicates the type of the security token in the "actor_token" parameter. This is REQUIRED when the "actor_token" parameter is present in the request but MUST NOT be included otherwise.

actor_token_type "actor_token" パラメーターに含まれるセキュリティトークンの種類を示す、3 節に記述された識別子。これは、要求に "actor_token" パラメーターが存在する場合は必須 (REQUIRED) であるが、そうでない場合は含めてはならない (MUST NOT)。

In processing the request, the authorization server MUST perform the appropriate validation procedures for the indicated token type and, if the actor token is present, also perform the appropriate validation procedures for its indicated token type. The validity criteria and details of any particular token are beyond the scope of this document and are specific to the respective type of token and its content.

要求を処理するにあたり、認可サーバーは示されたトークン種別に適した検証手順を実行しなければならず (MUST)、actor トークンが存在する場合は、その示されたトークン種別に適した検証手順も実行しなければならない。特定のトークンの有効性の基準と詳細は本書の範囲外であり、それぞれのトークンの種類とその内容に固有のものである。

In the absence of one-time-use or other semantics specific to the token type, the act of performing a token exchange has no impact on the validity of the subject token or actor token. Furthermore, the exchange is a one-time event and does not create a tight linkage between the input and output tokens, so that (for example) while the expiration time of the output token may be influenced by that of the input token, renewal or extension of the input token is not expected to be reflected in the output token's properties. It may still be appropriate or desirable to propagate token-revocation events. However, doing so is not a general property of the STS protocol and would be specific to a particular implementation, token type, or deployment.

一回限りの使用やその他トークン種別に固有のセマンティクスがない限り、トークン交換を行う行為は subject トークンや actor トークンの有効性に影響を与えない。さらに、交換は一回限りの出来事であり、入力トークンと出力トークンの間に密接な結びつきを作るものではない。したがって (例えば) 出力トークンの有効期限が入力トークンのそれに影響されることはあっても、入力トークンの更新や延長が出力トークンの特性に反映されることは期待されない。トークン失効イベントを伝播させることが適切または望ましい場合はなおありうる。しかし、そうすることは STS プロトコルの一般的な特性ではなく、特定の実装、トークン種別、または配備に固有のものとなる。

2.1.1.Relationship between Resource, Audience, and Scope

2.1.1.resource、audience、scope の関係

When requesting a token, the client can indicate the desired target service(s) where it intends to use that token by way of the "audience" and "resource" parameters as well as indicate the desired scope of the requested token using the "scope" parameter. The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services. Effectively, the requested access rights of the token are the Cartesian product of all the scopes at all the target services.

トークンを要求する際、クライアントは "audience" および "resource" パラメーターによってそのトークンを使用する予定の対象サービスを示し、また "scope" パラメーターを用いて要求するトークンの望ましいスコープを示すことができる。そのような要求のセマンティクスは、クライアントが要求したすべての対象サービスで使用可能な、要求したスコープを持つトークンを求めているというものである。事実上、トークンの要求されたアクセス権は、すべての対象サービスにおけるすべてのスコープのデカルト積である。

An authorization server may be unwilling or unable to fulfill any token request, but the likelihood of an unfulfillable request is significantly higher when very broad access rights are being solicited. As such, in the absence of specific knowledge about the relationship of systems in a deployment, clients should exercise discretion in the breadth of the access requested, particularly the number of target services. An authorization server can use the "invalid_target" error code, defined in Section 2.2.2, to inform a client that it requested access to too many target services simultaneously.

認可サーバーはいかなるトークン要求に対しても応じる意思がないか応じられないことがありうるが、非常に広範なアクセス権が求められている場合には、応じられない要求となる可能性が著しく高くなる。そのため、配備におけるシステム間の関係について具体的な知識がない場合、クライアントは要求するアクセスの広さ、特に対象サービスの数について慎重であるべきである。認可サーバーは、2.2.2 節で定義する "invalid_target" エラーコードを用いて、クライアントが同時にあまりに多くの対象サービスへのアクセスを要求したことを伝えることができる。

2.2.Response

2.2.応答

The authorization server responds to a token exchange request with a normal OAuth 2.0 response from the token endpoint, as specified in Section 5 of [RFC6749]. Additional details and explanation are provided in the following subsections.

認可サーバーは、[RFC6749] の 5 節で規定されるとおり、トークンエンドポイントからの通常の OAuth 2.0 応答でトークン交換要求に応答する。追加の詳細と説明は以下の各小節で示す。

2.2.1.Successful Response

2.2.1.成功応答

If the request is valid and meets all policy and other criteria of the authorization server, a successful token response is constructed by adding the following parameters to the entity-body of the HTTP response using the "application/json" media type, as specified by [RFC8259], and an HTTP 200 status code. The parameters are serialized into a JavaScript Object Notation (JSON) structure by adding each parameter at the top level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. The order of parameters does not matter and can vary.

要求が有効で、認可サーバーのすべてのポリシーおよびその他の基準を満たす場合、成功したトークン応答は、[RFC8259] で規定される "application/json" メディア種別を用いて HTTP 応答のエンティティボディに以下のパラメーターを追加し、HTTP 200 ステータスコードを付けて構築される。パラメーターは、各パラメーターをトップレベルに追加することで JavaScript Object Notation (JSON) 構造にシリアライズされる。パラメーター名と文字列値は JSON 文字列として含める。数値は JSON 数値として含める。パラメーターの順序は問わず、変わりうる。

access_token REQUIRED. The security token issued by the authorization server in response to the token exchange request. The "access_token" parameter from Section 5.1 of [RFC6749] is used here to carry the requested token, which allows this token exchange protocol to use the existing OAuth 2.0 request and response constructs defined for the token endpoint. The identifier "access_token" is used for historical reasons and the issued token need not be an OAuth access token.

access_token 必須 (REQUIRED)。トークン交換要求に応じて認可サーバーが発行したセキュリティトークン。ここでは [RFC6749] の 5.1 節の "access_token" パラメーターを用いて要求されたトークンを運ぶことで、本トークン交換プロトコルがトークンエンドポイント向けに定義された既存の OAuth 2.0 の要求および応答の構造を利用できるようにしている。"access_token" という識別子は歴史的な理由で用いられており、発行されるトークンが OAuth アクセストークンである必要はない。

issued_token_type REQUIRED. An identifier, as described in Section 3, for the representation of the issued security token.

issued_token_type 必須 (REQUIRED)。発行されたセキュリティトークンの表現を示す、3 節に記述された識別子。

token_type REQUIRED. A case-insensitive value specifying the method of using the access token issued, as specified in Section 7.1 of [RFC6749]. It provides the client with information about how to utilize the access token to access protected resources. For example, a value of "Bearer", as specified in [RFC6750], indicates that the issued security token is a bearer token and the client can simply present it as is without any additional proof of eligibility beyond the contents of the token itself. Note that the meaning of this parameter is different from the meaning of the "issued_token_type" parameter, which declares the representation of the issued security token; the term "token type" is more typically used to mean the structural or syntactical representation of the security token, as it is in all "*_token_type" parameters in this specification. If the issued token is not an access token or usable as an access token, then the "token_type" value "N_A" is used to indicate that an OAuth 2.0 "token_type" identifier is not applicable in that context.

token_type 必須 (REQUIRED)。[RFC6749] の 7.1 節で規定される、発行されたアクセストークンの使用方法を指定する、大文字小文字を区別しない値。これは、保護リソースにアクセスするためにアクセストークンをどのように利用するかについての情報をクライアントに提供する。例えば、[RFC6750] で規定される値 "Bearer" は、発行されたセキュリティトークンが bearer トークンであり、クライアントはトークンの内容自体以外に資格の追加の証明なしにそのまま提示できることを示す。このパラメーターの意味は、発行されたセキュリティトークンの表現を宣言する "issued_token_type" パラメーターの意味とは異なることに注意すること。「トークン種別」という用語は、本仕様のすべての "*_token_type" パラメーターにおいてそうであるように、より一般的にはセキュリティトークンの構造的または構文的な表現を意味するために用いられる。発行されたトークンがアクセストークンでない、またはアクセストークンとして使用できない場合は、その文脈では OAuth 2.0 の "token_type" 識別子が適用されないことを示すために "token_type" の値 "N_A" を用いる。

expires_in RECOMMENDED. The validity lifetime, in seconds, of the token issued by the authorization server. Oftentimes, the client will not have the inclination or capability to inspect the content of the token, and this parameter provides a consistent and token- type-agnostic indication of how long the token can be expected to be valid. For example, the value 1800 denotes that the token will expire in thirty minutes from the time the response was generated.

expires_in 推奨 (RECOMMENDED)。認可サーバーが発行したトークンの有効期間 (秒単位)。クライアントはトークンの内容を検査する意向や能力を持たないことが多く、このパラメーターは、トークンがどれだけの期間有効であると期待できるかについて、一貫したトークン種別に依存しない指標を提供する。例えば、値 1800 は、応答が生成された時点から 30 分後にトークンが失効することを示す。

scope OPTIONAL if the scope of the issued security token is identical to the scope requested by the client; otherwise, it is REQUIRED.

scope 発行されたセキュリティトークンのスコープがクライアントの要求したスコープと同一である場合は任意 (OPTIONAL)。それ以外の場合は必須 (REQUIRED) である。

refresh_token OPTIONAL. A refresh token will typically not be issued when the exchange is of one temporary credential (the subject_token) for a different temporary credential (the issued token) for use in some other context. A refresh token can be issued in cases where the client of the token exchange needs the ability to access a resource even when the original credential is no longer valid (e.g., user-not-present or offline scenarios where there is no longer any user entertaining an active session with the client). Profiles or deployments of this specification should clearly document the conditions under which a client should expect a refresh token in response to "urn:ietf:params:oauth:grant- type:token-exchange" grant type requests.

refresh_token 任意 (OPTIONAL)。ある一時的なクレデンシャル (subject_token) を、他の文脈で使用するための別の一時的なクレデンシャル (発行されるトークン) と交換する場合、リフレッシュトークンは通常発行されない。リフレッシュトークンは、元のクレデンシャルがもはや有効でなくなった場合でもトークン交換のクライアントがリソースにアクセスする能力を必要とする場合 (例えば、クライアントとのアクティブなセッションを維持しているユーザーがもはや存在しない、ユーザー不在またはオフラインのシナリオ) に発行されることがある。本仕様のプロファイルまたは配備は、"urn:ietf:params:oauth:grant-type:token-exchange" グラント種別の要求に応じてクライアントがリフレッシュトークンを期待すべき条件を明確に文書化すべきである。

2.2.2.Error Response

2.2.2.エラー応答

If the request itself is not valid or if either the "subject_token" or "actor_token" are invalid for any reason, or are unacceptable based on policy, the authorization server MUST construct an error response, as specified in Section 5.2 of [RFC6749]. The value of the "error" parameter MUST be the "invalid_request" error code.

要求自体が有効でない場合、または "subject_token" か "actor_token" のいずれかが何らかの理由で無効であるか、ポリシーに基づいて受け入れられない場合、認可サーバーは [RFC6749] の 5.2 節で規定されるエラー応答を構築しなければならない (MUST)。"error" パラメーターの値は "invalid_request" エラーコードでなければならない (MUST)。

If the authorization server is unwilling or unable to issue a token for any target service indicated by the "resource" or "audience" parameters, the "invalid_target" error code SHOULD be used in the error response.

認可サーバーが "resource" または "audience" パラメーターで示されたいずれかの対象サービス向けのトークンを発行する意思がないか発行できない場合、エラー応答では "invalid_target" エラーコードを用いるべきである (SHOULD)。

The authorization server MAY include additional information regarding the reasons for the error using the "error_description" as discussed in Section 5.2 of [RFC6749].

認可サーバーは、[RFC6749] の 5.2 節で論じられている "error_description" を用いて、エラーの理由に関する追加情報を含めてもよい (MAY)。

Other error codes may also be used, as appropriate.

適切に応じて、他のエラーコードを用いてもよい。

2.3.Example Token Exchange

2.3.トークン交換の例

The following example demonstrates a hypothetical token exchange in which an OAuth resource server assumes the role of the client during the exchange. It trades an access token, which it received in a protected resource request, for a new token that it will use to call to a backend service (extra line breaks and indentation in the examples are for display purposes only).

以下の例は、OAuth リソースサーバーが交換の際にクライアントの役割を担う、仮想的なトークン交換を示す。リソースサーバーは、保護リソース要求で受け取ったアクセストークンを、バックエンドサービスの呼び出しに用いる新しいトークンと交換する (例における余分な改行とインデントは表示のためだけのものである)。

Figure 1 shows the resource server receiving a protected resource request containing an OAuth access token in the Authorization header, as specified in Section 2.1 of [RFC6750].

図 1 は、[RFC6750] の 2.1 節で規定されるとおり、Authorization ヘッダーに OAuth アクセストークンを含む保護リソース要求をリソースサーバーが受け取る様子を示す。

In Figure 2, the resource server assumes the role of client for the token exchange, and the access token from the request in Figure 1 is sent to the authorization server using a request as specified in Section 2.1. The value of the "subject_token" parameter carries the access token, and the value of the "subject_token_type" parameter indicates that it is an OAuth 2.0 access token. The resource server, acting in the role of the client, uses its identifier and secret to authenticate to the authorization server using the HTTP Basic authentication scheme. The "resource" parameter indicates the location of the backend service, <https://backend.example.com/api>, where the issued token will be used.

図 2 では、リソースサーバーがトークン交換のためにクライアントの役割を担い、図 1 の要求に含まれていたアクセストークンが、2.1 節で規定される要求を用いて認可サーバーに送られる。"subject_token" パラメーターの値はアクセストークンを運び、"subject_token_type" パラメーターの値はそれが OAuth 2.0 アクセストークンであることを示す。クライアントの役割を担うリソースサーバーは、自身の識別子とシークレットを用い、HTTP Basic 認証スキームで認可サーバーに対して認証する。"resource" パラメーターは、発行されたトークンが使用されるバックエンドサービスの場所 <https://backend.example.com/api> を示す。

The authorization server validates the client credentials and the "subject_token" presented in the token exchange request. From the "resource" parameter, the authorization server is able to determine the appropriate policy to apply to the request and issues a token suitable for use at <https://backend.example.com>. The "access_token" parameter of the response shown in Figure 3 contains the new token, which is itself a bearer OAuth access token that is valid for one minute. The token happens to be a JWT; however, its structure and format are opaque to the client, so the "issued_token_type" indicates only that it is an access token.

認可サーバーは、クライアントクレデンシャルと、トークン交換要求で提示された "subject_token" を検証する。認可サーバーは "resource" パラメーターから要求に適用すべき適切なポリシーを決定でき、<https://backend.example.com> での使用に適したトークンを発行する。図 3 に示す応答の "access_token" パラメーターには新しいトークンが含まれており、これ自体は 1 分間有効な bearer OAuth アクセストークンである。このトークンはたまたま JWT であるが、その構造と形式はクライアントにとって不透明であるため、"issued_token_type" はそれがアクセストークンであることのみを示す。

The resource server can then use the newly acquired access token in making a request to the backend server as illustrated in Figure 4.

リソースサーバーはその後、図 4 に示すように、新たに取得したアクセストークンを用いてバックエンドサーバーに要求を行うことができる。

Additional examples can be found in Appendix A.

追加の例は付録 A にある。

3.Token Type Identifiers

3.トークン種別識別子

Several parameters in this specification utilize an identifier as the value to describe the token in question. Specifically, they are the "requested_token_type", "subject_token_type", and "actor_token_type" parameters of the request and the "issued_token_type" member of the response. Token type identifiers are URIs. Token exchange can work with both tokens issued by other parties and tokens from the given authorization server. For the former, the token type identifier indicates the syntax (e.g., JWT or SAML 2.0) so the authorization server can parse it; for the latter, it indicates what the given authorization server issued it for (e.g., "access_token" or "refresh_token").

本仕様のいくつかのパラメーターは、対象となるトークンを記述する値として識別子を用いる。具体的には、要求の "requested_token_type"、"subject_token_type"、"actor_token_type" パラメーターと、応答の "issued_token_type" メンバーである。トークン種別識別子は URI である。トークン交換は、他の当事者が発行したトークンと、当該認可サーバー自身が発行したトークンの双方を扱える。前者については、トークン種別識別子は認可サーバーがパースできるよう構文 (例えば JWT や SAML 2.0) を示し、後者については、当該認可サーバーがそれを何のために発行したか (例えば "access_token" や "refresh_token") を示す。

The following token type identifiers are defined by this specification. Other URIs MAY be used to indicate other token types.

本仕様では以下のトークン種別識別子を定義する。他のトークン種別を示すために他の URI を用いてもよい (MAY)。

urn:ietf:params:oauth:token-type:access_token Indicates that the token is an OAuth 2.0 access token issued by the given authorization server.

urn:ietf:params:oauth:token-type:access_token トークンが当該認可サーバーの発行した OAuth 2.0 アクセストークンであることを示す。

urn:ietf:params:oauth:token-type:refresh_token Indicates that the token is an OAuth 2.0 refresh token issued by the given authorization server.

urn:ietf:params:oauth:token-type:refresh_token トークンが当該認可サーバーの発行した OAuth 2.0 リフレッシュトークンであることを示す。

urn:ietf:params:oauth:token-type:id_token Indicates that the token is an ID Token as defined in Section 2 of [OpenID.Core].

urn:ietf:params:oauth:token-type:id_token トークンが [OpenID.Core] の 2 節で定義される ID トークンであることを示す。

urn:ietf:params:oauth:token-type:saml1 Indicates that the token is a base64url-encoded SAML 1.1 [OASIS.saml-core-1.1] assertion.

urn:ietf:params:oauth:token-type:saml1 トークンが base64url エンコードされた SAML 1.1 [OASIS.saml-core-1.1] アサーションであることを示す。

urn:ietf:params:oauth:token-type:saml2 Indicates that the token is a base64url-encoded SAML 2.0 [OASIS.saml-core-2.0-os] assertion.

urn:ietf:params:oauth:token-type:saml2 トークンが base64url エンコードされた SAML 2.0 [OASIS.saml-core-2.0-os] アサーションであることを示す。

The value "urn:ietf:params:oauth:token-type:jwt", which is defined in Section 9 of [JWT], indicates that the token is a JWT.

[JWT] の 9 節で定義される値 "urn:ietf:params:oauth:token-type:jwt" は、トークンが JWT であることを示す。

The distinction between an access token and a JWT is subtle. An access token represents a delegated authorization decision, whereas JWT is a token format. An access token can be formatted as a JWT but doesn't necessarily have to be. And a JWT might well be an access token, but not all JWTs are access tokens. The intent of this specification is that "urn:ietf:params:oauth:token-type:access_token" be an indicator that the token is a typical OAuth access token issued by the authorization server in question, opaque to the client, and usable the same manner as any other access token obtained from that authorization server. (It could well be a JWT, but the client isn't and needn't be aware of that fact.) Whereas, "urn:ietf:params:oauth:token-type:jwt" is to indicate specifically that a JWT is being requested or sent (perhaps in a cross-domain use case where the JWT is used as an authorization grant to obtain an access token from a different authorization server as is facilitated by [RFC7523]).

アクセストークンと JWT の区別は微妙である。アクセストークンは委任された認可の決定を表すのに対し、JWT はトークンの形式である。アクセストークンは JWT として形式化されることもあるが、必ずしもそうである必要はない。また、JWT がアクセストークンであることは十分ありうるが、すべての JWT がアクセストークンというわけではない。本仕様の意図は、"urn:ietf:params:oauth:token-type:access_token" が、当該認可サーバーの発行した典型的な OAuth アクセストークンであり、クライアントにとっては不透明で、その認可サーバーから取得した他のアクセストークンと同じように使用できることを示す指標となることである (それは JWT であるかもしれないが、クライアントはその事実を知らないし知る必要もない)。これに対し、"urn:ietf:params:oauth:token-type:jwt" は、JWT が要求または送信されていることを具体的に示すためのものである (例えば、[RFC7523] によって可能になるように、別の認可サーバーからアクセストークンを取得するための認可グラントとして JWT が用いられるクロスドメインのユースケースにおいて)。

Note that for tokens that are binary in nature, the URI used for conveying them needs to be associated with the semantics of a base64 or other encoding suitable for usage with HTTP and OAuth.

本質的にバイナリであるトークンについては、それを運ぶために用いる URI は、HTTP および OAuth での使用に適した base64 またはその他のエンコーディングのセマンティクスと関連付けられる必要があることに注意すること。

4.JSON Web Token Claims and Introspection Response Parameters

4.JSON Web Token クレームとイントロスペクション応答パラメーター

It is useful to have defined mechanisms to express delegation within a token as well as to express authorization to delegate or impersonate. Although the token exchange protocol described herein can be used with any type of token, this section defines claims to express such semantics specifically for JWTs and in an OAuth 2.0 Token Introspection [RFC7662] response. Similar definitions for other types of tokens are possible but beyond the scope of this specification.

トークン内で委任を表現する仕組みと、委任またはなりすましの認可を表現する仕組みが定義されていることは有用である。本書で記述するトークン交換プロトコルはどのような種類のトークンとも併用できるが、本節では、特に JWT と OAuth 2.0 トークンイントロスペクション [RFC7662] 応答においてそのようなセマンティクスを表現するためのクレームを定義する。他の種類のトークンに対する同様の定義も可能であるが、本仕様の範囲外である。

Note that the claims not established herein but used in examples and descriptions, such as "iss", "sub", "exp", etc., are defined by [JWT].

本書で定められていないが例や説明で用いられる "iss"、"sub"、"exp" などのクレームは、[JWT] で定義されていることに注意すること。

4.1."act" (Actor) Claim

4.1."act" (Actor) クレーム

The "act" (actor) claim provides a means within a JWT to express that delegation has occurred and identify the acting party to whom authority has been delegated. The "act" claim value is a JSON object, and members in the JSON object are claims that identify the actor. The claims that make up the "act" claim identify and possibly provide additional information about the actor. For example, the combination of the two claims "iss" and "sub" might be necessary to uniquely identify an actor.

"act" (actor) クレームは、委任が行われたことを表現し、権限を委任された行為者である当事者を識別する手段を JWT 内で提供する。"act" クレームの値は JSON オブジェクトであり、その JSON オブジェクトのメンバーは行為者を識別するクレームである。"act" クレームを構成するクレームは、行為者を識別し、場合によってはその行為者に関する追加情報を提供する。例えば、行為者を一意に識別するには "iss" と "sub" の二つのクレームの組み合わせが必要になることがある。

However, claims within the "act" claim pertain only to the identity of the actor and are not relevant to the validity of the containing JWT in the same manner as the top-level claims. Consequently, non- identity claims (e.g., "exp", "nbf", and "aud") are not meaningful when used within an "act" claim and are therefore not used.

ただし、"act" クレーム内のクレームは行為者のアイデンティティにのみ関係するものであり、トップレベルのクレームのようにそれを含む JWT の有効性に関係するものではない。したがって、アイデンティティ以外のクレーム (例えば "exp"、"nbf"、"aud") は "act" クレーム内で用いても意味を持たず、よって用いられない。

Figure 5 illustrates the "act" (actor) claim within a JWT Claims Set. The claims of the token itself are about user@example.com while the "act" claim indicates that admin@example.com is the current actor.

図 5 は、JWT クレームセット内の "act" (actor) クレームを示す。トークン自体のクレームは user@example.com に関するものであり、"act" クレームは admin@example.com が現在の行為者であることを示す。

A chain of delegation can be expressed by nesting one "act" claim within another. The outermost "act" claim represents the current actor while nested "act" claims represent prior actors. The least recent actor is the most deeply nested. The nested "act" claims serve as a history trail that connects the initial request and subject through the various delegation steps undertaken before reaching the current actor. In this sense, the current actor is considered to include the entire authorization/delegation history, leading naturally to the nested structure described here.

委任の連鎖は、ある "act" クレームを別の "act" クレームの中に入れ子にすることで表現できる。最も外側の "act" クレームが現在の行為者を表し、入れ子になった "act" クレームは以前の行為者を表す。最も古い行為者が最も深く入れ子になる。入れ子の "act" クレームは、最初の要求とサブジェクトから、現在の行為者に至るまでに行われた各委任ステップをつなぐ履歴の痕跡として機能する。この意味で、現在の行為者は認可と委任の履歴全体を含むものとみなされ、ここで記述した入れ子構造に自然につながる。

For the purpose of applying access control policy, the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the "act" claim. Prior actors identified by any nested "act" claims are informational only and are not to be considered in access control decisions.

アクセス制御ポリシーを適用する目的においては、トークンの利用者はトークンのトップレベルのクレームと、"act" クレームによって現在の行為者として識別された当事者のみを考慮しなければならない (MUST)。入れ子になった "act" クレームによって識別される以前の行為者は情報提供のためだけのものであり、アクセス制御の決定において考慮されるべきものではない。

The following example in Figure 6 illustrates nested "act" (actor) claims within a JWT Claims Set. The claims of the token itself are about user@example.com while the "act" claim indicates that the system <https://service16.example.com> is the current actor and <https://service77.example.com> was a prior actor. Such a token might come about as the result of service16 receiving a token in a call from service77 and exchanging it for a token suitable to call service26 while the authorization server notes the situation in the newly issued token.

図 6 の以下の例は、JWT クレームセット内の入れ子になった "act" (actor) クレームを示す。トークン自体のクレームは user@example.com に関するものであり、"act" クレームはシステム <https://service16.example.com> が現在の行為者で、<https://service77.example.com> が以前の行為者であったことを示す。このようなトークンは、service16 が service77 からの呼び出しでトークンを受け取り、それを service26 を呼び出すのに適したトークンと交換する際に、認可サーバーがその状況を新たに発行するトークンに記録した結果として生じうる。

When included as a top-level member of an OAuth token introspection response, "act" has the same semantics and format as the claim of the same name.

OAuth トークンイントロスペクション応答のトップレベルメンバーとして含まれる場合、"act" は同名のクレームと同じセマンティクスと形式を持つ。

4.2."scope" (Scopes) Claim

4.2."scope" (Scopes) クレーム

The value of the "scope" claim is a JSON string containing a space- separated list of scopes associated with the token, in the format described in Section 3.3 of [RFC6749].

"scope" クレームの値は、[RFC6749] の 3.3 節で記述される形式で、トークンに関連付けられたスコープの空白区切りリストを含む JSON 文字列である。

Figure 7 illustrates the "scope" claim within a JWT Claims Set.

図 7 は、JWT クレームセット内の "scope" クレームを示す。

OAuth 2.0 Token Introspection [RFC7662] already defines the "scope" parameter to convey the scopes associated with the token.

OAuth 2.0 トークンイントロスペクション [RFC7662] は、トークンに関連付けられたスコープを運ぶ "scope" パラメーターをすでに定義している。

4.3."client_id" (Client Identifier) Claim

4.3."client_id" (Client Identifier) クレーム

The "client_id" claim carries the client identifier of the OAuth 2.0 [RFC6749] client that requested the token.

"client_id" クレームは、トークンを要求した OAuth 2.0 [RFC6749] クライアントのクライアント識別子を運ぶ。

The following example in Figure 8 illustrates the "client_id" claim within a JWT Claims Set indicating an OAuth 2.0 client with "s6BhdRkqt3" as its identifier.

図 8 の以下の例は、JWT クレームセット内の "client_id" クレームを示し、識別子が "s6BhdRkqt3" である OAuth 2.0 クライアントを示している。

OAuth 2.0 Token Introspection [RFC7662] already defines the "client_id" parameter as the client identifier for the OAuth 2.0 client that requested the token.

OAuth 2.0 トークンイントロスペクション [RFC7662] は、トークンを要求した OAuth 2.0 クライアントのクライアント識別子として "client_id" パラメーターをすでに定義している。

4.4."may_act" (Authorized Actor) Claim

4.4."may_act" (Authorized Actor) クレーム

The "may_act" claim makes a statement that one party is authorized to become the actor and act on behalf of another party. The claim might be used, for example, when a "subject_token" is presented to the token endpoint in a token exchange request and "may_act" claim in the subject token can be used by the authorization server to determine whether the client (or party identified in the "actor_token") is authorized to engage in the requested delegation or impersonation. The claim value is a JSON object, and members in the JSON object are claims that identify the party that is asserted as being eligible to act for the party identified by the JWT containing the claim. The claims that make up the "may_act" claim identify and possibly provide additional information about the authorized actor. For example, the combination of the two claims "iss" and "sub" are sometimes necessary to uniquely identify an authorized actor, while the "email" claim might be used to provide additional useful information about that party.

"may_act" クレームは、ある当事者が行為者となって別の当事者に代わって行動することを認可されているという言明を行う。このクレームは、例えば、トークン交換要求で "subject_token" がトークンエンドポイントに提示された際に、subject トークン内の "may_act" クレームを認可サーバーが用いて、クライアント (または "actor_token" で識別される当事者) が要求された委任またはなりすましを行うことを認可されているかどうかを判断するために使われることがある。クレームの値は JSON オブジェクトであり、その JSON オブジェクトのメンバーは、このクレームを含む JWT によって識別される当事者に代わって行動する資格があると表明される当事者を識別するクレームである。"may_act" クレームを構成するクレームは、認可された行為者を識別し、場合によってはその行為者に関する追加情報を提供する。例えば、認可された行為者を一意に識別するには "iss" と "sub" の二つのクレームの組み合わせが必要になることがある一方、"email" クレームはその当事者に関する追加の有用な情報を提供するために用いられることがある。

However, claims within the "may_act" claim pertain only to the identity of that party and are not relevant to the validity of the containing JWT in the same manner as top-level claims. Consequently, claims such as "exp", "nbf", and "aud" are not meaningful when used within a "may_act" claim and are therefore not used.

ただし、"may_act" クレーム内のクレームはその当事者のアイデンティティにのみ関係するものであり、トップレベルのクレームのようにそれを含む JWT の有効性に関係するものではない。したがって、"exp"、"nbf"、"aud" などのクレームは "may_act" クレーム内で用いても意味を持たず、よって用いられない。

Figure 9 illustrates the "may_act" claim within a JWT Claims Set. The claims of the token itself are about user@example.com while the "may_act" claim indicates that admin@example.com is authorized to act on behalf of user@example.com.

図 9 は、JWT クレームセット内の "may_act" クレームを示す。トークン自体のクレームは user@example.com に関するものであり、"may_act" クレームは admin@example.com が user@example.com に代わって行動することを認可されていることを示す。

When included as a top-level member of an OAuth token introspection response, "may_act" has the same semantics and format as the claim of the same name.

OAuth トークンイントロスペクション応答のトップレベルメンバーとして含まれる場合、"may_act" は同名のクレームと同じセマンティクスと形式を持つ。

5.Security Considerations

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

Much of the guidance from Section 10 of [RFC6749], the Security Considerations in The OAuth 2.0 Authorization Framework, is also applicable here. Furthermore, [RFC6819] provides additional security considerations for OAuth, and [OAUTH-SECURITY] has updated security guidance based on deployment experience and new threats that have emerged since OAuth 2.0 was originally published.

OAuth 2.0 認可フレームワークのセキュリティに関する考慮事項である [RFC6749] の 10 節の指針の多くは、ここでも適用される。さらに、[RFC6819] は OAuth に対する追加のセキュリティに関する考慮事項を提供しており、[OAUTH-SECURITY] は、OAuth 2.0 が当初公開されて以降の配備経験と新たに出現した脅威に基づいて更新されたセキュリティ指針を提供している。

All of the normal security issues that are discussed in [JWT], especially in relationship to comparing URIs and dealing with unrecognized values, also apply here.

[JWT] で論じられている通常のセキュリティ上の問題はすべて、特に URI の比較と未知の値の扱いに関するものを含め、ここでも適用される。

In addition, both delegation and impersonation introduce unique security issues. Any time one principal is delegated the rights of another principal, the potential for abuse is a concern. The use of the "scope" claim (in addition to other typical constraints such as a limited token lifetime) is suggested to mitigate potential for such abuse, as it restricts the contexts in which the delegated rights can be exercised.

加えて、委任となりすましはいずれも固有のセキュリティ上の問題をもたらす。あるプリンシパルが別のプリンシパルの権利を委任されるときは常に、悪用の可能性が懸念される。"scope" クレームの使用は (限定されたトークン有効期間などの他の典型的な制約に加えて)、委任された権利を行使できる文脈を制限するため、そのような悪用の可能性を軽減するために推奨される。

6.Privacy Considerations

6.プライバシーに関する考慮事項

Tokens employed in the context of the functionality described herein may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, MUST only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure of certain information to the client, the token MUST be encrypted to its intended recipient. Deployments SHOULD determine the minimally necessary amount of data and only include such information in issued tokens. In some cases, data minimization may include representing only an anonymous or pseudonymous user.

本書で記述する機能の文脈で用いられるトークンはプライバシーに敏感な情報を含むことがあり、そのような情報が意図しない当事者に開示されるのを防ぐため、Transport Layer Security (TLS) などの暗号化されたチャネル上でのみ送信されなければならない (MUST)。特定の情報がクライアントに開示されるのを防ぐことが望ましい場合、トークンは意図した受信者に対して暗号化されなければならない (MUST)。配備は、最低限必要なデータ量を見極め、発行するトークンにはそのような情報のみを含めるべきである (SHOULD)。場合によっては、データの最小化には、匿名または仮名のユーザーのみを表現することが含まれうる。

7.IANA Considerations

7.IANA に関する考慮事項

7.1.OAuth URI Registration

7.1.OAuth URI の登録

IANA has registered the following values in the "OAuth URI" subregistry of the "OAuth Parameters" registry [IANA.OAuth.Parameters]. The "OAuth URI" subregistry was established by [RFC6755].

IANA は、"OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth URI" サブレジストリに以下の値を登録した。"OAuth URI" サブレジストリは [RFC6755] によって設立された。

* URN: urn:ietf:params:oauth:grant-type:token-exchange

URN: urn:ietf:params:oauth:grant-type:token-exchange

* Common Name: Token exchange grant type for OAuth 2.0

共通名: OAuth 2.0 のトークン交換グラントタイプ

* Change Controller: IESG

変更管理者: IESG

* Specification Document: Section 2.1 of RFC 8693

仕様文書: RFC 8693 の 2.1 節

* URN: urn:ietf:params:oauth:token-type:access_token

URN: urn:ietf:params:oauth:token-type:access_token

* Common Name: Token type URI for an OAuth 2.0 access token

共通名: OAuth 2.0 アクセストークンのトークンタイプ URI

* Change Controller: IESG

変更管理者: IESG

* Specification Document: Section 3 of RFC 8693

仕様文書: RFC 8693 の 3 節

* URN: urn:ietf:params:oauth:token-type:refresh_token

URN: urn:ietf:params:oauth:token-type:refresh_token

* Common Name: Token type URI for an OAuth 2.0 refresh token

共通名: OAuth 2.0 リフレッシュトークンのトークンタイプ URI

* Change Controller: IESG

変更管理者: IESG

* Specification Document: Section 3 of RFC 8693

仕様文書: RFC 8693 の 3 節

* URN: urn:ietf:params:oauth:token-type:id_token

URN: urn:ietf:params:oauth:token-type:id_token

* Common Name: Token type URI for an ID Token

共通名: ID トークンのトークンタイプ URI

* Change Controller: IESG

変更管理者: IESG

* Specification Document: Section 3 of RFC 8693

仕様文書: RFC 8693 の 3 節

* URN: urn:ietf:params:oauth:token-type:saml1

URN: urn:ietf:params:oauth:token-type:saml1

* Common Name: Token type URI for a base64url-encoded SAML 1.1 assertion

共通名: base64url エンコードされた SAML 1.1 アサーションのトークンタイプ URI

* Change Controller: IESG

変更管理者: IESG

* Specification Document: Section 3 of RFC 8693

仕様文書: RFC 8693 の 3 節

* URN: urn:ietf:params:oauth:token-type:saml2

URN: urn:ietf:params:oauth:token-type:saml2

* Common Name: Token type URI for a base64url-encoded SAML 2.0 assertion

共通名: base64url エンコードされた SAML 2.0 アサーションのトークンタイプ URI

* Change Controller: IESG

変更管理者: IESG

* Specification Document: Section 3 of RFC 8693

仕様文書: RFC 8693 の 3 節

7.2.OAuth Parameters Registration

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

IANA has registered the following values in the "OAuth Parameters" subregistry of the "OAuth Parameters" registry [IANA.OAuth.Parameters]. The "OAuth Parameters" subregistry was established by [RFC6749].

IANA は、"OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth Parameters" サブレジストリに以下の値を登録した。"OAuth Parameters" サブレジストリは [RFC6749] によって設立された。

* Parameter name: audience

パラメータ名: audience

* Parameter usage location: token request

パラメータの使用場所: トークンリクエスト

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.1 of RFC 8693

仕様文書: RFC 8693 の 2.1 節

* Parameter name: requested_token_type

パラメータ名: requested_token_type

* Parameter usage location: token request

パラメータの使用場所: トークンリクエスト

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.1 of RFC 8693

仕様文書: RFC 8693 の 2.1 節

* Parameter name: subject_token

パラメータ名: subject_token

* Parameter usage location: token request

パラメータの使用場所: トークンリクエスト

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.1 of RFC 8693

仕様文書: RFC 8693 の 2.1 節

* Parameter name: subject_token_type

パラメータ名: subject_token_type

* Parameter usage location: token request

パラメータの使用場所: トークンリクエスト

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.1 of RFC 8693

仕様文書: RFC 8693 の 2.1 節

* Parameter name: actor_token

パラメータ名: actor_token

* Parameter usage location: token request

パラメータの使用場所: トークンリクエスト

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.1 of RFC 8693

仕様文書: RFC 8693 の 2.1 節

* Parameter name: actor_token_type

パラメータ名: actor_token_type

* Parameter usage location: token request

パラメータの使用場所: トークンリクエスト

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.1 of RFC 8693

仕様文書: RFC 8693 の 2.1 節

* Parameter name: issued_token_type

パラメータ名: issued_token_type

* Parameter usage location: token response

パラメータの使用場所: トークンレスポンス

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.2.1 of RFC 8693

仕様文書: RFC 8693 の 2.2.1 節

7.3.OAuth Access Token Type Registration

7.3.OAuth アクセストークン種別の登録

IANA has registered the following access token type in the "OAuth Access Token Types" subregistry of the "OAuth Parameters" registry [IANA.OAuth.Parameters]. The "OAuth Access Token Types" subregistry was established by [RFC6749].

IANA は、"OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth Access Token Types" サブレジストリに以下のアクセストークン種別を登録した。"OAuth Access Token Types" サブレジストリは [RFC6749] によって設立された。

* Type name: N_A

タイプ名: N_A

* Additional Token Endpoint Response Parameters: none

追加のトークンエンドポイントレスポンスパラメータ: なし

* HTTP Authentication Scheme(s): none

HTTP 認証スキーム: なし

* Change controller: IESG

変更管理者: IESG

* Specification document(s): Section 2.2.1 of RFC 8693

仕様文書: RFC 8693 の 2.2.1 節

7.4.JSON Web Token Claims Registration

7.4.JSON Web Token クレームの登録

IANA has registered the following Claims in the "JSON Web Token Claims" subregistry of the "JSON Web Token (JWT)" registry [IANA.JWT]. The "JSON Web Token Claims" subregistry was established by [JWT].

IANA は、"JSON Web Token (JWT)" レジストリ [IANA.JWT] の "JSON Web Token Claims" サブレジストリに以下のクレームを登録した。"JSON Web Token Claims" サブレジストリは [JWT] によって設立された。

* Claim Name: act

クレーム名: act

* Claim Description: Actor

クレームの説明: アクター

* Change Controller: IESG

変更管理者: IESG

* Specification Document(s): Section 4.1 of RFC 8693

仕様文書: RFC 8693 の 4.1 節

* Claim Name: scope

クレーム名: scope

* Claim Description: Scope Values

クレームの説明: スコープ値

* Change Controller: IESG

変更管理者: IESG

* Specification Document(s): Section 4.2 of RFC 8693

仕様文書: RFC 8693 の 4.2 節

* Claim Name: client_id

クレーム名: client_id

* Claim Description: Client Identifier

クレームの説明: クライアント識別子

* Change Controller: IESG

変更管理者: IESG

* Specification Document(s): Section 4.3 of RFC 8693

仕様文書: RFC 8693 の 4.3 節

* Claim Name: may_act

クレーム名: may_act

* Claim Description: Authorized Actor - the party that is authorized to become the actor

クレームの説明: 認可されたアクター (アクターになることを認可された当事者)

* Change Controller: IESG

変更管理者: IESG

* Specification Document(s): Section 4.4 of RFC 8693

仕様文書: RFC 8693 の 4.4 節

7.5.OAuth Token Introspection Response Registration

7.5.OAuth トークンイントロスペクション応答の登録

IANA has registered the following values in the "OAuth Token Introspection Response" registry of the "OAuth Parameters" registry [IANA.OAuth.Parameters]. The "OAuth Token Introspection Response" registry was established by [RFC7662].

IANA は、"OAuth Parameters" レジストリ [IANA.OAuth.Parameters] の "OAuth Token Introspection Response" レジストリに以下の値を登録した。"OAuth Token Introspection Response" レジストリは [RFC7662] によって設立された。

* Name: act

名前: act

* Description: Actor

説明: アクター

* Change Controller: IESG

変更管理者: IESG

* Specification Document(s): Section 4.1 of RFC 8693

仕様文書: RFC 8693 の 4.1 節

* Name: may_act

名前: may_act

* Description: Authorized Actor - the party that is authorized to become the actor

説明: 認可されたアクター (アクターになることを認可された当事者)

* Change Controller: IESG

変更管理者: IESG

* Specification Document(s): Section 4.4 of RFC 8693

仕様文書: RFC 8693 の 4.4 節

8.References

8.参考資料

8.1.Normative References

8.1.引用規格

8.2.Informative References

8.2.参考文献

A.Additional Token Exchange Examples

A.トークン交換の追加例

Two example token exchanges are provided in the following sections illustrating impersonation and delegation, respectively (with extra line breaks and indentation for display purposes only).

以下の各節では、なりすましと委任をそれぞれ示す二つのトークン交換の例を示す (余分な改行とインデントは表示のためだけのものである)。

A.1.Impersonation Token Exchange Example

A.1.なりすましトークン交換の例

A.1.1.Token Exchange Request

A.1.1.トークン交換要求

In the following token exchange request, a client is requesting a token with impersonation semantics (delegation is impossible with only a "subject_token" and no "actor_token"). The client tells the authorization server that it needs a token for use at the target service with the logical name "urn:example:cooperation-context".

以下のトークン交換要求では、クライアントはなりすましのセマンティクスを持つトークンを要求している ("subject_token" のみで "actor_token" がない場合、委任は不可能である)。クライアントは認可サーバーに対し、論理名 "urn:example:cooperation-context" を持つ対象サービスで使用するためのトークンが必要であることを伝えている。

A.1.2.Subject Token Claims

A.1.2.subject トークンのクレーム

The "subject_token" in the prior request is a JWT, and the decoded JWT Claims Set is shown here. The JWT is intended for consumption by the authorization server within a specific time window. The subject of the JWT ("bdc@example.net") is the party on behalf of whom the new token is being requested.

前述の要求の "subject_token" は JWT であり、デコードされた JWT クレームセットをここに示す。この JWT は、特定の時間枠内に認可サーバーによって消費されることを意図している。JWT のサブジェクト ("bdc@example.net") は、新しいトークンがその当事者に代わって要求されている当事者である。

A.1.3.Token Exchange Response

A.1.3.トークン交換応答

The "access_token" parameter of the token exchange response shown below contains the new token that the client requested. The other parameters of the response indicate that the token is a bearer access token that expires in an hour.

以下に示すトークン交換応答の "access_token" パラメーターには、クライアントが要求した新しいトークンが含まれている。応答の他のパラメーターは、そのトークンが 1 時間で失効する bearer アクセストークンであることを示す。

A.1.4.Issued Token Claims

A.1.4.発行されたトークンのクレーム

The decoded JWT Claims Set of the issued token is shown below. The new JWT is issued by the authorization server and intended for consumption by a system entity known by the logical name "urn:example:cooperation-context" any time before its expiration. The subject ("sub") of the JWT is the same as the subject the token used to make the request, which effectively enables the client to impersonate that subject at the system entity known by the logical name of "urn:example:cooperation-context" by using the token.

発行されたトークンのデコードされた JWT クレームセットを以下に示す。新しい JWT は認可サーバーによって発行され、失効前であればいつでも、論理名 "urn:example:cooperation-context" で知られるシステムエンティティによって消費されることを意図している。JWT のサブジェクト ("sub") は、要求に用いられたトークンのサブジェクトと同一であり、これによりクライアントは、このトークンを用いて、論理名 "urn:example:cooperation-context" で知られるシステムエンティティにおいてそのサブジェクトになりすますことが事実上可能になる。

A.2.Delegation Token Exchange Example

A.2.委任トークン交換の例

A.2.1.Token Exchange Request

A.2.1.トークン交換要求

In the following token exchange request, a client is requesting a token and providing both a "subject_token" and an "actor_token". The client tells the authorization server that it needs a token for use at the target service with the logical name "urn:example:cooperation- context". Policy at the authorization server dictates that the issued token be a composite.

以下のトークン交換要求では、クライアントは "subject_token" と "actor_token" の双方を提供してトークンを要求している。クライアントは認可サーバーに対し、論理名 "urn:example:cooperation-context" を持つ対象サービスで使用するためのトークンが必要であることを伝えている。認可サーバーのポリシーにより、発行されるトークンは複合トークンとなる。

A.2.2.Subject Token Claims

A.2.2.subject トークンのクレーム

The "subject_token" in the prior request is a JWT, and the decoded JWT Claims Set is shown here. The JWT is intended for consumption by the authorization server before a specific expiration time. The subject of the JWT ("user@example.net") is the party on behalf of whom the new token is being requested.

前述の要求の "subject_token" は JWT であり、デコードされた JWT クレームセットをここに示す。この JWT は、特定の失効時刻より前に認可サーバーによって消費されることを意図している。JWT のサブジェクト ("user@example.net") は、新しいトークンがその当事者に代わって要求されている当事者である。

A.2.3.Actor Token Claims

A.2.3.actor トークンのクレーム

The "actor_token" in the prior request is a JWT, and the decoded JWT Claims Set is shown here. This JWT is also intended for consumption by the authorization server before a specific expiration time. The subject of the JWT ("admin@example.net") is the actor that will wield the security token being requested.

前述の要求の "actor_token" は JWT であり、デコードされた JWT クレームセットをここに示す。この JWT も、特定の失効時刻より前に認可サーバーによって消費されることを意図している。JWT のサブジェクト ("admin@example.net") は、要求されているセキュリティトークンを行使する行為者である。

A.2.4.Token Exchange Response

A.2.4.トークン交換応答

The "access_token" parameter of the token exchange response shown below contains the new token that the client requested. The other parameters of the response indicate that the token is a JWT that expires in an hour and that the access token type is not applicable since the issued token is not an access token.

以下に示すトークン交換応答の "access_token" パラメーターには、クライアントが要求した新しいトークンが含まれている。応答の他のパラメーターは、そのトークンが 1 時間で失効する JWT であること、および発行されたトークンがアクセストークンではないためアクセストークン種別が適用されないことを示す。

A.2.5.Issued Token Claims

A.2.5.発行されたトークンのクレーム

The decoded JWT Claims Set of the issued token is shown below. The new JWT is issued by the authorization server and intended for consumption by a system entity known by the logical name "urn:example:cooperation-context" any time before its expiration. The subject ("sub") of the JWT is the same as the subject of the "subject_token" used to make the request. The actor ("act") of the JWT is the same as the subject of the "actor_token" used to make the request. This indicates delegation and identifies "admin@example.net" as the current actor to whom authority has been delegated to act on behalf of "user@example.net".

発行されたトークンのデコードされた JWT クレームセットを以下に示す。新しい JWT は認可サーバーによって発行され、失効前であればいつでも、論理名 "urn:example:cooperation-context" で知られるシステムエンティティによって消費されることを意図している。JWT のサブジェクト ("sub") は、要求に用いられた "subject_token" のサブジェクトと同一である。JWT の行為者 ("act") は、要求に用いられた "actor_token" のサブジェクトと同一である。これは委任を示しており、"user@example.net" に代わって行動する権限を委任された現在の行為者として "admin@example.net" を識別している。

Acknowledgements

謝辞

This specification was developed within the OAuth Working Group, which includes dozens of active and dedicated participants. It was produced under the chairmanship of Hannes Tschofenig, Derek Atkins, and Rifaat Shekh-Yusef, with Kathleen Moriarty, Stephen Farrell, Eric Rescorla, Roman Danyliw, and Benjamin Kaduk serving as Security Area Directors.

本仕様は、数十名の活発で献身的な参加者を擁する OAuth ワーキンググループ内で策定された。Hannes Tschofenig、Derek Atkins、Rifaat Shekh-Yusef の議長の下で作成され、Kathleen Moriarty、Stephen Farrell、Eric Rescorla、Roman Danyliw、Benjamin Kaduk がセキュリティエリアディレクターを務めた。

The following individuals contributed ideas, feedback, and wording to this specification: Caleb Baker, Vittorio Bertocci, Mike Brown, Thomas Broyer, Roman Danyliw, William Denniss, Vladimir Dzhuvinov, Eric Fazendin, Phil Hunt, Benjamin Kaduk, Jason Keglovitz, Torsten Lodderstedt, Barry Leiba, Adam Lewis, James Manger, Nov Matake, Matt Miller, Hilarie Orman, Matthew Perry, Eric Rescorla, Justin Richer, Adam Roach, Rifaat Shekh-Yusef, Scott Tomilson, and Hannes Tschofenig.

以下の方々が本仕様にアイデア、フィードバック、文言を提供した: Caleb Baker、Vittorio Bertocci、Mike Brown、Thomas Broyer、Roman Danyliw、William Denniss、Vladimir Dzhuvinov、Eric Fazendin、Phil Hunt、Benjamin Kaduk、Jason Keglovitz、Torsten Lodderstedt、Barry Leiba、Adam Lewis、James Manger、Nov Matake、Matt Miller、Hilarie Orman、Matthew Perry、Eric Rescorla、Justin Richer、Adam Roach、Rifaat Shekh-Yusef、Scott Tomilson、Hannes Tschofenig。