RFC 8693 - OAuth 2.0 Token Exchange 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8693.html
タイトル : RFC 8693 - OAuth 2.0トークン交換
翻訳編集 : 自動生成

[要約] RFC 8693は、OAuth 2.0 Token Exchangeプロトコルに関する仕様です。この仕様の目的は、OAuthトークンの交換を容易にし、セキュリティとプライバシーを向上させることです。

Internet Engineering Task Force (IETF)                          M. Jones
Request for Comments: 8693                                    A. Nadalin
Category: Standards Track                                      Microsoft
ISSN: 2070-1721                                         B. Campbell, Ed.
                                                           Ping Identity
                                                              J. Bradley
                                                                  Yubico
                                                            C. Mortimore
                                                                    Visa
                                                            January 2020

OAuth 2.0 Token Exchange

OAuth 2.0トークン交換

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）のプロトコルを定義しています。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8693.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8693で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Delegation vs. Impersonation Semantics
     1.2.  Requirements Notation and Conventions
     1.3.  Terminology
   2.  Token Exchange Request and Response
     2.1.  Request
       2.1.1.  Relationship between Resource, Audience, and Scope
     2.2.  Response
       2.2.1.  Successful Response
       2.2.2.  Error Response
     2.3.  Example Token Exchange
   3.  Token Type Identifiers
   4.  JSON Web Token Claims and Introspection Response Parameters
     4.1.  "act" (Actor) Claim
     4.2.  "scope" (Scopes) Claim
     4.3.  "client_id" (Client Identifier) Claim
     4.4.  "may_act" (Authorized Actor) Claim
   5.  Security Considerations
   6.  Privacy Considerations
   7.  IANA Considerations
     7.1.  OAuth URI Registration
     7.2.  OAuth Parameters Registration
     7.3.  OAuth Access Token Type Registration
     7.4.  JSON Web Token Claims Registration
     7.5.  OAuth Token Introspection Response Registration
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Additional Token Exchange Examples
     A.1.  Impersonation Token Exchange Example
       A.1.1.  Token Exchange Request
       A.1.2.  Subject Token Claims
       A.1.3.  Token Exchange Response
       A.1.4.  Issued Token Claims
     A.2.  Delegation Token Exchange Example
       A.2.1.  Token Exchange Request
       A.2.2.  Subject Token Claims
       A.2.3.  Actor Token Claims
       A.2.4.  Token Exchange Response
       A.2.5.  Issued Token Claims
   Acknowledgements
   Authors' Addresses

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].

セキュリティトークンは、異種環境またはセキュリティドメイン間でのIDおよびセキュリティ情報の共有を容易にする一連の情報です。セキュリティトークンの例には、JSON Web Tokens（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 Authorization Framework [RFC6749]とOAuth 2.0 Bearer Tokens [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の一般的な使用例の1つは、リソースサーバー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を処理します。IDシステムの一部のメンバーは、偽装が行われていることを認識している可能性があります要件ではありません。すべての意図と目的で、AがBに成り代わっている場合、Aはトークンによって承認された権限のコンテキスト内ではBです。 AがBを偽装する能力は、トークンの内容またはアウトオブバンドメカニズムのどちらを使用する場合でも、スコープまたは時間に制限されたり、1回限りの使用制限で制限されたりする場合があります。

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.

委任のセマンティクスは偽装のセマンティクスとは異なりますが、2つは密接に関連しています。委任のセマンティクスでは、プリンシパルAは依然としてBとは別の独自のIDを持ち、Bはその権利の一部をAに委任している可能性がありますが、実行されたアクションはすべて、Bを表す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.

委任のセマンティクスは通常、トークンの主要なサブジェクトと、そのサブジェクトがその権利の一部を委任したアクターの両方に関する情報を含めることにより、トークンで表現されます。このようなトークンは、複数のサブジェクトに関する情報で構成されるため、複合トークンと呼ばれることがあります。通常、リクエストでは、「subject_token」はトークンが要求されている当事者のIDを表し、「actor_token」は発行されたトークンのアクセス権が委任されている当事者のIDを表します。許可サーバーによって発行された複合トークンには、両方の当事者に関する情報が含まれます。複合トークンがいつ発行されるかは、許可サーバーと適用可能なポリシーおよび構成の裁量に任されます。

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 Encoding」、「Claim」、および「JWT Claims Set」という用語。

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]は、ベアラー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は必須です。値「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.

リソースはオプションです。クライアントが要求されたセキュリティトークンを使用する予定のターゲットサービスまたはリソースを示すURI。これにより、許可サーバーは、発行するトークンのタイプと内容、またはトークンを暗号化するかどうか、またどのように暗号化するかなど、ターゲットに適したポリシーを適用できます。多くの場合、クライアントは、対話するシステムの論理的な構成についての知識を持たず、トークンを使用するサービスのURIのみを知っています。「リソース」パラメーターを使用すると、クライアントは、そのリソースへのアクセスに使用されるのと同じ形式のトークン交換リクエストで、通常はhttps URLとして場所を提供することにより、発行されたトークンを使用する場所を承認サーバーに示すことができます。。認可サーバーは通常、リソースURI値から適切なポリシーにマップする機能を備えています。 [resource]パラメータの値は、[RFC3986]のセクション4.3で指定されているように、クエリコンポーネントを含めることができ、フラグメントコンポーネントを含めてはならない絶対URIにする必要があります。複数の「リソース」パラメータを使用して、発行されたトークンがリストされている複数のリソースで使用されることを意図していることを示すことができます。「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.

視聴者オプション。クライアントが要求されたセキュリティトークンを使用する予定のターゲットサービスの論理名。これは「リソース」パラメータと同様の目的を果たしますが、クライアントはターゲットサービスの論理名を提供します。名前を解釈するには、値がクライアントと許可サーバーの両方が理解できるものである必要があります。 OAuthクライアント識別子、SAMLエンティティ識別子[OASIS.saml-core-2.0-os]、およびOpenID Connect発行者識別子[OpenID.Core]は、「オーディエンス」パラメーター値として使用できるものの例です。ただし、所定の許可サーバーで使用される「オーディエンス」値は、意図したタイプの値として適切に解釈されるように、そのサーバー内で固有でなければなりません。複数の「オーディエンス」パラメーターを使用して、発行されたトークンがリストされている複数のオーディエンスで使用されることを意図していることを示すことができます。「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.

スコープオプション。 [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が必要です。要求が行われている当事者のIDを表すセキュリティトークン。通常、このトークンのサブジェクトは、要求に応答して発行されるセキュリティトークンのサブジェクトになります。

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が必要です。セクション3で説明したように、 "subject_token"パラメータのセキュリティトークンのタイプを示す識別子。

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オプション。代行者のIDを表すセキュリティトークン。通常、これは、要求されたセキュリティトークンを使用する権限があり、サブジェクトに代わって動作する当事者です。

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セクション3で説明したように、「actor_token」パラメータのセキュリティトークンのタイプを示す識別子。これは、リクエストに「actor_token」パラメータが存在する場合に必須ですが、それ以外の場合は含めないでください。

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.

リクエストを処理する際に、認可サーバーは指定されたトークンタイプに適切な検証手順を実行する必要があり、アクタートークンが存在する場合は、指定されたトークンタイプに適切な検証手順も実行する必要があります。特定のトークンの有効性の基準と詳細は、このドキュメントの範囲外であり、それぞれのタイプのトークンとその内容に固有のものです。

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.

トークンタイプに固有の1回限りの使用またはその他のセマンティクスがない場合、トークン交換を実行する動作は、サブジェクトトークンまたはアクタートークンの有効性に影響を与えません。さらに、交換は1回限りのイベントであり、入力トークンと出力トークンの間の緊密なリンクを作成しないため、（たとえば）出力トークンの有効期限が入力トークンの有効期限によって影響を受ける可能性がある一方で、更新または入力トークンの拡張が出力トークンのプロパティに反映されることは想定されていません。トークン失効イベントを伝播することが適切または望ましい場合があります。ただし、これはSTSプロトコルの一般的なプロパティではなく、特定の実装、トークンタイプ、またはデプロイメントに固有のものです。

2.1.1. Relationship between Resource, Audience, and Scope

2.1.1. リソース、対象者、範囲の関係

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.

リクエストが有効で、承認サーバーのすべてのポリシーとその他の基準を満たしている場合、「application / json」メディアタイプを使用して、次のパラメータをHTTP応答のエンティティ本体に追加することにより、成功したトークン応答が作成されます。 [RFC8259]、および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が必要です。トークン交換要求に応答して許可サーバーによって発行されたセキュリティー・トークン。 [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.

発行されたトークンの種類が必要です。セクション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は必須です。 [RFC6749]のセクション7.1で指定されている、発行されたアクセストークンの使用方法を指定する、大文字と小文字を区別しない値。これは、保護されたリソースにアクセスするためのアクセストークンの利用方法に関する情報をクライアントに提供します。たとえば、[RFC6750]で指定されている「Bearer」の値は、発行されたセキュリティトークンがベアラートークンであり、クライアントがトークン自体の内容以外の適格性の追加の証明なしに、それをそのまま提示できることを示します。このパラメータの意味は、発行されたセキュリティトークンの表現を宣言する「issued_token_type」パラメータの意味とは異なることに注意してください。「トークンタイプ」という用語は、この仕様のすべての「* _token_type」パラメータと同様に、セキュリティトークンの構造的または構文的な表現を意味するために、より一般的に使用されます。発行されたトークンがアクセストークンではない、またはアクセストークンとして使用できない場合、「token_type」の値「N_A」を使用して、OAuth 2.0の「token_type」識別子がそのコンテキストに適用されないことを示します。

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.

発行されたセキュリティトークンのスコープがクライアントによって要求されたスコープと同一の場合はOPTIONAL。それ以外の場合は必須です。

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オプション。交換が1つの一時的な認証情報（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で指定されているように、エラー応答を作成する必要があります。「error」パラメータの値は、「invalid_request」エラーコードである必要があります。

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」を使用してエラーの理由に関する追加情報を含めることができます。

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アクセストークンを含む保護されたリソースリクエストを受信するリソースサーバーを示しています。

    GET /resource HTTP/1.1
    Host: frontend.example.com
    Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC

Figure 1: Protected Resource Request

図1：保護されたリソース要求

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基本認証スキームを使用する承認サーバーに対して認証します。「resource」パラメータは、発行されたトークンが使用されるバックエンドサービス<https://backend.example.com/api>の場所を示します。

    POST /as/token.oauth2 HTTP/1.1
    Host: as.example.com
    Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0
    Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &resource=https%3A%2F%2Fbackend.example.com%2Fapi &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC &subject_token_type= urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token

grant_type = urn％3Aietf％3Aparams％3Aoauth％3Agrant-type％3Atoken-exchange＆resource = https％3A％2F％2Fbackend.example.com％2Fapi＆subject_token = accVkjcJyb4BWCxGstype3％type_Act％type％3％type_A %%% A %%% A %%% A %% A %% A %%% A %%% A %% A %%% A %% A %%%% A %% A %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% F %%%%%%%%%%%% ==

Figure 2: Token Exchange Request

図2：トークン交換リクエスト

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」を検証します。「リソース」パラメーターから、認証サーバーはリクエストに適用する適切なポリシーを決定し、<https://backend.example.com>での使用に適したトークンを発行できます。図3に示す応答の "access_token"パラメーターには、それ自体が1分間有効なベアラーOAuthアクセストークンである新しいトークンが含まれています。トークンはたまたまJWTです。ただし、その構造と形式はクライアントに対して不透明であるため、「issued_token_type」はそれがアクセストークンであることのみを示します。

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

    {
     "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo
       dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV
       4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn
       N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx
       f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM
       y5-kdXjwhw",
     "issued_token_type":
         "urn:ietf:params:oauth:token-type:access_token",
     "token_type":"Bearer",
     "expires_in":60
    }

Figure 3: Token Exchange Response

図3：トークン交換応答

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に示すように、新しく取得したアクセストークンを使用して、バックエンドサーバーにリクエストを送信できます。

GET /api HTTP/1.1 Host: backend.example.com Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2 FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW vmDCMy5-kdXjwhw

GET / API HTTP / 1.1ホスト：backend.example.com認証：ベアラeyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2 FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW vmDCMy5-kdXjwhw

Figure 4: Backend Protected Resource Request

図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は他のトークンタイプを示すために使用されるかもしれません。

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"（俳優）クレーム

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」（俳優）クレームは、委任が発生したことを表明し、権限が委任された代理人を識別するJWT内の手段を提供します。「act」クレーム値はJSONオブジェクトであり、JSONオブジェクトのメンバーはアクターを識別するクレームです。「act」クレームを構成するクレームは、俳優に関する追加情報を特定し、可能であれば提供します。たとえば、俳優を一意に識別するには、2つのクレーム「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」クレーム内のクレームは、アクターのIDにのみ関連し、最上位のクレームと同じように、含まれている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」（俳優）クレームを示しています。トークン自体のクレームはuser@example.comに関するものですが、「act」クレームはadmin@example.comが現在のアクターであることを示しています。

    {
      "aud":"https://consumer.example.com",
      "iss":"https://issuer.example.com",
      "exp":1443904177,
      "nbf":1443904077,
      "sub":"user@example.com",
      "act":
      {
        "sub":"admin@example.com"
      }
    }

Figure 5: Actor Claim

図5：アクターの主張

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」クレームは、現在のアクターに到達する前に行われるさまざまな委任手順を通じて最初のリクエストとサブジェクトを接続する履歴証跡として機能します。この意味で、現在のアクターは承認/委任履歴全体を含むと見なされ、ここで説明する入れ子構造に自然につながります。

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」クレームによって現在のアクターとして識別されたパーティーのみを考慮する必要があります。ネストされた「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」（アクター）クレームを示しています。トークン自体のクレームはuser@example.comに関するものですが、「act」クレームは、システム<https://service16.example.com>が現在のアクターであり、<https://service77.example.com>であることを示しています。以前の俳優だった。このようなトークンは、service16がservice77からの呼び出しでトークンを受信し、それをservice26の呼び出しに適したトークンと交換した結果として発生する可能性があります。

    {
      "aud":"https://service26.example.com",
      "iss":"https://issuer.example.com",
      "exp":1443904100,
      "nbf":1443904000,
      "sub":"user@example.com",
      "act":
      {
        "sub":"https://service16.example.com",
        "act":
        {
          "sub":"https://service77.example.com"
        }
      }
    }

Figure 6: Nested Actor Claim

図6：ネストされた俳優の主張

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. 「スコープ」（スコープ）クレーム

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」クレームの値は、トークンに関連付けられたスコープのスペース区切りのリストを含むJSON文字列で、[RFC6749]のセクション3.3で説明されている形式です。

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

図7は、JWTクレームセット内の「スコープ」クレームを示しています。

    {
      "aud":"https://consumer.example.com",
      "iss":"https://issuer.example.com",
      "exp":1443904177,
      "nbf":1443904077,
      "sub":"dgaf4mvfs75Fci_FL3heQA",
      "scope":"email profile phone address"
    }

Figure 7: Scopes Claim

図7：スコープの主張

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

OAuth 2.0トークンイントロスペクション[RFC7662]では、トークンに関連付けられたスコープを伝達するための「スコープ」パラメータがすでに定義されています。

4.3. "client_id" (Client Identifier) Claim

4.3. "client_id"（クライアント識別子）クレーム

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クライアントを示しています。

    {
      "aud":"https://consumer.example.com",
      "iss":"https://issuer.example.com",
      "exp":1443904177,
      "sub":"user@example.com",
      "client_id":"s6BhdRkqt3"
    }

Figure 8: Client Identifier Claim

図8：クライアント識別子の要求

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]は、すでに "client_id"パラメータを、トークンを要求したOAuth 2.0クライアントのクライアント識別子として定義しています。

4.4. "may_act" (Authorized Actor) Claim

4.4. "may_act"（認定俳優）クレーム

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」がトークンエンドポイントに提示され、サブジェクトトークンの「may_act」クレームを認証サーバーで使用して、クライアント（またはパーティー「actor_token」内）は、要求された委任または偽装に従事することが許可されています。クレーム値はJSONオブジェクトであり、JSONオブジェクトのメンバーは、クレームを含むJWTによって識別されるパーティーに対して行動する資格があると主張されているパーティーを識別するクレームです。「may_act」クレームを構成するクレームは、許可されたアクターに関する識別情報と、場合によっては追加情報を提供します。たとえば、承認された俳優を一意に識別するために、2つのクレーム「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」クレーム内のクレームは、そのパーティーのIDにのみ関連し、最上位のクレームと同じ方法で包含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に代わって行動することを許可されていることを示しています。

    {
      "aud":"https://consumer.example.com",
      "iss":"https://issuer.example.com",
      "exp":1443904177,
      "nbf":1443904077,
      "sub":"user@example.com",
      "may_act":
      {
        "sub":"admin@example.com"
      }
    }

Figure 9: Authorized Actor Claim

図9：承認された俳優の主張

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.

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

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.

[RFC6749]のセクション10のガイダンスであるOAuth 2.0承認フレームワークのセキュリティに関する考慮事項の多くは、ここでも適用されます。さらに、[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.

さらに、委任と偽装の両方で固有のセキュリティ問題が発生します。あるプリンシパルが別のプリンシパルの権利を委任されるときはいつでも、虐待の可能性が懸念されます。「スコープ」クレームを使用すると、トークンの有効期間が制限されるなどの他の一般的な制約に加えて、委任された権利を行使できるコンテキストが制限されるため、このような悪用の可能性を軽減することが推奨されます。

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.

ここで説明する機能のコンテキストで使用されるトークンはプライバシーに敏感な情報を含む可能性があり、意図しない関係者へのそのような情報の開示を防ぐために、トランスポート層セキュリティ（TLS）などの暗号化チャネルでのみ送信する必要があります。特定の情報がクライアントに開示されないようにすることが望ましい場合は、意図した受信者に対してトークンを暗号化する必要があります。デプロイメントでは、必要最小限のデータ量を決定し、発行されたトークンにそのような情報のみを含める必要があります。場合によっては、データの最小化には、匿名または偽名のユーザーのみを表すことが含まれます。

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 * Common Name: Token exchange grant type for OAuth 2.0 * Change Controller: IESG * Specification Document: Section 2.1 of RFC 8693

* URN：urn：ietf：params：oauth：grant-type：token-exchange *一般名：OAuth 2.0のトークン交換付与タイプ*変更コントローラ：IESG *仕様ドキュメント：RFC 8693のセクション2.1

* URN: urn:ietf:params:oauth:token-type:access_token * Common Name: Token type URI for an OAuth 2.0 access token * Change Controller: IESG * Specification Document: Section 3 of RFC 8693

* URN：urn：ietf：params：oauth：token-type：access_token *一般名：OAuth 2.0アクセストークンのトークンタイプURI *変更コントローラ：IESG *仕様ドキュメント：RFC 8693のセクション3

* URN: urn:ietf:params:oauth:token-type:refresh_token * Common Name: Token type URI for an OAuth 2.0 refresh token * Change Controller: IESG * Specification Document: Section 3 of RFC 8693

* URN：urn：ietf：params：oauth：token-type：refresh_token *一般名：OAuth 2.0更新トークンのトークンタイプURI *変更コントローラー：IESG *仕様ドキュメント：RFC 8693のセクション3

* URN: urn:ietf:params:oauth:token-type:id_token * Common Name: Token type URI for an ID Token * Change Controller: IESG * Specification Document: Section 3 of RFC 8693

* URN：urn：ietf：params：oauth：token-type：id_token *一般名：IDトークンのトークンタイプURI *変更コントローラ：IESG *仕様ドキュメント：RFC 8693のセクション3

* URN: urn:ietf:params:oauth:token-type:saml1 * Common Name: Token type URI for a base64url-encoded SAML 1.1 assertion * Change Controller: IESG * Specification Document: Section 3 of RFC 8693

* URN：urn：ietf：params：oauth：token-type：saml1 *一般名：base64urlでエンコードされたSAML 1.1アサーションのトークンタイプURI *変更コントローラ：IESG *仕様ドキュメント：RFC 8693のセクション3

* URN: urn:ietf:params:oauth:token-type:saml2 * Common Name: Token type URI for a base64url-encoded SAML 2.0 assertion * Change Controller: IESG * Specification Document: Section 3 of RFC 8693

* URN：urn：ietf：params：oauth：token-type：saml2 *一般名：base64urlでエンコードされたSAML 2.0アサーションのトークンタイプURI *変更コントローラ：IESG *仕様ドキュメント：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」レジストリの「OAuth Parameters」サブレジストリ[IANA.OAuth.Parameters]に次の値を登録しました。 "OAuth Parameters"サブレジストリは[RFC6749]によって確立されました。

* Parameter name: audience * Parameter usage location: token request * Change controller: IESG * Specification document(s): Section 2.1 of RFC 8693

* パラメータ名：オーディエンス*パラメータの使用場所：トークンリクエスト*変更コントローラ：IESG *仕様書：RFC 8693のセクション2.1

* Parameter name: requested_token_type * Parameter usage location: token request * Change controller: IESG * Specification document(s): Section 2.1 of RFC 8693

* パラメータ名：requested_token_type *パラメータの使用場所：トークンリクエスト*変更コントローラ：IESG *仕様書：RFC 8693のセクション2.1

* Parameter name: subject_token * Parameter usage location: token request * Change controller: IESG * Specification document(s): Section 2.1 of RFC 8693

* パラメータ名：subject_token *パラメータの使用場所：トークンリクエスト*変更コントローラ：IESG *仕様書：RFC 8693のセクション2.1

* Parameter name: subject_token_type * Parameter usage location: token request * Change controller: IESG * Specification document(s): Section 2.1 of RFC 8693

* パラメータ名：subject_token_type *パラメータの使用場所：トークンリクエスト*変更コントローラ：IESG *仕様書：RFC 8693のセクション2.1

* Parameter name: actor_token * Parameter usage location: token request * Change controller: IESG * Specification document(s): Section 2.1 of RFC 8693

* パラメータ名：actor_token *パラメータの使用場所：トークンリクエスト*変更コントローラ：IESG *仕様書：RFC 8693のセクション2.1

* Parameter name: actor_token_type * Parameter usage location: token request * Change controller: IESG * Specification document(s): Section 2.1 of RFC 8693

* パラメータ名：actor_token_type *パラメータの使用場所：トークンリクエスト*変更コントローラ：IESG *仕様書：RFC 8693のセクション2.1

* Parameter name: issued_token_type * Parameter usage location: token response * Change controller: IESG * Specification document(s): Section 2.2.1 of RFC 8693

* パラメータ名：発行されたトークンのタイプ*パラメータの使用場所：トークン応答*変更コントローラ：IESG *仕様書：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パラメータ」レジストリ[IANA.OAuth.Parameters]の「OAuthアクセストークンタイプ」サブレジストリに次のアクセストークンタイプを登録しました。「OAuth Access Token Types」サブレジストリは、[RFC6749]によって確立されました。

* Type name: N_A * Additional Token Endpoint Response Parameters: none * HTTP Authentication Scheme(s): none * Change controller: IESG * Specification document(s): Section 2.2.1 of RFC 8693

* タイプ名：N_A *追加のトークンエンドポイントレスポンスパラメータ：なし* HTTP認証方式：なし*変更コントローラ：IESG *仕様書：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 * Claim Description: Actor * Change Controller: IESG * Specification Document(s): Section 4.1 of RFC 8693

* クレーム名：act *クレームの説明：アクター*変更コントローラ：IESG *仕様書：RFC 8693のセクション4.1

* Claim Name: scope * Claim Description: Scope Values * Change Controller: IESG * Specification Document(s): Section 4.2 of RFC 8693

* クレーム名：スコープ*クレームの説明：スコープの値*変更コントローラー：IESG *仕様書：RFC 8693のセクション4.2

* Claim Name: client_id * Claim Description: Client Identifier * Change Controller: IESG * Specification Document(s): Section 4.3 of RFC 8693

* クレーム名：client_id *クレームの説明：クライアントID *変更管理者：IESG *仕様書：RFC 8693のセクション4.3

* Claim Name: may_act * Claim Description: Authorized Actor - the party that is authorized to become the actor * Change Controller: IESG * Specification Document(s): Section 4.4 of RFC 8693

* クレーム名：may_act *クレームの説明：承認された俳優-俳優になることを承認された当事者*変更管理者：IESG *仕様書：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 * Description: Actor * Change Controller: IESG * Specification Document(s): Section 4.1 of RFC 8693

* 名前：act *説明：アクター*変更コントローラ：IESG *仕様書：RFC 8693のセクション4.1

* Name: may_act * Description: Authorized Actor - the party that is authorized to become the actor * Change Controller: IESG * Specification Document(s): Section 4.4 of RFC 8693

* 名前：may_act *説明：許可された俳優-俳優になることを許可された当事者*変更管理者：IESG *仕様書：RFC 8693のセクション4.4

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[IANA.JWT] IANA, "JSON Web Token (JWT)", <https://www.iana.org/assignments/jwt>.

[IANA.JWT] IANA、「JSON Web Token（JWT）」、<https://www.iana.org/assignments/jwt>。

[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.

[IANA.OAuth.Parameters] IANA、「OAuthパラメータ」、<https://www.iana.org/assignments/oauth-parameters>。

[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.

[JWT]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https://www.rfc-editor.org / info / rfc7519>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。

[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.

[RFC7662] Richer、J。、編、「OAuth 2.0トークンイントロスペクション」、RFC 7662、DOI 10.17487 / RFC7662、2015年10月、<https://www.rfc-editor.org/info/rfc7662>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.

[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。

8.2. Informative References

8.2. 参考引用

[OASIS.saml-core-1.1] Maler, E., Mishra, P., and R. Philpott, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1", OASIS Standard oasis-sstc-saml-core-1.1, September 2003, <https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf>.

[OASIS.saml-core-1.1] Maler、E.、Mishra、P。、およびR. Philpott、「OASIS Security Assertion Markup Language（SAML）V1.1のアサーションおよびプロトコル」、OASIS標準oasis-sstc-saml -core-1.1、2003年9月、<https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf>。

[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.

[OASIS.saml-core-2.0-os] Cantor、S.、Kemp、J.、Philpott、R.、and E. Maler、 "Assertions and Protocol for the OASIS Security Assertion Markup Language（SAML）V2.0"、 OASIS標準saml-core-2.0-os、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>。

[OAUTH-RESOURCE] Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", Work in Progress, Internet-Draft, draft-ietf-oauth-resource-indicators-08, 11 September 2019, <https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08>.

[OAUTH-RESOURCE] Campbell、B.、Bradley、J。、およびH. Tschofenig、「OAuth 2.0のリソースインジケーター」、Work in Progress、Internet-Draft、draft-ietf-oauth-resource-indicators-08、9月11日2019、<https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-08>。

[OAUTH-SECURITY] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "OAuth 2.0 Security Best Current Practice", Work in Progress, Internet-Draft, draft-ietf-oauth-security-topics-13, 8 July 2019, <https://tools.ietf.org/html/ draft-ietf-oauth-security-topics-13>.

[OAUTH-SECURITY] Lodderstedt、T.、Bradley、J.、Labunets、A。、およびD. Fett、「OAuth 2.0 Security Best Current Practice」、Work in Progress、Internet-Draft、draft-ietf-oauth-security- topics-13、2019年7月8日、<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13>。

[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <https://openid.net/specs/openid-connect-core-1_0.html>.

[OpenID.Core] Sakimura、N.、Bradley、J.、Jones、M.、de Medeiros、B、C。Mortimore、「OpenID Connect Core 1.0」、2014年11月、<https://openid.net/ specs / openid-connect-core-1_0.html>。

[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/info/rfc6750>.

[RFC6750]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、DOI 10.17487 / RFC6750、2012年10月、<https://www.rfc-editor.org/info/ rfc6750>。

[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/info/rfc6755>.

[RFC6755] Campbell、B。およびH. Tschofenig、「An an ITF URN Sub-Namespace for OAuth」、RFC 6755、DOI 10.17487 / RFC6755、2012年10月、<https://www.rfc-editor.org/info/rfc6755 >。

[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <https://www.rfc-editor.org/info/rfc6819>.

[RFC6819] Lodderstedt、T.、Ed。、McGloin、M。、およびP. Hunt、「OAuth 2.0脅威モデルとセキュリティの考慮事項」、RFC 6819、DOI 10.17487 / RFC6819、2013年1月、<https：//www.rfc -editor.org/info/rfc6819>。

[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <https://www.rfc-editor.org/info/rfc7521>.

[RFC7521] Campbell、B.、Mortimore、C.、Jones、M。、およびY. Goland、「OAuth 2.0クライアント認証および許可付与のためのアサーションフレームワーク」、RFC 7521、DOI 10.17487 / RFC7521、2015年5月、<https： //www.rfc-editor.org/info/rfc7521>。

[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/info/rfc7523>.

[RFC7523]ジョーンズ、M。、キャンベル、B。、およびC.モーティモア、「OAuth 2.0クライアント認証および許可付与のためのJSON Webトークン（JWT）プロファイル」、RFC 7523、DOI 10.17487 / RFC7523、2015年5月、<https： //www.rfc-editor.org/info/rfc7523>。

[WS-Trust] Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed., Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust 1.4", February 2012, <https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html>.

[WS-Trust] Nadalin、A.、Ed。、Goodner、M.、Ed。、Gudgin、M.、Ed。、Barbir、A.、Ed。、and H. Granqvist、Ed。、 "WS-Trust 1.4 "、2012年2月、<https://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html>。

Appendix 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).

次のセクションでは、偽装と委任をそれぞれ示す2つのトークン交換の例を示します（追加の改行とインデントは表示目的のみです）。

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」のターゲットサービスで使用するトークンが必要であることを許可サーバーに通知します。

    POST /as/token.oauth2 HTTP/1.1
    Host: as.example.com
    Content-Type: application/x-www-form-urlencoded

Figure 10: Token Exchange Request

図10：トークン交換リクエスト

A.1.2. Subject Token Claims

A.1.2. サブジェクトトークンの要求

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"）は、新しいトークンが要求されている当事者です。

     {
       "aud":"https://as.example.com",
       "iss":"https://original-issuer.example.net",
       "exp":1441910600,
       "nbf":1441909000,
       "sub":"bdc@example.net",
       "scope":"orders profile history"
     }

Figure 11: Subject Token Claims

図11：サブジェクトトークンの要求

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時間で期限切れになるベアラアクセストークンであることを示しています。

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

    {
     "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
       6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
       eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub
       mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF
       uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW
       nVKh85A",
     "issued_token_type":
       "urn:ietf:params:oauth:token-type:access_token",
     "token_type":"Bearer",
     "expires_in":3600
    }

Figure 12: Token Exchange Response

図12：トークン交換応答

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のサブジェクト（「サブ」）は、リクエストを作成するために使用されるトークンのサブジェクトと同じです。これにより、クライアントは、「urn：example：cooperation-」の論理名で知られるシステムエンティティでそのサブジェクトを偽装できます。トークンを使用して」。

     {
       "aud":"urn:example:cooperation-context",
       "iss":"https://as.example.com",
       "exp":1441913610,
       "sub":"bdc@example.net",
       "scope":"orders profile history"
     }

Figure 13: Issued Token Claims

図13：発行されたトークンの要求

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」のターゲットサービスで使用するトークンが必要であることを許可サーバーに通知します。許可サーバーのポリシーは、発行されたトークンが複合であることを指示します。

    POST /as/token.oauth2 HTTP/1.1
    Host: as.example.com
    Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange &audience=urn%3Aexample%3Acooperation-context &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1 pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt &actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ oUuDL2tEs6tqPlcBlMjiSzEjm3yBg &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

grant_type = URN％3Aietf％3Aparams％3Aoauth％3Agrant型％3Atoken交換＆観客= URN％3Aexample％3Acooperationコンテキスト＆subject_token = eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1 pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM XU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g＆subject_token_type = URN％3Aietf％ 3Aparams％3Aoauth％3Atoken型％3Ajwt＆actor_token = eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ oUuDL2tEs6tqPlcBlMjiSzEjm3yBg＆actor_token_type = URN％3Aietf％3Aparams％3Aoauth％3Atoken型％3Ajwt

Figure 14: Token Exchange Request

図14：トークン交換リクエスト

A.2.2. Subject Token Claims

A.2.2. サブジェクトトークンの要求

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"）は、新しいトークンが要求されている当事者に代わるものです。

     {
       "aud":"https://as.example.com",
       "iss":"https://original-issuer.example.net",
       "exp":1441910060,
       "scope":"status feed",
       "sub":"user@example.net",
       "may_act":
       {
         "sub":"admin@example.net"
       }
     }

Figure 15: Subject Token Claims

図15：サブジェクトトークンの要求

A.2.3. Actor Token Claims

A.2.3. 俳優トークンの主張

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"）は、要求されているセキュリティトークンを使用するアクターです。

     {
       "aud":"https://as.example.com",
       "iss":"https://original-issuer.example.net",
       "exp":1441910060,
       "sub":"admin@example.net"
     }

Figure 16: Actor Token Claims

図16：アクタートークンの要求

A.2.4. Token Exchange Response

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

以下に示すトークン交換応答の「access_token」パラメーターには、クライアントが要求した新しいトークンが含まれています。応答の他のパラメーターは、トークンが1時間で期限切れになるJWTであり、発行されたトークンはアクセストークンではないため、アクセストークンタイプは適用できないことを示しています。

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

    {
     "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
       6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
       eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ
       CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX
       hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG
       9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw",
     "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
     "token_type":"N_A",
     "expires_in":3600
    }

Figure 17: Token Exchange Response

図17：トークン交換応答

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」のサブジェクトと同じです。これは委任を示し、「admin@example.net」が「user@example.net」に代わって行動する権限が委任された現在のアクターとして識別されます。

     {
       "aud":"urn:example:cooperation-context",
       "iss":"https://as.example.com",
       "exp":1441913610,
       "scope":"status feed",
       "sub":"user@example.net",
       "act":
       {
         "sub":"admin@example.net"
       }
     }

Figure 18: Issued Token Claims

図18：発行されたトークンの要求

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、バリー・レイバ、アダム・ルイス、ジェームズ・マンガー、ノヴ・マタケ、マット・ミラー、ヒラリー・オーマン、マシュー・ペリー、エリック・レスコーラ、ジャスティン・リチャー、アダム・ローチ、リファート・シェク・ユセフ、スコット・トミルソン、ハンネス・ショフェニグ。

Authors' Addresses

著者のアドレス

Michael B. Jones Microsoft

マイケルB.ジョーンズマイクロソフト

   Email: mbj@microsoft.com
   URI:   https://self-issued.info/

Anthony Nadalin Microsoft

アンソニーナダリンマイクロソフト

   Email: tonynad@microsoft.com

Brian Campbell (editor) Ping Identity

ブライアンキャンベル（編集者）Ping Identity

   Email: brian.d.campbell@gmail.com

John Bradley Yubico

ジョンブラッドリーユビコ

   Email: ve7jtb@ve7jtb.com

Chuck Mortimore Visa

   Email: chuck.mortimore@visa.com