Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 9767 Bespoke Engineering
Category: Standards Track F. Imbault
ISSN: 2070-1721 acert.io
April 2025
The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software (the client) and conveying the results and artifacts of that delegation to the software. This extension defines methods for resource servers (RSs) to connect with authorization servers (ASs) in an interoperable fashion.
助成金交渉と承認プロトコル（GNAP）は、許可をソフトウェア（クライアント）に委任し、その委任の結果とアーティファクトをソフトウェアに伝えるメカニズムを定義します。この拡張機能は、リソースサーバー（RSS）の方法を定義して、相互運用可能な方法で認証サーバー（ASS）に接続します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9767.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9767で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. Access Tokens
2.1. General-Purpose Access Token Model
2.1.1. Value
2.1.2. Issuer
2.1.3. Audience
2.1.4. Key Binding
2.1.5. Flags
2.1.6. Access Rights
2.1.7. Time Validity Window
2.1.8. Token Identifier
2.1.9. Authorizing Resource Owner
2.1.10. End User
2.1.11. Client Instance
2.1.12. Label
2.1.13. Parent Grant Request
2.1.14. AS-Specific Access Tokens
2.2. Access Token Formats
3. Resource-Server-Facing API
3.1. RS-Facing AS Discovery
3.2. Protecting RS Requests to the AS
3.3. Token Introspection
3.4. Registering a Resource Set
3.5. Error Responses
4. Deriving a Downstream Token
5. IANA Considerations
5.1. Well-Known URIs
5.2. GNAP Grant Request Parameters
5.3. GNAP Token Formats
5.3.1. Registry Template
5.3.2. Initial Registry Contents
5.4. GNAP Token Introspection Request
5.4.1. Registry Template
5.4.2. Initial Registry Contents
5.5. GNAP Token Introspection Response
5.5.1. Registry Template
5.5.2. Initial Registry Contents
5.6. GNAP Resource Set Registration Request Parameters
5.6.1. Registry Template
5.6.2. Initial Registry Contents
5.7. GNAP Resource Set Registration Response Parameters
5.7.1. Registry Template
5.7.2. Initial Registry Contents
5.8. GNAP RS-Facing Discovery Document Fields
5.8.1. Registry Template
5.8.2. Initial Registry Contents
5.9. GNAP RS-Facing Error Codes
5.9.1. Registration Template
5.9.2. Initial Contents
6. Security Considerations
6.1. TLS Protection in Transit
6.2. Token Validation
6.3. Caching Token Validation Result
6.4. Key Proof Validation
6.5. Token Exfiltration
6.6. Token Reuse by an RS
6.7. Token Format Considerations
6.8. Oversharing Token Contents
6.9. Resource References
6.10. Token Reissuance from an Untrusted AS
6.11. Introspection of Token Keys
6.12. RS Registration and Management
7. Privacy Considerations
7.1. Token Contents
7.2. Token Use Disclosure through Introspection
7.3. Mapping a User to an AS
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
The core GNAP specification [GNAP] defines distinct roles for the authorization server (AS) and the resource server (RS). However, the core specification does not define how the RS gets answers to important questions, such as whether a given access token is still valid or what set of access rights the access token is approved for.
Core GNAP仕様[GNAP]は、認証サーバー（AS）およびリソースサーバー（RS）の異なる役割を定義します。ただし、コア仕様は、特定のアクセストークンがまだ有効か、アクセストークンが承認されているアクセス権のセットなど、RSが重要な質問にどのように回答するかを定義するものではありません。
While it's possible for the AS and RS to be tightly coupled, such as a single deployed server with a shared storage system, GNAP does not presume or require such a tight coupling. It is increasingly common for the AS and RS to be run and managed separately, particularly in cases where a single AS protects multiple RSs simultaneously.
共有ストレージシステムを備えた単一の展開サーバーなど、ASとRSをしっかりと結合することは可能ですが、GNAPはそのようなタイトな結合を推定または必要としません。ASとRSが個別に実行および管理されることはますます一般的になります。特に、単一のAS ASが複数のRSSを同時に保護する場合。
This specification defines a set of RS-facing APIs that an AS can make available for advanced loosely coupled deployments. Additionally, this document defines a general-purpose model for access tokens, which can be used in structured, formatted access tokens or in token introspection responses. This specification also defines a method for an RS to derive a downstream token for calling another chained RS.
この仕様は、ASが高度なゆるい結合展開に利用できるようにするRSに面したAPIのセットを定義します。さらに、このドキュメントでは、アクセストークンの汎用モデルを定義します。これは、構造化されたフォーマットされたアクセストークンまたはトークン内省応答で使用できます。この仕様は、RSが別のチェーン付きRSを呼び出すために下流トークンを導出する方法を定義します。
The means for the authorization server to issue the access token to the client instance and the means for the client instance to present the access token to the resource server are subjects of the core GNAP specification [GNAP].
Authorization Serverがクライアントインスタンスへのアクセストークンを発行する手段と、クライアントインスタンスがリソースサーバーにアクセストークンを提示する手段は、コアGNAP仕様[GNAP]のサブジェクトです。
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] で説明されているように解釈されます。
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and other elements. Some examples use a single trailing backslash \ to indicate line wrapping for long values, as per [RFC8792]. The \ character and leading spaces on wrapped lines are not part of the value.
このドキュメントには、部分的および完全なHTTPメッセージ、JSON構造、URL、クエリコンポーネント、キー、およびその他の要素の非規範的な例が含まれています。いくつかの例は、単一の後続のバックスラッシュ\を使用して、[RFC8792]に従って、長い値のラインラッピングを示しています。ラップラインの\文字と先行スペースは、値の一部ではありません。
Terminology specific to GNAP is defined in the terminology section of the core specification; see Section 1.1 of [GNAP]. The following protocol roles are defined: authorization server, client, end user, resource owner, and resource server. The following protocol elements are defined: access token, attribute, grant, privilege, protected resource, right, subject, and subject information. The same definitions are used in this document.
GNAPに固有の用語は、コア仕様の用語セクションで定義されています。[GNAP]のセクション1.1を参照してください。次のプロトコルの役割が定義されています：Authorization Server、クライアント、エンドユーザー、リソース所有者、およびリソースサーバー。次のプロトコル要素が定義されています：アクセストークン、属性、助成金、特権、保護されたリソース、右、主題、および主題情報。このドキュメントでは同じ定義が使用されています。
Access tokens are used as a mechanism for an AS to provide a client instance limited access to an RS. These access tokens are artifacts representing a particular set of access rights granted to the client instance to act on behalf of the RO. While the format of access tokens varies in different systems (see discussion in Section 2.2), the concept of an access token is consistent across all GNAP systems.
アクセストークンは、Rsへのクライアントインスタンスが制限されたアクセスを提供するためのメカニズムとして使用されます。これらのアクセストークンは、ROに代わって行動するためにクライアントインスタンスに付与された特定のアクセス権のセットを表すアーティファクトです。アクセストークンの形式はさまざまなシステムで異なりますが（セクション2.2の説明を参照）、アクセストークンの概念はすべてのGNAPシステムで一貫しています。
The core GNAP specification [GNAP] focuses on the relationship between the client and the AS. Since the access token is opaque to the client, the core specification does not define a token model. However, the AS will need to create tokens, and the RS will need to understand tokens. To facilitate a level of structural interoperability, a common access token model is presented here. Access tokens represent a common set of aspects across different GNAP deployments. This list is not intended to be universal or comprehensive but rather serves as guidance to implementers in developing data structures and associated systems across a GNAP deployment. These data structures are communicated between the AS and RS by using either a structured token or an API-like mechanism such as token introspection (see Section 3.3).
コアGNAP仕様[GNAP]は、クライアントとASの関係に焦点を当てています。アクセストークンはクライアントにとって不透明であるため、コア仕様はトークンモデルを定義しません。ただし、ASはトークンを作成する必要があり、RSはトークンを理解する必要があります。構造の相互運用性のレベルを促進するために、ここに共通のアクセストークンモデルが表示されます。アクセストークンは、さまざまなGNAP展開にわたる共通の側面セットを表します。このリストは、普遍的または包括的であることを意図したものではなく、GNAPの展開全体でデータ構造と関連システムを開発する際の実装者へのガイダンスとして機能します。これらのデータ構造は、構造化されたトークンまたはトークン内省などのAPI様メカニズムのいずれかを使用することにより、ASとRSの間で通信されます（セクション3.3を参照）。
This general-purpose data model does not assume either approach; in fact, both approaches can be used together to convey different pieces of information. Where possible, mappings to the JSON Web Token (JWT) [JWT] standard format are provided for each item in the model.
この汎用データモデルは、どちらのアプローチも想定していません。実際、両方のアプローチを一緒に使用して、さまざまな情報を伝えることができます。可能であれば、JSON Webトークン（JWT）[JWT]標準形式のマッピングがモデル内の各アイテムに提供されます。
All access tokens have a _value_, which is the string that is passed on the wire between parties. In order for different access tokens to be differentiated at runtime, the value of a token needs to be unique within a security domain (such as all systems controlled by an AS). Otherwise, two separate tokens would be confused for each other, which would lead to security issues. The AS chooses the value, which can be structured (see Section 2.2) or unstructured. When the token is structured, the token value also has a _format_ known to the AS and RS, and the other items in this token model are contained within the token's value in some fashion. When the token is unstructured, the values are usually retrieved by the RS using a service such as token introspection described in Section 3.3.
すべてのアクセストークンには_value_があります。これは、パーティー間でワイヤーに渡される文字列です。異なるアクセストークンを実行時に区別するためには、トークンの値は、セキュリティドメイン（ASで制御されるすべてのシステムなど）内で一意である必要があります。そうしないと、2つの別々のトークンが互いに混乱し、セキュリティの問題につながります。ASは、構造（セクション2.2を参照）または非構造化できる値を選択します。トークンが構造化されると、トークン値にはasとrsに既知の_format_があり、このトークンモデルの他のアイテムは、ある方法でトークンの値に含まれています。トークンが非構造化されている場合、セクション3.3で説明されているトークン内省などのサービスを使用して、値は通常RSによって取得されます。
The access token value is conveyed in the value field of an access_token response; see Section 3.2 of [GNAP].
アクセストークン値は、Access_Token Responseの値フィールドで伝えられます。[GNAP]のセクション3.2を参照してください。
The format and content of the access token value is opaque to the client software. While the client software needs to be able to carry and present the access token value, the client software is never expected nor intended to be able to understand the token value itself.
アクセストークン値の形式とコンテンツは、クライアントソフトウェアにとって不透明です。クライアントソフトウェアはアクセストークン値を携帯して提示できる必要がありますが、クライアントソフトウェアは決して予想されず、トークン値自体を理解することも意図していません。
If structured tokens like those in [JWT] are used, the value of the token might not be stored by the AS. Instead, a token identifier can be used along with protection by an AS-generated signature to validate and identify an individual token.
[JWT]のような構造化されたトークンを使用する場合、トークンの値はASによって保存されない場合があります。代わりに、個々のトークンを検証および識別するために、生成された署名による保護とともにトークン識別子を使用できます。
The access token is issued by the AS as defined in [GNAP]. The AS will need to identify itself in order to allow an RS to recognize tokens that the AS has issued, particularly in cases where tokens from multiple different ASs could be presented to the same RS.
アクセストークンは、[GNAP]で定義されているASによって発行されます。ASは、特に複数の異なるお尻からのトークンを同じRSに提示できる場合、RSが発行されたトークンを認識できるようにするために、それ自体を識別する必要があります。
This information is not usually conveyed directly to the client instance, since the client instance should know this information based on where it receives the token from.
クライアントインスタンスはトークンの受信先に基づいてこの情報を知っておく必要があるため、この情報は通常、クライアントインスタンスに直接伝えられません。
In the payload of a JSON Web Token [JWT] or a token introspection response, this corresponds to the iss claim.
JSON Webトークン[JWT]またはトークン内省応答のペイロードでは、これはISSクレームに対応しています。
The access token is intended for use at one or more RSs. The AS can list a token's intended RSs to allow each RS to ensure that the RS is not receiving a token intended for someone else. The AS and RS have to agree on the nature of any audience identifiers represented by the token, but the URIs of the RS are a common pattern.
アクセストークンは、1つ以上のRSSで使用することを目的としています。ASは、各RSがRSが他の誰かを対象としたトークンを受け取っていないことを保証できるように、トークンの意図したRSSをリストすることができます。ASとRSは、トークンで表されるオーディエンス識別子の性質に同意する必要がありますが、RSのURIは一般的なパターンです。
In the payload of a JSON Web Token [JWT] or token introspection response, this corresponds to the aud claim.
JSON Webトークン[JWT]またはトークン内省応答のペイロードでは、これはAUDクレームに対応します。
In cases where more complex access is required, the location field of objects in the access array can also convey audience information. In such cases, the client instance might need to know the audience information in order to differentiate between possible RSs to present the token to.
より複雑なアクセスが必要な場合、アクセス配列内のオブジェクトの位置フィールドは、視聴者情報を伝えることもできます。このような場合、クライアントインスタンスは、トークンを提示するために可能なRSを区別するために、視聴者情報を知る必要がある場合があります。
Access tokens in GNAP are bound to the client instance's registered or presented key, except in cases where the access token is a bearer token. For all tokens bound to a key, the AS and RS need to be able to identify which key the token is bound to; otherwise, an attacker could substitute their own key during presentation of the token. In the case of an asymmetric algorithm, the AS and RS need to know only the public key, while the client instance will also need to know the private key in order to present the token. In the case of a symmetric algorithm, all parties will need to either know or be able to derive the shared key.
GNAPのアクセストークンは、アクセストークンがベアラートークンである場合を除き、クライアントインスタンスの登録または提示キーにバインドされます。キーにバインドされたすべてのトークンについて、ASとRSは、トークンがどのキーにバインドされているかを特定できる必要があります。それ以外の場合、攻撃者はトークンの提示中に自分の鍵を置き換えることができます。非対称アルゴリズムの場合、ASとRSは公開キーのみを知る必要がありますが、クライアントインスタンスはトークンを提示するために秘密鍵も知る必要があります。対称アルゴリズムの場合、すべての関係者は、共有キーを知るか、導き出すことができる必要があります。
The source of this key information can vary depending on deployment decisions. For example, an AS could decide that all tokens issued to a client instance are always bound to that client instance's current key. When the key needs to be dereferenced, the AS looks up the client instance to which the token was issued and finds the key information there. Alternatively, the AS could bind each token to a specific key that is managed separately from client instance information. In such a case, the AS determines the key information directly. This approach allows the client instance to use a different key for each request or allows the AS to issue a key for the client instance to use with the particular token.
この重要な情報のソースは、展開の決定によって異なる場合があります。たとえば、クライアントインスタンスに発行されたすべてのトークンが常にそのクライアントインスタンスの現在のキーにバインドされていることを決定できるように。キーを参照する必要がある場合、ASはトークンが発行されたクライアントインスタンスを調べ、そこに重要な情報を見つけます。あるいは、ASは、各トークンをクライアントインスタンス情報とは別に管理する特定のキーに結合することができます。そのような場合、ASは重要な情報を直接決定します。このアプローチにより、クライアントインスタンスは各要求に異なるキーを使用するか、クライアントインスタンスが特定のトークンで使用できるようにキーを発行することができます。
In all cases, the key binding also includes a proofing mechanism, along with any parameters needed for that mechanism such as a signing or digest algorithm. If such information is not included with the proofing key, an attacker could present a token with a seemingly valid key using an insecure and incorrect proofing mechanism.
すべての場合において、重要な結合には、署名やダイジェストアルゴリズムなどのメカニズムに必要なパラメーターとともに、校正メカニズムも含まれます。そのような情報がプルーフキーに含まれていない場合、攻撃者は、安全でない誤った校正メカニズムを使用して、一見有効なキーを持つトークンを提示することができます。
This value is conveyed to the client instance in the key field of the access_token response in Section 3.2 of [GNAP]. Since the common case is that the token is bound to the client instance's registered key, this field can be omitted in this case since the client will be aware of its own key.
この値は、[GNAP]のセクション3.2のAccess_Token応答のキーフィールドのクライアントインスタンスに伝えられます。一般的なケースは、トークンがクライアントインスタンスの登録キーにバインドされていることであるため、クライアントは独自のキーを認識するため、この場合はこのフィールドを省略できます。
In the payload of a JSON Web Token [JWT], this corresponds to the cnf (confirmation) claim. In a token introspection response, this corresponds to the key claim.
JSON Webトークン[JWT]のペイロードでは、これはCNF（確認）クレームに対応します。トークン内注文応答では、これは重要な主張に対応します。
In the case of a bearer token, all parties need to know that a token has no key bound to it and will therefore reject any attempts to use the bearer token with a key in an undefined way.
ベアラートークンの場合、すべての当事者は、トークンにキーが縛られていないことを知る必要があるため、鍵を未定義の方法でキーで使用する試みを拒否します。
GNAP access tokens can have multiple associated data flags that indicate special processing or considerations for a token. For example, the data flags can indicate whether a token is a bearer token or should be expected to be durable across grant updates.
GNAPアクセストークンには、トークンの特別な処理または考慮事項を示す複数の関連データフラグを持つことができます。たとえば、データフラグは、トークンがベアラートークンであるかどうかを示すことができますか、それとも助成金の更新全体で耐久性があると予想される必要があります。
The client can request a set of flags using the flags field of the access_token grant request parameter in Section 2.1.1 of [GNAP].
クライアントは、[GNAP]のセクション2.1.1のAccess_Token Grant要求パラメーターのフラグフィールドを使用して、一連のフラグを要求できます。
These flags are conveyed from the AS to the client in the flags field of the access_token section of the grant response in Section 3.2 of [GNAP].
これらのフラグは、[GNAP]のセクション3.2の助成金応答のAccess_tokenセクションのフラグフィールドのASからASから伝えられます。
For token introspection, flags are returned in the flags field of the response.
トークンの内省の場合、フラグは応答のフラグフィールドに返されます。
Access tokens are tied to a limited set of access rights. These rights specify in some detail what the token can be used for, how it can be used, and where it can be used. The internal structure of access rights is detailed in Section 8 of [GNAP].
アクセストークンは、限られたアクセス権のセットに関連付けられています。これらの権利は、トークンを使用できるもの、使用方法、および使用できる場所を詳細に指定します。アクセス権の内部構造は、[GNAP]のセクション8で詳しく説明されています。
The access rights associated with an access token are calculated from the rights available to the client instance making the request, the rights available to be approved by the RO, the rights actually approved by the RO, and the rights corresponding to the RS in question. The rights for a specific access token are a subset of the overall rights in a grant request.
アクセストークンに関連するアクセス権は、リクエストを行うクライアントインスタンスが利用できる権利、ROによって承認される権利、ROによって実際に承認された権利、および問題のRSに対応する権利から計算されます。特定のアクセストークンの権利は、助成金要求の全体的な権利のサブセットです。
These rights are requested by the client instance in the access field of the access_token request; see Section 2.1 of [GNAP].
これらの権利は、Access_Tokenリクエストのアクセスフィールドにクライアントインスタンスによって要求されます。[GNAP]のセクション2.1を参照してください。
The rights associated with an issued access token are conveyed to the client instance in the access field of the access_token response in Section 3.2 of [GNAP].
発行されたアクセストークンに関連する権利は、[GNAP]のセクション3.2のAccess_Token応答のアクセスフィールドのクライアントインスタンスに伝えられます。
In token introspection responses, access rights correspond to the access claim.
トークン内省の応答では、アクセス権がアクセス請求に対応しています。
The access token can be limited to a certain time window outside of which it is no longer valid for use at an RS. This window can be explicitly bounded by an expiration time and a not-before time, or it could be calculated based on the issuance time of the token. For example, an RS could decide that it will accept tokens for most calls within an hour of a token's issuance, but only within five minutes of the token's issuance for certain high-value calls.
アクセストークンは、RSでの使用にはもはや有効でない外部の特定のタイムウィンドウに制限できます。このウィンドウは、有効期限とそれ以前の時間によって明示的に制限されるか、トークンの発行時間に基づいて計算することができます。たとえば、RSは、トークンの発行から1時間以内にほとんどの呼び出しに対してトークンを受け入れることを決定できますが、特定の高価値コールのトークンの発行から5分以内です。
Since access tokens could be revoked at any time for any reason outside of a client instance's control, the client instance often does not know or concern itself with the validity time window of an access token. However, this information can be made available to it by using the expires_in field of an access token response; see Section 3.2 of [GNAP].
アクセストークンは、クライアントインスタンスのコントロール以外の理由でいつでも取り消される可能性があるため、クライアントインスタンスは、アクセストークンの有効期間ウィンドウを知らないか関心がないことがよくあります。ただし、この情報は、アクセストークン応答のexpires_inフィールドを使用して利用できるようにすることができます。[GNAP]のセクション3.2を参照してください。
The issuance time of the token is conveyed in the iat claim in the payload of a JSON Web Token [JWT] or a token introspection response.
トークンの発行時間は、JSON Webトークン[JWT]またはトークン内省応答のペイロードでIATクレームで伝えられます。
The expiration time of a token, after which it is to be rejected, is conveyed in the exp claim in the payload of a JSON Web Token [JWT] or a token introspection response.
トークンの有効期限は、その後拒否されることになりますが、JSON Webトークン[JWT]またはトークン内省応答のペイロードのEXP請求で伝えられます。
The starting time of a token's validity window, before which it is to be rejected, is conveyed in the nbf claim in the payload of a JSON Web Token [JWT] or a token introspection response.
トークンの有効性ウィンドウの開始時間は、拒否されることでしたが、JSON Webトークン[JWT]またはトークン内省応答のペイロードでNBFクレームで伝えられます。
Individual access tokens often need a unique internal identifier to allow the AS to differentiate between multiple separate tokens. This value of the token can often be used as the identifier, but in some cases, a separate identifier is used.
個々のアクセストークンは、多くの場合、複数の個別のトークンを区別できるようにするために一意の内部識別子が必要です。トークンのこの値は多くの場合、識別子として使用できますが、場合によっては、別の識別子が使用されます。
This separate identifier can be conveyed in the jti claim in the payload of a JSON Web Token [JWT] or a token introspection response.
この個別の識別子は、JSON Webトークン[JWT]またはトークン内省応答のペイロードでJTIクレームで伝達できます。
This identifier is not usually exposed to the client instance using the token, because the client instance only needs to use the token by value.
クライアントインスタンスは値ごとにトークンを使用する必要があるため、この識別子は通常、トークンを使用してクライアントインスタンスにさらされません。
Access tokens are approved on behalf of a resource owner (RO). The identity of this RO can be used by the RS to determine exactly which resource to access or which kinds of access to allow. For example, an access token used to access identity information can hold a user identifier to allow the RS to determine which profile information to return. The nature of this information is subject to agreement by the AS and RS.
アクセストークンは、リソース所有者（RO）に代わって承認されます。このROのアイデンティティは、RSによって使用されて、アクセスするリソースまたは許可のアクセスの種類を正確に決定できます。たとえば、アイデンティティ情報にアクセスするために使用されるアクセストークンは、ユーザー識別子を保持して、RSがどのプロファイル情報を返すかを決定できるようにします。この情報の性質は、ASおよびRsによる合意の対象となります。
This corresponds to the sub claim in the payload of a JSON Web Token [JWT] or a token introspection response.
これは、JSON Webトークン[JWT]またはトークン内省応答のペイロードのサブクレームに対応します。
Detailed RO information is not returned to the client instance when an access token is requested alone, and in many cases, returning this information to the client instance would be a privacy violation on the part of the AS. Since the access token represents a specific delegated access, the client instance needs only to use the token at its target RS. Following the profile example, the client instance does not need to know the account identifier to get specific attributes about the account represented by the token.
アクセストークンが単独で要求された場合、詳細なRO情報はクライアントインスタンスに返されません。多くの場合、この情報をクライアントインスタンスに返すことは、AS側のプライバシー違反です。アクセストークンは特定の委任されたアクセスを表すため、クライアントインスタンスはターゲットRSでトークンを使用するだけです。プロファイルの例に従って、クライアントインスタンスは、トークンで表されるアカウントに関する特定の属性を取得するためにアカウント識別子を知る必要はありません。
GNAP does allow for the return of subject information separately from the access token, in the form of identifiers and assertions. These values are returned directly to the client separately from any access tokens that are requested, though it's common that they represent the same party.
GNAPは、識別子とアサーションの形で、アクセストークンとは別にサブジェクト情報の返還を許可します。これらの値は、要求されているアクセストークンとは別にクライアントに直接返されますが、同じ当事者を代表することは一般的です。
The end user is the party operating the client software. The client instance can facilitate the end user interacting with the AS in order to determine the end user's identity, gather authorization, and provide the results of that information back to the client instance.
エンドユーザーは、クライアントソフトウェアを操作するパーティーです。クライアントインスタンスは、エンドユーザーのIDを決定し、認可を収集し、その情報の結果をクライアントインスタンスに戻すために、ASと対話するエンドユーザーを促進できます。
In many instances, the end user is the same party as the resource owner. However, in some cases, the two roles can be fulfilled by different people, where the RO is consulted asynchronously. The token model should be able to reflect these kinds of situations by representing the end user and RO separately. For example, an end user can request a financial payment, but the RO is the holder of the account that the payment would be withdrawn from. The RO would be consulted for approval by the AS outside of the flow of the GNAP request. A token in such circumstances would need to show both the RO and end user as separate entities.
多くの場合、エンドユーザーはリソース所有者と同じパーティです。ただし、場合によっては、ROが非同期に相談されるさまざまな人によって2つの役割を果たすことができます。トークンモデルは、エンドユーザーとROを個別に表現することにより、この種の状況を反映できるはずです。たとえば、エンドユーザーは財務支払いを要求できますが、ROは支払いが撤回されるアカウントの所有者です。ROは、GNAPリクエストのフローの外側のASの承認のために相談されます。このような状況でのトークンは、ROユーザーとエンドユーザーの両方を別々のエンティティとして表示する必要があります。
Access tokens are issued to a specific client instance by the AS. The identity of this instance can be used by the RS to allow specific kinds of access or other attributes about the access token. For example, an AS that binds all access tokens issued to a particular client instance to that client instance's most recent key rotation would need to be able to look up the client instance in order to find the key binding detail.
アクセストークンは、ASによって特定のクライアントインスタンスに発行されます。このインスタンスのIDは、RSによって使用され、特定の種類のアクセスまたはアクセストークンに関するその他の属性を可能にすることができます。たとえば、特定のクライアントインスタンスに発行されたすべてのアクセストークンをそのクライアントインスタンスの最新のキーローテーションにバインドするASは、キーバインディングの詳細を見つけるためにクライアントインスタンスを検索できる必要があります。
This corresponds to the client_id claim in the payload of a JSON Web Token [JWT] or the instance_id field of a token introspection response.
これは、JSON Webトークン[JWT]のペイロードまたはトークン内省応答のinstance_idフィールドにおけるclient_idクレームに対応します。
The client is not normally informed of this information separately, since a client instance can usually correctly assume that it is the client instance to which a token that it receives was issued.
通常、クライアントのインスタンスは、受け取ったトークンが発行されたクライアントインスタンスであると正しく想定できるため、クライアントは通常この情報を個別に通知されません。
When multiple access tokens are requested or a client instance uses token labels, the parties will need to keep track of which labels were applied to each individual token. Since labels can be reused across different grant requests, the token label alone is not sufficient to uniquely identify a given access token in a system. However, within the context of a grant request, these labels are required to be unique.
複数のアクセストークンが要求される場合、またはクライアントインスタンスがトークンラベルを使用している場合、当事者は個々のトークンに適用されたラベルを追跡する必要があります。ラベルはさまざまな助成金リクエストで再利用できるため、トークンラベルだけでは、システム内の特定のアクセストークンを一意に識別するのに十分ではありません。ただし、助成金要求のコンテキスト内では、これらのラベルは一意である必要があります。
A client instance can request a specific label using the label field of an access_token request; see Section 2.1 of [GNAP].
クライアントインスタンスは、Access_Tokenリクエストのラベルフィールドを使用して特定のラベルを要求できます。[GNAP]のセクション2.1を参照してください。
The AS can inform the client instance of a token's label using the label field of an access_token response; see Section 3.2 of [GNAP].
ASは、Access_Token Responseのラベルフィールドを使用して、トークンのラベルのクライアントインスタンスを通知できます。[GNAP]のセクション3.2を参照してください。
This corresponds to the label field of a token introspection response.
これは、トークン内省応答のラベルフィールドに対応します。
All access tokens are issued in the context of a specific grant request from a client instance. The grant request itself represents a unique tuple of:
すべてのアクセストークンは、クライアントインスタンスからの特定の助成金要求のコンテキストで発行されます。グラントリクエスト自体は、次のユニークなタプルを表しています。
* The AS processing the grant request
* 助成金要求の処理として
* The client instance making the grant request
* クライアントインスタンスは、助成金リクエストを行います
* The RO (or set of ROs) approving the grant request (or needing to approve it)
* 助成金要求を承認する（またはそれを承認する必要がある）RO（またはROSのセット）
* The access rights granted by the RO
* ROによって付与されたアクセス権
* The current state of the grant request, as defined in Section 1.5 of [GNAP]
* [GNAP]のセクション1.5で定義されているように、助成金要求の現状
The AS can use this information to tie common information to a specific token. For instance, instead of specifying a client instance for every issued access token for a grant, the AS can store the client information in the grant itself and look it up by reference from the access token.
この情報を使用して、一般的な情報を特定のトークンに結び付けることができます。たとえば、助成金のために発行されたアクセストークンごとにクライアントインスタンスを指定する代わりに、クライアント情報を助成金自体に保存し、アクセストークンから参照して調べることができます。
The AS can also use this information when a grant request is updated. For example, if the client instance asks for a new access token from an existing grant, the AS can use this link to revoke older non-durable access tokens that had been previously issued under the grant.
ASは、助成金リクエストが更新されたときにこの情報を使用できます。たとえば、クライアントインスタンスが既存の助成金から新しいアクセストークンを要求する場合、このリンクを使用して、以前に助成金の下で発行されていた古い非耐久性のあるアクセストークンを取り消すことができます。
A client instance will have its own model of an ongoing grant request, especially if that grant request can be continued using the API defined in Section 5 of [GNAP] where several pieces of statefulness need to be kept in hand. The client instance might need to keep an association with the grant request that issued the token in case the access token expires or does not have sufficient access rights, so that the client instance can get a new access token without having to restart the grant request process from scratch.
クライアントインスタンスには、継続的な助成金リクエストの独自のモデルがあります。特に、[GNAP]のセクション5で定義されたAPIを使用してその助成金リクエストを継続できる場合は、いくつかの状態を保持する必要があります。クライアントインスタンスは、アクセストークンの有効期限が切れている場合や十分なアクセス権がない場合にトークンを発行する助成金リクエストとの関係を維持する必要がある場合があり、クライアントインスタンスは、グラントリクエストプロセスをゼロから再起動することなく新しいアクセストークンを取得できます。
Since the grant itself does not need to be identified in any of the protocol messages, GNAP does not define a specific grant identifier to be conveyed between any parties in the protocol. Only the AS needs to keep an explicit connection between an issued access token and the parent grant that issued it.
助成金自体はプロトコルメッセージのいずれでも識別する必要がないため、GNAPはプロトコル内の当事者間で伝える特定の助成金識別子を定義しません。発行されたアクセストークンとそれを発行した親の助成金との間に明示的な接続を維持する必要がある場合のみ。
When an access token is used for the grant continuation API defined in Section 5 of [GNAP] (the continuation access token), the token management API defined in Section 6 of [GNAP] (the token management access token), or the RS-facing API defined in Section 3 (the resource server management access token), the AS MUST separate these access tokens from other access tokens used at one or more RSs. The AS can do this through the use of a flag on the access token data structure, by using a special internal access right, or any other means at its disposal. Just like other access tokens in GNAP, the contents of these AS-specific access tokens are opaque to the software presenting the token. Unlike other access tokens, the contents of these AS-specific access tokens are also opaque to the RS.
[GNAP]（継続アクセストークン）のセクション5で定義されている助成金API、[GNAP]（GNAP]（トークン管理アクセストークン）のセクション6で定義されているトークン管理API、またはセクション3（リソースサーバー管理アクセストークン）で定義されたRSに向かうAPI（リソースサーバー管理アクセストークン）で定義されているトークン管理APIにアクセストークンが使用される場合、これらのアクセスを使用した他のアクセスからのアクセスを分離する必要があります。ASは、特別な内部アクセス権、または自由に使用できるその他の手段を使用して、アクセストークンデータ構造にフラグを使用してこれを行うことができます。GNAPの他のアクセストークンと同様に、これらのAS固有のアクセストークンの内容は、トークンを提示するソフトウェアに不透明です。他のアクセストークンとは異なり、これらのAS固有のアクセストークンの内容もRSに不透明です。
The client instance is given continuation access tokens only as part of the continue field of the grant response in Section 3.1 of [GNAP]. The client instance is given token management access tokens only as part of the manage field of the grant response in Section 3.2.1 of [GNAP]. The means by which the RS is given resource server management access tokens is out of scope of this specification, but methods could include preconfiguration of the token value with the RS software or granting the access token through a standard GNAP process.
クライアントインスタンスには、[GNAP]のセクション3.1の助成金応答の連続フィールドの一部としてのみ、継続アクセストークンが与えられます。クライアントインスタンスには、[GNAP]のセクション3.2.1の助成金応答の管理フィールドの一部としてのみ、トークン管理アクセストークンが与えられます。RSにリソースサーバー管理アクセストークンが与えられる手段は、この仕様の範囲外ですが、メソッドにはRSソフトウェアによるトークン値の事前設定、または標準のGNAPプロセスを通じてアクセストークンの付与が含まれます。
For continuation access tokens and token management access tokens, a client instance MUST take steps to differentiate these special-purpose access tokens from access tokens used at one or more RSs. To facilitate this, a client instance can store AS-specific access tokens separately from other access tokens in order to keep them from being confused with each other and used at the wrong endpoints.
継続アクセストークンとトークン管理アクセストークンの場合、クライアントインスタンスは、1つ以上のRSSで使用されるアクセストークンからこれらの特別な目的アクセストークンを区別するための措置を講じる必要があります。これを容易にするために、クライアントインスタンスは、他のアクセストークンとは別に固有のアクセストークンを保存して、互いに混乱し、間違ったエンドポイントで使用されないようにします。
An RS should never see an AS-specific access token presented, so any attempts to process one MUST fail. When introspection is used, the AS MUST NOT return an active value of true for AS-specific access tokens to the RS. If an AS implements its protected endpoints in such a way that it uses token introspection internally, the AS MUST differentiate these AS-specific access tokens from those issued for use at an external RS.
RSは、提示されたAS固有のアクセストークンを決して表示しないため、処理しようとする試みは失敗する必要があります。内省が使用される場合、ASはAS固有のアクセストークンに対してRsにTrueのアクティブ値を返してはなりません。Aが保護されたエンドポイントを内部的に内省を使用するように実装する場合、ASは、外部Rsで使用されるために発行されたものとこれらのAS固有のアクセストークンを区別する必要があります。
When the AS issues an access token for use at an RS, the RS needs to have some means of understanding what the access token is for in order to determine how to respond to the request. The core GNAP protocol makes neither assumptions nor demands on the format or contents of the access token, and in fact, the token format and contents are opaque to the client instance. However, such token formats can be the topic of agreements between the AS and RS.
ASがRSで使用するためのアクセストークンを発行する場合、RSは、リクエストに応答する方法を決定するために、アクセストークンが何であるかを理解する手段が必要です。Core GNAPプロトコルは、アクセストークンの形式または内容について仮定も要求もしていません。実際、トークン形式とコンテンツはクライアントインスタンスに不透明です。ただし、このようなトークン形式は、ASとRsの間の合意のトピックになる可能性があります。
Self-contained structured token formats allow for the conveyance of information between the AS and RS without requiring the RS to call the AS at runtime as described in Section 3.3. Structured tokens can also be used in combination with introspection, allowing the token itself to carry one class of information and the introspection response to carry another.
セクション3.3で説明されているように、RSが実行時にASを呼び出すことを要求することなく、ASとRSの間の情報の伝達を可能にします。構造化されたトークンは、内省と組み合わせて使用することもできます。これにより、トークン自体があるクラスの情報を運ぶことができ、内省的応答が別の情報を運ぶことができます。
Some token formats, such as Macaroons [MACAROON] and Biscuits [BISCUIT], allow for the RS to derive sub-tokens without having to call the AS as described in Section 4.
マカロン[マカロン]やビスケット[ビスケット]などのいくつかのトークン形式では、セクション4で説明されているとおりに呼び出さずに、RSがサブトケンを導き出すことができます。
The supported token formats can be communicated dynamically at runtime between the AS and RS in several places:
サポートされているトークン形式は、いくつかの場所でASとRSの間の実行時に動的に伝達できます。
* The AS can declare its supported token formats as part of RS-facing discovery (Section 3.1).
* ASは、RSに向かう発見の一部として、サポートされているトークン形式を宣言することができます（セクション3.1）。
* The RS can require a specific token format be used to access a registered resource set (Section 3.4).
* RSは、登録されたリソースセット（セクション3.4）にアクセスするために特定のトークン形式を使用する必要があります。
* The AS can return the token's format in an introspection response (Section 3.3).
* ASは、内省的応答でトークンの形式を返すことができます（セクション3.3）。
In all places where the token format is listed explicitly, it MUST be one of the registered values in the "GNAP Token Formats" registry Section 5.3.
トークン形式が明示的にリストされているすべての場所で、「GNAPトークン形式」レジストリセクション5.3の登録値の1つでなければなりません。
To facilitate runtime and dynamic connections with an RS, the AS can offer an RS-facing API consisting of one or more of the following optional pieces:
RSとのランタイムと動的接続を容易にするために、ASは、次のオプションの1つ以上で構成されるRSに向かうAPIを提供できます。
* Discovery
* 発見
* Introspection
* 内省
* Token chaining
* トークンチェーン
* Resource reference registration
* リソース参照登録
A GNAP AS offering RS-facing services can publish its features on a well-known discovery document at the URL with the same schema and authority as the grant request endpoint URL, at the path /.well-known/gnap-as-rs.
RS向けサービスを提供するGNAPは、Path /.well-known/gnap-as-rsで、Grant Request Endpoint URLと同じスキーマと権限を持つURLの有名なディスカバリードキュメントにその機能を公開できます。
The discovery response is a JSON document [RFC8259] consisting of a single JSON object with the following fields:
発見応答は、次のフィールドを持つ単一のJSONオブジェクトで構成されるJSONドキュメント[RFC8259]です。
grant_request_endpoint (string):
grant_request_endpoint（string）：
The location of the AS's grant request endpoint defined by Section 9 of [GNAP]. This URL MUST be the same URL used by client instances in support of GNAP requests. The RS can use this to derive downstream access tokens, if supported by the AS. The location MUST be a URL [RFC3986] with a scheme component that MUST be https, a host component, and (optionally) port, path, and query components and no fragment components. REQUIRED. See Section 4.
[GNAP]のセクション9で定義されたASの助成金要求エンドポイントの位置。このURLは、GNAP要求をサポートするためにクライアントインスタンスで使用されているのと同じURLでなければなりません。RSはこれを使用して、ASによってサポートされている場合、下流のアクセストークンを導出できます。場所は、HTTPS、ホストコンポーネント、および（オプションでは）ポート、パス、クエリコンポーネント、およびフラグメントコンポーネントなしでなければならないスキームコンポーネントを備えたURL [RFC3986]でなければなりません。必須。セクション4を参照してください。
introspection_endpoint (string):
内省エンドポイント（文字列）：
The URL of the endpoint offering introspection. The location MUST be a URL [RFC3986] with a scheme component that MUST be https, a host component, and (optionally) port, path, and query components and no fragment components. REQUIRED if the AS supports introspection. An absent value indicates that the AS does not support introspection. See Section 3.3.
内省を提供するエンドポイントのURL。場所は、HTTPS、ホストコンポーネント、および（オプションでは）ポート、パス、クエリコンポーネント、およびフラグメントコンポーネントなしでなければならないスキームコンポーネントを備えたURL [RFC3986]でなければなりません。ASが内省をサポートする場合が必要です。不在の値は、ASが内省をサポートしていないことを示しています。セクション3.3を参照してください。
token_formats_supported (array of strings):
token_formats_supported（文字列の配列）：
A list of token formats supported by this AS. The values in this list MUST be registered in the "GNAP Token Formats" registry per Section 5.3. OPTIONAL.
これでサポートされているトークン形式のリスト。このリストの値は、セクション5.3ごとに「GNAPトークン形式」レジストリに登録する必要があります。オプション。
resource_registration_endpoint (string):
resource_registration_endpoint（string）：
The URL of the endpoint offering resource registration. The location MUST be a URL [RFC3986] with a scheme component that MUST be https, a host component, and (optionally) port, path, and query components and no fragment components. REQUIRED if the AS supports dynamic resource registration. An absent value indicates that the AS does not support this feature. See Section 3.4.
リソース登録を提供するエンドポイントのURL。場所は、HTTPS、ホストコンポーネント、および（オプションでは）ポート、パス、クエリコンポーネント、およびフラグメントコンポーネントなしでなければならないスキームコンポーネントを備えたURL [RFC3986]でなければなりません。ASが動的リソース登録をサポートする場合が必要です。不在の値は、ASがこの機能をサポートしていないことを示します。セクション3.4を参照してください。
key_proofs_supported (array of strings):
key_proofs_supported（文字列の配列）：
A list of the AS's supported key proofing mechanisms. The values of this list correspond to possible values of the proof field of the key section of the request. Values MUST be registered in the "GNAP Key Proofing Methods" registry established by [GNAP]. OPTIONAL.
ASのサポートされている主要な校正メカニズムのリスト。このリストの値は、リクエストのキーセクションの証明フィールドの可能な値に対応しています。値は、[GNAP]によって確立された「GNAPキープルーフメソッド」レジストリに登録する必要があります。オプション。
Additional fields are defined in the "GNAP RS-Facing Discovery Document Fields" registry; see Section 5.8.
追加のフィールドは、「GNAP rs-facing discoveryドキュメントフィールド」レジストリで定義されています。セクション5.8を参照してください。
Unless otherwise specified, the RS MUST protect its calls to the AS using any of the signature methods defined in Section 7 of [GNAP].
特に指定されていない限り、RSは[GNAP]のセクション7で定義されている署名メソッドのいずれかを使用して、その呼び出しをASに保護する必要があります。
The RS MAY present its keys by reference or by value in a similar fashion to a client instance calling the AS in the core protocol of GNAP, as described in Section 7.1 of [GNAP]. In the protocols defined here, this takes the form of the resource server identifying itself by using a key field or by passing an instance identifier directly.
RSは、[GNAP]のセクション7.1で説明されているように、GNAPのコアプロトコルのASを呼び出すクライアントインスタンスと同様の方法で、参照または価値によってキーを提示することができます。ここで定義されているプロトコルでは、これはキーフィールドを使用するか、インスタンス識別子を直接渡すことにより、リソースサーバーがそれ自体を識別する形式を取得します。
POST /continue HTTP/1.1
Host: server.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Type: application/json
"resource_server": {
"key": {
"proof": "httpsig",
"jwk": {
"kty": "EC",
"crv": "secp256k1",
"kid": "2021-07-06T20:22:03Z",
"x": "-J9OJIZj4nmopZbQN7T8xv3sbeS5-f_vBNSy_EHnBZc",
"y": "sjrS51pLtu3P4LUTVvyAIxRfDV_be2RYpI5_f-Yjivw"
}
}
}
or by reference:
または参照により：
POST /continue HTTP/1.1
Host: server.example.com
Signature-Input: sig1=...
Signature: sig1=...
Content-Type: application/json
{
"resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
The means by which an RS's keys are made known to the AS are out of the scope of this specification. The AS MAY require an RS to preregister its keys, or it could allow calls from arbitrary keys in a trust-on-first-use model.
RSのキーがこの仕様の範囲外であるASに対して知られる手段。ASは、RSがそのキーを前提とするために必要な場合があります。または、ファーストオンファーストモデルの任意のキーからの呼び出しを許可する場合があります。
The AS MAY issue access tokens, called "resource server management access tokens", to the RS to protect the RS-facing API endpoints. If such tokens are issued, the RS MUST present them to the RS-facing API endpoints along with the RS authentication.
ASは、「リソースサーバー管理アクセストークン」と呼ばれるアクセストークンをRSに発行し、RSに向かうAPIエンドポイントを保護します。このようなトークンが発行された場合、RSはRS認証とともにRSに向かうAPIエンドポイントにそれらを提示する必要があります。
POST /continue HTTP/1.1
Host: server.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Type: application/json
{
"resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
The AS issues access tokens representing a set of delegated access rights to be used at one or more RSs. The AS can offer an introspection service to allow an RS to validate that a given access token:
ASの問題は、1つ以上のRSSで使用される一連の委任されたアクセス権を表すアクセストークンです。ASは、RSが特定のアクセストークンを検証できるようにするための内省サービスを提供できます。
* has been issued by the AS
* ASによって発行されました
* is valid at the current time
* 現在の時点で有効です
* has not been revoked
* 取り消されていません
* is appropriate for the RS identified in the call
* コールで特定されたRSに適しています
When the RS receives an access token, it can call the introspection endpoint at the AS to get token information.
RSがアクセストークンを受信すると、トークン情報を取得するために内省エンドポイントを呼び出すことができます。
+--------+ +------+ +------+
| Client +--(1)->| RS | | AS |
|Instance| | +--(2)->| |
| | | | | |
| | | |<-(3)--+ |
| | | | +------+
| |<-(4)--+ |
+--------+ +------+
1. The client instance calls the RS with its access token.
1. クライアントインスタンスは、アクセストークンでRSを呼び出します。
2. The RS introspects the access token value at the AS. The RS signs the request with its own key (not the client instance's key or the token's key).
2. RSは、ASでアクセストークン値を内省します。RSは、独自のキー（クライアントインスタンスのキーやトークンのキーではありません）でリクエストに署名します。
3. The AS validates the access token value and the RS's request and returns the introspection response for the token.
3. ASは、アクセストークン値とRSの要求を検証し、トークンの内省的応答を返します。
4. The RS fulfills the request from the client instance.
4. RSは、クライアントインスタンスからのリクエストを満たします。
The RS signs the request with its own key and sends the value of the access token in the body of the request as a JSON object with the following members:
RSは、独自のキーでリクエストに署名し、次のメンバーを持つJSONオブジェクトとしてリクエストの本文にアクセストークンの値を送信します。
access_token (string):
Access_Token（String）：
The access token value presented to the RS by the client instance. REQUIRED.
クライアントインスタンスによってRSに提示されたアクセストークン値。必須。
proof (string):
証明（文字列）：
The proofing method used by the client instance to bind the token to the RS request. The value MUST be registered in the "GNAP Key Proofing Methods" registry. RECOMMENDED.
クライアントインスタンスがトークンをRSリクエストにバインドするために使用するプルーフ方法。値は、「GNAPキープルーフメソッド」レジストリに登録する必要があります。推奨。
resource_server (object/string):
resource_server（object/string）：
The identification used to authenticate the resource server making this call, either by value or by reference as described in Section 3.2. REQUIRED.
セクション3.2で説明されているように、値または参照のいずれかで、この呼び出しを行うリソースサーバーを認証するために使用された識別。必須。
access (array of strings/objects):
アクセス（文字列/オブジェクトの配列）：
The minimum access rights required to fulfill the request. This MUST be in the format described in Section 8 of [GNAP]. OPTIONAL.
リクエストを満たすために必要な最低アクセス権。これは、[GNAP]のセクション8で説明されている形式でなければなりません。オプション。
Additional fields are defined in the "GNAP Token Introspection Request" registry (Section 5.4).
追加のフィールドは、「GNAPトークン内省要求」レジストリ（セクション5.4）で定義されています。
POST /introspect HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Digest: sha256=...
{
"access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"proof": "httpsig",
"resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
The AS MUST validate the access token value and determine if the token is active. The parameters of the request provide a context for the AS to evaluate the access token, and the AS MUST take all provided parameters into account when evaluating if the token is active. If the AS is unable to process part of the request, such as not understanding part of the access field presented, the AS MUST NOT indicate the token as active.
ASは、アクセストークン値を検証し、トークンがアクティブかどうかを判断する必要があります。リクエストのパラメーターは、アクセストークンを評価するためのコンテキストを提供し、トークンがアクティブであるかどうかを評価する際にASをすべて考慮しなければなりません。提示されたアクセスフィールドの一部を理解していないなど、リクエストの一部を処理できない場合、ASはトークンをアクティブとして示してはなりません。
An active access token is defined as a token that is all of the following:
アクティブアクセストークンは、次のすべてのトークンとして定義されます。
* was issued by the processing AS,
* 処理によって発行されました、
* has not been revoked,
* 取り消されていません、
* has not expired,
* 期限切れはありません、
* is bound using the proof method indicated,
* 示されている証明方法を使用してバインドされています、
* is appropriate for presentation at the identified RS, and
* 特定されたRsでのプレゼンテーションに適しています
* is appropriate for the access indicated (if present).
* 示されているアクセスに適しています（存在する場合）。
The AS responds with a data structure describing the token's current state and any information the RS would need to validate the token's presentation, such as its intended proofing mechanism and key material.
ASは、トークンの現在の状態を説明するデータ構造と、RSが目的の校正メカニズムや重要な素材など、トークンのプレゼンテーションを検証する必要がある情報で応答します。
active (boolean):
Active（boolean）：
If true, the access token presented is active, as defined above. If any of the criteria for an active token are not true, or if the AS is unable to make a determination (such as the token is not found), the value is set to false and other fields are omitted. REQUIRED.
Trueの場合、上記で定義されているように、提示されたアクセストークンはアクティブです。アクティブなトークンの基準のいずれかが真でない場合、またはASが決定を行うことができない場合（トークンなど）、値は偽に設定され、他のフィールドは省略されます。必須。
If the access token is active, additional fields from the single access token response structure defined in Section 3.2.1 of [GNAP] are included. In particular, these include the following:
アクセストークンがアクティブな場合、[GNAP]のセクション3.2.1で定義されている単一アクセストークン応答構造からの追加フィールドが含まれています。特に、これらには以下が含まれます。
access (array of strings/objects):
アクセス（文字列/オブジェクトの配列）：
The access rights associated with this access token. This MUST be in the format described in Section 8 of [GNAP]. This array MAY be filtered or otherwise limited for consumption by the identified RS, including being an empty array, which indicates that the token has no explicit access rights that can be disclosed to the RS. REQUIRED.
このアクセストークンに関連するアクセス権。これは、[GNAP]のセクション8で説明されている形式でなければなりません。このアレイは、空の配列であることを含め、特定されたRsによってフィルター処理または制限される場合があります。これは、トークンにRsに開示できる明示的なアクセス権がないことを示しています。必須。
key (object/string):
key（object/string）：
if the token is bound. The key bound to the access token, to allow the RS to validate the signature of the request from the client instance. If the access token is a bearer token, this MUST NOT be included. REQUIRED
トークンがバインドされている場合。RSがクライアントインスタンスからのリクエストの署名を検証できるようにするために、アクセストークンにバインドされています。アクセストークンがベアラートークンである場合、これを含めてはなりません。必須
flags (array of strings):
フラグ（文字列の配列）：
The set of flags associated with the access token. OPTIONAL.
アクセストークンに関連付けられたフラグのセット。オプション。
exp (integer):
exp（整数）：
The timestamp after which this token is no longer valid. Expressed as integer seconds from UNIX Epoch. OPTIONAL.
その後のタイムスタンプは、このトークンがもはや有効ではありません。Unix Epochから整数秒として表現されています。オプション。
iat (integer):
IAT（整数）：
The timestamp at which this token was issued by the AS. Expressed as integer seconds from UNIX Epoch. OPTIONAL.
このトークンがASによって発行されたタイムスタンプ。Unix Epochから整数秒として表現されています。オプション。
nbf (integer):
NBF（整数）：
The timestamp before which this token is not valid. Expressed as integer seconds from UNIX Epoch. OPTIONAL.
このトークンの前のタイムスタンプは無効です。Unix Epochから整数秒として表現されています。オプション。
aud (string or array of strings):
aud（文字列または文字列の配列）：
Identifiers for the resource servers this token can be accepted at. OPTIONAL.
リソースサーバーの識別子は、このトークンを受け入れることができます。オプション。
sub (string):
sub（string）：
Identifier of the resource owner who authorized this token. OPTIONAL.
このトークンを承認したリソース所有者の識別子。オプション。
iss (string):
ISS（文字列）：
Grant endpoint URL of the AS that issued this token. REQUIRED.
このトークンを発行したASのエンドポイントURLを付与します。必須。
instance_id (string):
instance_id（string）：
The instance identifier of the client instance that the token was issued to. OPTIONAL.
トークンが発行されたクライアントインスタンスのインスタンス識別子。オプション。
Additional fields are defined in the "GNAP Token Introspection Response" registry (Section 5.5).
追加のフィールドは、「GNAPトークン内省応答」レジストリ（セクション5.5）で定義されています。
The response MAY include any additional fields defined in an access token response and MUST NOT include the access token value itself.
応答には、アクセストークンの応答で定義された追加のフィールドが含まれる場合があり、アクセストークン値自体を含めてはなりません。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"active": true,
"access": [
"dolphin-metadata", "some other thing"
],
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-1",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeL...."
}
}
}
When processing the results of the introspection response, the RS MUST determine the appropriate course of action. For instance, if the RS determines that the access token's access rights are not sufficient for the request to which the token was attached, the RS can return an error or a public resource, as appropriate for the RS. In all cases, the final determination of the response is at the discretion of the RS.
内省応答の結果を処理する場合、RSは適切なアクションコースを決定する必要があります。たとえば、RSがアクセストークンのアクセス権が添付されている要求に対して十分ではないと判断した場合、RSはRSに適したエラーまたはパブリックリソースを返すことができます。すべての場合において、応答の最終決定はRsの裁量にあります。
If the RS needs to, it can post a set of resources, as described in Section 8 ("Resource Access Rights") of [GNAP], to the AS's resource registration endpoint along with information about what the RS will need to validate the request.
RSが必要な場合、[GNAP]のセクション8（「リソースアクセス権」）で説明されているように、RSがリクエストを検証するために必要なものに関する情報とともに、ASのリソース登録エンドポイントに一連のリソースを投稿できます。
access (array of objects/strings):
アクセス（オブジェクト/文字列の配列）：
The list of access rights associated with the request in the format described in Section 8 ("Resource Access Rights") of [GNAP]. REQUIRED.
[GNAP]のセクション8（「リソースアクセス権」）で説明されている形式のリクエストに関連付けられたアクセス権のリスト。必須。
resource_server (object/string):
resource_server（object/string）：
The identification used to authenticate the resource server making this call, either by value or by reference as described in Section 3.2. REQUIRED.
セクション3.2で説明されているように、値または参照のいずれかで、この呼び出しを行うリソースサーバーを認証するために使用された識別。必須。
token_formats_supported (array of strings):
token_formats_supported（文字列の配列）：
The list of token formats that the RS is able to process. The values in this array MUST be registered in the "GNAP Token Formats" registry per Section 5.3. If the field is omitted, the token format is at the discretion of the AS. If the AS does not support any of the requested token formats, the AS MUST return an error to the RS. OPTIONAL.
RSが処理できるトークン形式のリスト。この配列の値は、セクション5.3ごとに「GNAPトークン形式」レジストリに登録する必要があります。フィールドが省略されている場合、トークン形式はASの裁量にあります。ASが要求されたトークン形式のいずれをサポートしていない場合、ASはRSにエラーを返す必要があります。オプション。
token_introspection_required (boolean):
token_intropection_required（boolean）：
If present and set to true, the RS expects to make a token introspection request as described in Section 3.3. If absent or set to false, the RS does not anticipate needing to make an introspection request for tokens relating to this resource set. If the AS does not support token introspection for this RS, the AS MUST return an error to the RS. OPTIONAL.
存在してTrueに設定した場合、RSはセクション3.3で説明されているように、トークン内省要求を行う予定です。不在またはFalseに設定した場合、RSは、このリソースセットに関連するトークンの内省リクエストを行う必要があるとは予想していません。ASがこのRSのトークン内省をサポートしていない場合、ASはRSにエラーを返す必要があります。オプション。
Additional fields are defined in the "GNAP Resource Set Registration Request Parameters" registry (Section 5.6).
追加のフィールドは、「GNAPリソースセット登録要求パラメーター」レジストリ（セクション5.6）で定義されています。
The RS MUST identify itself with its own key and sign the request.
RSは、独自のキーで自分自身を識別し、リクエストに署名する必要があります。
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Digest: ...
{
"access": [
{
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"dolphin-metadata"
],
"resource_server": "7C7C4AZ9KHRS6X63AJAO"
}
The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests.
ASは、RSがリクエストで提示したリソースリストと、将来のリクエストでRSが必要とする可能性のある追加情報を表すために適切な参照で応答します。
resource_reference (string):
resource_reference（string）：
A single string representing the list of resources registered in the request. The RS MAY make this handle available to a client instance as part of a discovery response as described in Section 9.1 of [GNAP] or as documentation to client software developers. REQUIRED.
リクエストに登録されたリソースのリストを表す単一の文字列。RSは、[GNAP]のセクション9.1で説明されているように、またはクライアントソフトウェア開発者へのドキュメントとして、発見応答の一部として、クライアントインスタンスがこのハンドルを利用できるようにする場合があります。必須。
instance_id (string):
instance_id（string）：
An instance identifier that the RS can use to refer to itself in future calls to the AS, in lieu of sending its key by value. See Section 3.2. OPTIONAL.
RSが、将来の呼び出しで、そのキーを値で送信する代わりに、将来の呼び出しで自分自身を参照できるインスタンス識別子。セクション3.2を参照してください。オプション。
introspection_endpoint (string):
内省エンドポイント（文字列）：
The introspection endpoint of this AS that is used to allow the RS to perform token introspection. See Section 3.3. OPTIONAL.
RSがトークン内省を実行できるようにするために使用されるため、これの内省エンドポイント。セクション3.3を参照してください。オプション。
Additional fields are defined in the "GNAP Resource Set Registration Response Parameters" registry (Section 5.7).
追加のフィールドは、「GNAPリソースセット登録応答パラメーター」レジストリ（セクション5.7）で定義されています。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"resource_reference": "FWWIKYBQ6U56NL1"
}
If a resource was previously registered, the AS MAY return the same resource reference value as in previous responses.
リソースが以前に登録されていた場合、ASは以前の回答と同じリソース参照値を返すことができます。
If the registration fails, the AS returns HTTP status code 400 (Bad Request) to the RS, indicating that the registration was not successful.
登録が失敗した場合、ASはRSにHTTPステータスコード400（悪い要求）を返し、登録が成功しなかったことを示します。
The client instance can then use the resource_reference value as a string-type access reference as defined in Section 8.1 of [GNAP]. This value MAY be combined with any other additional access rights requested by the client instance.
クライアントインスタンスは、[GNAP]のセクション8.1で定義されているように、resource_reference値を文字列型アクセス参照として使用できます。この値は、クライアントインスタンスが要求する他の追加アクセス権と組み合わせることができます。
{
"access_token": {
"access": [
"FWWIKYBQ6U56NL1",
{
"type": "photo-api",
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"dolphin-metadata"
]
},
"client": "client-12351.bdxqf"
}
In the case of an error from the RS-facing API, the AS responds to the RS with HTTP status code 400 (Bad Request) and a JSON object consisting of a single error field, which is either an object or a string.
RSに向かうAPIからのエラーの場合、ASはHTTPステータスコード400（悪い要求）とrsに応答し、オブジェクトまたは文字列のいずれかである単一のエラーフィールドで構成されるJSONオブジェクトです。
When returned as a string, the error value is the error code:
文字列として返されると、エラー値はエラーコードです。
{
error: "invalid_access"
}
When returned as an object, the error object contains the following fields:
オブジェクトとして返されると、エラーオブジェクトには次のフィールドが含まれます。
code (string):
コード（文字列）：
A single ASCII error code defining the error. REQUIRED.
エラーを定義する単一のASCIIエラーコード。必須。
description (string):
説明（文字列）：
A human-readable string description of the error intended for the developer of the client. OPTIONAL.
クライアントの開発者向けのエラーの人間が読み取る文字列の説明。オプション。
{
"error": {
"code": "invalid_access",
"description": "Access to 'foo' is not permitted for this RS."
}
}
This specification defines the following error code values:
この仕様は、次のエラーコード値を定義します。
"invalid_request":
「invalid_request」：
The request is missing a required parameter, includes an invalid parameter value, or is otherwise malformed.
リクエストには、必要なパラメーターが欠落しているか、無効なパラメーター値が含まれているか、それ以外の場合は奇形です。
"invalid_resource_server":
「invalid_resource_server」：
The request was made from an RS that was not recognized or allowed by the AS, or the RS's signature validation failed.
リクエストは、ASによって認識または許可されていないRS、またはRSの署名検証が失敗したRSから行われました。
"invalid_access"
「invalid_access」
The RS is not permitted to register or introspect for the requested "access" value.
RSは、要求された「アクセス」値の登録または内省は許可されていません。
Additional error codes can be defined in the "GNAP RS-Facing Error Codes" registry (Section 5.9).
追加のエラーコードは、「GNAP rs-facingエラーコード」レジストリ（セクション5.9）で定義できます。
Some architectures require an RS to act as a client instance and use a derived access token for a secondary RS. Since the RS is not the same entity that made the initial grant request, the RS is not capable of referencing or modifying the existing grant. As such, the RS needs to request or generate a new access token for its use at the secondary RS. This internal secondary token is issued in the context of the incoming access token.
一部のアーキテクチャでは、クライアントインスタンスとして機能し、セカンダリRSに派生アクセストークンを使用するためにRSが必要です。RSは最初の助成金要求を行ったエンティティと同じではないため、RSは既存の助成金を参照または変更することはできません。そのため、RSは、セカンダリRSで使用するために新しいアクセストークンを要求または生成する必要があります。この内部セカンダリトークンは、着信アクセストークンのコンテキストで発行されます。
While it is possible to use a token format (Section 2) that allows for the RS to generate its own secondary token, the AS can allow the RS to request this secondary access token using the same process used by the original client instance to request the primary access token. Since the RS is acting as its own client instance from the perspective of GNAP, this process uses the same grant endpoint, request structure, and response structure as a client instance's request.
RSが独自のセカンダリトークンを生成できるようにするトークン形式（セクション2）を使用することは可能ですが、ASは、元のクライアントインスタンスで使用される同じプロセスを使用してプライマリアクセストークンを要求するのと同じプロセスを使用して、このセカンダリアクセストークンを要求できるようにすることができます。RSはGNAPの観点から独自のクライアントインスタンスとして機能しているため、このプロセスはクライアントインスタンスの要求と同じグラントエンドポイント、要求構造、および応答構造を使用します。
+--------+ +-------+ +------+ +-------+
| Client +--(1)->| RS1 | | AS | | RS2 |
|Instance| | +--(2)->| | | |
| | | |<-(3)--+ | | |
| | | | +------+ | |
| | | | | |
| | | +-----------(4)------->| |
| | | |<----------(5)--------+ |
| |<-(6)--+ | | |
+--------+ +-------+ +-------+
1. The client instance calls RS1 with an access token.
1. クライアントインスタンスは、アクセストークンを使用してRS1を呼び出します。
2. RS1 presents that token to the AS to get a derived token for use at RS2. RS1 indicates that it has no ability to interact with the RO. Note that RS1 signs its request with its own key, not the token's key or the client instance's key.
2. RS1は、RS2で使用するために派生トークンを取得するためにそのトークンを提示します。RS1は、ROと相互作用する能力がないことを示しています。RS1は、トークンのキーやクライアントインスタンスのキーではなく、独自のキーでリクエストに署名することに注意してください。
3. The AS returns a derived token to RS1 for use at RS2.
3. ASは、派生トークンをRS2で使用するためにRS1に返します。
4. RS1 calls RS2 with the token from (3).
4. RS1は（3）からトークンを使用してRS2を呼び出します。
5. RS2 fulfills the call from RS1.
5. RS2はRS1からのコールを満たします。
6. RS1 fulfills the call from the original client instance.
6. RS1は、元のクライアントインスタンスからの呼び出しを満たします。
If the RS needs to derive a token from one presented to it, it can request one from the AS by making a token request as described in [GNAP] and presenting the existing access token's value in the "existing_access_token" field.
RSが提示されたものからトークンを導出する必要がある場合、[GNAP]で説明されているようにトークン要求を作成し、「既存の_ACCESS_TOKEN」フィールドに既存のアクセストークンの値を提示することにより、ASからそれを要求できます。
Since the RS is acting as a client instance, the RS MUST identify itself with its own key in the client field and sign the request just as any client instance would, as described in Section 3.2. The AS MUST determine that the token being presented is appropriate for use at the RS making the token chaining request.
RSはクライアントインスタンスとして機能しているため、RSは、セクション3.2で説明されているように、クライアントインスタンスと同じように、クライアントフィールドの独自のキーで自分自身を識別し、リクエストに署名する必要があります。ASは、提示されているトークンがRSで使用するのに適していると判断する必要があります。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Detached-JWS: ejy0...
{
"access_token": {
"access": [
{
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"dolphin-metadata"
]
},
"client": "7C7C4AZ9KHRS6X63AJAO",
"existing_access_token": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0"
}
The AS responds with a token for the downstream RS2 as described in [GNAP]. The downstream RS2 could repeat this process as necessary for calling further RSs.
ASは、[GNAP]で説明されているように、下流のRS2のトークンで応答します。下流のRS2は、さらにRSSを呼び出すために必要に応じてこのプロセスを繰り返すことができます。
IANA has added values to existing registries and created five registries under the "Grant Negotiation and Authorization Protocol (GNAP)" registry group.
IANAは既存のレジストリに値を追加し、「助成金交渉と認可プロトコル（GNAP）」レジストリグループに基づいて5つのレジストリを作成しました。
The "gnap-as-rs" URI suffix is registered in the "Well-Known URIs" registry to support RS-facing discovery of the AS.
「gnap-as-rs」URIサフィックスは、「有名なURIS」レジストリに登録されており、ASのRS向けの発見をサポートしています。
URI Suffix:
URIサフィックス：
gnap-as-rs
gnap-as-rs
Change Controller:
Change Controller：
IETF
IETF
Specification Document:
仕様文書：
Section 3.1 of RFC 9767
RFC 9767のセクション3.1
Status:
状態：
Permanent
永続
The following parameter is registered in the "GNAP Grant Request Parameters" registry:
次のパラメーターは、「GNAP助成金要求パラメーター」レジストリに登録されています。
Name:
名前：
existing_access_token
既存の_access_token
Type:
タイプ：
string
弦
Reference:
参照：
Section 4 of RFC 9767
RFC 9767のセクション4
This document defines a GNAP token format, for which IANA has created and maintains a new registry titled "GNAP Token Formats". Initial values for this registry are given in Section 5.3.2. Future assignments and modifications to existing assignment are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAPトークン形式」というタイトルの新しいレジストリを作成および維持しているGNAPトークン形式を定義しています。このレジストリの初期値は、セクション5.3.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The designated expert (DE) is expected to ensure that:
指定された専門家（DE）は、次のことを確実にすることが期待されています。
* all registrations follow the template presented in Section 5.3.1.
* すべての登録は、セクション5.3.1に示されているテンプレートに従います。
* the format's definition is sufficiently unique from other formats provided by existing parameters.
* フォーマットの定義は、既存のパラメーターによって提供される他の形式とは十分に一意です。
* the format's definition specifies the format of the access token in sufficient detail to allow for the AS and RS to be able to communicate the token information.
* この形式の定義は、ASとRSがトークン情報を通信できるように、アクセストークンの形式を十分に詳細に指定しています。
Name:
名前：
The name of the format.
形式の名前。
Status:
状態：
Whether or not the format is in active use. Possible values are Active and Deprecated.
形式がアクティブに使用されているかどうか。考えられる値はアクティブで非推奨です。
Description:
説明：
The human-readable description of the access token format.
アクセストークン形式の人間が読める説明。
Reference:
参照：
The specification that defines the token format.
トークン形式を定義する仕様。
+===============+========+====================+============+
| Name | Status | Description | Reference |
+===============+========+====================+============+
| jwt-signed | Active | JSON Web Token, | [JWT] |
| | | signed with JWS | |
+---------------+--------+--------------------+------------+
| jwt-encrypted | Active | JSON Web Token, | [JWT] |
| | | encrypted with JWE | |
+---------------+--------+--------------------+------------+
| macaroon | Active | Macaroon | [MACAROON] |
+---------------+--------+--------------------+------------+
| biscuit | Active | Biscuit | [BISCUIT] |
+---------------+--------+--------------------+------------+
| zcap | Active | ZCAP | [ZCAPLD] |
+---------------+--------+--------------------+------------+
Table 1: Initial Contents of the GNAP Token Formats Registry
表1：GNAPトークンフォーマットレジストリの初期内容
This document defines GNAP token introspection, for which IANA has created and maintains a new registry titled "GNAP Token Introspection Request". Initial values for this registry are given in Section 5.4.2. Future assignments and modifications to existing assignment are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAPトークン内省要求」というタイトルの新しいレジストリを作成および維持しているGNAPトークン内省を定義しています。このレジストリの初期値は、セクション5.4.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure that:
DEはそれを確実にすることが期待されています：
* all registrations follow the template presented in Section 5.4.1.
* すべての登録は、セクション5.4.1に示されているテンプレートに従います。
* the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.
* クレームの定義は、機能性の重複を避けるため、レジストリで定義されている他のクレームに対して十分に直交しています。
* the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.
* クレームの定義は、ASとRSがトークン値を通信できるように、クレームの構文とクレームのセマンティクスを十分に詳細に指定しています。
Name:
名前：
The name of the claim.
クレームの名前。
Type:
タイプ：
The JSON data type of the claim value.
請求値のJSONデータ型。
Reference:
参照：
The specification that defines the claim.
クレームを定義する仕様。
The table below contains the initial contents of the "GNAP Token Introspection Request" registry.
以下の表には、「GNAPトークン内省要求」レジストリの初期内容が含まれています。
+=================+=================+=========================+
| Name | Type | Reference |
+=================+=================+=========================+
| access_token | string | Section 3.3 of RFC 9767 |
+-----------------+-----------------+-------------------------+
| proof | string | Section 3.3 of RFC 9767 |
+-----------------+-----------------+-------------------------+
| resource_server | object/string | Section 3.3 of RFC 9767 |
+-----------------+-----------------+-------------------------+
| access | array of | Section 3.3 of RFC 9767 |
| | strings/objects | |
+-----------------+-----------------+-------------------------+
Table 2: Initial Contents of the GNAP Token Introspection Request Registry
表2：GNAPトークン内省リクエストレジストリの初期内容
This document defines GNAP token introspection, for which IANA has created and maintains a new registry titled "GNAP Token Introspection Response". Initial values for this registry are given in Section 5.5.2. Future assignments and modifications to existing assignment are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAPトークン内省応答」というタイトルの新しいレジストリを作成および維持しているGNAPトークン内省を定義しています。このレジストリの初期値は、セクション5.5.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure that:
DEはそれを確実にすることが期待されています：
* all registrations follow the template presented in Section 5.5.1.
* すべての登録は、セクション5.5.1に示されているテンプレートに従います。
* the claim's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.
* クレームの定義は、機能性の重複を避けるため、レジストリで定義されている他のクレームに対して十分に直交しています。
* the claim's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the token values.
* クレームの定義は、ASとRSがトークン値を通信できるように、クレームの構文とクレームのセマンティクスを十分に詳細に指定しています。
Name:
名前：
The name of the claim.
クレームの名前。
Type:
タイプ：
The JSON data type of the claim value.
請求値のJSONデータ型。
Reference:
参照：
The specification that defines the claim.
クレームを定義する仕様。
The table below contains the initial contents of the "GNAP Token Introspection Response" registry.
以下の表には、「GNAPトークン内省応答」レジストリの初期内容が含まれています。
+=============+==========================+=========================+
| Name | Type | Reference |
+=============+==========================+=========================+
| active | boolean | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| access | array of strings/objects | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| key | object/string | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| flags | array of strings | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| exp | integer | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| iat | integer | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| nbf | integer | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| aud | string or array of | Section 3.3 of RFC 9767 |
| | strings | |
+-------------+--------------------------+-------------------------+
| sub | string | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| iss | string | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
| instance_id | string | Section 3.3 of RFC 9767 |
+-------------+--------------------------+-------------------------+
Table 3: Initial Contents of the GNAP Token Introspection Response Registry
表3：GNAPトークン内省反応レジストリの初期内容
This document defines a means to register a resource set for a GNAP AS, for which IANA has created and maintains a new registry titled "GNAP Resource Set Registration Request Parameters". Initial values for this registry are given in Section 5.6.2. Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy [RFC8126].
このドキュメントでは、IANAが「GNAPリソースセット登録要求パラメーター」というタイトルの新しいレジストリを作成および維持しているGNAPのリソースセットを登録する手段を定義しています。このレジストリの初期値は、セクション5.6.2に記載されています。既存の課題に対する将来の割り当てと変更は、専門家のレビュー登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure that:
DEはそれを確実にすることが期待されています：
* all registrations follow the template presented in Section 5.6.1.
* すべての登録は、セクション5.6.1に示されているテンプレートに従います。
* the parameter's definition is sufficiently orthogonal to other parameters defined in the registry so as avoid overlapping functionality.
* パラメーターの定義は、機能性の重複を避けるため、レジストリで定義されている他のパラメーターに対して十分に直交しています。
* the parameter's definition specifies the syntax and semantics of the parameter in sufficient detail to allow for the AS and RS to be able to communicate the resource set.
* パラメーターの定義は、ASとRSがリソースセットを通信できるように、パラメーターの構文とパラメーターのセマンティクスを十分に詳細に指定します。
Name:
名前：
The name of the parameter.
パラメーターの名前。
Type:
タイプ：
The JSON data type of the parameter value.
パラメーター値のJSONデータ型。
Reference:
参照：
The specification that defines the token.
トークンを定義する仕様。
The table below contains the initial contents of the "GNAP Resource Set Registration Request Parameters" registry.
以下の表には、「GNAPリソースセット登録要求パラメーター」レジストリの初期内容が含まれています。
+==============================+=================+=============+
| Name | Type | Reference |
+==============================+=================+=============+
| access | array of | Section 3.4 |
| | strings/objects | of RFC 9767 |
+------------------------------+-----------------+-------------+
| resource_server | object/string | Section 3.4 |
| | | of RFC 9767 |
+------------------------------+-----------------+-------------+
| token_formats_supported | array of | Section 3.4 |
| | strings | of RFC 9767 |
+------------------------------+-----------------+-------------+
| token_introspection_required | boolean | Section 3.4 |
| | | of RFC 9767 |
+------------------------------+-----------------+-------------+
Table 4: Initial Contents of the GNAP Resource Set Registration Request Parameters Registry
表4：GNAPリソースセット登録要求パラメータレジストリの初期内容
This document defines a means to register a resource set for a GNAP AS, for which IANA has created and maintains a new registry titled "GNAP Resource Set Registration Response Parameters". Initial values for this registry are given in Section 5.7.2. Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy [RFC8126].
このドキュメントでは、GNAPのリソースセットを登録する手段を定義します。IANAは、「GNAPリソースセット登録応答パラメーター」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション5.7.2に記載されています。既存の課題に対する将来の割り当てと変更は、専門家のレビュー登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure that:
DEはそれを確実にすることが期待されています：
* all registrations follow the template presented in Section 5.7.1.
* すべての登録は、セクション5.7.1に示されているテンプレートに従います。
* the parameter's definition is sufficiently orthogonal to other claims defined in the registry so as avoid overlapping functionality.
* パラメーターの定義は、機能性が重複しないように、レジストリで定義されている他のクレームに対して十分に直交しています。
* the parameter's definition specifies the syntax and semantics of the claim in sufficient detail to allow for the AS and RS to be able to communicate the resource set.
* パラメーターの定義は、ASとRSがリソースセットを通信できるようにするために、クレームの構文とクレームのセマンティクスを十分に詳細に指定しています。
Name:
名前：
The name of the parameter.
パラメーターの名前。
Type:
タイプ：
The JSON data type of the parameter value.
パラメーター値のJSONデータ型。
Reference:
参照：
The specification that defines the parameter.
パラメーターを定義する仕様。
The table below contains the initial contents of the "GNAP Resource Set Registration Response Parameters" registry.
以下の表には、「GNAPリソースセット登録応答パラメーター」レジストリの初期内容が含まれています。
+========================+========+=========================+
| Name | Type | Reference |
+========================+========+=========================+
| resource_reference | string | Section 3.4 of RFC 9767 |
+------------------------+--------+-------------------------+
| instance_id | string | Section 3.4 of RFC 9767 |
+------------------------+--------+-------------------------+
| introspection_endpoint | string | Section 3.4 of RFC 9767 |
+------------------------+--------+-------------------------+
Table 5: Initial Contents of the GNAP Resource Set Registration Response Parameters Registry
表5：GNAPリソースセット登録応答パラメータレジストリの初期コンテンツ
This document defines a means to for a GNAP AS to be discovered by a GNAP RS, for which IANA has created and maintains a new registry titled "GNAP RS-Facing Discovery Document Fields". Initial values for this registry are given in Section 5.8.2. Future assignments and modifications to existing assignment are to be made through the Expert Review registration policy [RFC8126].
このドキュメントは、GNAP RSによって発見されるGNAPの手段を定義します。IANAは、「GNAP RS-Facing Discovery Documentフィールド」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション5.8.2に記載されています。既存の課題に対する将来の割り当てと変更は、専門家のレビュー登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure that:
DEはそれを確実にすることが期待されています：
* all registrations follow the template presented in Section 5.8.1.
* すべての登録は、セクション5.8.1に示されているテンプレートに従います。
* the field's definition is sufficiently orthogonal to other fields defined in the registry so as avoid overlapping functionality.
* フィールドの定義は、機能性の重複を避けるため、レジストリで定義されている他のフィールドに対して十分に直交しています。
* the field's definition specifies the syntax and semantics of the fields in sufficient detail to allow for the RS to be able to communicate with the AS.
* フィールドの定義は、RSがASと通信できるように、フィールドの構文とフィールドのセマンティクスを十分に詳細に指定しています。
Name:
名前：
The name of the field.
フィールドの名前。
Type:
タイプ：
The JSON data type of the field value.
フィールド値のJSONデータ型。
Reference:
参照：
The specification that defines the field.
フィールドを定義する仕様。
The table below contains the initial contents of the "GNAP RS-Facing Discovery Document Fields" registry.
以下の表には、「GNAP rs-facingディスカバリードキュメントフィールド」レジストリの初期内容が含まれています。
+================================+==========+=============+
| Name | Type | Reference |
+================================+==========+=============+
| introspection_endpoint | string | Section 3.1 |
| | | of RFC 9767 |
+--------------------------------+----------+-------------+
| token_formats_supported | array of | Section 3.1 |
| | strings | of RFC 9767 |
+--------------------------------+----------+-------------+
| resource_registration_endpoint | string | Section 3.1 |
| | | of RFC 9767 |
+--------------------------------+----------+-------------+
| grant_request_endpoint | string | Section 3.1 |
| | | of RFC 9767 |
+--------------------------------+----------+-------------+
| key_proofs_supported | array of | Section 3.1 |
| | strings | of RFC 9767 |
+--------------------------------+----------+-------------+
Table 6: Initial Contents of the GNAP RS-Facing Discovery Document Fields Registry
表6：gnap rs-facing discoveryドキュメントフィールドレジストリの初期内容
This document defines a set of errors that the AS can return to the RS, for which IANA has created and maintains a new registry titled "GNAP RS-Facing Error Codes". Initial values for this registry are given in Section 5.9.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、ASがRSに戻ることができる一連のエラーを定義します。これは、IANAが「GNAP RS-Facingエラーコード」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション5.9.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure that:
DEはそれを確実にすることが期待されています：
* all registrations follow the template presented in Section 5.9.1.
* すべての登録は、セクション5.9.1に示されているテンプレートに従います。
* the error response is sufficiently unique from other errors to provide actionable information to the client instance.
* エラー応答は、クライアントインスタンスに実用的な情報を提供するために、他のエラーと十分に一意です。
* the definition of the error response specifies all conditions in which the error response is returned and what the client instance's expected action is.
* エラー応答の定義は、エラー応答が返されるすべての条件と、クライアントインスタンスの予想アクションが何であるかを指定します。
Error:
エラー：
A unique string code for the error.
エラー用の一意の文字列コード。
Reference:
参照：
Reference to the document(s) that specifies the value, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
値を指定するドキュメントへの参照、できればドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+=========================+=========================+
| Error | Reference |
+=========================+=========================+
| invalid_request | Section 3.5 of RFC 9767 |
+-------------------------+-------------------------+
| invalid_resource_server | Section 3.5 of RFC 9767 |
+-------------------------+-------------------------+
| invalid_access | Section 3.5 of RFC 9767 |
+-------------------------+-------------------------+
Table 7: Initial Contents of the GNAP RS-Facing Error Codes Registry
表7：gnap rs-facingエラーコードレジストリの初期内容
In addition to the normative requirements in this document and in [GNAP], implementers are strongly encouraged to consider the following additional security considerations in implementations and deployments of GNAP.
このドキュメントおよび[GNAP]の規範的要件に加えて、実装者は、GNAPの実装と展開における以下の追加のセキュリティ上の考慮事項を考慮することを強くお勧めします。
All requests in GNAP made over untrusted network connections have to be made over TLS as outlined in [BCP195] to protect the contents of the request and response from manipulation and interception by an attacker. This includes all requests from a client instance to the RS and all requests from the RS to an AS.
[BCP195]で概説されているように、信頼されていないネットワーク接続を介して行われたGNAPのすべての要求は、攻撃者による操作と傍受からの要求と応答の内容を保護するために、TLSを介して行う必要があります。これには、クライアントインスタンスからRSへのすべての要求、およびRSからASへのすべての要求が含まれます。
The RS has a responsibility to validate the incoming access token in a manner consistent with its deployment. For self-contained stateless tokens such as those described in Section 2.2, this consists of actions such as validating the token's signature and ensuring the relevant fields and results are appropriate for the request being made. For reference-style tokens or tokens that are otherwise opaque to the RS, the token introspection RS-facing API can be used to provide updated information about the state of the token, as described in Section 3.3.
RSには、展開と一致する方法で着信アクセストークンを検証する責任があります。セクション2.2で説明されているような自己完結型のステートレストークンの場合、これはトークンの署名の検証や関連するフィールドと結果がリクエストに適していることを確認するなどのアクションで構成されています。それ以外の場合はRSに不透明なリファレンススタイルのトークンまたはトークンの場合、セクション3.3で説明されているように、トークン内注文RS関数APIを使用して、トークンの状態に関する更新された情報を提供できます。
The RS needs to validate that a token:
RSはトークンを検証する必要があります。
* is intended for this RS (audience restriction)
* このRs（聴衆の制限）を目的としています
* is presented using the appropriate key for the token (see also Section 6.4)
* トークンの適切なキーを使用して提示されます（セクション6.4も参照）
* identifies an appropriate subject to access the resource (usually this is the resource owner who authorized the token's issuance)
* リソースにアクセスする適切な被験者を特定します（通常、これはトークンの発行を承認したリソース所有者です）
* is issued by a trusted AS for this resource
* このリソースについては、信頼できるものによって発行されます
Even though key proofing mechanisms have to cover the value of the token, validating the key proofing alone is not sufficient to protect a request to an RS. If an RS validates only the presentation method as described in Section 6.4 without validating the token itself, an attacker could use a compromised key or a confused deputy to make arbitrary calls to the RS beyond what has been authorized by the RO.
キープルーフメカニズムはトークンの価値をカバーする必要がありますが、キープルーフのみを検証するだけでは、Rsへの要求を保護するのに十分ではありません。RSがトークン自体を検証せずにセクション6.4で説明したようにプレゼンテーション方法のみを検証した場合、攻撃者は侵害されたキーまたは混乱した代理人を使用して、ROによって承認されたものを超えてRSにarbitrary意的な呼び出しを行うことができます。
Since token validation can be an expensive process, requiring either cryptographic operations or network calls to an introspection service as described in Section 3.3, an RS could cache the results of token validation for a particular token. The trade-off for using a cached validation for a token presents an important decision space for implementers: relying on a cached validation result increases performance and lowers processing overhead, but it comes at the expense of the liveness and accuracy of the information in the cache. While a cached value is in use at the RS, an attacker could present a revoked token and have it accepted by the RS.
セクション3.3で説明されているように、トークンの検証は高価なプロセスになる可能性があるため、暗号化操作または内省サービスへのネットワーク呼び出しのいずれかを必要とするため、RSは特定のトークンのトークン検証の結果をキャッシュできます。トークンにキャッシュされた検証を使用するためのトレードオフは、実装者にとって重要な決定空間を提示します。キャッシュされた検証結果に依存すると、パフォーマンスが向上し、オーバーヘッドの処理が低下しますが、キャッシュ内の情報のlivenivesと精度を犠牲にします。RSでキャッシュされた価値が使用されていますが、攻撃者は取り消されたトークンを提示し、RSに受け入れてもらうことができます。
As with any cache, the consistency of this cache can be managed in a variety of ways. One of the most simple methods is managing the lifetime of the cache in order to balance the performance and security properties. If the cache is too long, an attacker has a larger window in which to use a revoked token. If the window is too short, the benefits of using the cache are diminished. It is also possible that an AS could send a proactive signal to the RS to invalidate revoked access tokens, though such a mechanism is outside the scope of this specification.
他のキャッシュと同様に、このキャッシュの一貫性はさまざまな方法で管理できます。最も単純な方法の1つは、パフォーマンスとセキュリティのプロパティのバランスをとるために、キャッシュの寿命を管理することです。キャッシュが長すぎる場合、攻撃者は取り消されたトークンを使用するための大きなウィンドウを持っています。ウィンドウが短すぎる場合、キャッシュを使用することの利点は減少します。また、ASはRSにプロアクティブな信号を送信して、取り消されたアクセストークンを無効にすることができますが、このようなメカニズムはこの仕様の範囲外です。
For key-bound access tokens, the proofing method needs to be validated alongside the value of the token itself, as described in Section 6.2. The process of validation is defined by the key proofing method, as described in Section 7.3 of [GNAP].
キーバウンドアクセストークンの場合、セクション6.2で説明されているように、トークン自体の値とともに校正方法を検証する必要があります。検証のプロセスは、[GNAP]のセクション7.3で説明されているように、重要な校正方法によって定義されます。
If the proofing method is not validated, an attacker could use a compromised token without access to the token's bound key.
校正方法が検証されていない場合、攻撃者は、トークンのバインドキーにアクセスせずに侵害されたトークンを使用できます。
The RS also needs to ensure that the proofing method is appropriate for the key associated with the token, including any choice of algorithm or identifiers.
また、RSは、アルゴリズムまたは識別子の選択を含め、トークンに関連するキーに校正方法が適切であることを確認する必要があります。
The proofing should be validated independently on each request to the RS, particularly as aspects of the call could vary. As such, the RS should never cache the results of a proof validation from one message and apply it to a subsequent message.
特にコールの側面が異なる可能性があるため、RSへの各リクエストでは、校正は独立して検証する必要があります。そのため、RSは、1つのメッセージから証明検証の結果をキャッシュして、それを後続のメッセージに適用しないでください。
Since the RS sees the token value, it is possible for a compromised RS to leak that value to an attacker. As such, the RS needs to protect token values as sensitive information and protect them from exfiltration.
RSはトークン値を見ているため、侵害されたRSが攻撃者にその値を漏らすことが可能です。そのため、RSは、機密情報としてトークン値を保護し、それらを排出から保護する必要があります。
This is especially problematic with bearer tokens and tokens bound to a shared key, since an RS has access to all information necessary to create a new, valid request using the token in question.
これは、RSが問題のトークンを使用して新しい有効なリクエストを作成するために必要なすべての情報にアクセスできるため、共有キーにバインドされたベアラートークンとトークンで特に問題があります。
If the access token is a bearer token, or the RS has access to the key material needed to present the token, the RS could be tricked into reusing an access token presented to it by a client. While it is possible to build a system that makes use of this artifact as a feature, it is safer to exchange the incoming access token for another contextual token for use by the RS, as described in Section 4. This access token can be bound to the RS's own keys and limited to access needed by the RS, instead of the full set of rights associated with the token issued to the client instance.
アクセストークンがベアラートークンである場合、またはRSがトークンを提示するために必要な主要な資料にアクセスできる場合、RSはクライアントが提示されたアクセストークンを再利用するようにだまされる可能性があります。このアーティファクトを機能として使用するシステムを構築することは可能ですが、セクション4で説明されているように、RSの使用のために別のコンテキストトークンとRSの使用のために別のコンテキストトークンと交換する方が安全です。
With formatted tokens, the format of the token is likely to have its own considerations, and the RS needs to follow any such considerations during the token validation process. The application and scope of these considerations is specific to the format and outside the scope of this specification.
フォーマットされたトークンを使用すると、トークンの形式には独自の考慮事項がある可能性が高く、RSはトークン検証プロセス中にそのような考慮事項に従う必要があります。これらの考慮事項のアプリケーションと範囲は、この仕様の形式と範囲外に固有です。
The contents of the access token model divulge information about the access token's context and rights to the RS. This is true whether the contents are parsed from the token itself or sent in an introspection response.
アクセストークンモデルの内容は、アクセストークンのコンテキストとRSに対する権利に関する情報を漏らします。これは、内容物がトークン自体から解析されるか、内省的応答で送信されるかどうかに当てはまります。
It's likely that every RS does not need to know all details of the token model, especially in systems where a single access token is usable across multiple RSs. An attacker could use this to gain information about the larger system by compromising only one RS. By limiting the information available to only that which is relevant to a specific RS, such as using a limited introspection reply as defined in Section 3.3, a system can follow the principle of least disclosure to each RS.
すべてのRSは、特に単一のアクセストークンが複数のRSSで使用可能なシステムで、トークンモデルのすべての詳細を知る必要がない可能性があります。攻撃者は、これを使用して、1つのRSのみを侵害することにより、より大きなシステムに関する情報を取得できます。セクション3.3で定義されている限られた内省的応答を使用するなど、特定のRSに関連する情報のみが利用可能な情報を制限することにより、システムは各RSの最小開示の原則に従うことができます。
Resource references, as returned by the protocol in Section 3.4, are intended to be opaque to both the RS and the client. However, since they are under the control of the AS, the AS can put whatever content it wants into the reference value. This value could unintentionally disclose system structure or other internal details if it was processed by an unintended party. Furthermore, such patterns could lead to the client software and RS depending on certain structures being present in the reference value, which diminishes the separation of concerns of the different roles in a GNAP system.
セクション3.4のプロトコルによって返されるリソース参照は、RSとクライアントの両方に不透明であることを目的としています。ただし、ASの制御下にあるため、ASは必要なコンテンツを参照値に配置できます。この値は、意図しない当事者によって処理された場合、システム構造またはその他の内部の詳細を意図せずに開示する可能性があります。さらに、そのようなパターンは、参照値に存在する特定の構造に応じてクライアントソフトウェアとRSにつながる可能性があり、GNAPシステムにおける異なる役割の懸念の分離が減少します。
To mitigate this, the AS should only use fully random or encrypted values for resource references.
これを軽減するために、ASはリソース参照に完全にランダムまたは暗号化された値のみを使用する必要があります。
It is possible for an attacker's client instance to issue its own tokens to another client instance, acting as an AS that the second client instance has chosen to trust. If the token is a bearer token or the reissuance is bound using an AS-provided key, the target client instance will not be able to tell that the token was originally issued by the valid AS. This process allows an attacker to insert their own session and rights into an unsuspecting client instance in the guise of a valid token for the attacker that appears to have been issued to the target client instance on behalf of its own RO.
攻撃者のクライアントインスタンスが独自のトークンを別のクライアントインスタンスに発行することが可能です。トークンがベアラートークンであるか、再発行が提供されているキーを使用してバインドされている場合、ターゲットクライアントインスタンスは、トークンが元々有効なASによって発行されたことを知ることができません。このプロセスにより、攻撃者は、独自のROに代わってターゲットクライアントインスタンスに発行されたと思われる攻撃者の有効なトークンを装って、自分のセッションと権利を疑いを持たないクライアントインスタンスに挿入することができます。
This attack is predicated on a misconfiguration with the targeted client, as it has been configured to get tokens from the attacker's AS and use those tokens with the target RS, which has no association with the attacker's AS. However, since the token is ultimately coming from the trusted AS and is being presented with a valid key, the RS has no way of telling that the token was passed through an intermediary.
この攻撃は、攻撃者のASからトークンを取得し、ターゲットRSでそれらのトークンを使用するように構成されているため、ターゲットクライアントとの誤解に基づいています。ただし、トークンは最終的に信頼できるASから来ており、有効なキーが提示されているため、RSにはトークンが仲介者に渡されたことを伝える方法はありません。
To mitigate this, the RS can publish its association with the trusted AS through either discovery or documentation. Therefore, a client properly following this association would only go directly to the trusted RS for access tokens for the RS.
これを緩和するために、RSは、発見またはドキュメントのいずれかを通じて、信頼できる者との関係を公開できます。したがって、この協会を適切に追跡するクライアントは、Rsのアクセストークンの信頼できるRSに直接移動します。
Furthermore, limiting the use of bearer tokens and AS-provided keys to only highly trusted ASs in certain circumstances prevents the attacker from being able to willingly exfiltrate their token to an unsuspecting client instance.
さらに、ベアラートークンと提供されたキーの使用を特定の状況で非常に信頼できるお尻のみに制限することで、攻撃者はトークンを疑いを持たないクライアントインスタンスに喜んで除去することができなくなります。
The introspection response defined in Section 3.3 provides a means for the AS to tell the RS what key material is needed to validate the key proof of the request. Capture of the introspection response can expose these security keys to an attacker. In the case of asymmetric cryptography, only the public key is exposed, and the token cannot be reused by the attacker based on this result alone. This could potentially divulge information about the client instance that was unknown otherwise.
セクション3.3で定義されている内省的応答は、リクエストの重要な証明を検証するために必要な重要な資料をRSに伝えるための手段を提供します。内省的応答のキャプチャは、これらのセキュリティキーを攻撃者にさらす可能性があります。非対称暗号化の場合、公開鍵のみが公開され、この結果だけに基づいて攻撃者がトークンを再利用することはできません。これは、それ以外の場合は不明だったクライアントインスタンスに関する情報を潜在的に漏らす可能性があります。
If an access token is bound to a symmetric key, the RS will need access to the full key value in order to validate the key proof of the request, as described in Section 6.4. However, divulging the key material to the RS also gives the RS the ability to create a new request with the token. In this circumstance, the RS is under similar risk of token exfiltration and reuse as a bearer token, as described in Section 6.6. Consequently, symmetric keys should only be used in systems where the RS can be fully trusted to not create a new request with tokens presented to it.
アクセストークンが対称キーにバインドされている場合、RSは、セクション6.4で説明されているように、要求のキー証明を検証するために完全なキー値にアクセスする必要があります。ただし、主要な資料をRSに漏らすことで、RSはトークンで新しいリクエストを作成する機能も提供します。この状況では、RSは、セクション6.6で説明されているように、トークンの剥離と再利用のリスクが同様のリスクにさらされています。その結果、対称キーは、RSが提示されたトークンを使用して新しいリクエストを作成しないように完全に信頼できるシステムでのみ使用する必要があります。
Most functions of the RS-facing API in Section 3 are protected by requiring the RS to present proof of a signing key along with the request, in order to identify the RS making the call, potentially coupled with an AS-specific access token. This practice allows the AS to differentially respond to API calls to different RSs, such as answering introspection calls with only the access rights relevant to a given RS instead of all access rights an access token could be good for.
セクション3のRSに面したAPIのほとんどの関数は、RSがリクエストとともに署名キーの証明を提示するように要求することにより保護されます。このプラクティスにより、さまざまなRSSへのAPI呼び出しに差別的に応答することができます。たとえば、すべてのアクセス権の代わりに、特定のRSに関連するアクセス権のみを使用して内省コールに応答するなど、アクセストークンが適している可能性があります。
While the means by which an RS and its keys become known to the AS is out of scope for this specification, it is anticipated that common practice will be to statically register an RS, allowing it to protect specific resources or certain classes of resources. Fundamentally, the RS can only offer the resources that it serves. However, a rogue AS could attempt to register a set of resources that mimics a different RS in order to solicit an access token that is usable at the target RS. If the access token is a bearer token or is bound to a symmetric key that is known to the RS, then the attacker's RS gains the ability and knowledge needed to use that token elsewhere.
RSとそのキーがこの仕様の範囲外であることに知られるようになる手段は、一般的な慣行がRSを静的に登録し、特定のリソースまたは特定のクラスのリソースを保護できることが予想されます。基本的に、RSはそれが提供するリソースのみを提供することができます。ただし、ターゲットRSで使用可能なアクセストークンを求めるために、異なるRSを模倣する一連のリソースを登録しようとする不正があります。アクセストークンがベアラートークンであるか、RSに知られている対称キーにバインドされている場合、攻撃者のRSは、他の場所でそのトークンを使用するために必要な能力と知識を獲得します。
In some ecosystems, dynamic registration of an RS and its associated resources is feasible. In such systems, the identity of the RS could be conveyed by a URI passed in the location field of an access rights request, thereby allowing the AS to limit the view the RS has into the larger system.
一部の生態系では、RSの動的登録とそれに関連するリソースが実行可能です。このようなシステムでは、RSのアイデンティティは、アクセス権リクエストの位置フィールドに渡されたURIによって伝達される可能性があり、それにより、RSが持っているビューをより大きなシステムに制限するようになります。
The contents of the access token could potentially contain personal information about the end user, RO, or other parties. This is true whether the contents are parsed from the token itself or sent in an introspection response.
アクセストークンの内容には、エンドユーザー、RO、または他の関係者に関する個人情報が含まれる可能性があります。これは、内容物がトークン自体から解析されるか、内省的応答で送信されるかどうかに当てはまります。
While an RS will sometimes need this information for processing, it's often the case that an RS is exposed to these details only in passing, and not intentionally. For example, consider a client that has been issued an access token that is usable for both medical and non-medical APIs. If this access token contains a medical record number to facilitate the RS serving the medical API, then any RS for a non-medical API would also learn the user's medical record number in the process, even though that API has no need to make such a correlation.
RSはこの情報を処理するために必要な場合がありますが、多くの場合、RSは、意図的には通過しない場合にのみこれらの詳細にさらされています。たとえば、医療および非医療APIの両方で使用可能なアクセストークンを発行されたクライアントを検討してください。このアクセストークンに医療記録番号が含まれている場合、医療APIを提供するRSを促進する場合、非医療APIのRSは、そのAPIにそのような相関を行う必要がない場合でも、プロセスでユーザーの医療記録番号も学習します。
To mitigate this, a formatted token could contain separate sections targeted to different RSs to segregate data. Alternatively, token introspection can be used to limit the data returned to each RS, as defined in Section 3.3.
これを軽減するために、フォーマットされたトークンには、データを分離するために異なるRSSをターゲットにした個別のセクションを含めることができます。あるいは、セクション3.3で定義されているように、トークン内省を使用して、各RSに返されるデータを制限することができます。
When introspection is used by an RS, the AS is made aware of a particular token being used at a particular RS. When the RS is a separate system, the AS would not otherwise have insight into this action. This can potentially lead to the AS learning about patterns and actions of particular end users by watching which RSs are accessed and when.
Rsが内省を使用する場合、特定のトークンが特定のRsで使用されていることを認識しています。RSが個別のシステムである場合、そうでなければこのアクションについての洞察がありません。これは、どのRSSがアクセスしているかを視聴することにより、特定のエンドユーザーのパターンとアクションについてのAS AS学習に潜在的につながる可能性があります。
When the client instance receives information about the protecting AS from an RS, it can be used to derive information about the resources being protected without releasing the resources themselves. For example, if a medical record is protected by a personal AS, an untrusted client could call an RS to discover the location of the AS protecting the record. Since the AS is tied strongly to a single RO, the untrusted and unauthorized client software can gain information about the resource being protected without accessing the record itself.
クライアントインスタンスがRSから保護に関する情報を受け取ると、リソース自体をリリースせずに保護されているリソースに関する情報を導き出すために使用できます。たとえば、医療記録が個人的なASによって保護されている場合、信頼されていないクライアントがRSを呼び出して、記録を保護するASの位置を発見することができます。ASは単一のROに強く結び付けられているため、信頼されていない不正なクライアントソフトウェアは、レコード自体にアクセスすることなく保護されているリソースに関する情報を取得できます。
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[GNAP] Richer, J., Ed. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/info/rfc9635>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[BISCUIT] Biscuit, "Biscuit Authorization",
<https://www.biscuitsec.org/>.
[MACAROON] Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A.,
Vrable, M., and M. Lentczner, "Macaroons: Cookies with
Contextual Caveats for Decentralized Authorization in the
Cloud", NDSS Symposium 2014, DOI 10.14722/ndss.2014.23212,
February 2014, <https://www.ndss-symposium.org/ndss2014/
ndss-2014-programme/macaroons-cookies-contextual-caveats-
decentralized-authorization-cloud/>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[ZCAPLD] Lemmer-Webber, C., Ed. and M. Sporny, Ed., "Authorization
Capabilities for Linked Data v0.3", W3C Draft Community
Group Report, January 2023,
<https://w3c-ccg.github.io/zcap-spec/>.
The editors would like to thank the following individuals for their reviews, feedback, implementations, and contributions: Aaron Parecki, Adrian Gropper, Andrii Deinega, Annabelle Backman, Dmitry Barinov, Fabien Imbault, Florian Helmschmidt, George Fletcher, Justin Richer, Kathleen Moriarty, Leif Johansson, Mike Varley, Nat Sakimura, Takahiko Kawasaki, and Yaron Sheffer.
編集者は、レビュー、フィードバック、実装、貢献について次の個人に感謝したいと思います：アーロン・パレッキ、エイドリアン・グロッパー、アンドリ・デネガ、アナベル・バックマン、ドミトリー・バリノフ、ファビアン・インボー、フロリアン・ヘルムシュミット、ジョージ・フレッチャー、ジャスティン・リッチャー、カトリー・モリエン・ジョン・ジョン・ジョン・ジョン・ジョン・リッチャー、川崎高橋、ヤロン・シェファー。
Additionally, the editors want to acknowledge the immense contributions of Aaron Parecki to the content of this document. We thank him for his insight, input, and hard work, without which GNAP would not have grown to what it is.
さらに、編集者は、このドキュメントのコンテンツに対するAaron Pareckiの膨大な貢献を認めたいと考えています。私たちは彼の洞察、意見、勤勉に感謝しますが、それなしではGNAPがそれが何であるかに成長しなかったでしょう。
Justin Richer (editor)
Bespoke Engineering
Email: ietf@justin.richer.org
URI: https://bspk.io/
Fabien Imbault
acert.io
Email: fabien.imbault@acert.io
URI: https://acert.io/