Internet Engineering Task Force (IETF) J. Richer, Ed.
Request for Comments: 9635 Bespoke Engineering
Category: Standards Track F. Imbault
ISSN: 2070-1721 acert.io
October 2024
The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software.
助成金交渉と承認プロトコル（GNAP）は、許可をソフトウェアに委任し、その代表団の結果とアーティファクトをソフトウェアに伝えるメカニズムを定義します。この代表団には、APIのセットへのアクセスと、ソフトウェアに直接渡された主題情報を含めることができます。
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/rfc9635.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9635で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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
1.2. Roles
1.3. Elements
1.4. Trust Relationships
1.5. Protocol Flow
1.6. Sequences
1.6.1. Overall Protocol Sequence
1.6.2. Redirect-Based Interaction
1.6.3. User Code Interaction
1.6.4. Asynchronous Authorization
1.6.5. Software-Only Authorization
1.6.6. Refreshing an Expired Access Token
1.6.7. Requesting Subject Information Only
1.6.8. Cross-User Authentication
2. Requesting Access
2.1. Requesting Access to Resources
2.1.1. Requesting a Single Access Token
2.1.2. Requesting Multiple Access Tokens
2.2. Requesting Subject Information
2.3. Identifying the Client Instance
2.3.1. Identifying the Client Instance by Reference
2.3.2. Providing Displayable Client Instance Information
2.3.3. Authenticating the Client Instance
2.4. Identifying the User
2.4.1. Identifying the User by Reference
2.5. Interacting with the User
2.5.1. Start Mode Definitions
2.5.2. Interaction Finish Methods
2.5.3. Hints
3. Grant Response
3.1. Request Continuation
3.2. Access Tokens
3.2.1. Single Access Token
3.2.2. Multiple Access Tokens
3.3. Interaction Modes
3.3.1. Redirection to an Arbitrary URI
3.3.2. Launch of an Application URI
3.3.3. Display of a Short User Code
3.3.4. Display of a Short User Code and URI
3.3.5. Interaction Finish
3.4. Returning Subject Information
3.4.1. Assertion Formats
3.5. Returning a Dynamically Bound Client Instance Identifier
3.6. Error Response
4. Determining Authorization and Consent
4.1. Starting Interaction with the End User
4.1.1. Interaction at a Redirected URI
4.1.2. Interaction at the Static User Code URI
4.1.3. Interaction at a Dynamic User Code URI
4.1.4. Interaction through an Application URI
4.2. Post-Interaction Completion
4.2.1. Completing Interaction with a Browser Redirect to the
Callback URI
4.2.2. Completing Interaction with a Direct HTTP Request
Callback
4.2.3. Calculating the Interaction Hash
5. Continuing a Grant Request
5.1. Continuing after a Completed Interaction
5.2. Continuing during Pending Interaction (Polling)
5.3. Modifying an Existing Request
5.4. Revoking a Grant Request
6. Token Management
6.1. Rotating the Access Token Value
6.1.1. Binding a New Key to the Rotated Access Token
6.2. Revoking the Access Token
7. Securing Requests from the Client Instance
7.1. Key Formats
7.1.1. Key References
7.1.2. Key Protection
7.2. Presenting Access Tokens
7.3. Proving Possession of a Key with a Request
7.3.1. HTTP Message Signatures
7.3.2. Mutual TLS
7.3.3. Detached JWS
7.3.4. Attached JWS
8. Resource Access Rights
8.1. Requesting Resources by Reference
9. Discovery
9.1. RS-First Method of AS Discovery
9.2. Dynamic Grant Endpoint Discovery
10. IANA Considerations
10.1. HTTP Authentication Scheme Registration
10.2. Media Type Registration
10.2.1. application/gnap-binding-jwsd
10.2.2. application/gnap-binding-jws
10.2.3. application/gnap-binding-rotation-jwsd
10.2.4. application/gnap-binding-rotation-jws
10.3. GNAP Grant Request Parameters
10.3.1. Registration Template
10.3.2. Initial Contents
10.4. GNAP Access Token Flags
10.4.1. Registration Template
10.4.2. Initial Contents
10.5. GNAP Subject Information Request Fields
10.5.1. Registration Template
10.5.2. Initial Contents
10.6. GNAP Assertion Formats
10.6.1. Registration Template
10.6.2. Initial Contents
10.7. GNAP Client Instance Fields
10.7.1. Registration Template
10.7.2. Initial Contents
10.8. GNAP Client Instance Display Fields
10.8.1. Registration Template
10.8.2. Initial Contents
10.9. GNAP Interaction Start Modes
10.9.1. Registration Template
10.9.2. Initial Contents
10.10. GNAP Interaction Finish Methods
10.10.1. Registration Template
10.10.2. Initial Contents
10.11. GNAP Interaction Hints
10.11.1. Registration Template
10.11.2. Initial Contents
10.12. GNAP Grant Response Parameters
10.12.1. Registration Template
10.12.2. Initial Contents
10.13. GNAP Interaction Mode Responses
10.13.1. Registration Template
10.13.2. Initial Contents
10.14. GNAP Subject Information Response Fields
10.14.1. Registration Template
10.14.2. Initial Contents
10.15. GNAP Error Codes
10.15.1. Registration Template
10.15.2. Initial Contents
10.16. GNAP Key Proofing Methods
10.16.1. Registration Template
10.16.2. Initial Contents
10.17. GNAP Key Formats
10.17.1. Registration Template
10.17.2. Initial Contents
10.18. GNAP Authorization Server Discovery Fields
10.18.1. Registration Template
10.18.2. Initial Contents
11. Security Considerations
11.1. TLS Protection in Transit
11.2. Signing Requests from the Client Software
11.3. MTLS Message Integrity
11.4. MTLS Deployment Patterns
11.5. Protection of Client Instance Key Material
11.6. Protection of Authorization Server
11.7. Symmetric and Asymmetric Client Instance Keys
11.8. Generation of Access Tokens
11.9. Bearer Access Tokens
11.10. Key-Bound Access Tokens
11.11. Exposure of End-User Credentials to Client Instance
11.12. Mixing Up Authorization Servers
11.13. Processing of Client-Presented User Information
11.14. Client Instance Pre-registration
11.15. Client Instance Impersonation
11.16. Client-Hosted Logo URI
11.17. Interception of Information in the Browser
11.18. Callback URI Manipulation
11.19. Redirection Status Codes
11.20. Interception of Responses from the AS
11.21. Key Distribution
11.22. Key Rotation Policy
11.23. Interaction Finish Modes and Polling
11.24. Session Management for Interaction Finish Methods
11.25. Calculating Interaction Hash
11.26. Storage of Information during Interaction and Continuation
11.27. Denial of Service (DoS) through Grant Continuation
11.28. Exhaustion of Random Value Space
11.29. Front-Channel URIs
11.30. Processing Assertions
11.31. Stolen Token Replay
11.32. Self-Contained Stateless Access Tokens
11.33. Network Problems and Token and Grant Management
11.34. Server-Side Request Forgery (SSRF)
11.35. Multiple Key Formats
11.36. Asynchronous Interactions
11.37. Compromised RS
11.38. AS-Provided Token Keys
12. Privacy Considerations
12.1. Surveillance
12.1.1. Surveillance by the Client
12.1.2. Surveillance by the Authorization Server
12.2. Stored Data
12.3. Intrusion
12.4. Correlation
12.4.1. Correlation by Clients
12.4.2. Correlation by Resource Servers
12.4.3. Correlation by Authorization Servers
12.5. Disclosure in Shared References
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Comparison with OAuth 2.0
Appendix B. Example Protocol Flows
B.1. Redirect-Based User Interaction
B.2. Secondary Device Interaction
B.3. No User Involvement
B.4. Asynchronous Authorization
B.5. Applying OAuth 2.0 Scopes and Client IDs
Appendix C. Interoperability Profiles
C.1. Web-Based Redirection
C.2. Secondary Device
Appendix D. Guidance for Extensions
Appendix E. JSON Structures and Polymorphism
Acknowledgements
Authors' Addresses
GNAP allows a piece of software, the client instance, to request delegated authorization to resource servers and subject information. The delegated access to the resource server can be used by the client instance to access resources and APIs on behalf a resource owner, and delegated access to subject information can in turn be used by the client instance to make authentication decisions. This delegation is facilitated by an authorization server, usually on behalf of a resource owner. The end user operating the software can interact with the authorization server to authenticate, provide consent, and authorize the request as a resource owner.
GNAPを使用すると、クライアントインスタンスのソフトウェアであるクライアントインスタンスで、リソースサーバーとサブジェクト情報に委任された許可を要求できます。リソースサーバーへの委任されたアクセスは、クライアントインスタンスがリソース所有者に代わってリソースとAPIにアクセスするために使用でき、サブジェクト情報への委任されたアクセスをクライアントインスタンスで使用して、認証決定を下すことができます。この代表団は、通常、リソース所有者に代わって、認証サーバーによって促進されます。ソフトウェアを操作するエンドユーザーは、認証サーバーと対話して、リクエストをリソース所有者として認証、同意、および認証することができます。
The process by which the delegation happens is known as a grant, and GNAP allows for the negotiation of the grant process over time by multiple parties acting in distinct roles.
代表団が発生するプロセスは助成金として知られており、GNAPは、異なる役割で行動する複数の関係者による助成金プロセスの交渉を許可します。
This specification focuses on the portions of the delegation process facing the client instance. In particular, this specification defines interoperable methods for a client instance to request, negotiate, and receive access to information facilitated by the authorization server. This specification additionally defines methods for the client instance to access protected resources at a resource server. This specification also discusses discovery mechanisms that enable the client instance to configure itself dynamically. The means for an authorization server and resource server to interoperate are discussed in [GNAP-RS].
この仕様は、クライアントインスタンスに直面している委任プロセスの部分に焦点を当てています。特に、この仕様は、クライアントインスタンスが承認サーバーによって促進された情報へのアクセスを要求、交渉、および受信する相互運用可能な方法を定義します。この仕様では、クライアントインスタンスのメソッドを定義して、リソースサーバーで保護されたリソースにアクセスします。この仕様では、クライアントインスタンスが動的に自らを構成できるようにする発見メカニズムについても説明します。認証サーバーとリソースサーバーが[GNAP-RS]で議論される手段について説明します。
The focus of this protocol is to provide interoperability between the different parties acting in each role, not to specify implementation details of each. Where appropriate, GNAP may make recommendations about internal implementation details, but these recommendations are to ensure the security of the overall deployment rather than to be prescriptive in the implementation.
このプロトコルの焦点は、各役割で行動するさまざまな関係者間で相互運用性を提供することであり、それぞれの実装の詳細を指定することではありません。必要に応じて、GNAPは内部実装の詳細について推奨する場合がありますが、これらの推奨事項は、実装において規範的ではなく、全体的な展開のセキュリティを確保することです。
This protocol solves many of the same use cases as OAuth 2.0 [RFC6749], OpenID Connect [OIDC], and the family of protocols that have grown up around that ecosystem. However, GNAP is not an extension of OAuth 2.0 and is not intended to be directly compatible with OAuth 2.0. GNAP seeks to provide functionality and solve use cases that OAuth 2.0 cannot easily or cleanly address. Appendix A further details the protocol rationale compared to OAuth 2.0. GNAP and OAuth 2.0 will likely exist in parallel for many deployments, and considerations have been taken to facilitate the mapping and transition from existing OAuth 2.0 systems to GNAP. Some examples of these can be found in Appendix B.5.
このプロトコルは、OAUTH 2.0 [RFC6749]、OpenID Connect [OIDC]、およびその生態系の周りで成長したプロトコルのファミリーと同じユースケースの多くを解決します。ただし、GNAPはOAUTH 2.0の拡張ではなく、OAUTH 2.0と直接互換性があることを意図していません。GNAPは、機能を提供し、OAUTH 2.0が簡単にまたはきれいに対処できないユースケースを解決しようとしています。付録Aは、OAUTH 2.0と比較したプロトコルの根拠をさらに詳しく説明しています。GNAPとOAUTH 2.0は、多くの展開に対して並行して存在する可能性が高く、既存のOAUTH 2.0システムからGNAPへのマッピングと移行を促進するために考慮事項が課されています。これらのいくつかの例は、付録B.5に記載されています。
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.
キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URIs, query components, keys, and other elements. Whenever possible, the document uses URI as a generic term, since it aligns with the recommendations in [RFC3986] and better matches the intent that the identifier may be reachable through various/generic means (compared to URLs). 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構造、URI、クエリコンポーネント、キー、およびその他の要素の非規範的な例が含まれています。可能な場合はいつでも、ドキュメントはURIを一般的な用語として使用します。これは、[RFC3986]の推奨事項と一致し、識別子がさまざまな/一般的な手段を通じて（URLと比較して）到達可能であるという意図をよりよく一致させるためです。いくつかの例は、単一の後続のバックスラッシュ（\）を使用して、[RFC8792]に従って、長い値のラインラッピングを示しています。ラップラインの\文字と先行スペースは、値の一部ではありません。
This document uses the term "mutual TLS" as defined by [RFC8705]. The shortened form "MTLS" is used to mean the same thing.
このドキュメントでは、[RFC8705]で定義されている「相互TLS」という用語を使用します。短縮フォーム「MTLS」は、同じことを意味するために使用されます。
For brevity, the term "signature" on its own is used in this document to refer to both digital signatures (which use asymmetric cryptography) and keyed Message Authentication Codes (MACs) (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or a keyed MAC over a given signature base. The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation.
簡潔にするために、このドキュメントでは「署名」という用語は、デジタル署名（非対称暗号化を使用）とキー付きメッセージ認証コード（MAC）（対称暗号を使用）の両方を参照するために使用されます。同様に、動詞「符号」とは、特定の署名ベースにわたるデジタル署名またはキー付きMacの生成を指します。適格な用語「デジタル署名」とは、非対称暗号化署名操作の出力を特に指します。
The parties in GNAP perform actions under different roles. Roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol.
GNAPの当事者は、さまざまな役割の下でアクションを実行します。役割は、実行されたアクションと、全体的なプロトコルによって役割についてレバレッジされた期待によって定義されます。
+-------------+ +------------+
| | | |
|Authorization| | Resource |
| Server | | Server |
| |<--+ +--->| |
+-----+-------+ | | +------------+
║ | |
║ +--+---+---+
║ | Client |
║ | Instance |
║ +----+-----+
║ ║
.----+----. ║ .----------.
| | +=====+ |
| Resource | | End |
| Owner | ~ ~ ~ ~ ~ ~ | User |
| | | |
`---------` `----------`
Legend:
===== indicates interaction between a human and computer
----- indicates interaction between two pieces of software
~ ~ ~ indicates a potential equivalence or out-of-band
communication between roles
Figure 1: Roles in GNAP
図1：GNAPの役割
Authorization Server (AS):
承認サーバー（AS）：
Server that grants delegated privileges to a particular instance of client software in the form of access tokens or other information (such as subject information). The AS is uniquely defined by the grant endpoint URI, which is the absolute URI where grant requests are started by clients.
アクセストークンまたはその他の情報（サブジェクト情報など）の形でクライアントソフトウェアの特定のインスタンスに特権を委任するサーバー。ASは、助成金のエンドポイントURIによって一意に定義されています。これは、クライアントが助成金リクエストを開始する絶対的なURIです。
Client:
クライアント:
Application that consumes resources from one or several resource servers, possibly requiring access privileges from one or several ASes. The client is operated by the end user, or it runs autonomously on behalf of a resource owner.
1つまたは複数のリソースサーバーからリソースを消費するアプリケーションで、1つまたは複数のASEからのアクセス権限を必要とする可能性があります。クライアントはエンドユーザーによって操作されるか、リソース所有者に代わって自律的に実行されます。
For example, a client can be a mobile application, a web application, a backend data processor, etc.
たとえば、クライアントはモバイルアプリケーション、Webアプリケーション、バックエンドデータプロセッサなどです。
Note: This specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software). For some kinds of client software, there could be many instances of that software, each instance with a different key.
注：この仕様は、特定のインスタンス（クライアントインスタンス、その一意のキーによって識別される）と、インスタンスを実行しているソフトウェア（クライアントソフトウェア）を区別します。ある種のクライアントソフトウェアの場合、そのソフトウェアには多くのインスタンスがあり、各インスタンスは異なるキーを備えています。
Resource Server (RS):
リソースサーバー（RS）：
Server that provides an API on protected resources, where operations on the API require a valid access token issued by a trusted AS.
APIの操作には、信頼できるASが発行した有効なアクセストークンが必要な保護リソースのAPIを提供するサーバー。
Resource Owner (RO):
リソース所有者（RO）：
Subject entity that may grant or deny operations on resources it has authority upon.
権限を持っているリソースに対する運用を許可または拒否する可能性のある主題エンティティ。
Note: The act of granting or denying an operation may be manual (i.e., through an interaction with a physical person) or automatic (i.e., through predefined organizational rules).
注：操作を許可または拒否する行為は、マニュアル（つまり、物理的な人との相互作用）または自動（つまり、定義された組織ルールを通じて）である場合があります。
End user:
エンドユーザー：
Natural person that operates a client instance.
クライアントインスタンスを操作する自然人。
Note: That natural person may or may not be the same entity as the RO.
注：自然人はROと同じエンティティである場合とそうでない場合があります。
The design of GNAP does not assume any one deployment architecture but instead attempts to define roles that can be fulfilled in a number of different ways for different use cases. As long as a given role fulfills all of its obligations and behaviors as defined by the protocol, GNAP does not make additional requirements on its structure or setup.
GNAPの設計は、1つの展開アーキテクチャを想定するのではなく、異なるユースケースでさまざまな方法で満たすことができる役割を定義しようとします。特定の役割がプロトコルで定義されているすべての義務と行動を満たしている限り、GNAPはその構造またはセットアップに追加の要件を作成しません。
Multiple roles can be fulfilled by the same party, and a given party can switch roles in different instances of the protocol. For example, in many instances, the RO and end user are the same person, where a user authorizes the client instance to act on their own behalf at the RS. In this case, one party fulfills the roles of both RO and end user, but the roles themselves are still defined separately from each other to allow for other use cases where they are fulfilled by different parties.
同じ当事者によって複数の役割を果たすことができ、特定の当事者はプロトコルのさまざまな例で役割を切り替えることができます。たとえば、多くの場合、ROとエンドユーザーは同じ人物であり、ユーザーはクライアントインスタンスがRSで独自に行動することを許可します。この場合、一方の当事者はROユーザーとエンドユーザーの両方の役割を果たしますが、役割自体は、異なる当事者によって満たされる他のユースケースを可能にするために、互いに別々に定義されています。
As another example, in some complex scenarios, an RS receiving requests from one client instance can act as a client instance for a downstream secondary RS in order to fulfill the original request. In this case, one piece of software is both an RS and a client instance from different perspectives, and it fulfills these roles separately as far as the overall protocol is concerned.
別の例として、いくつかの複雑なシナリオでは、1つのクライアントインスタンスからRSの受信リクエストが、元のリクエストを満たすために、下流のセカンダリRSのクライアントインスタンスとして機能することができます。この場合、1つのソフトウェアはRSと異なる観点からのクライアントインスタンスの両方であり、全体的なプロトコルに関する限り、これらの役割を個別に満たします。
A single role need not be deployed as a monolithic service. For example, a client instance could have frontend components that are installed on the end user's device as well as a backend system that the frontend communicates with. If both of these components participate in the delegation protocol, they are both considered part of the client instance. If there are several copies of the client software that run separately but all share the same key material, such as a deployed cluster, then this cluster is considered a single client instance. In these cases, the distinct components of what is considered a GNAP client instance may use any number of different communication mechanisms between them, all of which would be considered an implementation detail of the client instances and out of scope of GNAP.
単一の役割をモノリシックサービスとして展開する必要はありません。たとえば、クライアントインスタンスには、エンドユーザーのデバイスにインストールされているフロントエンドコンポーネントと、フロントエンドが通信するバックエンドシステムを持つことができます。これらのコンポーネントの両方が委任プロトコルに参加している場合、どちらもクライアントインスタンスの一部と見なされます。クライアントソフトウェアのコピーが別々に実行されているが、すべてが展開されたクラスターなどの同じ重要な資料を共有している場合、このクラスターは単一のクライアントインスタンスと見なされます。これらの場合、GNAPクライアントインスタンスと見なされるものの明確なコンポーネントは、それらの間に任意の数の異なる通信メカニズムを使用する場合があります。これらはすべて、クライアントインスタンスの実装の詳細とGNAPの範囲外と見なされます。
As another example, an AS could likewise be built out of many constituent components in a distributed architecture. The component that the client instance calls directly could be different from the component that the RO interacts with to drive consent, since API calls and user interaction have different security considerations in many environments. Furthermore, the AS could need to collect identity claims about the RO from one system that deals with user attributes while generating access tokens at another system that deals with security rights. From the perspective of GNAP, all of these are pieces of the AS and together fulfill the role of the AS as defined by the protocol. These pieces may have their own internal communications mechanisms, which are considered out of scope of GNAP.
別の例として、同様に、分散アーキテクチャ内の多くの構成要素から構築できます。API呼び出しとユーザーインタラクションは多くの環境でセキュリティ上の考慮事項が異なるため、クライアントインスタンスが直接呼び出すコンポーネントは、ROが同意を促進するコンポーネントとは異なる可能性があります。さらに、ASは、セキュリティ権を扱う別のシステムでアクセストークンを生成しながら、ユーザー属性を扱うあるシステムからROに関するIDクレームを収集する必要があります。GNAPの観点から見ると、これらはすべてASの部分であり、プロトコルによって定義されたASの役割を一緒に満たします。これらのピースには、GNAPの範囲外と見なされる独自の内部通信メカニズムがある場合があります。
In addition to the roles above, the protocol also involves several elements that are acted upon by the roles throughout the process.
上記の役割に加えて、プロトコルには、プロセス全体の役割によって行動されるいくつかの要素も含まれます。
Access Token:
アクセストークン：
A data artifact representing a set of rights and/or attributes.
一連の権利および/または属性を表すデータアーティファクト。
Note: An access token can be first issued to a client instance (requiring authorization by the RO) and subsequently rotated.
注：アクセストークンは、最初にクライアントインスタンス（ROによる承認が必要）に発行され、その後回転することができます。
Grant:
付与：
(verb): To permit an instance of client software to receive some attributes at a specific time and with a specific duration of validity and/or to exercise some set of delegated rights to access a protected resource.
（動詞）：クライアントソフトウェアのインスタンスが特定の時間に、特定の妥当性の期間にいくつかの属性を受け取ることを許可し、および/または保護されたリソースにアクセスするための委任された権利のセットを行使することを許可します。
(noun): The act of granting permission to a client instance.
（名詞）：クライアントインスタンスに許可を付与する行為。
Privilege:
特権：
Right or attribute associated with a subject.
主題に関連付けられた右または属性。
Note: The RO defines and maintains the rights and attributes associated to the protected resource and might temporarily delegate some set of those privileges to an end user. This process is referred to as "privilege delegation".
注：ROは、保護されたリソースに関連する権利と属性を定義および維持し、これらの特権のセットをエンドユーザーに一時的に委任する可能性があります。このプロセスは「特権代表団」と呼ばれます。
Protected Resource:
保護されたリソース：
Protected API that is served by an RS and that can be accessed by a client, if and only if a valid and sufficient access token is provided.
RSが提供し、有効で十分なアクセストークンが提供された場合にのみ、クライアントがアクセスできる保護されたAPI。
Note: To avoid complex sentences, the specification document may simply refer to "resource" instead of "protected resource".
注：複雑な文を避けるために、仕様文書は単に「保護されたリソース」ではなく「リソース」を参照する場合があります。
Right:
右：
Ability given to a subject to perform a given operation on a resource under the control of an RS.
Rsの制御下でリソースで特定の操作を実行する被験者に与えられた能力。
Subject:
主題：
Person or organization. The subject decides whether and under which conditions its attributes can be disclosed to other parties.
人または組織。被験者は、その属性を他の当事者に開示できるかどうか、そしてその条件下で決定する。
Subject Information:
主題情報：
Set of statements and attributes asserted by an AS about a subject. These statements can be used by the client instance as part of an authentication decision.
被験者について主張された一連のステートメントと属性。これらのステートメントは、認証決定の一部としてクライアントインスタンスで使用できます。
GNAP defines its trust objective as follows: the RO trusts the AS to ensure access validation and delegation of protected resources to end users, through third party clients.
GNAPは、信頼の目的を次のように定義します。ROは、サードパーティのクライアントを通じて、エンドユーザーへの保護されたリソースのアクセス検証と委任を確保するために信頼しています。
This trust objective can be decomposed into trust relationships between software elements and roles, especially the pairs end user/ RO, end user/client, client/AS, RS/RO, AS/RO, and AS/RS. Trust of an agent by its pair can exist if the pair is informed that the agent has made a promise to follow the protocol in the past (e.g., pre-registration and uncompromised cryptographic components) or if the pair is able to infer by indirect means that the agent has made such a promise (e.g., a compliant client request). Each agent defines its own valuation function of promises given or received. Examples of such valuations can be the benefits from interacting with other agents (e.g., safety in client access and interoperability with identity standards), the cost of following the protocol (including its security and privacy requirements and recommendations), a ranking of promise importance (e.g., a policy decision made by the AS), the assessment of one's vulnerability or risk of not being able to defend against threats, etc. Those valuations may depend on the context of the request. For instance, depending on the specific case in which GNAP is used, the AS may decide to either take into account or discard hints provided by the client, or the RS may refuse bearer tokens. Some promises can be affected by previous interactions (e.g., repeated requests).
この信頼の目的は、ソフトウェア要素と役割の信頼関係、特にペアエンドユーザー/RO、エンドユーザー/クライアント、クライアント/AS、RS/RO、AS/RO、AS/RSに分解することができます。ペアによるエージェントの信頼は、エージェントが過去にプロトコルに従うことを約束したこと（例えば、事前登録や妥協のない暗号化コンポーネント）を約束したこと、またはペアが間接的な手段で推測できる場合、ペアによるエージェントの信頼が存在する可能性があります。エージェントがそのような約束をしたこと（たとえば、準拠したクライアントのリクエスト）。各エージェントは、与えられたまたは受け取った約束の独自の評価機能を定義します。そのような評価の例は、他のエージェントと対話することによる利点（例：クライアントアクセスの安全性とアイデンティティ基準との相互運用性）、プロトコルに従うコスト（セキュリティおよびプライバシー要件と推奨事項を含む）、約束の重要性のランキング（たとえば、ASによる政策決定、AS）、自分の脆弱性の評価または脅威から守ることができないというリスクなど。これらの評価は、要求のコンテキストに依存する場合があります。たとえば、GNAPが使用される特定のケースに応じて、ASは、クライアントが提供するヒントを考慮するか、RSがベアラートークンを拒否する場合があります。いくつかの約束は、以前の相互作用の影響を受ける可能性があります（例：繰り返しのリクエスト）。
Below are details of each trust relationship:
以下は、各信頼関係の詳細です。
end user/RO:
エンドユーザー/RO：
This relationship exists only when the end user and the RO are different, in which case the end user needs some out-of-band mechanism of getting the RO consent (see Section 4). GNAP generally assumes that humans can be authenticated, thanks to identity protocols (for instance, through an id_token assertion as described in Section 2.2).
この関係は、エンドユーザーとROが異なる場合にのみ存在します。その場合、エンドユーザーはROの同意を得るための帯域外のメカニズムを必要とします（セクション4を参照）。GNAPは、一般に、IDプロトコルのおかげで、人間が認証できると想定しています（たとえば、セクション2.2で説明されているID_TOKENアサーションを介して）。
end user/client:
エンドユーザー/クライアント：
The client acts as a user agent. Depending on the technology used (browser, single-page application (SPA), mobile application, Internet of Things (IoT) device, etc.), some interactions may or may not be possible (as described in Section 2.5.1). Client developers implement requirements and generally some recommendations or best practices, so that the end users may confidently use their software. However, end users might also face an attacker's client software or a poorly implemented client without even realizing it.
クライアントはユーザーエージェントとして機能します。使用されるテクノロジー（ブラウザ、シングルページアプリケーション（SPA）、モバイルアプリケーション、モノのインターネット（IoT）デバイスなど）に応じて、一部の相互作用が可能である場合とできない場合があります（セクション2.5.1で説明されています）。クライアント開発者は、要件と一般的にいくつかの推奨事項またはベストプラクティスを実装しているため、エンドユーザーが自信を持ってソフトウェアを使用できるようにします。ただし、エンドユーザーは、攻撃者のクライアントソフトウェアや、実装されていないクライアントに気付かずに直面する場合があります。
end user/AS:
エンドユーザー/AS：
When the client supports the interaction feature (see Section 3.3), the end user interacts with the AS through an AS-provided interface. In many cases, this happens through a front-channel interaction through the end user's browser. See Section 11.29 for some considerations in trusting these interactions.
クライアントがインタラクション機能をサポートすると（セクション3.3を参照）、エンドユーザーは、提供されたインターフェイスを介してASと対話します。多くの場合、これはエンドユーザーのブラウザを介したフロントチャネルの相互作用によって行われます。これらの相互作用を信頼するいくつかの考慮事項については、セクション11.29を参照してください。
client/AS:
クライアント/as：
An honest AS may face an attacker's client (as discussed just above), or the reverse, and GNAP aims to make common attacks impractical. This specification makes access tokens opaque to the client and defines the request/response scheme in detail, therefore avoiding extra trust hypotheses from this critical piece of software. Yet, the AS may further define cryptographic attestations or optional rules to simplify the access of clients it already trusts, due to past behavior or organizational policies (see Section 2.3).
正直なところ、攻撃者のクライアント（上で説明したように）または逆に直面する可能性があります。この仕様により、アクセストークンがクライアントに不透明になり、リクエスト/応答スキームを詳細に定義するため、この重要なソフトウェアからの追加の信頼仮説を回避します。しかし、ASは、過去の行動や組織のポリシーにより、既に信頼できるクライアントのアクセスを簡素化するために、暗号化の証明またはオプションのルールをさらに定義する場合があります（セクション2.3を参照）。
RS/RO:
RS/RO：
On behalf of the RO, the RS promises to protect its resources from unauthorized access and only accepts valid access tokens issued by a trusted AS. In case tokens are key bound, proper validation of the proofing method is expected from the RS.
ROを代表して、RSは不正アクセスからリソースを保護することを約束し、信頼できるASによって発行された有効なアクセストークンのみを受け入れます。トークンが重要なバウンドである場合、Rsからプルーフ方法の適切な検証が予想されます。
AS/RO:
as/ro：
The AS is expected to follow the decisions made by the RO, through either interactive consent requests, repeated interactions, or automated rules (as described in Section 1.6). Privacy considerations aim to reduce the risk of an honest but too-curious AS or the consequences of an unexpected user data exposure.
対話型の同意要求、繰り返しの相互作用、または自動化されたルール（セクション1.6で説明されているように）を通じて、ROによって下された決定に従うことが予想されています。プライバシーの考慮事項は、正直であるが、あまりにも好意的すぎるリスクを減らすこと、または予期しないユーザーデータ露出の結果を減らすことを目的としています。
AS/RS:
As/rs：
The AS promises to issue valid access tokens to legitimate client requests (i.e., after carrying out appropriate due diligence, as defined in the GNAP). Some optional configurations are covered by [GNAP-RS].
正当なクライアント要求に有効なアクセストークンを発行することを約束します（つまり、GNAPで定義されている適切なデューデリジェンスを実行した後）。一部のオプションの構成は[GNAP-RS]でカバーされています。
A global assumption made by GNAP is that authorization requests are security and privacy sensitive, and appropriate measures are detailed in Sections 11 and 12, respectively.
GNAPによってなされたグローバルな仮定は、承認要求がセキュリティとプライバシーに敏感であり、適切な措置がそれぞれセクション11と12に詳述されていることです。
A formal trust model is out of scope of this specification, but one could be developed using techniques such as the Promise Theory [promise-theory].
正式な信頼モデルはこの仕様の範囲外ですが、Promise Theory [Promise-Theory]などの手法を使用して開発できます。
GNAP is fundamentally designed to allow delegated access to APIs and other information, such as subject information, using a multi-stage, stateful process. This process allows different parties to provide information into the system to alter and augment the state of the delegated access and its artifacts.
GNAPは、マルチステージのステートフルなプロセスを使用して、APIやサブジェクト情報などのその他の情報への委任されたアクセスを許可するように基本的に設計されています。このプロセスにより、さまざまな関係者がシステムに情報を提供して、委任されたアクセスとそのアーティファクトの状態を変更および増強することができます。
The underlying requested grant moves through several states as different actions take place during the protocol, as shown in Figure 2.
図2に示すように、プロトコル中に異なるアクションが行われると、基礎となる要求された助成金はいくつかの州を移動します。
.-----.
| |
+------+--+ | Continue
.---Need Interaction---->| | |
/ | Pending |<--`
/ .--Finish Interaction--+ |
/ / (approve/deny) +----+----+
/ / |
/ / | Cancel
/ v v
+-+----------+ +===========+
| | ║ ║
---Request-->| Processing +------Finalize---->║ Finalized ║
| | ║ ║
+-+----------+ +===========+
\ ^ ^
\ \ | Revoke or
\ \ | Finalize
\ \ +-----+----+
\ `-----Update---------+ |
\ | Approved |<--.
`-----No Interaction--->| | |
+-------+--+ | Continue
| |
`-----`
Figure 2: State Diagram of a Grant Request in GNAP
図2：GNAPでの助成金要求の状態図
The state of the grant request is defined and managed by the AS, though the client instance also needs to manage its view of the grant request over time. The means by which these roles manage their state are outside the scope of this specification.
クライアントインスタンスは、ASによって定義および管理されますが、ASによって管理されます。これらの役割が州を管理する手段は、この仕様の範囲外です。
_Processing_:
_処理_：
When a request for access (Section 2) is received by the AS, a new grant request is created and placed in the _processing_ state by the AS. This state is also entered when an existing grant request is updated by the client instance and when interaction is completed. In this state, the AS processes the context of the grant request to determine whether interaction with the end user or RO is required for approval of the request. The grant request has to exit this state before a response can be returned to the client instance. If approval is required, the request moves to the _pending_ state, and the AS returns a continuation response (Section 3.1) along with any appropriate interaction responses (Section 3.3). If no such approval is required, such as when the client instance is acting on its own behalf or the AS can determine that access has been fulfilled, the request moves to the _approved_ state where access tokens for API access (Section 3.2) and subject information (Section 3.4) can be issued to the client instance. If the AS determines that no additional processing can occur (such as a timeout or an unrecoverable error), the grant request is moved to the _finalized_ state and is terminated.
ASがアクセスのリクエスト（セクション2）を受信すると、ASによって_Processing_状態に新しい助成金リクエストが作成され、配置されます。この状態は、クライアントインスタンスによって既存の助成金リクエストが更新され、インタラクションが完了したときにも入力されます。この状態では、AS ASは、リクエストの承認にエンドユーザーまたはROとの対話が必要かどうかを判断するために、助成金要求のコンテキストを処理します。助成金リクエストは、クライアントインスタンスに応答を返す前に、この状態を終了する必要があります。承認が必要な場合、要求は_Pending_状態に移動し、ASは適切な相互作用応答（セクション3.3）とともに継続応答（セクション3.1）を返します。クライアントインスタンスが独自に行動している場合や、アクセスが満たされていると判断できるように、そのような承認が必要ない場合、リクエストはAPIアクセスのアクセストークン（セクション3.2）およびサブジェクト情報の_Approved_状態に移動します。（セクション3.4）は、クライアントインスタンスに発行できます。ASが追加の処理が発生しないと判断した場合（タイムアウトや回復不可能なエラーなど）、Grantリクエストは_Finalized_状態に移動し、終了します。
_Pending_:
_保留中_：
When a request needs to be approved by an RO, or interaction with the end user is required, the grant request enters a state of _pending_. In this state, no access tokens can be granted, and no subject information can be released to the client instance. While a grant request is in this state, the AS seeks to gather the required consent and authorization (Section 4) for the requested access. A grant request in this state is always associated with a continuation access token bound to the client instance's key (see Section 3.1 for details of the continuation access token). If no interaction finish method (Section 2.5.2) is associated with this request, the client instance can send a polling continuation request (Section 5.2) to the AS. This returns a continuation response (Section 3.1) while the grant request remains in this state, allowing the client instance to continue to check the state of the pending grant request. If an interaction finish method (Section 2.5.2) is specified in the grant request, the client instance can continue the request after interaction (Section 5.1) to the AS to move this request to the _processing_ state to be re-evaluated by the AS. Note that this occurs whether the grant request has been approved or denied by the RO, since the AS needs to take into account the full context of the request before determining the next step for the grant request. When other information is made available in the context of the grant request, such as through the asynchronous actions of the RO, the AS moves this request to the _processing_ state to be re-evaluated. If the AS determines that no additional interaction can occur, e.g., all the interaction methods have timed out or a revocation request (Section 5.4) is received from the client instance, the grant request can be moved to the _finalized_ state.
リクエストをROによって承認する必要がある場合、またはエンドユーザーとの相互作用が必要な場合、助成金リクエストは_Pending_の状態に入ります。この状態では、アクセストークンを付与することはできず、クライアントインスタンスに主題情報をリリースすることはできません。この状態には助成金要求がありますが、ASは要求されたアクセスのために必要な同意と承認（セクション4）を収集しようとしています。この状態の助成金要求は、常にクライアントインスタンスのキーにバインドされた継続アクセストークンに関連付けられています（継続アクセストークンの詳細については、セクション3.1を参照）。相互作用終了方法（セクション2.5.2）がこのリクエストに関連付けられていない場合、クライアントインスタンスはポーリング継続要求（セクション5.2）をASに送信できます。これにより、継続的な応答（セクション3.1）が返されますが、助成金要求はこの状態に残り、クライアントインスタンスが保留中の助成金要求の状態を引き続き確認できます。相互作用終了方法（セクション2.5.2）が助成金リクエストで指定されている場合、クライアントインスタンスは、このリクエストを_Processing_状態に移動するための相互作用後（セクション5.1）を継続することができます。。これは、助成金要求の次のステップを決定する前に、ASが要求の完全なコンテキストを考慮に入れる必要があるため、助成金要求がROによって承認されたか拒否されたかどうかにかかわらず発生することに注意してください。ROの非同期アクションなど、助成金要求のコンテキストで他の情報が利用可能になった場合、ASはこの要求を_Processing_状態に再評価するように移動します。ASが追加の相互作用が発生しないと判断した場合、たとえば、すべての相互作用方法がタイムアウトしたか、取消し要求（セクション5.4）がクライアントインスタンスから受信された場合、助成金要求は_Finalized_状態に移動できます。
_Approved_:
_承認された_：
When a request has been approved by an RO and no further interaction with the end user is required, the grant request enters a state of _approved_. In this state, responses to the client instance can include access tokens for API access (Section 3.2) and subject information (Section 3.4). If continuation and updates are allowed for this grant request, the AS can include the continuation response (Section 3.1). In this state, post-interaction continuation requests (Section 5.1) are not allowed and will result in an error, since all interaction is assumed to have been completed. If the client instance sends a polling continuation request (Section 5.2) while the request is in this state, new access tokens (Section 3.2) can be issued in the response. Note that this always creates a new access token, but any existing access tokens could be rotated and revoked using the token management API (Section 6). The client instance can send an update continuation request (Section 5.3) to modify the requested access, causing the AS to move the request back to the _processing_ state for re-evaluation. If the AS determines that no additional tokens can be issued and that no additional updates are to be accepted (e.g., the continuation access tokens have expired), the grant is moved to the _finalized_ state.
ROによってリクエストが承認され、エンドユーザーとのさらなる相互作用が不要な場合、助成金リクエストは_Approved_の状態に入ります。この状態では、クライアントインスタンスへの回答には、APIアクセスのためのアクセストークン（セクション3.2）およびサブジェクト情報（セクション3.4）を含めることができます。この助成金リクエストに継続と更新が許可されている場合、ASには継続応答が含まれます（セクション3.1）。この状態では、相互作用後の継続要求（セクション5.1）は許可されておらず、すべての相互作用が完了したと想定されるため、エラーが発生します。クライアントインスタンスがこの状態にあるリクエストがある間にポーリング継続要求（セクション5.2）を送信する場合、応答で新しいアクセストークン（セクション3.2）を発行できます。これにより、常に新しいアクセストークンが作成されますが、既存のアクセストークンは、トークン管理API（セクション6）を使用して回転および取り消すことができることに注意してください。クライアントインスタンスは、更新継続要求（セクション5.3）を送信して要求されたアクセスを変更し、再評価のために要求を_Processing_状態に戻すようにすることができます。追加のトークンを発行できず、追加の更新が受け入れられないと判断した場合（たとえば、継続アクセストークンが期限切れになっている）、助成金は_Finalized_状態に移動します。
_Finalized_:
_finalized_：
After the access tokens are issued, if the AS does not allow any additional updates on the grant request, the grant request enters the _finalized_ state. This state is also entered when an existing grant request is revoked by the client instance (Section 5.4) or otherwise revoked by the AS (such as through out-of-band action by the RO). This state can also be entered if the AS determines that no additional processing is possible, for example, if the RO has denied the requested access or if interaction is required but no compatible interaction methods are available. Once in this state, no new access tokens can be issued, no subject information can be returned, and no interactions can take place. Once in this state, the grant request is dead and cannot be revived. If future access is desired by the client instance, a new grant request can be created, unrelated to this grant request.
アクセストークンが発行された後、ASが助成金リクエストで追加の更新を許可しない場合、助成金リクエストは_Finalized_状態に入ります。この状態は、既存の助成金要求がクライアントインスタンス（セクション5.4）によって取り消された場合、またはAS（ROによる帯域外アクションなど）によって取り消された場合にも入力されます。この状態は、ROが要求されたアクセスを拒否した場合、または相互作用が必要であるが互換性のある相互作用方法が利用できない場合、追加の処理が不可能であると判断した場合にも入力できます。この状態では、新しいアクセストークンを発行することはできません。サブジェクト情報を返すことはできません。また、相互作用は行われません。この状態で、助成金の要求は死んでおり、復活できません。将来のアクセスがクライアントインスタンスに必要な場合は、この助成金リクエストとは無関係に、新しい助成金リクエストを作成できます。
While it is possible to deploy an AS in a stateless environment, GNAP is a stateful protocol, and such deployments will need a way to manage the current state of the grant request in a secure and deterministic fashion without relying on other components, such as the client software, to keep track of the current state.
ステートレス環境でASを展開することは可能ですが、GNAPはステートフルプロトコルであり、そのような展開には、他のコンポーネントなどの他のコンポーネントに依存せずに、安全で決定的な方法で助成金リクエストの現在の状態を管理する方法が必要です。現在の状態を追跡するためのクライアントソフトウェア。
GNAP can be used in a variety of ways to allow the core delegation process to take place. Many portions of this process are conditionally present depending on the context of the deployments, and not every step in this overview will happen in all circumstances.
GNAPは、コア委任プロセスを実施できるようにするために、さまざまな方法で使用できます。このプロセスの多くの部分は、展開のコンテキストに応じて条件付きで存在し、この概要のすべてのステップがすべての状況で発生するわけではありません。
Note that a connection between roles in this process does not necessarily indicate that a specific protocol message is sent across the wire between the components fulfilling the roles in question or that a particular step is required every time. For example, for a client instance interested in only getting subject information directly and not calling an RS, all steps involving the RS below do not apply.
このプロセスにおける役割間の接続は、問題の役割を満たすコンポーネント間のワイヤ間で特定のプロトコルメッセージが送信されること、または毎回特定のステップが必要であることを必ずしも示しているわけではないことに注意してください。たとえば、サブジェクト情報のみを直接取得し、RSを呼び出すことなく直接取得することに関心のあるクライアントインスタンスの場合、以下のRSに関連するすべての手順は適用されません。
In some circumstances, the information needed at a given stage is communicated out of band or is pre-configured between the components or entities performing the roles. For example, one entity can fulfill multiple roles, so explicit communication between the roles is not necessary within the protocol flow. Additionally, some components may not be involved in all use cases. For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS.
状況によっては、特定の段階で必要な情報はバンドから通信されるか、役割を実行するコンポーネントまたはエンティティ間で事前に構成されます。たとえば、1つのエンティティが複数の役割を果たすことができるため、プロトコルフロー内では、役割間の明示的な通信は必要ありません。さらに、一部のコンポーネントはすべてのユースケースに関与していない場合があります。たとえば、クライアントインスタンスは、直接ユーザー情報を取得するためだけにASを呼び出し、Rsを呼び出すためにアクセストークンを取得する必要はありません。
The following diagram provides a general overview of GNAP, including many different optional phases and connections. The diagrams in the following sections provide views of GNAP under more specific circumstances. These additional diagrams use the same conventions as the overall diagram below.
次の図は、多くの異なるオプションのフェーズと接続を含むGNAPの一般的な概要を示します。次のセクションの図は、より具体的な状況下でのGNAPのビューを提供します。これらの追加図は、以下の全体的な図と同じ規則を使用します。
.----------. .----------.
| End user | ~ ~ ~ ~ | Resource |
| | | Owner (RO) |
`----+-----` `-----+----`
║ ║
║ ║
(A) (B)
║ ║
║ ║
+-----+--+ ║ +------------+
| Client | (1) ║ | Resource |
|Instance| ║ | Server |
| | +-----------+---+ | (RS) |
| +--(2)-->| Authorization | | |
| |<-(3)---+ Server | | |
| | | (AS) | | |
| +--(4)-->| | | |
| |<-(5)---+ | | |
| | | | | |
| +---------------(6)------------->| |
| | | | (7) | |
| |<--------------(8)------------->| |
| | | | | |
| +--(9)-->| | | |
| |<-(10)--+ | | |
| | | | | |
| +---------------(11)------------>| |
| | | | (12) | |
| +--(13)->| | | |
| | | | | |
+--------+ +---------------+ +------------+
Legend:
===== indicates a possible interaction with a human
----- indicates an interaction between protocol roles
~ ~ ~ indicates a potential equivalence or out-of-band
communication between roles
Figure 3: Overall Sequence of GNAP
図3：GNAPの全体的なシーケンス
* (A) The end user interacts with the client instance to indicate a need for resources on behalf of the RO. This could identify the RS that the client instance needs to call, the resources needed, or the RO that is needed to approve the request. Note that the RO and end user are often the same entity in practice, but GNAP makes no general assumption that they are.
* （a）エンドユーザーはクライアントインスタンスと対話して、ROに代わってリソースの必要性を示します。これにより、クライアントインスタンスが呼び出す必要があるRS、必要なリソース、またはリクエストを承認するために必要なROを識別できます。ROおよびエンドユーザーは実際に同じエンティティと同じエンティティであることが多いことに注意してくださいが、GNAPはそれらが一般的であるという一般的な仮定をしていません。
* (1) The client instance determines what access is needed and which AS to approach for access. Note that for most situations, the client instance is pre-configured with which AS to talk to and which kinds of access it needs, but some more dynamic processes are discussed in Section 9.1.
* （1）クライアントインスタンスは、必要なアクセスとアクセスのためにアプローチするアクセスを決定します。ほとんどの状況では、クライアントインスタンスは事前に構成されており、それはどのような種類のアクセスが必要かについて事前に構成されていますが、セクション9.1でいくつかのより動的なプロセスについて説明します。
* (2) The client instance requests access at the AS (Section 2).
* （2）クライアントインスタンスは、AS（セクション2）でアクセスを要求します。
* (3) The AS processes the request and determines what is needed to fulfill the request (see Section 4). The AS sends its response to the client instance (Section 3).
* （3）ASは要求を処理し、要求を満たすために必要なものを決定します（セクション4を参照）。ASは、クライアントインスタンス（セクション3）への応答を送信します。
* (B) If interaction is required, the AS interacts with the RO (Section 4) to gather authorization. The interactive component of the AS can function using a variety of possible mechanisms, including web page redirects, applications, challenge/response protocols, or other methods. The RO approves the request for the client instance being operated by the end user. Note that the RO and end user are often the same entity in practice, and many of GNAP's interaction methods allow the client instance to facilitate the end user interacting with the AS in order to fulfill the role of the RO.
* （b）相互作用が必要な場合、ASはRO（セクション4）と相互作用して認可を収集します。ASのインタラクティブなコンポーネントは、Webページのリダイレクト、アプリケーション、チャレンジ/応答プロトコル、またはその他の方法など、さまざまなメカニズムを使用して機能します。ROは、エンドユーザーが操作するクライアントインスタンスのリクエストを承認します。ROとエンドユーザーは多くの場合、実際には同じエンティティであり、GNAPのインタラクション方法の多くにより、クライアントインスタンスがROの役割を果たすためにASと対話するエンドユーザーを促進することができることに注意してください。
* (4) The client instance continues the grant at the AS (Section 5). This action could occur in response to receiving a signal that interaction has finished (Section 4.2) or through a periodic polling mechanism, depending on the interaction capabilities of the client software and the options active in the grant request.
* （4）クライアントインスタンスは、AS（セクション5）で助成金を継続します。このアクションは、クライアントソフトウェアの相互作用機能と助成金リクエストでアクティブなオプションに応じて、相互作用が終了したという信号（セクション4.2）または定期的なポーリングメカニズムを介して発生することに応じて発生する可能性があります。
* (5) If the AS determines that access can be granted, it returns a response to the client instance (Section 3), including an access token (Section 3.2) for calling the RS and any directly returned information (Section 3.4) about the RO.
* （5）ASがアクセスを許可できると判断した場合、RSを呼び出すためのアクセストークン（セクション3.2）およびROに関する直接返された情報（セクション3.4）を含むクライアントインスタンス（セクション3）への応答を返します。。
* (6) The client instance uses the access token (Section 7.2) to call the RS.
* （6）クライアントインスタンスは、アクセストークン（セクション7.2）を使用してRsを呼び出します。
* (7) The RS determines if the token is sufficient for the request by examining the token. The means of the RS determining this access are out of scope of this specification, but some options are discussed in [GNAP-RS].
* （7）RSは、トークンを調べてトークンがリクエストに十分であるかどうかを判断します。このアクセスを決定するRSの平均は、この仕様の範囲外ですが、[GNAP-RS]でいくつかのオプションについて説明します。
* (8) The client instance calls the RS (Section 7.2) using the access token until the RS or client instance determines that the token is no longer valid.
* （8）クライアントインスタンスは、RSまたはクライアントインスタンスがトークンがもはや有効でないと判断するまで、アクセストークンを使用してRS（セクション7.2）を呼び出します。
* (9) When the token no longer works, the client instance rotates the access token (Section 6.1).
* （9）トークンが機能しなくなった場合、クライアントインスタンスはアクセストークンを回転させます（セクション6.1）。
* (10) The AS issues a new access token (Section 3.2) to the client instance with the same rights as the original access token returned in (5).
* （10）ASは、（5）で返された元のアクセストークンと同じ権利を持つクライアントインスタンスへの新しいアクセストークン（セクション3.2）を発行します。
* (11) The client instance uses the new access token (Section 7.2) to call the RS.
* （11）クライアントインスタンスは、新しいアクセストークン（セクション7.2）を使用してRsを呼び出します。
* (12) The RS determines if the new token is sufficient for the request, as in (7).
* （12）RSは、（7）のように、新しいトークンが要求に十分であるかどうかを決定します。
* (13) The client instance disposes of the token (Section 6.2) once the client instance has completed its access of the RS and no longer needs the token.
* （13）クライアントインスタンスは、クライアントインスタンスがRSのアクセスを完了し、トークンを必要としなくなったら、トークン（セクション6.2）を処分します。
The following sections and Appendix B contain specific guidance on how to use GNAP in different situations and deployments. For example, it is possible for the client instance to never request an access token and never call an RS, just as it is possible to have no end user involved in the delegation process.
次のセクションと付録Bには、さまざまな状況と展開でGNAPを使用する方法に関する特定のガイダンスが含まれています。たとえば、クライアントインスタンスがアクセストークンを要求せず、委任プロセスにエンドユーザーが関与しない可能性があるように、RSを呼び出すことはできません。
In this example flow, the client instance is a web application that wants access to resources on behalf of the current user, who acts as both the end user and the RO. Since the client instance is capable of directing the user to an arbitrary URI and receiving responses from the user's browser, interaction here is handled through front-channel redirects using the user's browser. The redirection URI used for interaction is a service hosted by the AS in this example. The client instance uses a persistent session with the user to ensure the same user that is starting the interaction is the user that returns from the interaction.
この例では、クライアントインスタンスは、エンドユーザーとROの両方として機能する現在のユーザーに代わってリソースにアクセスすることを望むWebアプリケーションです。クライアントインスタンスはユーザーを任意のURIに誘導し、ユーザーのブラウザから応答を受信できるため、ここでのインタラクションは、ユーザーのブラウザを使用してフロントチャネルリダイレクトを介して処理されます。相互作用に使用されるリダイレクトURIは、この例でASがホストするサービスです。クライアントインスタンスは、ユーザーとの永続的なセッションを使用して、インタラクションを開始しているのと同じユーザーがインタラクションから戻るユーザーであることを確認します。
+--------+ +--------+ .----.
| Client | | AS | | End |
|Instance| | | | User |
| |<=(1)== Start Session ===============================+ |
| | | | | |
| +--(2)--- Request Access --------->| | | |
| | | | | |
| |<-(3)-- Interaction Needed -------+ | | |
| | | | | |
| +==(4)== Redirect for Interaction ===================>| |
| | | | +------+
| | | |<==(5)==>| |
| | | | AuthN | RO |
| | | | | |
| | | |<==(6)==>| |
| | | | AuthZ +------+
| | | | | End |
| |<=(7)== Redirect for Continuation ===================+ User |
| | | | `----`
| +--(8)--- Continue Request ------->| |
| | | |
| |<-(9)----- Grant Access ----------+ |
| | | |
| | | | +--------+
| +--(10)-- Access API ---------------------------->| RS |
| | | | | |
| |<-(11)-- API Response ---------------------------| |
| | | | +--------+
+--------+ +--------+
Figure 4: Diagram of a Redirect-Based Interaction
図4：リダイレクトベースの相互作用の図
* (1) The client instance establishes a session with the user, in the role of the end user.
* （1）クライアントインスタンスは、エンドユーザーの役割でユーザーとのセッションを確立します。
* (2) The client instance requests access to the resource (Section 2). The client instance indicates that it can redirect to an arbitrary URI (Section 2.5.1.1) and receive a redirect from the browser (Section 2.5.2.1). The client instance stores verification information for its redirect in the session created in (1).
* （2）クライアントインスタンスは、リソースへのアクセスを要求します（セクション2）。クライアントインスタンスは、任意のURI（セクション2.5.1.1）にリダイレクトし、ブラウザからリダイレクトを受信できることを示しています（セクション2.5.2.1）。クライアントインスタンスは、（1）で作成されたセッションでのリダイレクトの検証情報を保存します。
* (3) The AS determines that interaction is needed and responds (Section 3) with a URI to send the user to (Section 3.3.1) and information needed to verify the redirect (Section 3.3.5) in (7). The AS also includes information the client instance will need to continue the request (Section 3.1) in (8). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), and (8).
* （3）ASは、相互作用が必要であり、URIに応答し（セクション3）、ユーザーを（セクション3.3.1）に送信するために応答（セクション3）と（7）のリダイレクト（セクション3.3.5）を検証するために必要な情報を決定します。ASには、クライアントインスタンスが（8）のリクエスト（セクション3.1）を継続する必要がある情報も含まれています。ASは、（4）、（6）、および（8）で参照される継続的なリクエストと関連付けられています。
* (4) The client instance stores the verification and continuation information from (3) in the session from (1). The client instance then redirects the user to the URI (Section 4.1.1) given by the AS in (3). The user's browser loads the interaction redirect URI. The AS loads the pending request based on the incoming URI generated in (3).
* （4）クライアントインスタンスは、（1）からのセッションで（3）から検証情報と継続情報を保存します。クライアントインスタンスは、AS（3）によって与えられたURI（セクション4.1.1）にユーザーをリダイレクトします。ユーザーのブラウザは、インタラクションリダイレクトURIをロードします。ASは、（3）で生成された着信URIに基づいて保留中の要求をロードします。
* (5) The user authenticates at the AS, taking on the role of the RO.
* （5）ユーザーはASで認証し、ROの役割を引き受けます。
* (6) As the RO, the user authorizes the pending request from the client instance.
* （6）ROとして、ユーザーはクライアントインスタンスからの保留中の要求を承認します。
* (7) When the AS is done interacting with the user, the AS redirects the user back (Section 4.2.1) to the client instance using the redirect URI provided in (2). The redirect URI is augmented with an interaction reference that the AS associates with the ongoing request created in (2) and referenced in (4). The redirect URI is also augmented with a hash of the security information provided in (2) and (3). The client instance loads the verification information from (2) and (3) from the session created in (1). The client instance calculates a hash (Section 4.2.3) based on this information and continues only if the hash validates. Note that the client instance needs to ensure that the parameters for the incoming request match those that it is expecting from the session created in (1). The client instance also needs to be prepared for the end user never being returned to the client instance and handle timeouts appropriately.
* （7）ユーザーと対話するASが行われた場合、ASは（2）で提供されるリダイレクトURIを使用して、ユーザーをクライアントインスタンスにリダイレクトします（セクション4.2.1）。リダイレクトURIは、ASが（2）で作成され、（4）で参照されている継続的な要求に関連する相互作用の参照で補強されています。リダイレクトURIは、（2）および（3）で提供されるセキュリティ情報のハッシュでも増強されます。クライアントインスタンスは、（1）で作成されたセッションから（2）および（3）から検証情報をロードします。クライアントインスタンスは、この情報に基づいてハッシュ（セクション4.2.3）を計算し、ハッシュが検証した場合にのみ継続します。クライアントインスタンスは、着信要求のパラメーターが（1）に作成されたセッションから期待されているものと一致することを確認する必要があることに注意してください。クライアントインスタンスは、クライアントインスタンスに返されず、タイムアウトを適切に処理することなく、エンドユーザーのために準備する必要があります。
* (8) The client instance loads the continuation information from (3) and sends the interaction reference from (7) in a request to continue the request (Section 5.1). The AS validates the interaction reference, ensuring that the reference is associated with the request being continued.
* （8）クライアントインスタンスは、（3）から継続情報をロードし、リクエストを継続する要求で（7）から相互作用の参照を送信します（セクション5.1）。ASは、相互作用の参照を検証し、参照がリクエストが継続されることに関連付けられていることを確認します。
* (9) If the request has been authorized, the AS grants access to the information in the form of access tokens (Section 3.2) and direct subject information (Section 3.4) to the client instance.
* （9）リクエストが承認されている場合、AS AS ASは、アクセストークン（セクション3.2）および直接主題情報（セクション3.4）の形式で情報へのアクセスをクライアントインスタンスに付与します。
* (10) The client instance uses the access token (Section 7.2) to call the RS.
* （10）クライアントインスタンスは、アクセストークン（セクション7.2）を使用してRsを呼び出します。
* (11) The RS validates the access token and returns an appropriate response for the API.
* （11）RSはアクセストークンを検証し、APIの適切な応答を返します。
An example set of protocol messages for this method can be found in Appendix B.1.
この方法のプロトコルメッセージの例は、付録B.1に記載されています。
In this example flow, the client instance is a device that is capable of presenting a short, human-readable code to the user and directing the user to enter that code at a known URI. The user enters the code at a URI that is an interactive service hosted by the AS in this example. The client instance is not capable of presenting an arbitrary URI to the user, nor is it capable of accepting incoming HTTP requests from the user's browser. The client instance polls the AS while it is waiting for the RO to authorize the request. The user's interaction is assumed to occur on a secondary device. In this example, it is assumed that the user is both the end user and RO. Note that since the user is not assumed to be interacting with the client instance through the same web browser used for interaction at the AS, the user is not shown as being connected to the client instance in this diagram.
この例では、クライアントインスタンスは、ユーザーに短い人間の読み取り可能なコードを提示し、ユーザーに既知のURIでそのコードを入力するように指示できるデバイスです。ユーザーは、この例のASがホストするインタラクティブサービスであるURIでコードを入力します。クライアントインスタンスは、ユーザーに任意のURIを提示することもできず、ユーザーのブラウザからの入っているHTTP要求を受け入れることもできません。クライアントインスタンスは、ROがリクエストを承認するのを待っている間にポーリングします。ユーザーの相互作用は、セカンダリデバイスで発生すると想定されています。この例では、ユーザーはエンドユーザーとROの両方であると想定されています。ユーザーは、ASでの対話に使用される同じWebブラウザを介してクライアントインスタンスと対話していると想定されていないため、ユーザーはこの図のクライアントインスタンスに接続されていると表示されないことに注意してください。
+--------+ +--------+ .----.
| Client | | AS | | End |
|Instance+--(1)--- Request Access --------->| | | User |
| | | | | |
| |<-(2)-- Interaction Needed -------+ | | |
| | | | | |
| +==(3)==== Display User Code ========================>| |
| | | | | |
| | | |<==(4)===+ |
| | | |Open URI | |
| | | | +------+
| | | |<==(5)==>| RO |
| | | | AuthN | |
| +--(9)--- Continue Request (A) --->| | | |
| | | |<==(6)==>| |
| |<-(10)-- Not Yet Granted (Wait) --+ | Code | |
| | | | | |
| | | |<==(7)==>| |
| | | | AuthZ | |
| | | | | |
| | | |<==(8)==>| |
| | | |Complete | |
| | | | +------+
| +--(11)-- Continue Request (B) --->| | | End |
| | | | | User |
| |<-(12)----- Grant Access ---------+ | `----`
| | | |
| | | | +--------+
| +--(13)-- Access API ---------------------------->| RS |
| | | | | |
| |<-(14)-- API Response ---------------------------+ |
| | | | +--------+
+--------+ +--------+
Figure 5: Diagram of a User-Code-Based Interaction
図5：ユーザーコードベースのインタラクションの図
* (1) The client instance requests access to the resource (Section 2). The client instance indicates that it can display a user code (Section 2.5.1.3).
* （1）クライアントインスタンスは、リソースへのアクセスを要求します（セクション2）。クライアントインスタンスは、ユーザーコードを表示できることを示しています（セクション2.5.1.3）。
* (2) The AS determines that interaction is needed and responds (Section 3) with a user code to communicate to the user (Section 3.3.3). The AS also includes information the client instance will need to continue the request (Section 3.1) in (8) and (10). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10).
* （2）ASは、インタラクションが必要であり、ユーザーと通信するユーザーコードで応答する（セクション3）を決定します（セクション3.3.3）。ASには、クライアントインスタンスが（8）および（10）のリクエスト（セクション3.1）を継続する必要がある情報も含まれています。ASは、（4）、（6）、（8）、および（10）で参照される継続的なリクエストと関連付けられています。
* (3) The client instance stores the continuation information from (2) for use in (8) and (10). The client instance then communicates the code to the user (Section 4.1.2) given by the AS in (2).
* （3）クライアントインスタンスは、（2）から（8）および（10）で使用するために継続情報を保存します。クライアントインスタンスは、（2）のASで与えられたユーザー（セクション4.1.2）にコードを通知します。
* (4) The user directs their browser to the user code URI. This URI is stable and can be communicated via the client software's documentation, the AS documentation, or the client software itself. Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a mechanism to launch the RO's browser at this URI.
* （4）ユーザーはブラウザをユーザーコードURIに向けます。このURIは安定しており、クライアントソフトウェアのドキュメント、ASドキュメント、またはクライアントソフトウェア自体を介して伝達できます。ROはセカンダリデバイスを介してASと相互作用すると想定されるため、クライアントインスタンスはこのURIでROのブラウザを起動するメカニズムを提供しません。
* (5) The end user authenticates at the AS, taking on the role of the RO.
* （5）エンドユーザーがASで認証し、ROの役割を引き受けます。
* (6) The RO enters the code communicated in (3) to the AS. The AS validates this code against a current request in process.
* （6）ROは、（3）で通信されたコードにASに入ります。ASは、プロセス中の現在の要求に対してこのコードを検証します。
* (7) As the RO, the user authorizes the pending request from the client instance.
* （7）ROとして、ユーザーはクライアントインスタンスからの保留中の要求を承認します。
* (8) When the AS is done interacting with the user, the AS indicates to the RO that the request has been completed.
* （8）ASがユーザーと相互作用した場合、ROにリクエストが完了したことを示します。
* (9) Meanwhile, the client instance loads the continuation information stored at (3) and continues the request (Section 5). The AS determines which ongoing access request is referenced here and checks its state.
* （9）一方、クライアントインスタンスは（3）に保存されている継続情報をロードし、要求を継続します（セクション5）。ASは、ここで参照されている継続的なアクセス要求を決定し、その状態をチェックします。
* (10) If the access request has not yet been authorized by the RO in (6), the AS responds to the client instance to continue the request (Section 3.1) at a future time through additional polled continuation requests. This response can include updated continuation information as well as information regarding how long the client instance should wait before calling again. The client instance replaces its stored continuation information from the previous response (2). Note that the AS may need to determine that the RO has not approved the request in a sufficient amount of time and return an appropriate error to the client instance.
* （10）アクセス要求がROのROによってまだ承認されていない場合、ASは、追加の世論調査継続要求を通じて将来の時間にリクエスト（セクション3.1）を継続するためにクライアントインスタンスに応答します。この応答には、更新された継続情報と、クライアントインスタンスが再び電話をかける前に待機する時間に関する情報を含めることができます。クライアントインスタンスは、以前の回答（2）から保存された継続情報を置き換えます。ASは、ROが十分な時間でリクエストを承認しておらず、クライアントインスタンスに適切なエラーを返すことを決定する必要がある場合があることに注意してください。
* (11) The client instance continues to poll the AS (Section 5.2) with the new continuation information in (9).
* （11）クライアントインスタンスは、（9）の新しい継続情報でAS（セクション5.2）を投票し続けています。
* (12) If the request has been authorized, the AS grants access to the information in the form of access tokens (Section 3.2) and direct subject information (Section 3.4) to the client instance.
* （12）リクエストが承認されている場合、AS AS ASは、アクセストークン（セクション3.2）および直接的な主題情報（セクション3.4）の形式で情報へのアクセスをクライアントインスタンスに付与します。
* (13) The client instance uses the access token (Section 7.2) to call the RS.
* （13）クライアントインスタンスは、アクセストークン（セクション7.2）を使用してRsを呼び出します。
* (14) The RS validates the access token and returns an appropriate response for the API.
* （14）RSはアクセストークンを検証し、APIの適切な応答を返します。
An example set of protocol messages for this method can be found in Appendix B.2.
この方法のプロトコルメッセージの例は、付録B.2に記載されています。
In this example flow, the end user and RO roles are fulfilled by different parties, and the RO does not interact with the client instance. The AS reaches out asynchronously to the RO during the request process to gather the RO's authorization for the client instance's request. The client instance polls the AS while it is waiting for the RO to authorize the request.
この例では、エンドユーザーとROの役割はさまざまな関係者によって満たされており、ROはクライアントインスタンスと対話しません。ASは、クライアントインスタンスの要求に対するROの承認を収集するために、要求プロセス中にROに非同期に到達します。クライアントインスタンスは、ROがリクエストを承認するのを待っている間にポーリングします。
+--------+ +--------+ .----.
| Client | | AS | | RO |
|Instance+--(1)--- Request Access --------->| | | |
| | | | | |
| |<-(2)-- Not Yet Granted (Wait) ---+ | | |
| | | |<==(3)==>| |
| | | | AuthN | |
| +--(6)--- Continue Request (A) --->| | | |
| | | |<==(4)==>| |
| |<-(7)-- Not Yet Granted (Wait) ---+ | AuthZ | |
| | | | | |
| | | |<==(5)==>| |
| | | |Completed| |
| | | | | |
| +--(8)--- Continue Request (B) --->| | `----`
| | | |
| |<-(9)------ Grant Access ---------+ |
| | | |
| | | | +--------+
| +--(10)-- Access API ---------------------------->| RS |
| | | | | |
| |<-(11)-- API Response ---------------------------+ |
| | | | +--------+
+--------+ +--------+
Figure 6: Diagram of an Asynchronous Authorization Process, with No End-User Interaction
図6：エンドユーザーの相互作用なしで非同期認証プロセスの図
* (1) The client instance requests access to the resource (Section 2). The client instance does not send any interaction modes to the server, indicating that it does not expect to interact with the RO. The client instance can also signal which RO it requires authorization from, if known, by using the subject request field (Section 2.2) and user request field (Section 2.4). It's also possible for the AS to determine which RO needs to be contacted by the nature of what access is being requested.
* （1）クライアントインスタンスは、リソースへのアクセスを要求します（セクション2）。クライアントインスタンスは、インタラクションモードをサーバーに送信せず、ROと対話することを期待していないことを示しています。クライアントインスタンスは、件名リクエストフィールド（セクション2.2）とユーザー要求フィールド（セクション2.4）を使用して、既知の場合（既知の場合）許可を必要とするROがどのROを必要とするかを示すこともできます。また、どのROが要求されているかの性質によって接触する必要があるROを決定することも可能です。
* (2) The AS determines that interaction is needed, but the client instance cannot interact with the RO. The AS responds (Section 3) with the information the client instance will need to continue the request (Section 3.1) in (6) and (8), including a signal that the client instance should wait before checking the status of the request again. The AS associates this continuation information with an ongoing request that will be referenced in (3), (4), (5), (6), and (8).
* （2）ASは、相互作用が必要であると判断しますが、クライアントインスタンスはROと相互作用できません。AS応答（セクション3）は、クライアントインスタンスがリクエスト（6）および（8）のリクエスト（セクション3.1）を継続する必要があります。ASは、この継続情報を、（3）、（4）、（5）、（6）、および（8）で参照する継続的な要求に関連付けられています。
* (3) The AS determines which RO to contact based on the request in (1), through a combination of the user request (Section 2.4), the subject request (Section 2.2), the access request (Section 2.1), and other policy information. The AS contacts the RO and authenticates them.
* （3）（1）の要求に基づいて、ユーザー要求（セクション2.4）、件名リクエスト（セクション2.2）、アクセス要求（セクション2.1）、およびその他のポリシーの組み合わせを通じて、どのROが連絡するかを決定します。情報。ASはROに接触し、それらを認証します。
* (4) The RO authorizes the pending request from the client instance.
* （4）ROは、クライアントインスタンスからの保留中の要求を承認します。
* (5) When the AS is done interacting with the RO, the AS indicates to the RO that the request has been completed.
* （5）ROと相互作用して行われたASが、リクエストが完了したことをROに示します。
* (6) Meanwhile, the client instance loads the continuation information stored at (2) and continues the request (Section 5). The AS determines which ongoing access request is referenced here and checks its state.
* （6）一方、クライアントインスタンスは（2）に保存されている継続情報をロードし、要求を継続します（セクション5）。ASは、ここで参照されている継続的なアクセス要求を決定し、その状態をチェックします。
* (7) If the access request has not yet been authorized by the RO in (6), the AS responds to the client instance to continue the request (Section 3.1) at a future time through additional polling. Note that this response is not an error message, since no error has yet occurred. This response can include refreshed credentials as well as information regarding how long the client instance should wait before calling again. The client instance replaces its stored continuation information from the previous response (2). Note that the AS may need to determine that the RO has not approved the request in a sufficient amount of time and return an appropriate error to the client instance.
* （7）アクセス要求がROのROによってまだ承認されていない場合、ASはクライアントインスタンスに応答して、追加のポーリングを通じて将来の時間にリクエスト（セクション3.1）を継続します。エラーがまだ発生していないため、この応答はエラーメッセージではないことに注意してください。この応答には、リフレッシュされた資格情報と、クライアントインスタンスが再び電話をかける前に待機する時間に関する情報を含めることができます。クライアントインスタンスは、以前の回答（2）から保存された継続情報を置き換えます。ASは、ROが十分な時間でリクエストを承認しておらず、クライアントインスタンスに適切なエラーを返すことを決定する必要がある場合があることに注意してください。
* (8) The client instance continues to poll the AS (Section 5.2) with the new continuation information from (7).
* （8）クライアントインスタンスは、（7）からの新しい継続情報でAS（セクション5.2）を投票し続けています。
* (9) If the request has been authorized, the AS grants access to the information in the form of access tokens (Section 3.2) and direct subject information (Section 3.4) to the client instance.
* （9）リクエストが承認されている場合、AS AS ASは、アクセストークン（セクション3.2）および直接主題情報（セクション3.4）の形式で情報へのアクセスをクライアントインスタンスに付与します。
* (10) The client instance uses the access token (Section 7.2) to call the RS.
* （10）クライアントインスタンスは、アクセストークン（セクション7.2）を使用してRsを呼び出します。
* (11) The RS validates the access token and returns an appropriate response for the API.
* （11）RSはアクセストークンを検証し、APIの適切な応答を返します。
An example set of protocol messages for this method can be found in Appendix B.4.
この方法のプロトコルメッセージの例は、付録B.4に記載されています。
Additional considerations for asynchronous interactions like this are discussed in Section 11.36.
このような非同期相互作用に関する追加の考慮事項については、セクション11.36で説明します。
In this example flow, the AS policy allows the client instance to make a call on its own behalf, without the need for an RO to be involved at runtime to approve the decision. Since there is no explicit RO, the client instance does not interact with an RO.
この例では、ASポリシーにより、クライアントインスタンスは、実行時にROが関与することなく、決定を承認する必要なく、独自に電話をかけることができます。明示的なROがないため、クライアントインスタンスはROと相互作用しません。
+--------+ +--------+
| Client | | AS |
|Instance+--(1)--- Request Access --->| |
| | | |
| |<-(2)---- Grant Access -----+ |
| | | | +--------+
| +--(3)--- Access API ------------------->| RS |
| | | | | |
| |<-(4)--- API Response ------------------+ |
| | | | +--------+
+--------+ +--------+
Figure 7: Diagram of a Software-Only Authorization, with No End User or Explicit Resource Owner
図7：エンドユーザーまたは明示的なリソース所有者がいないソフトウェアのみの認証の図
* (1) The client instance requests access to the resource (Section 2). The client instance does not send any interaction modes to the server.
* （1）クライアントインスタンスは、リソースへのアクセスを要求します（セクション2）。クライアントインスタンスは、インタラクションモードをサーバーに送信しません。
* (2) The AS determines that the request has been authorized based on the identity of the client instance making the request and the access requested (Section 2.1). The AS grants access to the resource in the form of access tokens (Section 3.2) to the client instance. Note that direct subject information (Section 3.4) is not generally applicable in this use case, as there is no user involved.
* （2）リクエストが要求され、アクセスが要求されたクライアントインスタンスのIDに基づいて、リクエストが承認されていることを決定します（セクション2.1）。ASは、クライアントインスタンスにアクセストークン（セクション3.2）の形でリソースにアクセスできます。ユーザーが関与していないため、このユースケースには一般的に適用されない直接的な主題情報（セクション3.4）は一般的に適用できないことに注意してください。
* (3) The client instance uses the access token (Section 7.2) to call the RS.
* （3）クライアントインスタンスは、アクセストークン（セクション7.2）を使用してRsを呼び出します。
* (4) The RS validates the access token and returns an appropriate response for the API.
* （4）RSはアクセストークンを検証し、APIの適切な応答を返します。
An example set of protocol messages for this method can be found in Appendix B.3.
この方法のプロトコルメッセージの例は、付録B.3に記載されています。
In this example flow, the client instance receives an access token to access an RS through some valid GNAP process. The client instance uses that token at the RS for some time, but eventually the access token expires. The client instance then gets a refreshed access token by rotating the expired access token's value at the AS using the token management API.
この例では、クライアントインスタンスがアクセストークンを受信して、有効なGNAPプロセスを介してRSにアクセスします。クライアントインスタンスは、しばらくの間RSでそのトークンを使用しますが、最終的にアクセストークンは期限切れになります。クライアントインスタンスは、Token Management APIを使用して、有効期限が切れたアクセストークンの値を回転させることにより、更新されたアクセストークンを取得します。
+--------+ +--------+
| Client | | AS |
|Instance+--(1)--- Request Access ----------------->| |
| | | |
| |<-(2)--- Grant Access --------------------+ |
| | | |
| | +--------+ | |
| +--(3)--- Access Resource --->| RS | | |
| | | | | |
| |<-(4)--- Success Response ---+ | | |
| | | | | |
| | ( Time Passes ) | | | |
| | | | | |
| +--(5)--- Access Resource --->| | | |
| | | | | |
| |<-(6)--- Error Response -----+ | | |
| | +--------+ | |
| | | |
| +--(7)--- Rotate Token ------------------->| |
| | | |
| |<-(8)--- Rotated Token -------------------+ |
| | | |
+--------+ +--------+
Figure 8: Diagram of the Process of Refreshing an Expired Access Token
図8：期限切れのアクセストークンを更新するプロセスの図
* (1) The client instance requests access to the resource (Section 2).
* （1）クライアントインスタンスは、リソースへのアクセスを要求します（セクション2）。
* (2) The AS grants access to the resource (Section 3) with an access token (Section 3.2) usable at the RS. The access token response includes a token management URI.
* （2）Rsで使用可能なアクセストークン（セクション3.2）を使用して、リソースへのアクセス（セクション3）を付与します。アクセストークンの応答には、トークン管理URIが含まれます。
* (3) The client instance uses the access token (Section 7.2) to call the RS.
* （3）クライアントインスタンスは、アクセストークン（セクション7.2）を使用してRsを呼び出します。
* (4) The RS validates the access token and returns an appropriate response for the API.
* （4）RSはアクセストークンを検証し、APIの適切な応答を返します。
* (5) Time passes and the client instance uses the access token to call the RS again.
* （5）時間が経過し、クライアントインスタンスはアクセストークンを使用してRsを再度呼び出します。
* (6) The RS validates the access token and determines that the access token is expired. The RS responds to the client instance with an error.
* （6）RSはアクセストークンを検証し、アクセストークンの有効期限が切れていると判断します。RSは、エラーでクライアントインスタンスに応答します。
* (7) The client instance calls the token management URI returned in (2) to rotate the access token (Section 6.1). The client instance uses the access token (Section 7.2) in this call as well as the appropriate key; see Section 6.1 for details.
* （7）クライアントインスタンスは、（2）で返されたトークン管理URIを呼び出してアクセストークンを回転させます（セクション6.1）。クライアントインスタンスは、この呼び出しのアクセストークン（セクション7.2）と適切なキーを使用します。詳細については、セクション6.1を参照してください。
* (8) The AS validates the rotation request, including the signature and keys presented in (7), and refreshes the access token (Section 3.2.1). The response includes a new version of the access token and can also include updated token management information, which the client instance will store in place of the values returned in (2).
* （8）（7）に表示される署名とキーを含む回転要求を検証し、アクセストークン（セクション3.2.1）を再表示します。応答には、アクセストークンの新しいバージョンが含まれており、更新されたトークン管理情報を含めることもできます。クライアントインスタンスは（2）で返される値の代わりに保存されます。
In this scenario, the client instance does not call an RS and does not request an access token. Instead, the client instance only requests and is returned direct subject information (Section 3.4). Many different interaction modes can be used in this scenario, so these are shown only in the abstract as functions of the AS here.
このシナリオでは、クライアントインスタンスはRSを呼び出さず、アクセストークンを要求しません。代わりに、クライアントインスタンスは要求のみを要求し、直接主題情報を返します（セクション3.4）。このシナリオでは、さまざまな相互作用モードを使用できるため、これらはここにあるASの関数としての抽象的にのみ表示されます。
+--------+ +--------+ .----.
| Client | | AS | | End |
|Instance| | | | User |
| +--(1)--- Request Access --------->| | | |
| | | | | |
| |<-(2)-- Interaction Needed -------+ | | |
| | | | | |
| +==(3)== Facilitate Interaction =====================>| |
| | | | +------+
| | | |<==(4)==>| RO |
| | | | AuthN | |
| | | | | |
| | | |<==(5)==>| |
| | | | AuthZ +------+
| | | | | End |
| |<=(6)== Signal Continuation =========================+ User |
| | | | `----`
| +--(7)--- Continue Request ------->| |
| | | |
| |<-(8)----- Grant Access ----------+ |
| | | |
+--------+ +--------+
Figure 9: Diagram of the Process of Requesting and Releasing Subject Information apart from Access Tokens
図9：アクセストークンとは別にサブジェクト情報をリクエストおよびリリースするプロセスの図
* (1) The client instance requests access to subject information (Section 2).
* （1）クライアントインスタンスは、主題情報へのアクセスを要求します（セクション2）。
* (2) The AS determines that interaction is needed and responds (Section 3) with appropriate information for facilitating user interaction (Section 3.3).
* （2）ASは、相互作用が必要であると判断し、ユーザーの相互作用を促進するための適切な情報を使用して応答します（セクション3）（セクション3.3）。
* (3) The client instance facilitates the user interacting with the AS (Section 4) as directed in (2).
* （3）クライアントインスタンスは、（2）に向けられているように、AS（セクション4）と対話するユーザーを容易にします。
* (4) The user authenticates at the AS, taking on the role of the RO.
* （4）ユーザーはASで認証し、ROの役割を引き受けます。
* (5) As the RO, the user authorizes the pending request from the client instance.
* （5）ROとして、ユーザーはクライアントインスタンスからの保留中の要求を承認します。
* (6) When the AS is done interacting with the user, the AS returns the user to the client instance and signals continuation.
* （6）ASがユーザーと対話する場合、ASはユーザーをクライアントインスタンスに返し、継続を信号します。
* (7) The client instance loads the continuation information from (2) and calls the AS to continue the request (Section 5).
* （7）クライアントインスタンスは（2）から継続情報をロードし、要求を続行するように呼び出します（セクション5）。
* (8) If the request has been authorized, the AS grants access to the requested direct subject information (Section 3.4) to the client instance. At this stage, the user is generally considered "logged in" to the client instance based on the identifiers and assertions provided by the AS. Note that the AS can restrict the subject information returned, and it might not match what the client instance requested; see Section 3.4 for details.
* （8）要求が承認されている場合、AS AS AS ASは、要求された直接主題情報（セクション3.4）へのアクセスをクライアントインスタンスに付与します。この段階では、ユーザーは通常、ASが提供する識別子とアサーションに基づいてクライアントインスタンスに「ログイン」されていると見なされます。ASは返されたサブジェクト情報を制限でき、クライアントインスタンスが要求したものと一致しない可能性があることに注意してください。詳細については、セクション3.4を参照してください。
In this scenario, the end user and RO are two different people. Here, the client instance already knows who the end user is, likely through a separate authentication process. The end user, operating the client instance, needs to get subject information about another person in the system, the RO. The RO is given an opportunity to release this information using an asynchronous interaction method with the AS. This scenario would apply, for instance, when the end user is an agent in a call center and the RO is a customer authorizing the call-center agent to access their account on their behalf.
このシナリオでは、エンドユーザーとROは2人の異なる人です。ここでは、クライアントインスタンスは、おそらく個別の認証プロセスを通じて、エンドユーザーが誰であるかをすでに知っています。クライアントインスタンスを操作するエンドユーザーは、システム内の他の人に関する主題情報、ROを取得する必要があります。ROには、ASとの非同期相互作用方法を使用してこの情報をリリースする機会が与えられます。たとえば、このシナリオは、エンドユーザーがコールセンターのエージェントであり、ROがコールセンターエージェントがアカウントに代わってアカウントにアクセスすることを許可する顧客である場合に適用されます。
.----. .----.
| End | | RO |
| User |<=================(1)== Identify RO ==================>| |
| | | |
| | +--------+ +--------+ | |
| +==(2)==>| Client | | AS | | |
| | RO ID |Instance| | | | |
| | | | | | | |
| | | +--(3)-- Req. ---->| | | |
| | | | | | | |
| | | |<-(4)-- Res. -----+ | | |
| | | | | |<==(5)==>| |
| | | | | | AuthN | |
| | | | | | | |
| | | | | |<==(6)==>| |
| | | | | | AuthZ | |
| | | | | | | |
| | | | | |<==(7)==>| |
| | | |<-(8)--- Finish --+ |Completed| |
| | | | | | | |
| | | +--(9)--- Cont. -->| | | |
| | | | | | | |
| | | |<-(10)-- Subj. ---+ | | |
| |<=(11)==+ | Info | | | |
| | Return | | | | | |
| | RO | | | | | |
| | Info | | | | | |
`----` +--------+ +--------+ `----`
Figure 10: Diagram of Cross-User Authorization, Where the End User and RO Are Different
図10：エンドユーザーとROが異なるクロスユーザー認証の図
Precondition: The end user is authenticated to the client instance, and the client instance has an identifier representing the end user that it can present to the AS. This identifier should be unique to the particular session with the client instance and the AS. The client instance is also known to the AS and allowed to access this advanced functionality where the information of someone other than the end user is returned to the client instance.
前提条件：エンドユーザーはクライアントインスタンスに認証され、クライアントインスタンスには、ASに提示できるエンドユーザーを表す識別子があります。この識別子は、クライアントインスタンスとASとの特定のセッションに固有のものでなければなりません。クライアントインスタンスはASにも知られており、エンドユーザー以外の誰かの情報がクライアントインスタンスに返されるこの高度な機能にアクセスすることができます。
* (1) The RO communicates a human-readable identifier to the end user, such as an email address or account number. This communication happens out of band from the protocol, such as over the phone between parties. Note that the RO is not interacting with the client instance.
* （1）ROは、電子メールアドレスやアカウント番号など、人間の読み取り可能な識別子をエンドユーザーに伝えます。このコミュニケーションは、当事者間の電話など、プロトコルからバンドから発生します。ROがクライアントインスタンスと相互作用していないことに注意してください。
* (2) The end user communicates the identifier to the client instance. The means by which the identifier is communicated to the client instance are out of scope for this specification.
* （2）エンドユーザーは、識別子をクライアントインスタンスに伝えます。識別子がクライアントインスタンスに通信する手段は、この仕様の範囲外です。
* (3) The client instance requests access to subject information (Section 2). The request includes the RO's identifier in the sub_ids field of the subject information request (Section 2.2) and the end user's identifier in the user field (Section 2.4). The request includes no interaction start methods, since the end user is not expected to be the one interacting with the AS. The request does include the push-based interaction finish method (Section 2.5.2.2) to allow the AS to signal to the client instance when the interaction with the RO has concluded.
* （3）クライアントインスタンスは、主題情報へのアクセスを要求します（セクション2）。リクエストには、サブジェクト情報リクエストのsub_idsフィールド（セクション2.2）とユーザーフィールドのエンドユーザーの識別子（セクション2.4）のROの識別子が含まれます。リクエストには、エンドユーザーがASと対話するものであるとは予想されないため、インタラクション開始方法は含まれていません。リクエストには、ROとの相互作用が終了したときにASがクライアントインスタンスに信号を送信できるようにするためのプッシュベースのインタラクション仕上げ方法（セクション2.5.2.2）が含まれています。
* (4) The AS sees that the identifiers for the end user and subject being requested are different. The AS determines that it can reach out to the RO asynchronously for approval. While it is doing so, the AS returns a continuation response (Section 3.1) with a finish nonce to allow the client instance to continue the grant request after interaction with the RO has concluded.
* （4）ASは、要求されるエンドユーザーと被験者の識別子が異なることを確認します。ASは、承認のために非同期にROに手を差し伸べることができると判断します。そうしている間、ASは、ROとのやり取りの後にクライアントインスタンスが助成金要求を継続できるようにするために、継続応答（セクション3.1）をフィニッシュノンセで返します。
* (5) The AS contacts the RO and has them authenticate to the system. The means for doing this are outside the scope of this specification, but the identity of the RO is known from the Subject Identifier sent in (3).
* （5）ASはROに接触し、システムに認証されています。これを行うための手段はこの仕様の範囲外ですが、ROの同一性は（3）に送信された被験者識別子から知られています。
* (6) The RO is prompted to authorize the end user's request via the client instance. Since the end user was identified in (3) via the user field, the AS can show this information to the RO during the authorization request.
* （6）ROは、クライアントインスタンスを介してエンドユーザーの要求を承認するように求められます。エンドユーザーはユーザーフィールドを介して（3）で特定されたため、ASは承認リクエスト中にこの情報をROに表示できます。
* (7) The RO completes the authorization with the AS. The AS marks the request as _approved_.
* （7）ROはASで承認を完了します。ASは、_Approved_としてリクエストをマークします。
* (8) The RO pushes the interaction finish message (Section 4.2.2) to the client instance. Note that in the case the RO cannot be reached or the RO denies the request, the AS still sends the interaction finish message to the client instance, after which the client instance can negotiate next steps if possible.
* （8）ROは、インタラクション仕上げメッセージ（セクション4.2.2）をクライアントインスタンスにプッシュします。ROに到達できない場合、またはROがリクエストを拒否している場合、ASはまだクライアントインスタンスにインタラクション仕上げメッセージを送信し、その後、クライアントインスタンスが可能であれば次のステップをネゴシエートすることができます。
* (9) The client instance validates the interaction finish message and continues the grant request (Section 5.1).
* （9）クライアントインスタンスは、インタラクション仕上げメッセージを検証し、助成金リクエストを継続します（セクション5.1）。
* (10) The AS returns the RO's subject information (Section 3.4) to the client instance.
* （10）ASは、ROのサブジェクト情報（セクション3.4）をクライアントインスタンスに返します。
* (11) The client instance can display or otherwise utilize the RO's user information in its session with the end user. Note that since the client instance requested different sets of user information in (3), the client instance does not conflate the end user with the RO.
* （11）クライアントインスタンスは、エンドユーザーとのセッションでROのユーザー情報を表示または使用できます。クライアントインスタンスは（3）でさまざまなユーザー情報のセットを要求しているため、クライアントインスタンスはエンドユーザーとROと融合していないことに注意してください。
Additional considerations for asynchronous interactions like this are discussed in Section 11.36.
このような非同期相互作用に関する追加の考慮事項については、セクション11.36で説明します。
To start a request, the client instance sends an HTTP POST with a JSON [RFC8259] document to the grant endpoint of the AS. The grant endpoint is a URI that uniquely identifies the AS to client instances and serves as the identifier for the AS. The document is a JSON object where each field represents a different aspect of the client instance's request. Each field is described in detail in a subsection below.
リクエストを開始するために、クライアントインスタンスはJSON [RFC8259]ドキュメントを含むHTTP投稿をASの助成金エンドポイントに送信します。助成金のエンドポイントは、クライアントインスタンスに関して一意に識別し、ASの識別子として機能するURIです。このドキュメントは、各フィールドがクライアントインスタンスの要求の異なる側面を表すJSONオブジェクトです。各フィールドについては、以下のサブセクションで詳しく説明しています。
access_token (object / array of objects):
Access_Token（オブジェクトのオブジェクト /配列）：
Describes the rights and properties associated with the requested access token. REQUIRED if requesting an access token. See Section 2.1.
要求されたアクセストークンに関連する権利と財産について説明します。アクセストークンを要求する場合は必要です。セクション2.1を参照してください。
subject (object):
件名（オブジェクト）：
Describes the information about the RO that the client instance is requesting to be returned directly in the response from the AS. REQUIRED if requesting subject information. See Section 2.2.
クライアントインスタンスがASからの応答で直接返されることを要求しているROに関する情報について説明します。サブジェクト情報を要求する場合に必要です。セクション2.2を参照してください。
client (object / string):
クライアント（オブジェクト /文字列）：
Describes the client instance that is making this request, including the key that the client instance will use to protect this request, any continuation requests at the AS, and any user-facing information about the client instance used in interactions. REQUIRED. See Section 2.3.
クライアントインスタンスがこのリクエストを保護するために使用するキー、ASでの継続要求、およびインタラクションで使用されるクライアントインスタンスに関するユーザー向け情報を含む、このリクエストを行っているクライアントインスタンスについて説明します。必須。セクション2.3を参照してください。
user (object / string):
ユーザー（オブジェクト /文字列）：
Identifies the end user to the AS in a manner that the AS can verify, either directly or by interacting with the end user to determine their status as the RO. OPTIONAL. See Section 2.4.
直接またはエンドユーザーと対話してROとしてのステータスを決定することにより、ASが検証できる方法でエンドユーザーを識別します。オプション。セクション2.4を参照してください。
interact (object):
対話（オブジェクト）：
Describes the modes that the client instance supports for allowing the RO to interact with the AS and modes for the client instance to receive updates when interaction is complete. REQUIRED if interaction is supported. See Section 2.5.
クライアントインスタンスがサポートするモードについて説明します。Clientインスタンスは、ClientインスタンスのASとモードと相互作用して、インタラクションが完了したときに更新を受信します。相互作用がサポートされている場合は必要です。セクション2.5を参照してください。
Additional members of this request object can be defined by extensions using the "GNAP Grant Request Parameters" registry (Section 10.3).
このリクエストオブジェクトの追加メンバーは、「GNAP助成金要求パラメーター」レジストリ（セクション10.3）を使用して拡張機能によって定義できます。
A non-normative example of a grant request is below:
助成金リクエストの非規範的な例は以下にあります。
{
"access_token": {
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"dolphin-metadata"
]
},
"client": {
"display": {
"name": "My Client Display Name",
"uri": "https://example.net/client"
},
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-1",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeL...."
}
}
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
},
"subject": {
"sub_id_formats": ["iss_sub", "opaque"],
"assertion_formats": ["id_token"]
}
}
Sending a request to the grant endpoint creates a grant request in the _processing_ state. The AS processes this request to determine whether interaction or authorization are necessary (moving to the _pending_ state) or if access can be granted immediately (moving to the _approved_ state).
グラントエンドポイントにリクエストを送信すると、_Processing_状態に付与リクエストが作成されます。ASこの要求は、相互作用または承認が必要か（_Pending_ Stateに移動する）か、すぐにアクセスを許可できるか（_Approved_ Stateに移動できるかどうかを判断するためにこの要求を処理します。
The request MUST be sent as a JSON object in the content of the HTTP POST request with Content-Type application/json. A key proofing mechanism MAY define an alternative content type, as long as the content is formed from the JSON object. For example, the attached JSON Web Signature (JWS) key proofing mechanism (see Section 7.3.4) places the JSON object into the payload of a JWS wrapper, which is in turn sent as the message content.
リクエストは、Content-Type Application/JSONを使用したHTTP POSTリクエストのコンテンツ内のJSONオブジェクトとして送信する必要があります。重要な校正メカニズムは、JSONオブジェクトからコンテンツが形成されている限り、代替コンテンツタイプを定義する場合があります。たとえば、添付されたJSON Web署名（JWS）キープルーフメカニズム（セクション7.3.4を参照）は、JSONオブジェクトをJWSラッパーのペイロードに入れ、メッセージコンテンツとして送信されます。
If the client instance is requesting one or more access tokens for the purpose of accessing an API, the client instance MUST include an access_token field. This field MUST be an object (for a single access token (Section 2.1.1)) or an array of these objects (for multiple access tokens (Section 2.1.2)), as described in the following subsections.
クライアントインスタンスがAPIにアクセスする目的で1つ以上のアクセストークンを要求している場合、クライアントインスタンスにはAccess_Tokenフィールドを含める必要があります。このフィールドは、以下のサブセクションで説明されているように、これらのオブジェクトの配列（単一のアクセストークン（セクション2.1.1）の場合）またはこれらのオブジェクトの配列（複数のアクセストークン（セクション2.1.2））である必要があります。
To request a single access token, the client instance sends an access_token object composed of the following fields.
単一のアクセストークンをリクエストするために、クライアントインスタンスは次のフィールドで構成されるアクセス_tokenオブジェクトを送信します。
access (array of objects/strings):
アクセス（オブジェクト/文字列の配列）：
Describes the rights that the client instance is requesting for the access token to be used at the RS. REQUIRED. See Section 8.
クライアントインスタンスがRSで使用するようにアクセストークンを要求している権利について説明します。必須。セクション8を参照してください。
label (string):
ラベル（文字列）：
A unique name chosen by the client instance to refer to the resulting access token. The value of this field is opaque to the AS and is not intended to be exposed to or used by the end user. If this field is included in the request, the AS MUST include the same label in the token response (Section 3.2). REQUIRED if used as part of a request for multiple access tokens (Section 2.1.2); OPTIONAL otherwise.
結果のアクセストークンを参照するために、クライアントインスタンスによって選択された一意の名前。このフィールドの値は、ASに不透明であり、エンドユーザーにさらされたり使用されたりすることを意図していません。このフィールドがリクエストに含まれている場合、ASはトークン応答に同じラベルを含める必要があります（セクション3.2）。複数のアクセストークンのリクエストの一部として使用される場合（セクション2.1.2）。それ以外の場合はオプション。
flags (array of strings):
フラグ（文字列の配列）：
A set of flags that indicate desired attributes or behavior to be attached to the access token by the AS. OPTIONAL.
ASによってアクセストークンに添付される希望の属性または動作を示す一連のフラグ。オプション。
The values of the flags field defined by this specification are as follows:
この仕様で定義されたフラグフィールドの値は次のとおりです。
"bearer":
「ベアラー」：
If this flag is included, the access token being requested is a bearer token. If this flag is omitted, the access token is bound to the key used by the client instance in this request (or that key's most recent rotation), and the access token MUST be presented using the same key and proofing method. Methods for presenting bound and bearer access tokens are described in Section 7.2. See Section 11.9 for additional considerations on the use of bearer tokens.
このフラグが含まれている場合、要求されるアクセストークンはベアラートークンです。このフラグが省略されている場合、アクセストークンは、このリクエスト（またはそのキーの最新の回転）でクライアントインスタンスで使用されるキーにバインドされ、アクセストークンは同じキーと校正方法を使用して提示する必要があります。バインドおよびベアラーアクセストークンを提示する方法については、セクション7.2で説明します。Bearer Tokensの使用に関する追加の考慮事項については、セクション11.9を参照してください。
Flag values MUST NOT be included more than once. If the request includes a flag value multiple times, the AS MUST return an invalid_flag error defined in Section 3.6.
フラグの値を複数回含めてはなりません。リクエストにフラグ値が複数回含まれている場合、ASはセクション3.6で定義された無効なエラーを返す必要があります。
Additional flags can be defined by extensions using the "GNAP Access Token Flags" registry (Section 10.4).
追加のフラグは、「GNAPアクセストークンフラグ」レジストリ（セクション10.4）を使用して拡張機能によって定義できます。
In the following non-normative example, the client instance is requesting access to a complex resource described by a pair of access request object.
次の非規範的な例では、クライアントインスタンスは、アクセス要求オブジェクトのペアによって記述された複雑なリソースへのアクセスを要求しています。
"access_token": {
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"delete"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
{
"type": "walrus-access",
"actions": [
"foo",
"bar"
],
"locations": [
"https://resource.other/"
],
"datatypes": [
"data",
"pictures",
"walrus whiskers"
]
}
],
"label": "token1-23"
}
If access is approved, the resulting access token is valid for the described resource. Since the bearer flag is not provided in this example, the token is bound to the client instance's key (or its most recent rotation). The token is labeled "token1-23". The token response structure is described in Section 3.2.1.
アクセスが承認されている場合、結果のアクセストークンは説明されているリソースに対して有効です。この例では、Bearerフラグは提供されていないため、トークンはクライアントインスタンスのキー（または最新の回転）にバインドされています。トークンには「token1-23」というラベルが付けられています。トークン応答構造については、セクション3.2.1で説明しています。
To request that multiple access tokens be returned in a single response, the client instance sends an array of objects as the value of the access_token parameter. Each object MUST conform to the request format for a single access token request, as specified in Section 2.1.1. Additionally, each object in the array MUST include the label field, and all values of these fields MUST be unique within the request. If the client instance does not include a label value for any entry in the array or the values of the label field are not unique within the array, the AS MUST return an "invalid_request" error (Section 3.6).
複数のアクセストークンを単一の応答で返すように要求するために、クライアントインスタンスはAccess_Tokenパラメーターの値としてオブジェクトの配列を送信します。セクション2.1.1で指定されているように、各オブジェクトは、単一のアクセストークン要求の要求形式に準拠する必要があります。さらに、配列内の各オブジェクトにはラベルフィールドを含める必要があり、これらのフィールドのすべての値はリクエスト内で一意でなければなりません。クライアントインスタンスに配列内のエントリのラベル値が含まれていない場合、またはラベルフィールドの値が配列内で一意ではない場合、ASは「invalid_request」エラー（セクション3.6）を返す必要があります。
The following non-normative example shows a request for two separate access tokens: token1 and token2.
次の非規範的な例は、2つの個別のアクセストークンのリクエストを示しています：token1とtoken2。
"access_token": [
{
"label": "token1",
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"dolphin-metadata"
]
},
{
"label": "token2",
"access": [
{
"type": "walrus-access",
"actions": [
"foo",
"bar"
],
"locations": [
"https://resource.other/"
],
"datatypes": [
"data",
"pictures",
"walrus whiskers"
]
}
],
"flags": [ "bearer" ]
}
]
All approved access requests are returned in the response structure for multiple access tokens (Section 3.2.2) using the values of the label fields in the request.
承認されたすべてのアクセス要求は、リクエスト内のラベルフィールドの値を使用して、複数のアクセストークン（セクション3.2.2）の応答構造で返されます。
If the client instance is requesting information about the RO from the AS, it sends a subject field as a JSON object. This object MAY contain the following fields.
クライアントインスタンスがASからROに関する情報を要求している場合、JSONオブジェクトとしてサブジェクトフィールドを送信します。このオブジェクトには、次のフィールドが含まれる場合があります。
sub_id_formats (array of strings):
sub_id_formats（文字列の配列）：
An array of Subject Identifier subject formats requested for the RO, as defined by [RFC9493]. REQUIRED if Subject Identifiers are requested.
[RFC9493]で定義されているように、ROに対して要求された被験者識別子の主題形式の配列。被験者の識別子が要求された場合に必要です。
assertion_formats (array of strings):
assertion_formats（文字列の配列）：
An array of requested assertion formats. Possible values include id_token for an OpenID Connect ID Token [OIDC] and saml2 for a Security Assertion Markup Language (SAML) 2 assertion [SAML2]. Additional assertion formats can be defined in the "GNAP Assertion Formats" registry (Section 10.6). REQUIRED if assertions are requested.
要求されたアサーション形式の配列。考えられる値には、OpenID Connect IDトークン[OIDC]のID_TOKENおよびセキュリティアサーションマークアップ言語（SAML）2アサーション[SAML2]のSAML2が含まれます。追加のアサーション形式は、「GNAPアサーション形式」レジストリ（セクション10.6）で定義できます。アサーションが要求された場合に必要です。
sub_ids (array of objects):
sub_ids（オブジェクトの配列）：
An array of Subject Identifiers representing the subject for which information is being requested. Each object is a Subject Identifier as defined by [RFC9493]. All identifiers in the sub_ids array MUST identify the same subject. If omitted, the AS SHOULD assume that subject information requests are about the current user and SHOULD require direct interaction or proof of presence before releasing information. OPTIONAL.
情報が要求されている主題を表す主題識別子の配列。各オブジェクトは、[RFC9493]で定義されているサブジェクト識別子です。sub_ids配列のすべての識別子は、同じ主題を識別する必要があります。省略した場合、ASは、サブジェクト情報の要求が現在のユーザーに関するものであり、情報をリリースする前に直接的な相互作用または存在の証明を必要とする必要があると仮定する必要があります。オプション。
Additional fields can be defined in the "GNAP Subject Information Request Fields" registry (Section 10.5).
追加のフィールドは、「GNAPサブジェクト情報リクエストフィールド」レジストリ（セクション10.5）で定義できます。
"subject": {
"sub_id_formats": [ "iss_sub", "opaque" ],
"assertion_formats": [ "id_token", "saml2" ]
}
The AS can determine the RO's identity and permission for releasing this information through interaction with the RO (Section 4), AS policies, or assertions presented by the client instance (Section 2.4). If this is determined positively, the AS MAY return the RO's information in its response (Section 3.4) as requested.
ASは、クライアントインスタンス（セクション2.4）によって提示されたポリシー、またはアサーションとして、RO（セクション4）との相互作用を通じて、ROのアイデンティティとこの情報を公開する許可を決定できます。これが肯定的に決定された場合、ASは、要求されているようにROの情報をその応答（セクション3.4）に返すことがあります。
Subject Identifier types requested by the client instance serve only to identify the RO in the context of the AS and can't be used as communication channels by the client instance, as discussed in Section 3.4.
セクション3.4で説明したように、クライアントインスタンスが要求したサブジェクト識別子タイプは、ASのコンテキストでのみROを識別するのにのみROを識別し、クライアントインスタンスによって通信チャネルとして使用することはできません。
When sending a new grant request to the AS, the client instance MUST identify itself by including its client information in the client field of the request and by signing the request with its unique key as described in Section 7.3. Note that once a grant has been created and is in either the _pending_ or the _approved_ state, the AS can determine which client is associated with the grant by dereferencing the continuation access token sent in the continuation request (Section 5). As a consequence, the client field is not sent or accepted for continuation requests.
ASに新しい助成金リクエストを送信する場合、クライアントインスタンスは、クライアント情報をリクエストのクライアントフィールドに含めることと、セクション7.3で説明されている一意のキーとリクエストに署名することにより、自分自身を識別する必要があります。助成金が作成され、_Pending_または_Approved_状態のいずれかにあると、ASは、継続要求で送信された継続アクセストークンを拒否することにより、どのクライアントが助成金に関連付けられているかを決定できることに注意してください（セクション5）。結果として、クライアントフィールドは継続リクエストのために送信または受け入れられません。
Client information is sent by value as an object or by reference as a string (see Section 2.3.1).
クライアント情報は、値によってオブジェクトとして、または参照によって文字列として送信されます（セクション2.3.1を参照）。
When client instance information is sent by value, the client field of the request consists of a JSON object with the following fields.
クライアントインスタンス情報がValueで送信されると、リクエストのクライアントフィールドは、次のフィールドを持つJSONオブジェクトで構成されます。
key (object / string):
key（object / string）：
The public key of the client instance to be used in this request as described in Section 7.1 or a reference to a key as described in Section 7.1.1. REQUIRED.
セクション7.1で説明されているように、この要求で使用されるクライアントインスタンスの公開鍵、またはセクション7.1.1で説明されているキーへの参照。必須。
class_id (string):
class_id（string）：
An identifier string that the AS can use to identify the client software comprising this client instance. The contents and format of this field are up to the AS. OPTIONAL.
このクライアントインスタンスで構成されるクライアントソフトウェアを識別するために使用できる識別子文字列。このフィールドの内容と形式はAS次第です。オプション。
display (object):
表示（オブジェクト）：
An object containing additional information that the AS MAY display to the RO during interaction, authorization, and management. OPTIONAL. See Section 2.3.2.
インタラクション、承認、および管理中にROに表示される可能性のある追加情報を含むオブジェクト。オプション。セクション2.3.2を参照してください。
"client": {
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-1",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8..."
}
},
"class_id": "web-server-1234",
"display": {
"name": "My Client Display Name",
"uri": "https://example.net/client"
}
}
Additional fields can be defined in the "GNAP Client Instance Fields" registry (Section 10.7).
追加のフィールドは、「GNAPクライアントインスタンスフィールド」レジストリ（セクション10.7）で定義できます。
Absent additional attestations, profiles, or trust mechanisms, both the display and class_id fields are self-declarative, presented by the client instance. The AS needs to exercise caution in their interpretation, taking them as a hint but not as absolute truth. The class_id field can be used in a variety of ways to help the AS make sense of the particular context in which the client instance is operating. In corporate environments, for example, different levels of trust might apply depending on security policies. This field aims to help the AS adjust its own access decisions for different classes of client software. It is possible to configure a set of values and rules during a pre-registration and then have the client instances provide them later in runtime as a hint to the AS. In other cases, the client runs with a specific AS in mind, so a single hardcoded value would be acceptable (for instance, a set-top box with a class_id claiming to be "FooBarTV version 4"). While the client instance may not have contacted the AS yet, the value of this class_id field can be evaluated by the AS according to a broader context of dynamic use, alongside other related information available elsewhere (for instance, corresponding fields in a certificate). If the AS is not able to interpret or validate the class_id field, it MUST either return an invalid_client error (Section 3.6) or interpret the request as if the class_id were not present. See additional discussion of client instance impersonation in Section 11.15.
追加の証明、プロファイル、または信頼メカニズムがない場合、ディスプレイとclass_idフィールドの両方が自己宣言的であり、クライアントインスタンスによって提示されます。彼らの解釈に注意を払う必要があり、それらをヒントとしてとって、絶対的な真実としてではありません。class_idフィールドは、クライアントインスタンスが動作している特定のコンテキストを理解するのに役立つさまざまな方法で使用できます。たとえば、企業環境では、セキュリティポリシーに応じて、さまざまなレベルの信頼が適用される場合があります。このフィールドは、さまざまなクラスのクライアントソフトウェアのAS独自のアクセス決定を調整するのを支援することを目的としています。事前登録中に一連の値とルールを構成し、クライアントインスタンスにASのヒントとしてランタイムの後半にそれらを提供させることができます。それ以外の場合、クライアントは特定のように念頭にあるように動作するため、単一のハードコードされた値を受け入れます（たとえば、「FOOBARTVバージョン4」と主張するClass_IDを備えたセットトップボックス）。クライアントインスタンスはまだASに連絡していない可能性がありますが、このclass_idフィールドの値は、他の場所で利用可能な他の関連情報（たとえば、証明書の対応するフィールド）とともに、動的使用のより広いコンテキストに従ってASによって評価できます。ASがclass_idフィールドを解釈または検証できない場合、無効なエラー（セクション3.6）を返すか、class_idが存在しないかのようにリクエストを解釈する必要があります。セクション11.15のクライアントインスタンスのなりすましの追加の議論を参照してください。
The client instance MUST prove possession of any presented key by the proofing mechanism associated with the key in the request. Key proofing methods are defined in the "GNAP Key Proofing Methods" registry (Section 10.16), and an initial set of methods is described in Section 7.3.
クライアントインスタンスは、リクエストのキーに関連するプルーフメカニズムによって提示されたキーの所有を証明する必要があります。キープルーフ方法は、「GNAPキープルーフメソッド」レジストリ（セクション10.16）で定義されており、セクション7.3で説明されています。
If the same public key is sent by value on different access requests, the AS MUST treat these requests as coming from the same client instance for purposes of identification, authentication, and policy application.
同じ公開キーが異なるアクセス要求で値によって送信される場合、ASは、識別、認証、およびポリシーアプリケーションの目的で、同じクライアントインスタンスから来るものとしてこれらの要求を扱う必要があります。
If the AS does not know the client instance's public key ahead of time, the AS can choose how to process the unknown key. Common approaches include:
ASが事前にクライアントインスタンスの公開キーを知らない場合、ASは不明キーを処理する方法を選択できます。一般的なアプローチには次のものがあります。
* Allowing the request and requiring RO authorization in a trust-on-first-use model
* リクエストを許可し、ファーストオンファーストモデルでのRO許可を要求する
* Limiting the client's requested access to only certain APIs and information
* 特定のAPIと情報のみへのクライアントの要求されたアクセスを制限する
* Denying the request entirely by returning an invalid_client error (Section 3.6)
* Invalid_Clientエラーを返すことにより、要求を完全に拒否します（セクション3.6）
The client instance MUST NOT send a symmetric key by value in the key field of the request, as doing so would expose the key directly instead of simply proving possession of it. See considerations on symmetric keys in Section 11.7. To use symmetric keys, the client instance can send the key by reference (Section 7.1.1) or send the entire client identity by reference (Section 2.3.1).
クライアントインスタンスは、リクエストのキーフィールドに値ごとに対称キーを送信してはなりません。そうすることで、単に所有権を証明するのではなく、キーを直接公開するためです。セクション11.7の対称キーに関する考慮事項を参照してください。対称キーを使用するには、クライアントインスタンスは参照（セクション7.1.1）でキーを送信したり、参照によってクライアントのアイデンティティ全体を送信したり（セクション2.3.1）。
The client instance's key can be pre-registered with the AS ahead of time and associated with a set of policies and allowable actions pertaining to that client. If this pre-registration includes other fields that can occur in the client request object described in this section, such as class_id or display, the pre-registered values MUST take precedence over any values given at runtime. Additional fields sent during a request but not present in a pre-registered client instance record at the AS SHOULD NOT be added to the client's pre-registered record. See additional considerations regarding client instance impersonation in Section 11.15.
クライアントインスタンスのキーは、事前に事前に登録され、そのクライアントに関連する一連のポリシーと許容アクションに関連付けられます。この事前登録が、このセクションで説明されているクライアントリクエストオブジェクトで発生する可能性のある他のフィールドがClass_IDやDisplayなどに含まれている場合、事前に登録された値は、実行時に与えられた値よりも優先される必要があります。リクエスト中に送信される追加のフィールドは、ASで事前に登録されたクライアントインスタンスレコードに存在していません。クライアントの事前登録レコードに追加されるべきではありません。セクション11.15のクライアントインスタンスのなりすましに関する追加の考慮事項を参照してください。
A client instance that is capable of talking to multiple ASes SHOULD use a different key for each AS to prevent a class of mix-up attacks as described in Section 11.31, unless other mechanisms can be used to assure the identity of the AS for a given request.
複数のASEと話すことができるクライアントインスタンスは、セクション11.31で説明されているように、他のメカニズムを使用してASのアイデンティティを保証できる場合を除き、セクション11.31で説明されているクラスの混合攻撃を防ぐために、それぞれに異なるキーを使用する必要があります。リクエスト。
If the client instance has an instance identifier that the AS can use to determine appropriate key information, the client instance can send this instance identifier as a direct reference value in lieu of the client object. The instance identifier MAY be assigned to a client instance at runtime through a grant response (Section 3.5) or MAY be obtained in another fashion, such as a static registration process at the AS.
クライアントインスタンスに、ASが適切なキー情報を決定するために使用できるインスタンス識別子がある場合、クライアントインスタンスは、クライアントオブジェクトの代わりにこのインスタンス識別子を直接基準値として送信できます。インスタンス識別子は、補助金応答（セクション3.5）を介して実行時にクライアントインスタンスに割り当てることも、ASでの静的登録プロセスなど、別の方法で取得することもできます。
"client": "client-541-ab"
When the AS receives a request with an instance identifier, the AS MUST ensure that the key used to sign the request (Section 7.3) is associated with the instance identifier.
ASがインスタンス識別子を使用してリクエストを受信した場合、ASは、キーがリクエストに署名するために使用される（セクション7.3）にインスタンス識別子に関連付けられていることを確認する必要があります。
If the AS does not recognize the instance identifier, the request MUST be rejected with an invalid_client error (Section 3.6).
ASがインスタンス識別子を認識しない場合、リクエストは無効なエラー（セクション3.6）で拒否する必要があります。
If the client instance has additional information to display to the RO during any interactions at the AS, it MAY send that information in the "display" field. This field is a JSON object that declares information to present to the RO during any interactive sequences.
クライアントインスタンスに、ASでのインタラクション中にROに表示する追加情報がある場合、「表示」フィールドにその情報が送信される場合があります。このフィールドは、インタラクティブシーケンス中に情報をROに提示する情報を宣言するJSONオブジェクトです。
name (string):
名前（文字列）：
Display name of the client software. RECOMMENDED.
クライアントソフトウェアの名前を表示します。推奨。
uri (string):
uri（string）：
User-facing information about the client software, such as a web page. This URI MUST be an absolute URI. OPTIONAL.
Webページなど、クライアントソフトウェアに関するユーザー向け情報。このURIは絶対的なURIでなければなりません。オプション。
logo_uri (string):
logo_uri（string）：
Display image to represent the client software. This URI MUST be an absolute URI. The logo MAY be passed by value by using a data: URI [RFC2397] referencing an image media type. OPTIONAL.
クライアントソフトウェアを表すために画像を表示します。このURIは絶対的なURIでなければなりません。ロゴは、画像メディアタイプを参照するデータを使用して、値で渡すことができます。オプション。
"display": {
"name": "My Client Display Name",
"uri": "https://example.net/client",
"logo_uri": "data:image/png;base64,Eeww...="
}
Additional display fields can be defined in the "GNAP Client Instance Display Fields" registry (Section 10.8).
追加の表示フィールドは、「GNAPクライアントインスタンス表示フィールド」レジストリ（セクション10.8）で定義できます。
The AS SHOULD use these values during interaction with the RO. The values are for informational purposes only and MUST NOT be taken as authentic proof of the client instance's identity or source. The AS MAY restrict display values to specific client instances, as identified by their keys in Section 2.3. See additional considerations for displayed client information in Section 11.15 and for the logo_uri in particular in Section 11.16.
ASは、ROとの相互作用中にこれらの値を使用する必要があります。価値は情報目的のみであり、クライアントインスタンスのIDまたはソースの本物の証明とみなされてはなりません。ASは、セクション2.3のキーによって識別されるように、特定のクライアントインスタンスに表示値を制限する場合があります。セクション11.15の表示されたクライアント情報と、特にセクション11.16のlogo_uriについての追加の考慮事項を参照してください。
If the presented key is known to the AS and is associated with a single instance of the client software, the process of presenting a key and proving possession of that key is sufficient to authenticate the client instance to the AS. The AS MAY associate policies with the client instance identified by this key, such as limiting which resources can be requested and which interaction methods can be used. For example, only specific client instances with certain known keys might be trusted with access tokens without the AS interacting directly with the RO, as in Appendix B.3.
提示されたキーがASに知られ、クライアントソフトウェアの単一のインスタンスに関連付けられている場合、キーを提示してそのキーの所有を証明するプロセスは、ASにクライアントインスタンスを認証するのに十分です。ASは、どのリソースを要求できるか、どの相互作用方法を使用できるかなど、このキーによって特定されたクライアントインスタンスにポリシーを関連付けることができます。たとえば、付録B.3のように、特定の既知のキーを持つ特定のクライアントインスタンスのみがROと直接相互作用することなく、アクセストークンで信頼される場合があります。
The presentation of a key allows the AS to strongly associate multiple successive requests from the same client instance with each other. This is true when the AS knows the key ahead of time and can use the key to authenticate the client instance, but it is also true if the key is ephemeral and created just for this series of requests. As such, the AS MAY allow for client instances to make requests with unknown keys. This pattern allows for ephemeral client instances (such as single-page applications) and client software with many individual long-lived instances (such as mobile applications) to generate key pairs per instance and use the keys within the protocol without having to go through a separate registration step. The AS MAY limit which capabilities are made available to client instances with unknown keys. For example, the AS could have a policy saying that only previously registered client instances can request particular resources or that all client instances with unknown keys have to be interactively approved by an RO.
キーのプレゼンテーションにより、同じクライアントインスタンスからの複数の連続したリクエストを互いに強く関連付けることができます。これは、ASが事前にキーを知っており、キーを使用してクライアントインスタンスを認証できる場合に当てはまりますが、キーが短命であり、この一連のリクエストのためだけに作成された場合にも当てはまります。そのため、クライアントインスタンスが未知のキーでリクエストを行うことを可能にする可能性があります。このパターンを使用すると、短命クライアントインスタンス（シングルページアプリケーションなど）と多くの個別の長寿命インスタンス（モバイルアプリケーションなど）を備えたクライアントソフトウェアがインスタンスごとにキーペアを生成し、プロトコル内のキーを使用せずに使用することを可能にします。登録ステップを個別に。ASは、未知のキーを持つクライアントインスタンスで利用可能にされる機能を制限する場合があります。たとえば、以前に登録されていたクライアントインスタンスのみが特定のリソースを要求できる、または不明なキーを持つすべてのクライアントインスタンスをROによってインタラクティブに承認する必要があるというポリシーがある可能性があります。
If the client instance knows the identity of the end user through one or more identifiers or assertions, the client instance MAY send that information to the AS in the user field. The client instance MAY pass this information by value or by reference (see Section 2.4.1).
クライアントインスタンスが1つ以上の識別子またはアサーションを介してエンドユーザーの身元を知っている場合、クライアントインスタンスはその情報をユーザーフィールドのASに送信する場合があります。クライアントインスタンスは、この情報を価値または参照によって渡すことができます（セクション2.4.1を参照）。
sub_ids (array of objects):
sub_ids（オブジェクトの配列）：
An array of Subject Identifiers for the end user, as defined by [RFC9493]. OPTIONAL.
[RFC9493]で定義されているエンドユーザーの被験者識別子の配列。オプション。
assertions (array of objects):
アサーション（オブジェクトの配列）：
An array containing assertions as objects, each containing the assertion format and the assertion value as the JSON string serialization of the assertion, as defined in Section 3.4. OPTIONAL.
セクション3.4で定義されているように、それぞれがアサーション形式とアサーション値としてアサーション値を含むJSON文字列のシリアル化としてのアサーションを含む配列。オプション。
"user": {
"sub_ids": [ {
"format": "opaque",
"id": "J2G8G8O4AZ"
} ],
"assertions": [ {
"format": "id_token",
"value": "eyj..."
} ]
}
Subject Identifiers are hints to the AS in determining the RO and MUST NOT be taken as authoritative statements that a particular RO is present at the client instance and acting as the end user.
被験者の識別子は、ROを決定する際のASのヒントであり、特定のROがクライアントインスタンスに存在し、エンドユーザーとして行動するという権威ある声明としてとらないでください。
Assertions presented by the client instance SHOULD be validated by the AS. While the details of such validation are outside the scope of this specification, common validation steps include verifying the signature of the assertion against a trusted signing key, verifying the audience and issuer of the assertion map to expected values, and verifying the time window for the assertion itself. However, note that in many use cases, some of these common steps are relaxed. For example, an AS acting as an identity provider (IdP) could expect that assertions being presented using this mechanism were issued by the AS to the client software. The AS would verify that the AS is the issuer of the assertion, not the audience, and that the client instance is instead the audience of the assertion. Similarly, an AS might accept a recently expired assertion in order to help bootstrap a new session with a specific end user.
クライアントインスタンスによって提示されたアサーションは、ASによって検証される必要があります。このような検証の詳細はこの仕様の範囲外ですが、一般的な検証手順には、信頼できる署名キーに対するアサーションの署名の検証、アサーションマップの視聴者と発行者の期待値の確認、およびアサーション自体。ただし、多くのユースケースでは、これらの一般的な手順の一部が緩和されていることに注意してください。たとえば、IDプロバイダー（IDP）として行動するASは、このメカニズムを使用して提示されているアサーションがクライアントソフトウェアによって発行されたことを期待できます。ASは、ASが聴衆ではなく主張の発行者であり、クライアントインスタンスが代わりにアサーションの聴衆であることを確認します。同様に、特定のエンドユーザーとの新しいセッションをブートストラップするのを助けるために、最近期限切れのアサーションを受け入れる可能性があります。
If the identified end user does not match the RO present at the AS during an interaction step and the AS is not explicitly allowing a cross-user authorization, the AS SHOULD reject the request with an unknown_user error (Section 3.6).
識別されたエンドユーザーが、相互作用ステップ中に存在するROと一致しない場合、ASはクロスユーザーの認証を明示的に許可していない場合、ASは不明な_USERエラー（セクション3.6）でリクエストを拒否する必要があります。
If the AS trusts the client instance to present verifiable assertions or known Subject Identifiers, such as an opaque identifier issued by the AS for this specific client instance, the AS MAY decide, based on its policy, to skip interaction with the RO, even if the client instance provides one or more interaction modes in its request.
ASが、この特定のクライアントインスタンスによって発行された不透明な識別子など、検証可能なアサーションまたは既知のサブジェクト識別子を提示するクライアントインスタンスを信頼している場合、ASは、そのポリシーに基づいて、たとえROとの相互作用をスキップすることを決定する場合があります。クライアントインスタンスは、その要求に1つ以上の相互作用モードを提供します。
See Section 11.30 for considerations for the AS when accepting and processing assertions from the client instance.
クライアントインスタンスからアサーションを受け入れて処理する場合の考慮事項については、セクション11.30を参照してください。
The AS can identify the current end user to the client instance with a reference that can be used by the client instance to refer to the end user across multiple requests. If the client instance has a reference for the end user at this AS, the client instance MAY pass that reference as a string. The format of this string is opaque to the client instance.
ASは、複数のリクエストでエンドユーザーを参照するためにクライアントインスタンスで使用できるリファレンスを使用して、クライアントインスタンスに現在のエンドユーザーを識別できます。クライアントインスタンスがこれでエンドユーザーの参照を持っている場合、クライアントインスタンスはその参照を文字列として渡すことができます。この文字列の形式は、クライアントインスタンスに不透明です。
"user": "XUT2MFM1XBIKJKSDU8QM"
One means of dynamically obtaining such a user reference is from the AS returning an opaque Subject Identifier as described in Section 3.4. Other means of configuring a client instance with a user identifier are out of scope of this specification. The lifetime and validity of these user references are determined by the AS, and this lifetime is not exposed to the client instance in GNAP. As such, a client instance using such a user reference is likely to keep using that reference until it stops working.
このようなユーザー参照を動的に取得する1つの手段は、セクション3.4で説明されているように、不透明な被験者識別子を返すASからです。ユーザー識別子を使用してクライアントインスタンスを構成する他の手段は、この仕様の範囲外です。これらのユーザー参照の寿命と有効性はASによって決定され、この寿命はGNAPのクライアントインスタンスにさらされていません。そのため、このようなユーザーリファレンスを使用するクライアントインスタンスは、動作を停止するまでその参照を使用し続ける可能性があります。
User reference identifiers are not intended to be human-readable user identifiers or structured assertions. For the client instance to send either of these, the client can use the full user request object (Section 2.4) instead.
ユーザーリファレンス識別子は、人間が読み取るユーザー識別子または構造化されたアサーションであることを意図したものではありません。クライアントインスタンスがこれらのいずれかを送信するために、クライアントは代わりに完全なユーザーリクエストオブジェクト（セクション2.4）を使用できます。
If the AS does not recognize the user reference, it MUST return an unknown_user error (Section 3.6).
ASがユーザー参照を認識していない場合、不明な_userエラー（セクション3.6）を返す必要があります。
Often, the AS will require interaction with the RO (Section 4) in order to approve a requested delegation to the client instance for both access to resources and direct subject information. Many times, the end user using the client instance is the same person as the RO, and the client instance can directly drive interaction with the end user by facilitating the process through means such as redirection to a URI or launching an application. Other times, the client instance can provide information to start the RO's interaction on a secondary device, or the client instance will wait for the RO to approve the request asynchronously. The client instance could also be signaled that interaction has concluded through a callback mechanism.
多くの場合、ASは、リソースへのアクセスと直接的な主題情報の両方について、クライアントインスタンスに要求された代表団を承認するために、RO（セクション4）との相互作用を必要とします。多くの場合、クライアントインスタンスを使用するエンドユーザーはROと同じ人物であり、クライアントインスタンスは、URIへのリダイレクトやアプリケーションの起動などの手段を介してプロセスを促進することにより、エンドユーザーとの対話を直接駆動できます。また、クライアントインスタンスは、セカンダリデバイスでのROのインタラクションを開始するための情報を提供することもできます。または、クライアントインスタンスがROがリクエストを非同期に承認するのを待ちます。クライアントインスタンスは、相互作用がコールバックメカニズムを介して終了したことを示すこともできます。
The client instance declares the parameters for interaction methods that it can support using the interact field.
クライアントインスタンスは、インタラクションフィールドを使用してサポートできる相互作用方法のパラメーターを宣言します。
The interact field is a JSON object with three keys whose values declare how the client can initiate and complete the request, as well as provide hints to the AS about user preferences such as locale. A client instance MUST NOT declare an interaction mode it does not support. The client instance MAY send multiple modes in the same request. There is no preference order specified in this request. An AS MAY respond to any, all, or none of the presented interaction modes (Section 3.3) in a request, depending on its capabilities and what is allowed to fulfill the request.
インタラクションフィールドは、クライアントがリクエストを開始および完了する方法を宣言する3つのキーを備えたJSONオブジェクトであり、Localeなどのユーザー設定に関するヒントを提供します。クライアントインスタンスは、サポートしていないインタラクションモードを宣言してはなりません。クライアントインスタンスは、同じリクエストで複数のモードを送信する場合があります。このリクエストで指定された優先順序はありません。ASは、その機能と要求を満たすことが許可されているものに応じて、リクエストで提示された相互作用モード（セクション3.3）に応答する場合があります。
start (array of objects/strings):
start（オブジェクト/文字列の配列）：
Indicates how the client instance can start an interaction. REQUIRED. See Section 2.5.1.
クライアントインスタンスがインタラクションを開始する方法を示します。必須。セクション2.5.1を参照してください。
finish (object):
仕上げ（オブジェクト）：
Indicates how the client instance can receive an indication that interaction has finished at the AS. OPTIONAL. See Section 2.5.2.
クライアントインスタンスがASで相互作用が終了したことを示していることを示します。オプション。セクション2.5.2を参照してください。
hints (object):
ヒント（オブジェクト）：
Provides additional information to inform the interaction process at the AS. OPTIONAL. See Section 2.5.3.
ASで相互作用プロセスを通知するための追加情報を提供します。オプション。セクション2.5.3を参照してください。
In the following non-normative example, the client instance is indicating that it can redirect (Section 2.5.1.1) the end user to an arbitrary URI and can receive a redirect (Section 2.5.2.1) through a browser request. Note that the client instance does not accept a push-style callback. The pattern of using a redirect for both interaction start and finish is common for web-based client software.
以下の非規範的な例では、クライアントインスタンスは、エンドユーザーを任意のURIにリダイレクト（セクション2.5.1.1）に任意のURIにリダイレクトできることを示しており、ブラウザリクエストを介してリダイレクト（セクション2.5.2.1）を受信できることを示しています。クライアントインスタンスはプッシュスタイルのコールバックを受け入れないことに注意してください。インタラクションの開始と仕上げの両方にリダイレクトを使用するパターンは、Webベースのクライアントソフトウェアで一般的です。
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
}
In the following non-normative example, the client instance is indicating that it can display a user code (Section 2.5.1.3) and direct the end user to an arbitrary URI (Section 2.5.1.1), but it cannot accept a redirect or push-style callback. This pattern is common for devices that have robust display capabilities but expect the use of a secondary device to facilitate end-user interaction with the AS, such as a set-top box capable of displaying an interaction URL as a QR code.
次の非規範的な例では、クライアントインスタンスはユーザーコード（セクション2.5.1.3）を表示し、エンドユーザーを任意のURI（セクション2.5.1.1）に誘導できることを示していますが、リダイレクトまたはプッシュを受け入れることはできません。- スタイルコールバック。このパターンは、堅牢なディスプレイ機能を備えたデバイスでは一般的ですが、QRコードとしてインタラクションURLを表示できるセットトップボックスなど、ASとのエンドユーザーの相互作用を促進するためのセカンダリデバイスの使用を期待しています。
"interact": {
"start": ["redirect", "user_code"]
}
In the following non-normative example, the client instance is indicating that it cannot start any interaction with the end user but that the AS can push an interaction finish message (Section 2.5.2.2) when authorization from the RO is received asynchronously. This pattern is common for scenarios where a service needs to be authorized, but the RO is able to be contacted separately from the GNAP transaction itself, such as through a push notification or existing interactive session on a secondary device.
次の非規範的な例では、クライアントインスタンスは、エンドユーザーとの相互作用を開始できないが、ROからの認可を非同期に受信した場合のインタラクション仕上げメッセージ（セクション2.5.2.2）をプッシュできることを示しています。このパターンは、サービスを承認する必要があるシナリオでは一般的ですが、ROは、プッシュ通知やセカンダリデバイス上の既存のインタラクティブセッションなど、GNAPトランザクション自体とは別に連絡することができます。
"interact": {
"start": [],
"finish": {
"method": "push",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
}
If all of the following conditions are true, the AS MUST return an invalid_interaction error (Section 3.6) since the client instance will be unable to complete the request without authorization:
次のすべての条件が真である場合、ASは、クライアントインスタンスが許可なしにリクエストを完了できないため、nivalid_interactionエラー（セクション3.6）を返す必要があります。
* The client instance does not provide a suitable interaction mechanism.
* クライアントインスタンスは、適切な相互作用メカニズムを提供しません。
* The AS cannot contact the RO asynchronously.
* ASは非同期に接触することはできません。
* The AS determines that interaction is required.
* ASは、相互作用が必要であると判断します。
If the client instance is capable of starting interaction with the end user, the client instance indicates this by sending an array of start modes under the start key. Each interaction start mode has a unique identifying name. Interaction start modes are specified in the array either by a string, which consists of the start mode name on its own, or by a JSON object with the required field mode:
クライアントインスタンスがエンドユーザーとの相互作用を開始できる場合、クライアントインスタンスは、開始キーの下に一連の開始モードを送信することでこれを示します。各インタラクション開始モードには、一意の識別名があります。インタラクション開始モードは、アレイで、独自のスタートモード名で構成される文字列で、または必要なフィールドモードを備えたJSONオブジェクトで指定されます。
mode:
モード：
The interaction start mode. REQUIRED.
インタラクション開始モード。必須。
Interaction start modes defined as objects MAY define additional parameters to be required in the object.
オブジェクトとして定義された相互作用開始モードは、オブジェクトに必要な追加のパラメーターを定義する場合があります。
The start array can contain both string-type and object-type modes.
開始配列には、string-typeモードとオブジェクトタイプモードの両方を含めることができます。
This specification defines the following interaction start modes:
この仕様は、次のインタラクション開始モードを定義します。
"redirect" (string):
「リダイレクト」（文字列）：
Indicates that the client instance can direct the end user to an arbitrary URI for interaction. See Section 2.5.1.1.
クライアントインスタンスが、インタラクションのためにエンドユーザーを任意のURIに誘導できることを示します。セクション2.5.1.1を参照してください。
"app" (string):
「app」（文字列）：
Indicates that the client instance can launch an application on the end user's device for interaction. See Section 2.5.1.2.
クライアントインスタンスがインタラクションのためにエンドユーザーのデバイスでアプリケーションを起動できることを示します。セクション2.5.1.2を参照してください。
"user_code" (string):
「user_code」（文字列）：
Indicates that the client instance can communicate a short, human-readable code to the end user for use with a stable URI. See Section 2.5.1.3.
クライアントインスタンスが、安定したURIで使用するために、短い人間の読み取り可能なコードをエンドユーザーに通信できることを示します。セクション2.5.1.3を参照してください。
"user_code_uri" (string):
「user_code_uri」（文字列）：
Indicates that the client instance can communicate a short, human-readable code to the end user for use with a short, dynamic URI. See Section 2.5.1.4.
クライアントインスタンスは、短いダイナミックURIで使用するために短い人間の読み取り可能なコードをエンドユーザーに通信できることを示します。セクション2.5.1.4を参照してください。
Additional start modes can be defined in the "GNAP Interaction Start Modes" registry (Section 10.9).
追加の開始モードは、「GNAPインタラクション開始モード」レジストリ（セクション10.9）で定義できます。
If the client instance is capable of directing the end user to a URI defined by the AS at runtime, the client instance indicates this by including redirect in the array under the start key. The means by which the client instance will activate this URI are out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end user's device, providing a scannable image encoding, and printing out a URI to an interactive console. While this URI is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the grant endpoint URI.
クライアントインスタンスが実行時にASで定義されたURIにエンドユーザーを指示できる場合、クライアントインスタンスは、開始キーの下に配列にリダイレクトを含めることによりこれを示します。クライアントインスタンスがこのURIをアクティブにする手段はこの仕様の範囲外ですが、一般的な方法にはHTTPリダイレクト、エンドユーザーのデバイス上のブラウザの起動、スキャン可能な画像エンコードの提供、インタラクティブへのURIの印刷が含まれます。コンソール。このURIは一般にASでホストされていますが、クライアントインスタンスは、その内容、構成、または助成金のエンドポイントURIとの関係について推測することはできません。
"interact": {
"start": ["redirect"]
}
If this interaction mode is supported for this client instance and request, the AS returns a redirect interaction response (Section 3.3.1). The client instance manages this interaction method as described in Section 4.1.1.
この相互作用モードがこのクライアントインスタンスとリクエストでサポートされている場合、ASはリダイレクトインタラクション応答を返します（セクション3.3.1）。クライアントインスタンスは、セクション4.1.1で説明されているように、この相互作用方法を管理します。
See Section 11.29 for more considerations regarding the use of front-channel communication techniques.
フロントチャネル通信技術の使用に関する詳細については、セクション11.29を参照してください。
If the client instance can open a URI associated with an application on the end user's device, the client instance indicates this by including app in the array under the start key. The means by which the client instance determines the application to open with this URI are out of scope of this specification.
クライアントインスタンスがエンドユーザーのデバイス上のアプリケーションに関連付けられているURIを開くことができる場合、クライアントインスタンスは、STARTキーの下に配列にアプリを含めることでこれを示します。クライアントインスタンスがこのURIで開くアプリケーションを決定する手段は、この仕様の範囲外です。
"interact": {
"start": ["app"]
}
If this interaction mode is supported for this client instance and request, the AS returns an app interaction response with an app URI payload (Section 3.3.2). The client instance manages this interaction method as described in Section 4.1.4.
この相互作用モードがこのクライアントインスタンスとリクエストに対してサポートされている場合、ASはApp URIペイロード（セクション3.3.2）でアプリインタラクション応答を返します。クライアントインスタンスは、セクション4.1.4で説明されているように、この相互作用方法を管理します。
If the client instance is capable of displaying or otherwise communicating a short, human-entered code to the RO, the client instance indicates this by including user_code in the array under the start key. This code is to be entered at a static URI that does not change at runtime. The client instance has no reasonable means to communicate a dynamic URI to the RO, so this URI is usually communicated out of band to the RO through documentation or other messaging outside of GNAP. While this URI is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the grant endpoint URI.
クライアントインスタンスが短いヒューマン入力コードをROに表示または通信できる場合、クライアントインスタンスは、開始キーの下に配列にuser_codeを含めることによりこれを示します。このコードは、実行時に変更されない静的URIに入力されます。クライアントインスタンスには、動的URIをROに伝える合理的な手段がないため、このURIは通常、GNAP以外のドキュメントまたは他のメッセージングを介してROにバンドから伝えられます。このURIは一般にASでホストされていますが、クライアントインスタンスは、その内容、構成、または助成金のエンドポイントURIとの関係について推測することはできません。
"interact": {
"start": ["user_code"]
}
If this interaction mode is supported for this client instance and request, the AS returns a user code as specified in Section 3.3.3. The client instance manages this interaction method as described in Section 4.1.2.
この相互作用モードがこのクライアントインスタンスとリクエストでサポートされている場合、ASはセクション3.3.3で指定されているようにユーザーコードを返します。クライアントインスタンスは、セクション4.1.2で説明されているように、この相互作用方法を管理します。
If the client instance is capable of displaying or otherwise communicating a short, human-entered code along with a short, human-entered URI to the RO, the client instance indicates this by including user_code_uri in the array under the start key. This code is to be entered at the dynamic URL given in the response. While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the grant endpoint URI.
クライアントインスタンスが、短いヒューマンで入力されたコードと、短いヒューマンで入力されたURIをROに表示または通信できる場合、クライアントインスタンスは、STARTキーの下の配列にuser_code_uriを含めることでこれを示します。このコードは、応答に与えられた動的URLに入力されます。このURLは一般にASでホストされていますが、クライアントインスタンスは、その内容、構成、または助成金のエンドポイントURIとの関係について推測することはできません。
"interact": {
"start": ["user_code_uri"]
}
If this interaction mode is supported for this client instance and request, the AS returns a user code and interaction URL as specified in Section 3.3.4. The client instance manages this interaction method as described in Section 4.1.3.
このクライアントインスタンスとリクエストでこのインタラクションモードがサポートされている場合、ASはセクション3.3.4で指定されているユーザーコードとインタラクションURLを返します。クライアントインスタンスは、セクション4.1.3で説明されているように、この相互作用方法を管理します。
If the client instance is capable of receiving a message from the AS indicating that the RO has completed their interaction, the client instance indicates this by sending the following members of an object under the finish key.
クライアントインスタンスがROがインタラクションを完了したことを示すASからメッセージを受信できる場合、クライアントインスタンスは、フィニッシュキーの下にオブジェクトの次のメンバーを送信することによりこれを示します。
method (string):
方法（文字列）：
The callback method that the AS will use to contact the client instance. REQUIRED.
ASがクライアントインスタンスに連絡するために使用するコールバック方法。必須。
uri (string):
uri（string）：
Indicates the URI that the AS will use to signal the client instance that interaction has completed. This URI MAY be unique per request and MUST be hosted by or accessible to the client instance. This URI MUST be an absolute URI and MUST NOT contain any fragment component. If the client instance needs any state information to tie to the front-channel interaction response, it MUST use a unique callback URI to link to that ongoing state. The allowable URIs and URI patterns MAY be restricted by the AS based on the client instance's presented key information. The callback URI SHOULD be presented to the RO during the interaction phase before redirect. REQUIRED for redirect and push methods.
ASがインタラクションが完了したというクライアントインスタンスを信号するために使用するURIを示します。このURIは、リクエストごとに一意である場合があり、クライアントインスタンスによってホストされるか、アクセスできる必要があります。このURIは絶対的なURIである必要があり、フラグメント成分を含めてはなりません。クライアントインスタンスがフロントチャネル相互作用応答に結び付けるために状態情報を必要とする場合、その進行中の状態にリンクするために一意のコールバックURIを使用する必要があります。許容可能なURIおよびURIパターンは、クライアントインスタンスの提示された重要な情報に基づいてASによって制限される場合があります。コールバックURIは、リダイレクトの前に相互作用段階でROに提示する必要があります。リダイレクトおよびプッシュメソッドに必要です。
nonce (string):
nonce（string）：
Unique ASCII string value to be used in the calculation of the "hash" query parameter sent to the callback URI. It must be sufficiently random to be unguessable by an attacker. It MUST be generated by the client instance as a unique value for this request. REQUIRED.
コールバックURIに送信された「ハッシュ」クエリパラメーターの計算で使用される一意のASCII文字列値。攻撃者が十分にランダムにすることは、十分にランダムでなければなりません。このリクエストの一意の値として、クライアントインスタンスによって生成する必要があります。必須。
hash_method (string):
hash_method（string）：
An identifier of a hash calculation mechanism to be used for the callback hash in Section 4.2.3, as defined in the IANA "Named Information Hash Algorithm Registry" [HASH-ALG]. If absent, the default value is sha-256. OPTIONAL.
セクション4.2.3のコールバックハッシュに使用されるハッシュ計算メカニズムの識別子は、「情報ハッシュアルゴリズムレジストリ」[Hash-Alg]という名前のIANAで定義されています。不在の場合、デフォルト値はSHA-256です。オプション。
This specification defines the following values for the method parameter; additional values can be defined in the "GNAP Interaction Finish Methods" registry (Section 10.10):
この仕様は、メソッドパラメーターの次の値を定義します。追加の値は、「GNAPインタラクション仕上げ方法」レジストリ（セクション10.10）で定義できます。
"redirect":
"リダイレクト"：
Indicates that the client instance can receive a redirect from the end user's device after interaction with the RO has concluded. See Section 2.5.2.1.
ROとのやり取りが終了した後、クライアントインスタンスがエンドユーザーのデバイスからリダイレクトを受信できることを示します。セクション2.5.2.1を参照してください。
"push":
"押す"：
Indicates that the client instance can receive an HTTP POST request from the AS after interaction with the RO has concluded. See Section 2.5.2.2.
クライアントインスタンスが、ROとの相互作用後のAS ASからHTTP POSTリクエストを受信できることを示します。セクション2.5.2.2を参照してください。
If interaction finishing is supported for this client instance and request, the AS will return a nonce (Section 3.3.5) used by the client instance to validate the callback. All interaction finish methods MUST use this nonce to allow the client to verify the connection between the pending interaction request and the callback. GNAP does this through the use of the interaction hash, defined in Section 4.2.3. All requests to the callback URI MUST be processed as described in Section 4.2.
このクライアントインスタンスとリクエストで相互作用の仕上げがサポートされている場合、ASは、クライアントインスタンスで使用されるノンセ（セクション3.3.5）を返してコールバックを検証します。すべてのインタラクション仕上げ方法は、このNonCEを使用して、クライアントが保留中のインタラクションリクエストとコールバックの間の接続を確認できるようにする必要があります。GNAPは、セクション4.2.3で定義されている相互作用ハッシュを使用してこれを行います。コールバックURIへのすべての要求は、セクション4.2で説明されているように処理する必要があります。
All interaction finish methods MUST require presentation of an interaction reference for continuing this grant request. This means that the interaction reference MUST be returned by the AS and MUST be presented by the client as described in Section 5.1. The means by which the interaction reference is returned to the client instance are specific to the interaction finish method.
すべてのインタラクション仕上げ方法は、この助成金リクエストを継続するために、相互作用リファレンスの提示を必要とする必要があります。つまり、セクション5.1で説明されているように、インタラクションリファレンスはASによって返され、クライアントが提示する必要があります。相互作用リファレンスがクライアントインスタンスに返される手段は、インタラクション仕上げ方式に固有です。
A finish method value of redirect indicates that the client instance will expect a request from the RO's browser using the HTTP method GET as described in Section 4.2.1.
リダイレクトの仕上げメソッド値は、クライアントインスタンスが、セクション4.2.1で説明されているように、HTTPメソッドを使用したROのブラウザからのリクエストを期待することを示しています。
The client instance's URI MUST be protected by HTTPS, be hosted on a server local to the RO's browser ("localhost"), or use an application-specific URI scheme that is loaded on the end user's device.
クライアントインスタンスのURIは、HTTPSによって保護され、ROのブラウザ（ "LocalHost"）にローカルなサーバーでホストされるか、エンドユーザーのデバイスにロードされるアプリケーション固有のURIスキームを使用する必要があります。
"interact": {
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
}
Requests to the callback URI MUST be processed by the client instance as described in Section 4.2.1.
セクション4.2.1で説明されているように、コールバックURIへのリクエストは、クライアントインスタンスによって処理される必要があります。
Since the incoming request to the callback URI is from the RO's browser, this method is usually used when the RO and end user are the same entity. See Section 11.24 for considerations on ensuring the incoming HTTP message matches the expected context of the request. See Section 11.29 for more considerations regarding the use of front-channel communication techniques.
コールバックURIへの着信要求はROのブラウザからのものであるため、この方法は通常、ROとエンドユーザーが同じエンティティである場合に使用されます。着信HTTPメッセージがリクエストの予想されるコンテキストと一致するようにするための考慮事項については、セクション11.24を参照してください。フロントチャネル通信技術の使用に関する詳細については、セクション11.29を参照してください。
A finish method value of push indicates that the client instance will expect a request from the AS directly using the HTTP method POST as described in Section 4.2.2.
プッシュの終了メソッド値は、クライアントインスタンスがセクション4.2.2で説明されているように、HTTPメソッド投稿を直接使用してASからのリクエストを期待することを示します。
The client instance's URI MUST be protected by HTTPS, be hosted on a server local to the RO's browser ("localhost"), or use an application-specific URI scheme that is loaded on the end user's device.
クライアントインスタンスのURIは、HTTPSによって保護され、ROのブラウザ（ "LocalHost"）にローカルなサーバーでホストされるか、エンドユーザーのデバイスにロードされるアプリケーション固有のURIスキームを使用する必要があります。
"interact": {
"finish": {
"method": "push",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
}
Requests to the callback URI MUST be processed by the client instance as described in Section 4.2.2.
コールバックURIへのリクエストは、セクション4.2.2で説明されているように、クライアントインスタンスによって処理される必要があります。
Since the incoming request to the callback URI is from the AS and not from the RO's browser, this request is not expected to have any shared session information from the start method. See Sections 11.24 and 11.23 for more considerations regarding the use of back-channel and polling mechanisms like this.
コールバックURIへの着信要求はROのブラウザからではなく、ASからのものであるため、このリクエストにはSTARTメソッドからの共有セッション情報がないとは予想されていません。このようなバックチャネルとポーリングメカニズムの使用に関する詳細については、セクション11.24および11.23を参照してください。
The hints key is an object describing one or more suggestions from the client instance that the AS can use to help drive user interaction.
ヒントキーは、クライアントインスタンスからの1つ以上の提案を説明するオブジェクトです。これは、ASがユーザーのインタラクションを促進するために使用できることです。
This specification defines the following property under the hints key:
この仕様は、ヒントキーの下に次のプロパティを定義します。
ui_locales (array of strings):
ui_locales（文字列の配列）：
Indicates the end user's preferred locales that the AS can use during interaction, particularly before the RO has authenticated. OPTIONAL. Section 2.5.3.1
特にROが認証される前に、インタラクション中にASが使用できるエンドユーザーの好ましいロケールを示します。オプション。セクション2.5.3.1
The following subsection details requests for interaction hints. Additional interaction hints can be defined in the "GNAP Interaction Hints" registry (Section 10.11).
次のサブセクションの詳細は、相互作用のヒントを要求します。追加の相互作用ヒントは、「GNAP相互作用ヒント」レジストリ（セクション10.11）で定義できます。
If the client instance knows the end user's locale and language preferences, the client instance can send this information to the AS using the ui_locales field with an array of locale strings as defined by [RFC5646].
クライアントインスタンスがエンドユーザーのロケールと言語の好みを知っている場合、クライアントインスタンスは[RFC5646]で定義されているように、ロケール文字列の配列を使用してUI_Localesフィールドを使用してこの情報をASに送信できます。
"interact": {
"hints": {
"ui_locales": ["en-US", "fr-CA"]
}
}
If possible, the AS SHOULD use one of the locales in the array, with preference to the first item in the array supported by the AS. If none of the given locales are supported, the AS MAY use a default locale.
可能であれば、ASはASによってサポートされているアレイの最初のアイテムよりも優先され、配列内のロケールの1つを使用する必要があります。特定のロケールがサポートされていない場合、ASはデフォルトのロケールを使用する場合があります。
In response to a client instance's request, the AS responds with a JSON object as the HTTP content. Each possible field is detailed in the subsections below.
クライアントインスタンスの要求に応じて、ASはJSONオブジェクトでHTTPコンテンツとして応答します。可能な各フィールドは、以下のサブセクションで詳しく説明されています。
continue (object):
続行（オブジェクト）：
Indicates that the client instance can continue the request by making one or more continuation requests. REQUIRED if continuation calls are allowed for this client instance on this grant request. See Section 3.1.
クライアントインスタンスは、1つ以上の継続リクエストを行うことでリクエストを継続できることを示します。このクライアントインスタンスがこの助成金リクエストで継続コールが許可されている場合。セクション3.1を参照してください。
access_token (object / array of objects):
Access_Token（オブジェクトのオブジェクト /配列）：
A single access token or set of access tokens that the client instance can use to call the RS on behalf of the RO. REQUIRED if an access token is included. See Section 3.2.
クライアントインスタンスがROに代わってRSを呼び出すために使用できる単一のアクセストークンまたはアクセストークンのセット。アクセストークンが含まれている場合は必要です。セクション3.2を参照してください。
interact (object):
対話（オブジェクト）：
Indicates that interaction through some set of defined mechanisms needs to take place. REQUIRED if interaction is expected. See Section 3.3.
いくつかの一連の定義されたメカニズムを介した相互作用が行われる必要があることを示します。相互作用が予想される場合は必要です。セクション3.3を参照してください。
subject (object):
件名（オブジェクト）：
Claims about the RO as known and declared by the AS. REQUIRED if subject information is included. See Section 3.4.
ASによって既知および宣言されたROについての主張。サブジェクト情報が含まれている場合は必要です。セクション3.4を参照してください。
instance_id (string):
instance_id（string）：
An identifier this client instance can use to identify itself when making future requests. OPTIONAL. See Section 3.5.
このクライアントインスタンスは、将来のリクエストを行うときに自分自身を識別するために使用できる識別子です。オプション。セクション3.5を参照してください。
error (object or string):
エラー（オブジェクトまたは文字列）：
An error code indicating that something has gone wrong. REQUIRED for an error condition. See Section 3.6.
何かがうまくいかなかったことを示すエラーコード。エラー状態に必要です。セクション3.6を参照してください。
Additional fields can be defined by extensions to GNAP in the "GNAP Grant Response Parameters" registry (Section 10.12).
追加のフィールドは、「GNAP助成金応答パラメーター」レジストリ（セクション10.12）のGNAPへの拡張によって定義できます。
In the following non-normative example, the AS is returning an interaction URI (Section 3.3.1), a callback nonce (Section 3.3.5), and a continuation response (Section 3.1).
次の非規範的な例では、ASは相互作用URI（セクション3.3.1）、コールバックNonCE（セクション3.3.5）、および継続応答（セクション3.1）を返しています。
NOTE: '\' line wrapping per RFC 8792
{
"interact": {
"redirect": "https://server.example.com/interact/4CF492ML\
VMSW9MKMXKHQ",
"finish": "MBDOFXG4Y5CVJCX821LH"
},
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU",
},
"uri": "https://server.example.com/tx"
}
}
In the following non-normative example, the AS is returning a bearer access token (Section 3.2.1) with a management URI and a Subject Identifier (Section 3.4) in the form of an opaque identifier.
次の非規範的な例では、ASは、不透明な識別子の形で、管理URIと被験者の識別子（セクション3.4）を使用して、Bearer Access Token（セクション3.2.1）を返しています。
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"flags": ["bearer"],
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
}
},
"subject": {
"sub_ids": [ {
"format": "opaque",
"id": "J2G8G8O4AZ"
} ]
}
}
In the following non-normative example, the AS is returning set of Subject Identifiers (Section 3.4), simultaneously as an opaque identifier, an email address, and a decentralized identifier (DID), formatted as a set of Subject Identifiers as defined in [RFC9493].
次の非規範的な例では、ASは、サブジェクト識別子の返信セット（セクション3.4）、不透明な識別子、電子メールアドレス、および分散型識別子（DED）として同時に、[[で定義された被験者識別子のセットとしてフォーマットされています。RFC9493]。
{
"subject": {
"sub_ids": [ {
"format": "opaque",
"id": "J2G8G8O4AZ"
}, {
"format": "email",
"email": "user@example.com"
}, {
"format": "did",
"url": "did:example:123456"
} ]
}
}
The response MUST be sent as a JSON object in the content of the HTTP response with Content-Type application/json, unless otherwise specified by the specific response (e.g., an empty response with no Content-Type).
応答は、特定の応答（たとえば、コンテンツタイプのない空の応答）で特に指定されていない限り、コンテンツタイプのアプリケーション/JSONを使用したHTTP応答のコンテンツのJSONオブジェクトとして送信する必要があります。
The AS MUST include the HTTP Cache-Control response header field [RFC9111] with a value set to "no-store".
ASには、「ノーストア」に設定された値を備えたHTTPキャッシュコントロール応答ヘッダーフィールド[RFC9111]を含める必要があります。
If the AS determines that the grant request can be continued by the client instance, the AS responds with the continue field. This field contains a JSON object with the following properties.
ASがクライアントインスタンスによって助成金リクエストを継続できると判断した場合、ASは継続フィールドで応答します。このフィールドには、次のプロパティを持つJSONオブジェクトが含まれています。
uri (string):
uri（string）：
The URI at which the client instance can make continuation requests. This URI MAY vary per request or MAY be stable at the AS. This URI MUST be an absolute URI. The client instance MUST use this value exactly as given when making a continuation request (Section 5). REQUIRED.
クライアントインスタンスが継続リクエストを行うことができるURI。このURIは、リクエストごとに異なる場合があるか、ASで安定している場合があります。このURIは絶対的なURIでなければなりません。クライアントインスタンスは、継続リクエストを行うときに与えられたとおりにこの値を正確に使用する必要があります（セクション5）。必須。
wait (integer):
待機（整数）：
The amount of time in integer seconds the client instance MUST wait after receiving this request continuation response and calling the continuation URI. The value SHOULD NOT be less than five seconds, and omission of the value MUST be interpreted as five seconds. RECOMMENDED.
整数秒の時間は、クライアントインスタンスがこの要求の継続応答を受信し、継続URIを呼び出す後に待つ必要があります。値は5秒未満であってはならず、値の省略は5秒として解釈する必要があります。推奨。
access_token (object):
Access_Token（オブジェクト）：
A unique access token for continuing the request, called the "continuation access token". The value of this property MUST be an object in the format specified in Section 3.2.1. This access token MUST be bound to the client instance's key used in the request and MUST NOT be a bearer token. As a consequence, the flags array of this access token MUST NOT contain the string bearer, and the key field MUST be omitted. This access token MUST NOT have a manage field. The client instance MUST present the continuation access token in all requests to the continuation URI as described in Section 7.2. REQUIRED.
「継続アクセストークン」と呼ばれるリクエストを継続するためのユニークなアクセストークン。このプロパティの値は、セクション3.2.1で指定された形式のオブジェクトでなければなりません。このアクセストークンは、リクエストで使用されるクライアントインスタンスのキーにバインドする必要があり、ベアラートークンであってはなりません。結果として、このアクセストークンのフラグアレイには弦楽器が含まれていない必要があり、キーフィールドを省略する必要があります。このアクセストークンには、管理フィールドが必要です。クライアントインスタンスは、セクション7.2で説明されているように、継続URIへのすべての要求で継続アクセストークンを提示する必要があります。必須。
{
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU"
},
"uri": "https://server.example.com/continue",
"wait": 60
}
}
This field is REQUIRED if the grant request is in the _pending_ state, as the field contains the information needed by the client request to continue the request as described in Section 5. Note that the continuation access token is bound to the client instance's key; therefore, the client instance MUST sign all continuation requests with its key as described in Section 7.3 and MUST present the continuation access token in its continuation request.
このフィールドは、セクション5で説明されているように、クライアント要求がリクエストを継続するために必要な情報が含まれているため、付与要求が_Pending_状態にある場合に必要です。したがって、クライアントインスタンスは、セクション7.3で説明されているように、すべての継続要求にキーを使用して署名する必要があり、継続リクエストで継続アクセストークンを提示する必要があります。
If the AS has successfully granted one or more access tokens to the client instance, the AS responds with the access_token field. This field contains either a single access token as described in Section 3.2.1 or an array of access tokens as described in Section 3.2.2.
ASがクライアントインスタンスに1つ以上のアクセストークンを付与した場合、ASはAccess_Tokenフィールドで応答します。このフィールドには、セクション3.2.1で説明されている1つのアクセストークンまたはセクション3.2.2で説明されているアクセストークンの配列が含まれています。
The client instance uses any access tokens in this response to call the RS as described in Section 7.2.
クライアントインスタンスは、この応答のアクセストークンを使用して、セクション7.2で説明されているRSを呼び出します。
The grant request MUST be in the _approved_ state to include this field in the response.
助成金要求は、応答にこのフィールドを含めるために_Approved_状態にある必要があります。
If the client instance has requested a single access token and the AS has granted that access token, the AS responds with the "access_token" field. The value of this field is an object with the following properties.
クライアントインスタンスが単一のアクセストークンを要求し、ASがそのアクセストークンを付与した場合、ASは「Access_Token」フィールドで応答します。このフィールドの値は、次のプロパティを持つオブジェクトです。
value (string):
値（文字列）：
The value of the access token as a string. The value is opaque to the client instance. The value MUST be limited to the token68 character set defined in Section 11.2 of [HTTP] to facilitate transmission over HTTP headers and within other protocols without requiring additional encoding. REQUIRED.
文字列としてのアクセストークンの値。値は、クライアントインスタンスに不透明です。値は、[http]のセクション11.2で定義されているtoken68文字セットに制限して、追加のエンコードを必要とせずにHTTPヘッダーおよび他のプロトコル内での送信を容易にする必要があります。必須。
label (string):
ラベル（文字列）：
The value of the label the client instance provided in the associated token request (Section 2.1), if present. REQUIRED for multiple access tokens or if a label was included in the single access token request; OPTIONAL for a single access token where no label was included in the request.
存在する場合、関連するトークン要求（セクション2.1）で提供されるクライアントインスタンスのラベルの値。複数のアクセストークンに必要な場合、または単一アクセストークンリクエストにラベルが含まれている場合。リクエストにラベルが含まれていなかった単一のアクセストークンのオプション。
manage (object):
管理（オブジェクト）：
Access information for the token management API for this access token. If provided, the client instance MAY manage its access token as described in Section 6. This management API is a function of the AS and is separate from the RS the client instance is requesting access to. OPTIONAL.
このアクセストークンのトークン管理APIのアクセス情報。提供されている場合、クライアントインスタンスはセクション6で説明されているようにアクセストークンを管理できます。この管理APIは、ASの関数であり、クライアントインスタンスがアクセスを要求しているRSとは別のものです。オプション。
access (array of objects/strings):
アクセス（オブジェクト/文字列の配列）：
A description of the rights associated with this access token, as defined in Section 8. If included, this MUST reflect the rights associated with the issued access token. These rights MAY vary from what was requested by the client instance. REQUIRED.
セクション8で定義されているように、このアクセストークンに関連する権利の説明。これは、発行されたアクセストークンに関連する権利を反映する必要があります。これらの権利は、クライアントインスタンスによって要求されたものとは異なる場合があります。必須。
expires_in (integer):
expires_in（integer）：
The number of seconds in which the access will expire. The client instance MUST NOT use the access token past this time. Note that the access token MAY be revoked by the AS or RS at any point prior to its expiration. OPTIONAL.
アクセスが期限切れになる秒数。クライアントインスタンスは、今回のアクセストークンを使用してはなりません。アクセストークンは、有効期限が切れる前の任意の時点でASまたはRSによって取り消される場合があることに注意してください。オプション。
key (object / string):
key（object / string）：
The key that the token is bound to, if different from the client instance's presented key. The key MUST be an object or string in a format described in Section 7.1. The client instance MUST be able to dereference or process the key information in order to be able to sign subsequent requests using the access token (Section 7.2). When the key is provided by value from the AS, the token shares some security properties with bearer tokens as discussed in Section 11.38. It is RECOMMENDED that keys returned for use with access tokens be key references as described in Section 7.1.1 that the client instance can correlate to its known keys. OPTIONAL.
クライアントインスタンスの提示キーとは異なる場合、トークンがバインドされるキー。キーは、セクション7.1で説明されている形式のオブジェクトまたは文字列でなければなりません。クライアントインスタンスは、アクセストークン（セクション7.2）を使用して後続のリクエストに署名できるように、重要な情報を再参照または処理できる必要があります。キーがASの値によって提供される場合、トークンはセクション11.38で説明したように、ベアラートークンといくつかのセキュリティプロパティを共有します。クライアントインスタンスが既知のキーと相関することができるセクション7.1.1で説明されているように、アクセストークンで使用するためにキーを返すことをお勧めします。オプション。
flags (array of strings):
フラグ（文字列の配列）：
A set of flags that represent attributes or behaviors of the access token issued by the AS. OPTIONAL.
ASによって発行されたアクセストークンの属性または動作を表すフラグのセット。オプション。
The value of the manage field is an object with the following properties:
マネージフィールドの値は、次のプロパティを持つオブジェクトです。
uri (string):
uri（string）：
The URI of the token management API for this access token. This URI MUST be an absolute URI. This URI MUST NOT include the value of the access token being managed or the value of the access token used to protect the URI. This URI SHOULD be different for each access token issued in a request. REQUIRED.
このアクセストークンのトークン管理APIのURI。このURIは絶対的なURIでなければなりません。このURIには、管理されているアクセストークンの値や、URIを保護するために使用されるアクセストークンの値を含めるべきではありません。このURIは、リクエストで発行されたアクセストークンごとに異なるはずです。必須。
access_token (object):
Access_Token（オブジェクト）：
A unique access token for continuing the request, called the "token management access token". The value of this property MUST be an object in the format specified in Section 3.2.1. This access token MUST be bound to the client instance's key used in the request (or its most recent rotation) and MUST NOT be a bearer token. As a consequence, the flags array of this access token MUST NOT contain the string bearer, and the key field MUST be omitted. This access token MUST NOT have a manage field. This access token MUST NOT have the same value as the token it is managing. The client instance MUST present the continuation access token in all requests to the continuation URI as described in Section 7.2. REQUIRED.
「トークン管理アクセストークン」と呼ばれるリクエストを継続するためのユニークなアクセストークン。このプロパティの値は、セクション3.2.1で指定された形式のオブジェクトでなければなりません。このアクセストークンは、リクエスト（または最新の回転）で使用されるクライアントインスタンスのキーにバインドする必要があり、ベアラートークンであってはなりません。結果として、このアクセストークンのフラグアレイには弦楽器が含まれていない必要があり、キーフィールドを省略する必要があります。このアクセストークンには、管理フィールドが必要です。このアクセストークンは、管理しているトークンと同じ値を持っている必要があります。クライアントインスタンスは、セクション7.2で説明されているように、継続URIへのすべての要求で継続アクセストークンを提示する必要があります。必須。
The values of the flags field defined by this specification are as follows:
この仕様で定義されたフラグフィールドの値は次のとおりです。
"bearer":
「ベアラー」：
Flag indicating whether the token is a bearer token, not bound to a key and proofing mechanism. If the bearer flag is present, the access token is a bearer token, and the key field in this response MUST be omitted. See Section 11.9 for additional considerations on the use of bearer tokens.
トークンがベアラートークンであるかどうかを示すフラグは、キーとプルーフメカニズムに縛られていないかどうかを示します。Bearerフラグが存在する場合、アクセストークンはベアラートークンであり、この応答の重要なフィールドを省略する必要があります。Bearer Tokensの使用に関する追加の考慮事項については、セクション11.9を参照してください。
"durable":
「耐久性」：
Flag indicating a hint of AS behavior on token rotation. If this flag is present, then the client instance can expect a previously issued access token to continue to work after it has been rotated (Section 6.1) or the underlying grant request has been modified (Section 5.3), resulting in the issuance of new access tokens. If this flag is omitted, the client instance can anticipate a given access token could stop working after token rotation or grant request modification. Note that a token flagged as durable can still expire or be revoked through any normal means.
トークン回転の行動のヒントを示すフラグ。このフラグが存在する場合、クライアントインスタンスは、以前に発行されたアクセストークンが回転した後も動作し続けることを期待できます（セクション6.1）または基礎となる助成金要求が変更され（セクション5.3）、新しいアクセスが発行されますトークン。このフラグが省略された場合、クライアントインスタンスは、トークンの回転または付与リクエストの変更後に、特定のアクセストークンが動作を停止する可能性があると予想できます。耐久性があるとフラグが付けられたトークンは、通常の手段では依然として期限切れになるか、取り消される可能性があることに注意してください。
Flag values MUST NOT be included more than once.
フラグの値を複数回含めてはなりません。
Additional flags can be defined by extensions using the "GNAP Access Token Flags" registry (Section 10.4).
追加のフラグは、「GNAPアクセストークンフラグ」レジストリ（セクション10.4）を使用して拡張機能によって定義できます。
If the bearer flag and the key field in this response are omitted, the token is bound to the key used by the client instance (Section 2.3) in its request for access. If the bearer flag is omitted and the key field is present, the token is bound to the key and proofing mechanism indicated in the key field. The means by which the AS determines how to bind an access token to a key other than that presented by the client instance are out of scope for this specification, but common practices include pre-registering specific keys in a static fashion.
この応答のBearerフラグとキーフィールドが省略されている場合、トークンは、アクセスの要求でクライアントインスタンス（セクション2.3）が使用するキーにバインドされます。Bearerフラグが省略され、キーフィールドが存在する場合、トークンはキーフィールドに示されているキーおよびプルーフメカニズムに結合します。アクセストークンをクライアントインスタンスによって提示されたもの以外のキーにバインドする方法を決定する手段は、この仕様の範囲外ですが、一般的なプラクティスには、静的な方法で特定のキーを事前登録することが含まれます。
The client software MUST reject any access token where the flags field contains the bearer flag and the key field is present with any value.
クライアントソフトウェアは、FlagsフィールドにBearerフラグが含まれており、キーフィールドに任意の価値が存在する場合、アクセストークンを拒否する必要があります。
The following non-normative example shows a single access token bound to the client instance's key used in the initial request. The access token has a management URI and has access to three described resources (one using an object and two described by reference strings).
次の非規範的な例は、最初のリクエストで使用されたクライアントインスタンスのキーにバインドされた単一のアクセストークンを示しています。アクセストークンには管理URIがあり、記述された3つのリソースにアクセスできます（1つはオブジェクトを使用し、2つは参照文字列で説明されています）。
NOTE: '\' line wrapping per RFC 8792
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
},
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"read", "dolphin-metadata"
]
}
The following non-normative example shows a single bearer access token with access to two described resources.
次の非規範的な例は、2つの記載されたリソースにアクセスできる単一のBEARER ACCESSトークンを示しています。
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"flags": ["bearer"],
"access": [
"finance", "medical"
]
}
If the client instance requested a single access token (Section 2.1.1), the AS MUST NOT respond with the structure for multiple access tokens.
クライアントインスタンスが単一のアクセストークン（セクション2.1.1）を要求した場合、ASは複数のアクセストークンの構造で応答しないでください。
If the client instance has requested multiple access tokens and the AS has granted at least one of them, the AS responds with the "access_token" field. The value of this field is a JSON array, the members of which are distinct access tokens as described in Section 3.2.1. Each object MUST have a unique label field, corresponding to the token labels chosen by the client instance in the request for multiple access tokens (Section 2.1.2).
クライアントインスタンスが複数のアクセストークンを要求し、ASが少なくとも1つを付与した場合、ASは「Access_Token」フィールドで応答します。このフィールドの値はJSONアレイであり、そのメンバーはセクション3.2.1で説明されているように異なるアクセストークンです。各オブジェクトには、複数のアクセストークンの要求でクライアントインスタンスが選択したトークンラベルに対応する一意のラベルフィールドが必要です（セクション2.1.2）。
In the following non-normative example, two tokens are issued under the names token1 and token2, and only the first token has a management URI associated with it.
次の非規範的な例では、2つのトークンがtoken1とtoken2という名前で発行され、最初のトークンのみがそれに関連付けられた管理URIを持っています。
NOTE: '\' line wrapping per RFC 8792
"access_token": [
{
"label": "token1",
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
},
"access": [ "finance" ]
},
{
"label": "token2",
"value": "UFGLO2FDAFG7VGZZPJ3IZEMN21EVU71FHCARP4J1",
"access": [ "medical" ]
}
}
Each access token corresponds to one of the objects in the access_token array of the client instance's request (Section 2.1.2).
各アクセストークンは、クライアントインスタンスのリクエスト（セクション2.1.2）のAccess_Token配列のオブジェクトの1つに対応しています。
The AS MAY refuse to issue one or more of the requested access tokens for any reason. In such cases, the refused token is omitted from the response, and all of the other issued access tokens are included in the response under their respective requested labels. If the client instance requested multiple access tokens (Section 2.1.2), the AS MUST NOT respond with a single access token structure, even if only a single access token is granted. In such cases, the AS MUST respond with a structure for multiple access tokens containing one access token.
ASは、何らかの理由で要求されたアクセストークンの1つ以上を発行することを拒否する場合があります。そのような場合、拒否されたトークンは応答から省略され、他のすべての発行されたアクセストークンは、それぞれの要求されたラベルの下で応答に含まれます。クライアントインスタンスが複数のアクセストークン（セクション2.1.2）を要求した場合、ASは、単一のアクセストークンのみが許可されていても、単一のアクセストークン構造で応答しないでください。そのような場合、ASは、1つのアクセストークンを含む複数のアクセストークンの構造で応答する必要があります。
"access_token": [
{
"label": "token2",
"value": "8N6BW7OZB8CDFONP219-OS9M2PMHKUR64TBRP1LT0",
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
},
"access": [ "fruits" ]
}
]
The parameters of each access token are separate. For example, each access token is expected to have a unique value and (if present) label, and each access token likely has different access rights associated with it. Each access token could also be bound to different keys with different proofing mechanisms.
各アクセストークンのパラメーターは個別です。たとえば、各アクセストークンには一意の値と（存在する場合）ラベルがあると予想され、各アクセストークンにはそれに関連する異なるアクセス権がある可能性があります。各アクセストークンは、さまざまなプルーフメカニズムを備えた異なるキーにバインドされる可能性もあります。
If the client instance has indicated a capability to interact with the RO in its request (Section 2.5) and the AS has determined that interaction is both supported and necessary, the AS responds to the client instance with any of the following values in the interact field of the response. There is no preference order for interaction modes in the response, and it is up to the client instance to determine which ones to use. All supported interaction methods are included in the same interact object.
クライアントインスタンスがROWとの対話能力（セクション2.5）と、相互作用がサポートされており、必要であると判断した場合、ASは、相互作用フィールドの次の値のいずれかでクライアントインスタンスに応答します。応答の。応答には相互作用モードの優先順序はありません。また、使用するものを決定するのはクライアントインスタンス次第です。サポートされているすべてのインタラクション方法は、同じ相互作用オブジェクトに含まれています。
redirect (string):
リダイレクト（文字列）：
Redirect to an arbitrary URI. REQUIRED if the redirect interaction start mode is possible for this request. See Section 3.3.1.
任意のURIにリダイレクトします。このリクエストにリダイレクトインタラクション開始モードが可能な場合は必要です。セクション3.3.1を参照してください。
app (string):
アプリ（文字列）：
Launch of an application URI. REQUIRED if the app interaction start mode is possible for this request. See Section 3.3.2.
アプリケーションURIの発売。このリクエストにアプリインタラクション開始モードが可能な場合は必要です。セクション3.3.2を参照してください。
user_code (string):
user_code（string）：
Display a short user code. REQUIRED if the user_code interaction start mode is possible for this request. See Section 3.3.3.
短いユーザーコードを表示します。このリクエストにuser_codeインタラクション開始モードが可能な場合に必要です。セクション3.3.3を参照してください。
user_code_uri (object):
user_code_uri（object）：
Display a short user code and URI. REQUIRED if the user_code_uri interaction start mode is possible for this request. Section 3.3.4
短いユーザーコードとURIを表示します。このリクエストにuser_code_uriインタラクションスタートモードが可能な場合に必要です。セクション3.3.4
finish (string):
仕上げ（文字列）：
A unique ASCII string value provided by the AS as a nonce. This is used by the client instance to verify the callback after interaction is completed. REQUIRED if the interaction finish method requested by the client instance is possible for this request. See Section 3.3.5.
AS AS AS NONCEによって提供される一意のASCII文字列値。これは、相互作用が完了した後にコールバックを検証するためにクライアントインスタンスによって使用されます。このリクエストには、クライアントインスタンスによって要求されたインタラクション仕上げ方法が可能である場合が必要です。セクション3.3.5を参照してください。
expires_in (integer):
expires_in（integer）：
The number of integer seconds after which this set of interaction responses will expire and no longer be usable by the client instance. If the interaction methods expire, the client MAY restart the interaction process for this grant request by sending an update (Section 5.3) with a new interaction request field (Section 2.5). OPTIONAL. If omitted, the interaction response modes returned do not expire but MAY be invalidated by the AS at any time.
この一連の相互作用応答のセットが期限切れになり、クライアントインスタンスによって使用されなくなります。相互作用方法が期限切れになった場合、クライアントは、新しいインタラクションリクエストフィールド（セクション2.5）を使用して更新（セクション5.3）を送信することにより、この助成金要求の相互作用プロセスを再開できます。オプション。省略した場合、返された相互作用応答モードは期限切れになりませんが、ASによっていつでも無効になる可能性があります。
Additional interaction mode responses can be defined in the "GNAP Interaction Mode Responses" registry (Section 10.13).
追加の相互作用モード応答は、「GNAP相互作用モード応答」レジストリ（セクション10.13）で定義できます。
The AS MUST NOT respond with any interaction mode that the client instance did not indicate in its request, and the AS MUST NOT respond with any interaction mode that the AS does not support. Since interaction responses include secret or unique information, the AS SHOULD respond to each interaction mode only once in an ongoing request, particularly if the client instance modifies its request (Section 5.3).
ASは、クライアントインスタンスがその要求で示さなかった相互作用モードで応答してはなりません。ASは、ASがサポートしていない相互作用モードで応答してはなりません。相互作用応答には秘密または一意の情報が含まれるため、特にクライアントインスタンスが要求を変更する場合（セクション5.3）、各インタラクションモードに継続的なリクエストで1回のみ応答するはずです。
The grant request MUST be in the _pending_ state to include this field in the response.
助成金要求は、応答にこのフィールドを含めるために_pending_状態でなければなりません。
If the client instance indicates that it can redirect to an arbitrary URI (Section 2.5.1.1) and the AS supports this mode for the client instance's request, the AS responds with the "redirect" field, which is a string containing the URI for the end user to visit. This URI MUST be unique for the request and MUST NOT contain any security-sensitive information such as user identifiers or access tokens.
クライアントインスタンスが任意のURI（セクション2.5.1.1）にリダイレクトし、ASがクライアントインスタンスの要求のこのモードをサポートできることを示している場合、ASは「リダイレクト」フィールドに応答します。訪問するエンドユーザー。このURIは、リクエストのために一意でなければならず、ユーザー識別子やアクセストークンなどのセキュリティに敏感な情報を含めてはなりません。
"interact": {
"redirect": "https://interact.example.com/4CF492MLVMSW9MKMXKHQ"
}
The URI returned is a function of the AS, but the URI itself MAY be completely distinct from the grant endpoint URI that the client instance uses to request access (Section 2), allowing an AS to separate its user-interaction functionality from its backend security functionality. The AS will need to dereference the specific grant request and its information from the URI alone. If the AS does not directly host the functionality accessed through the redirect URI, then the means for the interaction functionality to communicate with the rest of the AS are out of scope for this specification.
返されたURIはASの関数ですが、URI自体は、クライアントインスタンスがアクセスを要求するために使用する助成金エンドポイントURIとは完全に異なる場合があります（セクション2）。機能。ASは、特定の助成金リクエストとURIだけからの情報を再参照する必要があります。ASがリダイレクトURIを介してアクセスされる機能を直接ホストしていない場合、相互作用機能がこの仕様の範囲外である他のASと通信する手段。
The client instance sends the end user to the URI to interact with the AS. The client instance MUST NOT alter the URI in any way. The means for the client instance to send the end user to this URI are out of scope of this specification, but common methods include an HTTP redirect, launching the system browser, displaying a scannable code, or printing out the URI in an interactive console. See details of the interaction in Section 4.1.1.
クライアントインスタンスは、ASと対話するためにエンドユーザーをURIに送信します。クライアントインスタンスは、URIを決して変更してはなりません。クライアントインスタンスがエンドユーザーをこのURIに送信する手段はこの仕様の範囲外ですが、一般的な方法にはHTTPリダイレクト、システムブラウザーの起動、スキャン可能なコードの表示、インタラクティブコンソールのURIの印刷が含まれます。セクション4.1.1の相互作用の詳細を参照してください。
If the client instance indicates that it can launch an application URI (Section 2.5.1.2) and the AS supports this mode for the client instance's request, the AS responds with the "app" field, which is a string containing the URI for the client instance to launch. This URI MUST be unique for the request and MUST NOT contain any security-sensitive information such as user identifiers or access tokens.
クライアントインスタンスがアプリケーションURI（セクション2.5.1.2）を起動できることを示している場合、ASはクライアントインスタンスのリクエストのこのモードをサポートしています。発売するインスタンス。このURIは、リクエストのために一意でなければならず、ユーザー識別子やアクセストークンなどのセキュリティに敏感な情報を含めてはなりません。
"interact": {
"app": "https://app.example.com/launch?tx=4CF492MLV"
}
The means for the launched application to communicate with the AS are out of scope for this specification.
起動されたアプリケーションがこの仕様の範囲外であると通信する手段。
The client instance launches the URI as appropriate on its platform; the means for the client instance to launch this URI are out of scope of this specification. The client instance MUST NOT alter the URI in any way. The client instance MAY attempt to detect if an installed application will service the URI being sent before attempting to launch the application URI. See details of the interaction in Section 4.1.4.
クライアントインスタンスは、プラットフォームで適切にURIを起動します。クライアントインスタンスがこのURIを起動する手段は、この仕様の範囲外です。クライアントインスタンスは、URIを決して変更してはなりません。クライアントインスタンスは、アプリケーションURIを起動しようとする前に、インストールされたアプリケーションが送信されるURIにサービスを提供するかどうかを検出しようとする場合があります。セクション4.1.4の相互作用の詳細を参照してください。
If the client instance indicates that it can display a short, user-typeable code (Section 2.5.1.3) and the AS supports this mode for the client instance's request, the AS responds with a "user_code" field. This field is string containing a unique short code that the user can type into a web page. To facilitate usability, this string MUST consist only of characters that can be easily typed by the end user (such as ASCII letters or numbers) and MUST be processed by the AS in a case-insensitive manner (see Section 4.1.2). The string MUST be randomly generated so as to be unguessable by an attacker within the time it is accepted. The time in which this code will be accepted SHOULD be short lived, such as several minutes. It is RECOMMENDED that this code be between six and eight characters in length.
クライアントインスタンスが、短いユーザータイプ可能なコード（セクション2.5.1.3）を表示できることを示している場合、ASはクライアントインスタンスの要求にこのモードをサポートしている場合、ASは「user_code」フィールドで応答します。このフィールドは、ユーザーがWebページに入力できる一意の短いコードを含む文字列です。ユーザビリティを促進するには、この文字列は、エンドユーザー（ASCIIの文字や数字など）が簡単に入力できる文字でのみ構成され、ASがケースに依存しない方法で処理する必要があります（セクション4.1.2を参照）。文字列は、攻撃者が受け入れられるまでに装備できないようにランダムに生成する必要があります。このコードが受け入れられる時間は、数分など、短命である必要があります。このコードは、長さ6〜8文字の間であることをお勧めします。
"interact": {
"user_code": "A1BC3DFF"
}
The client instance MUST communicate the "user_code" value to the end user in some fashion, such as displaying it on a screen or reading it out audibly. This code is used by the interaction component of the AS as a means of identifying the pending grant request and does not function as an authentication factor for the RO.
クライアントインスタンスは、「user_code」値を何らかの方法でエンドユーザーに通信する必要があります。このコードは、保留中の助成金要求を識別する手段としてASの相互作用コンポーネントによって使用され、ROの認証係数としては機能しません。
The URI that the end user is intended to enter the code into MUST be stable, since the client instance is expected to have no means of communicating a dynamic URI to the end user at runtime.
クライアントインスタンスは実行時にエンドユーザーにダイナミックURIを通信する手段がないと予想されるため、エンドユーザーがコードを入力することを意図しているURIは安定している必要があります。
As this interaction mode is designed to facilitate interaction via a secondary device, it is not expected that the client instance redirect the end user to the URI where the code is entered. If the client instance is capable of communicating a short arbitrary URI to the end user for use with the user code, the client instance SHOULD instead use the "user_code_uri" mode (Section 2.5.1.4). If the client instance is capable of communicating a long arbitrary URI to the end user, such as through a scannable code, the client instance SHOULD use the "redirect" mode (Section 2.5.1.1) for this purpose, instead of or in addition to the user code mode.
このインタラクションモードは、セカンダリデバイスを介してインタラクションを容易にするように設計されているため、クライアントインスタンスがエンドユーザーをコードの入力でURIにリダイレクトすることは予想されません。クライアントインスタンスがユーザーコードで使用するために短い任意のURIをエンドユーザーに通信できる場合、クライアントインスタンスは代わりに「user_code_uri」モード（セクション2.5.1.4）を使用する必要があります。クライアントインスタンスがスキャン可能なコードを介してエンドユーザーに長い任意のURIを通信できる場合、クライアントインスタンスは、この目的のために、またはそれに加えて、この目的のために「リダイレクト」モード（セクション2.5.1.1）を使用する必要があります。ユーザーコードモード。
See details of the interaction in Section 4.1.2.
セクション4.1.2の相互作用の詳細を参照してください。
If the client instance indicates that it can display a short, user-typeable code (Section 2.5.1.3) and the AS supports this mode for the client instance's request, the AS responds with a "user_code_uri" object that contains the following members.
クライアントインスタンスが、短いユーザータイプ可能なコード（セクション2.5.1.3）を表示し、ASがクライアントインスタンスの要求にこのモードをサポートできることを示している場合、ASは次のメンバーを含む「user_code_uri」オブジェクトで応答します。
code (string):
コード（文字列）：
A unique short code that the end user can type into a provided URI. To facilitate usability, this string MUST consist only of characters that can be easily typed by the end user (such as ASCII letters or numbers) and MUST be processed by the AS in a case-insensitive manner (see Section 4.1.3). The string MUST be randomly generated so as to be unguessable by an attacker within the time it is accepted. The time in which this code will be accepted SHOULD be short lived, such as several minutes. It is RECOMMENDED that this code be between six and eight characters in length. REQUIRED.
エンドユーザーが提供されたURIに入力できる一意の短いコード。ユーザビリティを促進するには、この文字列は、エンドユーザー（ASCIIの文字や数字など）が簡単に入力できる文字でのみ構成され、ASがケースに依存しない方法で処理する必要があります（セクション4.1.3を参照）。文字列は、攻撃者が受け入れられるまでに装備できないようにランダムに生成する必要があります。このコードが受け入れられる時間は、数分など、短命である必要があります。このコードは、長さ6〜8文字の間であることをお勧めします。必須。
uri (string):
uri（string）：
The interaction URI that the client instance will direct the RO to. This URI MUST be short enough to be communicated to the end user by the client instance. It is RECOMMENDED that this URI be short enough for an end user to type in manually. The URI MUST NOT contain the code value. This URI MUST be an absolute URI. REQUIRED.
クライアントインスタンスがROに指示する相互作用URI。このURIは、クライアントインスタンスによってエンドユーザーに通信するのに十分な短くなければなりません。このURIは、エンドユーザーが手動で入力するのに十分短くすることをお勧めします。URIにはコード値が含まれてはなりません。このURIは絶対的なURIでなければなりません。必須。
"interact": {
"user_code_uri": {
"code": "A1BC3DFF",
"uri": "https://s.example/device"
}
}
The client instance MUST communicate the "code" to the end user in some fashion, such as displaying it on a screen or reading it out audibly. This code is used by the interaction component of the AS as a means of identifying the pending grant request and does not function as an authentication factor for the RO.
クライアントインスタンスは、画面に表示したり、聞こえたり読み出すなど、「コード」を何らかの方法でエンドユーザーに通信する必要があります。このコードは、保留中の助成金要求を識別する手段としてASの相互作用コンポーネントによって使用され、ROの認証係数としては機能しません。
The client instance MUST also communicate the URI to the end user. Since it is expected that the end user will continue interaction on a secondary device, the URI needs to be short enough to allow the end user to type or copy it to a secondary device without mistakes.
クライアントインスタンスは、URIをエンドユーザーに通信する必要があります。エンドユーザーはセカンダリデバイスでのインタラクションを継続することが予想されるため、URIはエンドユーザーが間違いなくそれをタイプまたはコピーすることができるほど短くする必要があります。
The URI returned is a function of the AS, but the URI itself MAY be completely distinct from the grant endpoint URI that the client instance uses to request access (Section 2), allowing an AS to separate its user-interaction functionality from its backend security functionality. If the AS does not directly host the functionality accessed through the given URI, then the means for the interaction functionality to communicate with the rest of the AS are out of scope for this specification.
返されたURIはASの関数ですが、URI自体は、クライアントインスタンスがアクセスを要求するために使用する助成金エンドポイントURIとは完全に異なる場合があります（セクション2）。機能。ASが指定されたURIを介してアクセスされる機能を直接ホストしていない場合、相互作用機能がこの仕様の範囲外である他のASと通信する手段。
See details of the interaction in Section 4.1.2.
セクション4.1.2の相互作用の詳細を参照してください。
If the client instance indicates that it can receive a post-interaction redirect or push at a URI (Section 2.5.2) and the AS supports this mode for the client instance's request, the AS responds with a finish field containing a nonce that the client instance will use in validating the callback as defined in Section 4.2.
クライアントインスタンスが、相互作用後リダイレクトを受け取るか、URIでプッシュできることを示している場合（セクション2.5.2）、ASがクライアントインスタンスの要求のこのモードをサポートしている場合、ASはクライアントのNONCEを含むフィニッシュフィールドで応答します。インスタンスは、セクション4.2で定義されているコールバックの検証に使用されます。
"interact": {
"finish": "MBDOFXG4Y5CVJCX821LH"
}
When the interaction is completed, the interaction component of the AS MUST contact the client instance using the means defined by the finish method as described in Section 4.2.
相互作用が完了すると、ASの相互作用コンポーネントは、セクション4.2で説明されているように、仕上げメソッドで定義された平均を使用してクライアントインスタンスに連絡する必要があります。
If the AS returns the finish field, the client instance MUST NOT continue a grant request before it receives the associated interaction reference on the callback URI. See details in Section 4.2.
ASがフィニッシュフィールドを返した場合、クライアントインスタンスは、コールバックURIの関連するインタラクションリファレンスを受信する前に助成金リクエストを継続してはなりません。セクション4.2の詳細を参照してください。
If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information in the "subject" response field. The AS MUST return the subject field only in cases where the AS is sure that the RO and the end user are the same party. This can be accomplished through some forms of interaction with the RO (Section 4).
ROに関する情報が要求され、ASがそのデータへのクライアントインスタンスアクセスを付与する場合、ASは「サブジェクト」応答フィールドの承認された情報を返します。ASは、ROとエンドユーザーが同じパーティであると確信している場合にのみ、サブジェクトフィールドを返す必要があります。これは、ROとの何らかの形の相互作用を通じて実現できます（セクション4）。
This field is an object with the following properties.
このフィールドは、次のプロパティを備えたオブジェクトです。
sub_ids (array of objects):
sub_ids（オブジェクトの配列）：
An array of Subject Identifiers for the RO, as defined by [RFC9493]. REQUIRED if returning Subject Identifiers.
[RFC9493]で定義されているROの被験者識別子の配列。被験者の識別子を返す場合が必要です。
assertions (array of objects):
アサーション（オブジェクトの配列）：
An array containing assertions as objects, each containing the assertion object described below. REQUIRED if returning assertions.
以下に説明するアサーションオブジェクトを含むオブジェクトとしてのアサーションを含む配列。アサーションを返す場合は必要です。
updated_at (string):
updated_at（string）：
Timestamp as a date string as described in [RFC3339], indicating when the identified account was last updated. The client instance MAY use this value to determine if it needs to request updated profile information through an identity API. The definition of such an identity API is out of scope for this specification. RECOMMENDED.
[RFC3339]で説明されている日付文字列としてのタイムスタンプ。特定されたアカウントが最後に更新された時期を示します。クライアントインスタンスは、この値を使用して、IDAPIを介して更新されたプロファイル情報を要求する必要があるかどうかを判断する場合があります。このようなIDAPIの定義は、この仕様の範囲外です。推奨。
Assertion objects contain the following fields:
アサーションオブジェクトには、次のフィールドが含まれています。
format (string):
フォーマット（文字列）：
The assertion format. Possible formats are listed in Section 3.4.1. Additional assertion formats can be defined in the "GNAP Assertion Formats" registry (Section 10.6). REQUIRED.
アサーション形式。可能な形式は、セクション3.4.1にリストされています。追加のアサーション形式は、「GNAPアサーション形式」レジストリ（セクション10.6）で定義できます。必須。
value (string):
値（文字列）：
The assertion value as the JSON string serialization of the assertion. REQUIRED.
JSON文字列のアサーションのシリアル化としてのアサーション値。必須。
The following non-normative example contains an opaque identifier and an OpenID Connect ID Token:
次の非規範的な例には、不透明な識別子とOpenID Connect IDトークンが含まれています。
"subject": {
"sub_ids": [ {
"format": "opaque",
"id": "XUT2MFM1XBIKJKSDU8QM"
} ],
"assertions": [ {
"format": "id_token",
"value": "eyj..."
} ]
}
Subject Identifiers returned by the AS SHOULD uniquely identify the RO at the AS. Some forms of Subject Identifiers are opaque to the client instance (such as the subject of an issuer and subject pair), while other forms (such as email address and phone number) are intended to allow the client instance to correlate the identifier with other account information at the client instance. The client instance MUST NOT request or use any returned Subject Identifiers for communication purposes (see Section 2.2). That is, a Subject Identifier returned in the format of an email address or a phone number only identifies the RO to the AS and does not indicate that the AS has validated that the represented email address or phone number in the identifier is suitable for communication with the current user. To get such information, the client instance MUST use an identity protocol to request and receive additional identity claims. The details of an identity protocol and associated schema are outside the scope of this specification.
ASによって返されたサブジェクト識別子は、ASでROを一意に識別する必要があります。サブジェクト識別子のいくつかの形式は、クライアントインスタンス（発行者やサブジェクトペアの主題など）に不透明ですが、他のフォーム（電子メールアドレスや電話番号など）は、クライアントインスタンスが識別子を他のアカウントと相関させることを目的としています。クライアントインスタンスでの情報。クライアントインスタンスは、通信目的で返されたサブジェクト識別子を要求または使用してはなりません（セクション2.2を参照）。つまり、電子メールアドレスまたは電話番号の形式で返されたサブジェクト識別子は、ASにROを識別するだけであり、ASが識別子の代表される電子メールアドレスまたは電話番号がとの通信に適していることを検証したことを示していません。現在のユーザー。そのような情報を取得するには、クライアントインスタンスはIDプロトコルを使用して追加のIDクレームを要求および受信する必要があります。IDプロトコルと関連するスキーマの詳細は、この仕様の範囲外です。
The AS MUST ensure that the returned subject information represents the RO. In most cases, the AS will also ensure that the returned subject information represents the end user authenticated interactively at the AS. The AS SHOULD NOT reuse Subject Identifiers for multiple different ROs.
ASは、返されたサブジェクト情報がROを表すことを確認する必要があります。ほとんどの場合、ASは、返されたサブジェクト情報がASでインタラクティブに認証されたエンドユーザーを表すことを保証します。ASは、複数の異なるROSの被験者識別子を再利用しないでください。
The "sub_ids" and "assertions" response fields are independent of each other. That is, a returned assertion MAY use a different Subject Identifier than other assertions and Subject Identifiers in the response. However, all Subject Identifiers and assertions returned MUST refer to the same party.
「sub_ids」および「assertions」応答フィールドは、互いに独立しています。つまり、返されたアサーションは、応答の他のアサーションおよび主題識別子とは異なる主題識別子を使用する場合があります。ただし、返されたすべての被験者識別子とアサーションは、同じ当事者を参照する必要があります。
The client instance MUST interpret all subject information in the context of the AS from which the subject information is received, as is discussed in Section 6 of [SP80063C]. For example, one AS could return an email identifier of "user@example.com" for one RO, and a different AS could return that same email identifier of "user@example.com" for a completely different RO. A client instance talking to both ASes needs to differentiate between these two accounts by accounting for the AS source of each identifier and not assuming that either has a canonical claim on the identifier without additional configuration and trust agreements. Otherwise, a rogue AS could exploit this to take over a targeted account asserted by a different AS.
クライアントインスタンスは、[SP80063C]のセクション6で説明するように、被験者情報の受信ASのコンテキストですべてのサブジェクト情報を解釈する必要があります。たとえば、1つのROの「user@example.com」の電子メール識別子を返すことができ、まったく異なるROの「user@example.com」の同じ電子メール識別子を返すことができるのは別のものです。両方のASEと話すクライアントインスタンスは、各識別子のソースを説明することにより、これら2つのアカウントを区別する必要があり、どちらも追加の構成と信頼契約なしに識別子に標準的な請求があると仮定しません。それ以外の場合、これを悪用して、別のASによって主張されたターゲットアカウントを引き継ぐことができます。
Extensions to this specification MAY define additional response properties in the "GNAP Subject Information Response Fields" registry (Section 10.14).
この仕様の拡張は、「GNAPサブジェクト情報応答フィールド」レジストリ（セクション10.14）の追加の応答プロパティを定義する場合があります。
The grant request MUST be in the _approved_ state to return this field in the response.
助成金要求は、応答でこのフィールドを返すために_Approved_状態にある必要があります。
See Section 11.30 for considerations that the client instance has to make when accepting and processing assertions from the AS.
ASからアサーションを受け入れて処理するときに、クライアントインスタンスが行わなければならない考慮事項については、セクション11.30を参照してください。
The following assertion formats are defined in this specification:
この仕様では、次のアサーション形式が定義されています。
id_token:
id_token：
An OpenID Connect ID Token [OIDC], in JSON Web Token (JWT) compact format as a single string.
JSON Web Token（JWT）コンパクト形式のOpenID Connect ID Token [OIDC]、単一の文字列として。
saml2:
SAML2：
A SAML 2.0 assertion [SAML2], encoded as a single base64url string with no padding.
SAML 2.0アサーション[SAML2]、パディングのない単一のbase64url文字列としてエンコードされています。
Many parts of the client instance's request can be passed as either a value or a reference. The use of a reference in place of a value allows for a client instance to optimize requests to the AS.
クライアントインスタンスの要求の多くの部分は、値または参照のいずれかとして渡すことができます。値の代わりに参照を使用すると、クライアントインスタンスがASにリクエストを最適化することができます。
Some references, such as for the client instance's identity (Section 2.3.1) or the requested resources (Section 8.1), can be managed statically through an admin console or developer portal provided by the AS or RS. The developer of the client software can include these values in their code for a more efficient and compact request.
クライアントインスタンスのID（セクション2.3.1）または要求されたリソース（セクション8.1）などのいくつかの参照は、ASまたはRSが提供する管理コンソールまたは開発者ポータルを介して静的に管理できます。クライアントソフトウェアの開発者は、より効率的でコンパクトなリクエストのために、これらの値をコードに含めることができます。
If desired, the AS MAY also generate and return an instance identifier dynamically to the client instance in the response to facilitate multiple interactions with the same client instance over time. The client instance SHOULD use this instance identifier in future requests in lieu of sending the associated data values in the client field.
必要に応じて、ASは、時間の経過とともに同じクライアントインスタンスとの複数の相互作用を促進するために、応答中にインスタンス識別子をクライアントインスタンスに動的に生成および返すこともできます。クライアントインスタンスは、クライアントフィールドに関連するデータ値を送信する代わりに、将来の要求でこのインスタンス識別子を使用する必要があります。
Dynamically generated client instance identifiers are string values that MUST be protected by the client instance as secrets. Instance identifier values MUST be unguessable and MUST NOT contain any information that would compromise any party if revealed. Instance identifier values are opaque to the client instance, and their content is determined by the AS. The instance identifier MUST be unique per client instance at the AS.
動的に生成されたクライアントインスタンス識別子は、秘密としてクライアントインスタンスによって保護する必要がある文字列値です。インスタンス識別子値は装備できない必要があり、明らかにされた場合、あらゆる当事者を侵害する情報を含めてはなりません。インスタンス識別子値はクライアントインスタンスに不透明であり、そのコンテンツはASによって決定されます。インスタンス識別子は、ASのクライアントインスタンスごとに一意でなければなりません。
instance_id (string):
instance_id（string）：
A string value used to represent the information in the client object that the client instance can use in a future request, as described in Section 2.3.1. OPTIONAL.
セクション2.3.1で説明されているように、クライアントインスタンスが将来の要求で使用できるクライアントオブジェクトの情報を表すために使用される文字列値。オプション。
The following non-normative example shows an instance identifier alongside an issued access token.
次の非規範的な例は、発行されたアクセストークンとともにインスタンス識別子を示しています。
{
"instance_id": "7C7C4AZ9KHRS6X63AJAO",
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0"
}
}
If the AS determines that the request cannot be completed for any reason, it responds to the client instance with an error field in the response message. This field is either an object or a string.
ASが要求を何らかの理由で完了できないと判断した場合、応答メッセージにエラーフィールドを使用してクライアントインスタンスに応答します。このフィールドは、オブジェクトまたは文字列のいずれかです。
When returned as an object, the object contains the following fields:
オブジェクトとして返されると、オブジェクトには次のフィールドが含まれます。
code (string):
コード（文字列）：
A single ASCII error code defining the error. The value MUST be defined in the "GNAP Error Codes" registry (Section 10.15). REQUIRED.
エラーを定義する単一のASCIIエラーコード。値は、「GNAPエラーコード」レジストリ（セクション10.15）で定義する必要があります。必須。
description (string):
説明（文字列）：
A human-readable string description of the error intended for the developer of the client. The value is chosen by the implementation. OPTIONAL.
クライアントの開発者向けのエラーの人間が読み取る文字列の説明。値は実装によって選択されます。オプション。
This specification defines the following code values:
この仕様では、次のコード値を定義します。
"invalid_request":
「invalid_request」：
The request is missing a required parameter, includes an invalid parameter value, or is otherwise malformed.
リクエストには、必要なパラメーターが欠落しているか、無効なパラメーター値が含まれているか、それ以外の場合は奇形です。
"invalid_client":
「Invalid_Client」：
The request was made from a client that was not recognized or allowed by the AS, or the client's signature validation failed.
リクエストは、ASによって認識または許可されていないクライアントから行われたか、クライアントの署名検証が失敗しました。
"invalid_interaction":
「Invalid_Interaction」：
The client instance has provided an interaction reference that is incorrect for this request, or the interaction modes in use have expired.
クライアントインスタンスは、このリクエストに対して間違った相互作用リファレンスを提供しているか、使用中のインタラクションモードが有効になっています。
"invalid_flag":
「Invalid_flag」：
The flag configuration is not valid.
フラグ構成は無効です。
"invalid_rotation":
「Invalid_rotation」：
The token rotation request is not valid.
トークン回転要求は無効です。
"key_rotation_not_supported":
「key_rotation_not_supported」：
The AS does not allow rotation of this access token's key.
ASは、このアクセストークンのキーの回転を許可しません。
"invalid_continuation":
「Invalid_Continuation」：
The continuation of the referenced grant could not be processed.
参照された助成金の継続は処理できませんでした。
"user_denied":
「user_denied」：
The RO denied the request.
ROは要求を否定しました。
"request_denied":
"request_denied"：
The request was denied for an unspecified reason.
この要求は、不特定の理由で拒否されました。
"unknown_user":
「不明_user」：
The user presented in the request is not known to the AS or does not match the user present during interaction.
リクエストで提示されたユーザーは、ASが知られていないか、インタラクション中に存在するユーザーと一致しません。
"unknown_interaction":
"nownowed_interaction"：
The interaction integrity could not be established.
相互作用の完全性を確立できませんでした。
"too_fast":
"too_fast"：
The client instance did not respect the timeout in the wait response before the next call.
クライアントインスタンスは、次の呼び出しの前に待機応答のタイムアウトを尊重しませんでした。
"too_many_attempts":
「Too_many_attempts」：
A limit has been reached in the total number of reasonable attempts. This number is either defined statically or adjusted based on runtime conditions by the AS.
合理的な試みの総数で制限に達しました。この数値は、ASによるランタイム条件に基づいて静的に定義されるか、調整されます。
Additional error codes can be defined in the "GNAP Error Codes" registry (Section 10.15).
追加のエラーコードは、「GNAPエラーコード」レジストリ（セクション10.15）で定義できます。
For example, if the RO denied the request while interacting with the AS, the AS would return the following error when the client instance tries to continue the grant request:
たとえば、ROがASと対話しながらリクエストを拒否した場合、ASはクライアントインスタンスが助成金リクエストを継続しようとすると、次のエラーを返します。
{
"error": {
"code": "user_denied",
"description": "The RO denied the request"
}
}
Alternatively, the AS MAY choose to only return the error as codes and provide the error as a string. Since the description field is not intended to be machine-readable, the following response is considered functionally equivalent to the previous example for the purposes of the client software's understanding:
あるいは、ASは、エラーをコードとしてのみ返すことを選択し、文字列としてエラーを提供することを選択します。説明フィールドは機械読み取り可能であることを意図していないため、次の応答は、クライアントソフトウェアの理解の目的のために、以前の例と機能的に同等であると考えられています。
{
"error": "user_denied"
}
If an error state is reached but the grant is in the _pending_ state (and therefore the client instance can continue), the AS MAY include the continue field in the response along with the error, as defined in Section 3.1. This allows the client instance to modify its request for access, potentially leading to prompting the RO again. Other fields MUST NOT be included in the response.
エラー状態に到達したが、助成金が_Pending_状態にある場合（したがってクライアントインスタンスは継続できます）、ASには、セクション3.1で定義されているように、エラーとともに応答の連続フィールドが含まれる場合があります。これにより、クライアントインスタンスがアクセスの要求を変更することができ、ROを再び促す可能性があります。他のフィールドを応答に含めてはなりません。
When the client instance makes its initial request (Section 2) to the AS for delegated access, it is capable of asking for several different kinds of information in response:
クライアントインスタンスが最初の要求（セクション2）を委任されたアクセスの場合、それに応じていくつかの異なる種類の情報を要求することができます。
* the access being requested, in the access_token request parameter
* Access_Tokenリクエストパラメーターで、アクセスが要求されています
* the subject information being requested, in the subject request parameter
* 件名リクエストパラメーターで要求されている主題情報
* any additional requested information defined by extensions of this protocol
* このプロトコルの拡張によって定義された追加の要求された情報
When the grant request is in the _processing_ state, the AS determines what authorizations and consents are required to fulfill this requested delegation. The details of how the AS makes this determination are out of scope for this document. However, there are several common patterns defined and supported by GNAP for fulfilling these requirements, including information sent by the client instance, information gathered through the interaction process, and information supplied by external parties. An individual AS can define its own policies and processes for deciding when and how to gather the necessary authorizations and consent and how those are applied to the grant request.
助成金要求が_processing_状態にある場合、この要求された代表団を満たすために必要な承認と同意が決定されます。ASがこの決定をどのように行うかの詳細は、このドキュメントの範囲外です。ただし、クライアントインスタンスから送信された情報、相互作用プロセスを通じて収集された情報、外部関係者が提供する情報など、これらの要件を満たすためにGNAPによって定義およびサポートされているいくつかの一般的なパターンがあります。個人は、必要な承認と同意を収集する時期を決定するための独自のポリシーとプロセスを定義できます。
To facilitate the AS fulfilling this request, the client instance sends information about the actions the client software can take, including:
この要求を満たすように促進するために、クライアントインスタンスは、以下を含むクライアントソフトウェアがとることができるアクションに関する情報を送信します。
* starting interaction with the end user, in the interact request parameter
* インタラクションリクエストパラメーターで、エンドユーザーとの相互作用を開始
* receiving notification that interaction with the RO has concluded, in the interact request parameter
* ROとの相互作用が結論付けたという通知を受信して、インタラクションリクエストパラメーターで
* any additional capabilities defined by extensions of this protocol
* このプロトコルの拡張によって定義された追加の機能
The client instance can also supply information directly to the AS in its request. The client instance can send several kinds of things, including:
クライアントインスタンスは、そのリクエストでASに直接情報を提供することもできます。クライアントインスタンスは、次のようないくつかの種類のものを送信できます。
* the identity of the client instance, known from the keys or identifiers in the client request parameter
* クライアントリクエストパラメーターのキーまたは識別子から認識されているクライアントインスタンスのID
* the identity of the end user, in the user request parameter
* ユーザーリクエストパラメーターでのエンドユーザーの身元
* any additional information presented by the client instance in the request defined by extensions of this protocol
* このプロトコルの拡張によって定義されたリクエストにクライアントインスタンスによって提示された追加情報
The AS will process this presented information in the context of the client instance's request and can only trust the information as much as it trusts the presentation and context of that request. If the AS determines that the information presented in the initial request is sufficient for granting the requested access, the AS MAY move the grant request to the _approved_ state and return results immediately in its response (Section 3) with access tokens and subject information.
ASは、クライアントインスタンスのリクエストのコンテキストで提示された情報を処理し、その要求のプレゼンテーションとコンテキストを信頼するのと同じくらい、情報を信頼することができます。ASが最初のリクエストで提示された情報が要求されたアクセスを付与するのに十分であると判断した場合、ASは_Approved_状態に付与要求を移動し、アクセストークンとサブジェクト情報を使用してその応答（セクション3）ですぐに結果を返すことができます。
If the AS determines that additional runtime authorization is required, the AS can either deny the request outright (if there is no possible recovery) or move the grant request to the _pending_ state and use a number of means at its disposal to gather that authorization from the appropriate ROs, including:
追加のランタイム承認が必要であると判断した場合、ASはリクエストを完全に拒否するか（回復不可能な場合）、_Pending_状態に助成金リクエストを移動し、その許可を自由に使用するために多くの手段を使用して、その認可を収集します。適切なROSを含む：
* starting interaction with the end user facilitated by the client software, such as a redirection or user code
* リダイレクトやユーザーコードなど、クライアントソフトウェアによって促進されたエンドユーザーとのやり取りの開始
* challenging the client instance through a challenge-response mechanism
* チャレンジ応答メカニズムを通じてクライアントインスタンスに挑戦します
* requesting that the client instance present specific additional information, such as a user's credential or an assertion
* クライアントインスタンスがユーザーの資格情報やアサーションなどの特定の追加情報を提示するよう要求する
* contacting an RO through an out-of-band mechanism, such as a push notification
* プッシュ通知など、バンド外のメカニズムを介してROに連絡する
* executing an auxiliary software process through an out-of-band mechanism, such as querying a digital wallet
* デジタルウォレットのクエリなど、帯域外のメカニズムを介して補助ソフトウェアプロセスを実行する
The process of gathering authorization and consent in GNAP is left deliberately flexible to allow for a wide variety of different deployments, interactions, and methodologies. In this process, the AS can gather consent from the RO or apply the RO's policy as necessitated by the access that has been requested. The AS can sometimes determine which RO needs to prompt for consent based on what has been requested by the client instance, such as a specific RS record, an identified subject, or a request requiring specific access such as approval by an administrator. In other cases, the request is applied to whichever RO is present at the time of consent gathering. This pattern is especially prevalent when the end user is sent to the AS for an interactive session, during which the end user takes on the role of the RO. In these cases, the end user is delegating their own access as RO to the client instance.
GNAPでの許可と同意を収集するプロセスは、さまざまな展開、相互作用、および方法論を可能にするために、意図的に柔軟なままにされています。このプロセスでは、ASはROから同意を集めたり、要求されたアクセスによって必要なROのポリシーを適用したりできます。ASは、特定のRSレコード、識別された主題、または管理者による承認などの特定のアクセスを必要とするリクエストなど、クライアントインスタンスによって要求されたものに基づいて同意を求める必要があるROを時々決定できます。それ以外の場合、リクエストは、同意の収集時にROが存在する場合でも適用されます。このパターンは、エンドユーザーがインタラクティブセッションのためにASに送信されると、特に一般的です。その間、エンドユーザーはROの役割を引き受けます。これらの場合、エンドユーザーは、クライアントインスタンスへのROとして独自のアクセスを委任しています。
The client instance can indicate that it is capable of facilitating interaction with the end user, another party, or another piece of software through its interaction start request (Section 2.5.1). Here, the AS usually needs to interact directly with the end user to determine their identity, determine their status as an RO, and collect their consent. If the AS has determined that authorization is required and the AS can support one or more of the requested interaction start methods, the AS returns the associated interaction start responses (Section 3.3). The client instance SHOULD initiate one or more of these interaction methods (Section 4.1) in order to facilitate the granting of the request. If more than one interaction start method is available, the means by which the client chooses which methods to follow are out of scope of this specification.
クライアントインスタンスは、インタラクションスタートリクエストを使用して、エンドユーザー、別のパーティ、または別のソフトウェアとの相互作用を促進できることを示すことができます（セクション2.5.1）。ここでは、通常、エンドユーザーと直接対話してアイデンティティを決定し、ROとしてのステータスを決定し、同意を収集する必要があります。ASが許可が必要であると判断し、ASが要求されたインタラクション開始方法の1つ以上をサポートできる場合、ASは関連するインタラクション開始応答を返します（セクション3.3）。クライアントインスタンスは、リクエストの付与を促進するために、これらの相互作用方法の1つ以上（セクション4.1）を開始する必要があります。複数のインタラクション開始方法が利用可能な場合、クライアントが従うべき方法を選択する手段は、この仕様の範囲外です。
After starting interaction, the client instance can then make a continuation request (Section 5) either in response to a signal indicating the finish of the interaction (Section 4.2), after a time-based polling, or through some other method defined by an extension of this specification through the "GNAP Interaction Mode Responses" registry (Section 10.13).
相互作用を開始した後、クライアントインスタンスは、相互作用の終了（セクション4.2）を示す信号（セクション4.2）に応答して、拡張で定義された他の方法を介して、継続要求（セクション5）を作成できます（セクション5）。この仕様の「GNAPインタラクションモード応答」レジストリ（セクション10.13）。
If the grant request is not in the _approved_ state, the client instance can repeat the interaction process by sending a grant update request (Section 5.3) with new interaction methods (Section 2.5).
助成金要求が_Approved_状態にない場合、クライアントインスタンスは、新しいインタラクション方法（セクション2.5）を使用して助成金アップデートリクエスト（セクション5.3）を送信することにより、相互作用プロセスを繰り返すことができます。
The client instance MUST use each interaction method once at most if a response can be detected. The AS MUST handle any interact request as a one-time-use mechanism and SHOULD apply suitable timeouts to any interaction start methods provided, including user codes and redirection URIs. The client instance SHOULD apply suitable timeouts to any interaction finish method.
クライアントインスタンスは、応答を検出できる場合は、各インタラクションメソッドをせいぜい最大で使用する必要があります。ASは、任意の任意のリクエストを1回限りのメカニズムとして処理する必要があり、ユーザーコードやリダイレクトURIを含む、提供された任意のインタラクション開始方法に適切なタイムアウトを適用する必要があります。クライアントインスタンスは、任意のインタラクション仕上げ方式に適切なタイムアウトを適用する必要があります。
In order to support client software deployed in disadvantaged network conditions, the AS MAY allow for processing of the same interaction method multiple times if the AS can determine that the request is from the same party and the results are idempotent. For example, if a client instance launches a redirect to the AS but does not receive a response within a reasonable time, the client software can launch the redirect again, assuming that it never reached the AS in the first place. However, if the AS in question receives both requests, it could mistakenly process them separately, creating an undefined state for the client instance. If the AS can determine that both requests come from the same origin or under the same session, and the requests both came before any additional state change to the grant occurs, the AS can reasonably conclude that the initial response was not received and the same response can be returned to the client instance.
恵まれないネットワーク条件で展開されたクライアントソフトウェアをサポートするために、ASは、同じ当事者からの要求であり、結果が等量であると判断できる場合、同じ相互作用方法の処理を複数回処理できる場合があります。たとえば、クライアントインスタンスがASへのリダイレクトを起動したが、合理的な時間内に応答を受信しない場合、クライアントソフトウェアは、最初にASに到達しなかったと仮定して、リダイレクトを再度起動できます。ただし、問題のASが両方の要求を受信した場合、それらを誤って個別に処理し、クライアントインスタンスに未定義の状態を作成する可能性があります。両方のリクエストが同じ起源または同じセッションの下で行われ、追加の州の変更が発生する前に両方のリクエストが来たと判断できる場合、Asは、最初の応答が受信されなかったと同じ応答を合理的に結論付けることができますクライアントインスタンスに返すことができます。
If the AS instead has a means of contacting the RO directly, it could do so without involving the client instance in its consent-gathering process. For example, the AS could push a notification to a known RO and have the RO approve the pending request asynchronously. These interactions can be through an interface of the AS itself (such as a hosted web page), through another application (such as something installed on the RO's device), through a messaging fabric, or any other means.
ASが代わりにROに直接連絡する手段がある場合、クライアントインスタンスを同意収集プロセスに巻き込むことなくそうすることができます。たとえば、通知を既知のROにプッシュし、ROに保留中の要求を非同期に承認させる可能性があります。これらの相互作用は、AS自体（ホストされたWebページなど）のインターフェイス、別のアプリケーション（ROのデバイスにインストールされているものなど）、メッセージングファブリック、またはその他の手段を介して行うことができます。
When interacting with an RO, the AS can use various strategies to determine the authorization of the requested grant, including:
ROと対話する場合、ASはさまざまな戦略を使用して、次のような要求された助成金の承認を決定できます。
* authenticate the RO through a local account or some other means, such as federated login
* ローカルアカウントまたはフェデレーションログインなどのその他の手段を介してROを認証する
* validate the RO through presentation of claims, attributes, or other information
* 請求、属性、またはその他の情報の提示を通じてROを検証する
* prompt the RO for consent for the requested delegation
* ROに要求された代表団の同意を求めます
* describe to the RO what information is being released, to whom, and for what purpose
* どの情報が公開されているか、誰に、どのような目的のために、ROに説明してください
* provide warnings to the RO about potential attacks or negative effects of allowing the information
* 情報を許可することの潜在的な攻撃または悪影響についての警告をROに提供する
* allow the RO to modify the client instance's requested access, including limiting or expanding that access
* ROがクライアントインスタンスの要求されたアクセスを変更してもらい、そのアクセスの制限または拡張を含む
* provide the RO with artifacts such as receipts to facilitate an audit trail of authorizations
* 承認の監査証跡を容易にするために、領収書などのアーティファクトをROに提供する
* allow the RO to deny the requested delegation
* ROが要求された代表団を拒否してもらう
The AS is also allowed to request authorization from more than one RO, if the AS deems fit. For example, a medical record might need to be released by both an attending nurse and a physician, or both owners of a bank account need to sign off on a transfer request. Alternatively, the AS could require N of M possible ROs to approve a given request. In some circumstances, the AS could even determine that the end user present during the interaction is not the appropriate RO for a given request and reach out to the appropriate RO asynchronously.
ASが適切な場合、複数のROから認可を要求することも許可されています。たとえば、医療記録は、出席看護師と医師の両方によって釈放される必要がある場合があります。銀行口座の所有者の両方は、譲渡要求に登録する必要があります。あるいは、特定のリクエストを承認するために、Mの可能なROSのNを必要とする可能性があります。状況によっては、インタラクション中に存在するエンドユーザーが特定の要求に適したROではなく、適切なROに非同期に手を差し伸べることさえ判断することさえできます。
The RO is also allowed to define an automated policy at the AS to determine which kind of end user can get access to the resource and under which conditions. For instance, such a condition might require the end user to log in and accept the RO's legal provisions. Alternatively, client software could be acting without an end user, and the RO's policy allows issuance of access tokens to specific instances of that client software without human interaction.
また、ROは、どの種類のエンドユーザーがリソースにアクセスできるか、どの条件にアクセスできるかを決定するために、自動化されたポリシーを定義することも許可されています。たとえば、このような条件では、エンドユーザーがROの法的規定をログインして受け入れる必要がある場合があります。あるいは、クライアントソフトウェアはエンドユーザーなしで行動する可能性があり、ROのポリシーにより、人間の相互作用なしにそのクライアントソフトウェアの特定のインスタンスへのアクセストークンの発行が可能になります。
While all of these cases are supported by GNAP, the details of their implementation and the methods for determining which ROs or related policies are required for a given request are out of scope for this specification.
これらのケースはすべてGNAPによってサポートされていますが、実装の詳細と、特定の要求に必要なROSまたは関連するポリシーを決定する方法は、この仕様の範囲外です。
When a grant request is in the _pending_ state, the interaction start methods sent by the client instance can be used to facilitate interaction with the end user. To initiate an interaction start method indicated by the interaction start responses (Section 3.3) from the AS, the client instance follows the steps defined by that interaction start mode. The actions of the client instance required for the interaction start modes defined in this specification are described in the following subsections. Interaction start modes defined in extensions to this specification MUST define the expected actions of the client software when that interaction start mode is used.
助成金リクエストが_Pending_状態にある場合、クライアントインスタンスによって送信されたインタラクション開始方法を使用して、エンドユーザーとの対話を促進できます。ASからのインタラクション開始応答（セクション3.3）で示されるインタラクション開始方法を開始するには、クライアントインスタンスは、そのインタラクション開始モードで定義されたステップに従います。この仕様で定義されているインタラクション開始モードに必要なクライアントインスタンスのアクションは、以下のサブセクションで説明されています。この仕様の拡張で定義されたインタラクション開始モードは、そのインタラクション開始モードを使用したときにクライアントソフトウェアの予想アクションを定義する必要があります。
If the client instance does not start an interaction start mode within an AS-determined amount of time, the AS MUST reject attempts to use the interaction start modes. If the client instance has already begun one interaction start mode and the interaction has been successfully completed, the AS MUST reject attempts to use other interaction start modes. For example, if a user code has been successfully entered for a grant request, the AS will need to reject requests to an arbitrary redirect URI on the same grant request in order to prevent an attacker from capturing and altering an active authorization process.
クライアントインスタンスが決定された時間内にインタラクション開始モードを起動しない場合、ASはインタラクション開始モードを使用する試みを拒否する必要があります。クライアントインスタンスが既に1つのインタラクション開始モードを開始し、インタラクションが正常に完了している場合、ASは他のインタラクションスタートモードを使用する試みを拒否する必要があります。たとえば、助成金リクエストのためにユーザーコードが正常に入力された場合、ASは、攻撃者がアクティブな承認プロセスをキャプチャして変更するのを防ぐために、同じ助成金リクエストでURIをリダイレクトする要求を拒否する必要があります。
When the end user is directed to an arbitrary URI through the "redirect" mode (Section 3.3.1), the client instance facilitates opening the URI through the end user's web browser. The client instance could launch the URI through the system browser, provide a clickable link, redirect the user through HTTP response codes, or display the URI in a form the end user can use to launch, such as a multidimensional barcode. In all cases, the URI is accessed with an HTTP GET request, and the resulting page is assumed to allow direct interaction with the end user through an HTTP user agent. With this method, it is common (though not required) for the RO to be the same party as the end user, since the client instance has to communicate the redirection URI to the end user.
エンドユーザーが「リダイレクト」モード（セクション3.3.1）を介して任意のURIに向けられると、クライアントインスタンスはエンドユーザーのWebブラウザーを介してURIを開くことが容易になります。クライアントインスタンスは、システムブラウザを介してURIを起動したり、クリック可能なリンクを提供したり、HTTP応答コードを介してユーザーをリダイレクトしたり、エンドユーザーがマルチディジェンションバーコードなどの起動に使用できる形式でURIを表示したりできます。すべての場合において、URIにはHTTP GETリクエストでアクセスされ、結果のページはHTTPユーザーエージェントを介してエンドユーザーと直接対話できると想定されています。この方法では、クライアントインスタンスがリダイレクトURIをエンドユーザーに通信する必要があるため、ROがエンドユーザーと同じパーティになることは一般的です（必須ではありませんが）。
In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and interactively provide consent. The URI value is used to identify the grant request being authorized. If the URI cannot be associated with a currently active request, the AS MUST display an error to the RO and MUST NOT attempt to redirect the RO back to any client instance, even if a redirect finish method is supplied (Section 2.5.2.1). If the URI is not hosted by the AS directly, the means of communication between the AS and the service provided by this URI are out of scope for this specification.
多くの場合、URIはASでホストされているWebページを示しており、ASがエンドユーザーをROとして認証し、インタラクティブな同意を提供することを可能にします。URI値は、許可されている助成金要求を識別するために使用されます。URIが現在アクティブな要求に関連付けられない場合、ASはROにエラーを表示する必要があり、リダイレクト仕上げメソッドが提供されていても、ROをクライアントインスタンスにリダイレクトしようとしてはなりません（セクション2.5.2.1）。URIがASの直接によってホストされていない場合、このURIが提供するASとサービスの間の通信手段は、この仕様の範囲外です。
The client instance MUST NOT modify the URI when launching it; in particular, the client instance MUST NOT add any parameters to the URI. The URI MUST be reachable from the end user's browser, though the URI MAY be opened on a separate device from the client instance itself. The URI MUST be accessible from an HTTP GET request, and it MUST be protected by HTTPS, be hosted on a server local to the RO's browser ("localhost"), or use an application-specific URI scheme that is loaded on the end user's device.
クライアントインスタンスは、URIを起動するときに変更してはなりません。特に、クライアントインスタンスはURIにパラメーターを追加してはなりません。URIはエンドユーザーのブラウザから到達可能でなければなりませんが、URIはクライアントインスタンス自体から別のデバイスで開かれる場合があります。URIはHTTP GETリクエストからアクセスできる必要があり、HTTPSによって保護するか、ROのブラウザのローカルサーバーでホストする必要があります（ "localhost"）、またはエンドユーザーにロードされるアプリケーション固有のURIスキームを使用する必要があります。デバイス。
When the end user is directed to enter a short code through the "user_code" mode (Section 3.3.3), the client instance communicates the user code to the end user and directs the end user to enter that code at an associated URI. The client instance MAY format the user code in such a way as to facilitate memorability and transfer of the code, so long as this formatting does not alter the value as accepted at the user code URI. For example, a client instance receiving the user code "A1BC3DFF" could choose to display this to the user as "A1BC 3DFF", breaking up the long string into two shorter strings.
エンドユーザーが「user_code」モード（セクション3.3.3）を介して短いコードを入力するように指示されると、クライアントインスタンスはユーザーコードをエンドユーザーに通知し、エンドユーザーに関連するURIでそのコードを入力するよう指示します。クライアントインスタンスは、ユーザーコードURIで受け入れられているようにこのフォーマットが値を変更しない限り、コードの記憶性と転送を促進するような方法でユーザーコードをフォーマットする場合があります。たとえば、ユーザーコード「A1BC3DFF」を受信するクライアントインスタンスは、これを「A1BC 3DFF」としてユーザーに表示することを選択し、長い文字列を2つの短い文字列に分割します。
When processing input codes, the AS MUST transform the input string to remove invalid characters. In the above example, the space in between the two parts would be removed upon its entry into the interactive form at the user code URI. Additionally, the AS MUST treat user input as case insensitive. For example, if the user inputs the string "a1bc 3DFF", the AS will treat the input the same as "A1BC3DFF". To facilitate this, it is RECOMMENDED that the AS use only ASCII letters and numbers as valid characters for the user code.
入力コードを処理する場合、ASは入力文字列を変換して無効な文字を削除する必要があります。上記の例では、2つの部分の間のスペースが、ユーザーコードURIのインタラクティブフォームへのエントリと削除されます。さらに、ASはユーザー入力をケースの鈍感として扱う必要があります。たとえば、ユーザーが文字列「A1BC 3DFF」を入力すると、ASは「A1BC3DFF」と同じ入力を扱います。これを容易にするために、AS ASの使用は、ユーザーコードの有効な文字としてASCIIの文字と数字のみを使用することをお勧めします。
It is RECOMMENDED that the AS choose from character values that are easily copied and typed without ambiguity. For example, some glyphs have multiple Unicode code points for the same visual character, and the end user could potentially type a different character than what the AS has returned. For additional considerations of internationalized character strings, see [RFC8264].
あいまいさなく簡単にコピーされて入力される文字値から選択することをお勧めします。たとえば、一部のグリフには同じ視覚文字の複数のユニコードコードポイントがあり、エンドユーザーはASが返されたものとは異なる文字を入力する可能性があります。国際化された文字列の追加考慮事項については、[RFC8264]を参照してください。
This mode is designed to be used when the client instance is not able to communicate or facilitate launching an arbitrary URI. The associated URI could be statically configured with the client instance or in the client software's documentation. As a consequence, these URIs SHOULD be short. The user code URI MUST be reachable from the end user's browser, though the URI is usually opened on a separate device from the client instance itself. The URI MUST be accessible from an HTTP GET request, and it MUST be protected by HTTPS, be hosted on a server local to the RO's browser ("localhost"), or use an application-specific URI scheme that is loaded on the end user's device.
このモードは、クライアントインスタンスが任意のURIの起動を通信または促進できない場合に使用するように設計されています。関連するURIは、クライアントインスタンスまたはクライアントソフトウェアのドキュメントで静的に構成できます。結果として、これらのURIは短いはずです。ユーザーコードURIは、エンドユーザーのブラウザから到達可能でなければなりませんが、通常、URIはクライアントインスタンス自体とは別のデバイスで開かれています。URIはHTTP GETリクエストからアクセスできる必要があり、HTTPSによって保護するか、ROのブラウザのローカルサーバーでホストする必要があります（ "localhost"）、またはエンドユーザーにロードされるアプリケーション固有のURIスキームを使用する必要があります。デバイス。
In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and interactively provide consent. The value of the user code is used to identify the grant request being authorized. If the user code cannot be associated with a currently active request, the AS MUST display an error to the RO and MUST NOT attempt to redirect the RO back to any client instance, even if a redirect finish method is supplied (Section 2.5.2.1). If the interaction component at the user code URI is not hosted by the AS directly, the means of communication between the AS and this URI, including communication of the user code itself, are out of scope for this specification.
多くの場合、URIはASでホストされているWebページを示しており、ASがエンドユーザーをROとして認証し、インタラクティブな同意を提供することを可能にします。ユーザーコードの値は、許可されている助成金要求を識別するために使用されます。ユーザーコードが現在アクティブな要求に関連付けられていない場合、ASはROにエラーを表示する必要があり、リダイレクト仕上げメソッドが提供された場合でも、ROをクライアントインスタンスにリダイレクトしようとしてはなりません（セクション2.5.2.1）。ユーザーコードURIの相互作用コンポーネントがASによって直接ホストされていない場合、ASとこのURI間の通信の手段は、ユーザーコード自体の通信を含め、この仕様の範囲外です。
When the RO enters this code at the user code URI, the AS MUST uniquely identify the pending request that the code was associated with. If the AS does not recognize the entered code, the interaction component MUST display an error to the user. If the AS detects too many unrecognized code enter attempts, the interaction component SHOULD display an error to the user indicating too many attempts and MAY take additional actions such as slowing down the input interactions. The user should be warned as such an error state is approached, if possible.
ROがユーザーコードURIでこのコードを入力すると、ASはコードが関連付けられている保留中の要求を一意に識別する必要があります。ASが入力されたコードを認識していない場合、インタラクションコンポーネントはユーザーにエラーを表示する必要があります。ASが認識されていないコードが多すぎると試みを検出した場合、インタラクションコンポーネントはユーザーにエラーを表示し、あまりにも多くの試みを示し、入力インタラクションの遅延などの追加アクションを実行する可能性があります。可能であれば、そのようなエラー状態にアプローチされるため、ユーザーは警告する必要があります。
When the end user is directed to enter a short code through the "user_code_uri" mode (Section 3.3.4), the client instance communicates the user code and associated URI to the end user and directs the end user to enter that code at the URI. The client instance MAY format the user code in such a way as to facilitate memorability and transfer of the code, so long as this formatting does not alter the value as accepted at the user code URI. For example, a client instance receiving the user code "A1BC3DFF" could choose to display this to the user as "A1BC 3DFF", breaking up the long string into two shorter strings.
エンドユーザーが「user_code_uri」モード（セクション3.3.4）を介して短いコードを入力するように指示されると、クライアントインスタンスはユーザーコードと関連するURIをエンドユーザーに伝え、エンドユーザーにURIにそのコードを入力するよう指示します。クライアントインスタンスは、ユーザーコードURIで受け入れられているようにこのフォーマットが値を変更しない限り、コードの記憶性と転送を促進するような方法でユーザーコードをフォーマットする場合があります。たとえば、ユーザーコード「A1BC3DFF」を受信するクライアントインスタンスは、これを「A1BC 3DFF」としてユーザーに表示することを選択し、長い文字列を2つの短い文字列に分割します。
When processing input codes, the AS MUST transform the input string to remove invalid characters. In the above example, the space in between the two parts would be removed upon its entry into the interactive form at the user code URI. Additionally, the AS MUST treat user input as case insensitive. For example, if the user inputs the string "a1bc 3DFF", the AS will treat the input the same as "A1BC3DFF". To facilitate this, it is RECOMMENDED that the AS use only ASCII letters and numbers as valid characters for the user code.
入力コードを処理する場合、ASは入力文字列を変換して無効な文字を削除する必要があります。上記の例では、2つの部分の間のスペースが、ユーザーコードURIのインタラクティブフォームへのエントリと削除されます。さらに、ASはユーザー入力をケースの鈍感として扱う必要があります。たとえば、ユーザーが文字列「A1BC 3DFF」を入力すると、ASは「A1BC3DFF」と同じ入力を扱います。これを容易にするために、AS ASの使用は、ユーザーコードの有効な文字としてASCIIの文字と数字のみを使用することをお勧めします。
This mode is used when the client instance is not able to facilitate launching a complex arbitrary URI but can communicate arbitrary values like URIs. As a consequence, these URIs SHOULD be short enough to allow the URI to be typed by the end user, such as a total length of 20 characters or fewer. The client instance MUST NOT modify the URI when communicating it to the end user; in particular the client instance MUST NOT add any parameters to the URI. The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself. The URI MUST be accessible from an HTTP GET request, and it MUST be protected by HTTPS, be hosted on a server local to the RO's browser ("localhost"), or use an application-specific URI scheme that is loaded on the end user's device.
このモードは、クライアントインスタンスが複雑な任意のURIの起動を容易にすることができないが、URIのような任意の値を通信できる場合に使用されます。結果として、これらのURIは、総長さ20文字以下など、URIをエンドユーザーによって入力できるようにするのに十分な短いはずです。クライアントインスタンスは、URIをエンドユーザーに通信するときに変更してはなりません。特に、クライアントインスタンスはURIにパラメーターを追加してはなりません。ユーザーコードURIはエンドユーザーのブラウザから到達可能でなければなりませんが、通常、URIはクライアントインスタンス自体とは別のデバイスで開かれます。URIはHTTP GETリクエストからアクセスできる必要があり、HTTPSによって保護するか、ROのブラウザのローカルサーバーでホストする必要があります（ "localhost"）、またはエンドユーザーにロードされるアプリケーション固有のURIスキームを使用する必要があります。デバイス。
In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and interactively provide consent. The value of the user code is used to identify the grant request being authorized. If the user code cannot be associated with a currently active request, the AS MUST display an error to the RO and MUST NOT attempt to redirect the RO back to any client instance, even if a redirect finish method is supplied (Section 2.5.2.1). If the interaction component at the user code URI is not hosted by the AS directly, the means of communication between the AS and this URI, including communication of the user code itself, are out of scope for this specification.
多くの場合、URIはASでホストされているWebページを示しており、ASがエンドユーザーをROとして認証し、インタラクティブな同意を提供することを可能にします。ユーザーコードの値は、許可されている助成金要求を識別するために使用されます。ユーザーコードが現在アクティブな要求に関連付けられていない場合、ASはROにエラーを表示する必要があり、リダイレクト仕上げメソッドが提供された場合でも、ROをクライアントインスタンスにリダイレクトしようとしてはなりません（セクション2.5.2.1）。ユーザーコードURIの相互作用コンポーネントがASによって直接ホストされていない場合、ASとこのURI間の通信の手段は、ユーザーコード自体の通信を含め、この仕様の範囲外です。
When the RO enters this code at the given URI, the AS MUST uniquely identify the pending request that the code was associated with. If the AS does not recognize the entered code, the interaction component MUST display an error to the user. If the AS detects too many unrecognized code enter attempts, the interaction component SHOULD display an error to the user indicating too many attempts and MAY take additional actions such as slowing down the input interactions. The user should be warned as such an error state is approached, if possible.
ROが指定されたURIでこのコードを入力すると、ASはコードが関連付けられている保留中の要求を一意に識別する必要があります。ASが入力されたコードを認識していない場合、インタラクションコンポーネントはユーザーにエラーを表示する必要があります。ASが認識されていないコードが多すぎると試みを検出した場合、インタラクションコンポーネントはユーザーにエラーを表示し、あまりにも多くの試みを示し、入力インタラクションの遅延などの追加アクションを実行する可能性があります。可能であれば、そのようなエラー状態にアプローチされるため、ユーザーは警告する必要があります。
When the client instance is directed to launch an application through the "app" mode (Section 3.3.2), the client launches the URI as appropriate to the system, such as through a deep link or custom URI scheme registered to a mobile application. The means by which the AS and the launched application communicate with each other and perform any of the required actions are out of scope for this specification.
クライアントインスタンスが「アプリ」モード（セクション3.3.2）を介してアプリケーションを起動するように指示されると、クライアントは、モバイルアプリケーションに登録されたディープリンクやカスタムURIスキームなど、システムに適切なようにURIを起動します。ASおよび起動されたアプリケーションが相互に通信し、必要なアクションのいずれかを実行する手段は、この仕様の範囲外です。
If an interaction "finish" method (Section 3.3.5) is associated with the current request, the AS MUST follow the appropriate method upon completion of interaction in order to signal the client instance to continue, except for some limited error cases discussed below. If a finish method is not available, the AS SHOULD instruct the RO to return to the client instance upon completion. In such cases, it is expected that the client instance will poll the continuation endpoint as described in Section 5.2.
インタラクションの「終了」メソッド（セクション3.3.5）が現在の要求に関連付けられている場合、ASは、以下で説明するいくつかの限られたエラーケースを除き、クライアントインスタンスを継続するように信号を送るために、相互作用の完了時に適切な方法に従う必要があります。仕上げメソッドが利用できない場合、ASはROに、完了時にクライアントインスタンスに戻るように指示する必要があります。そのような場合、セクション5.2で説明されているように、クライアントインスタンスが継続エンドポイントを投票することが予想されます。
The AS MUST create an interaction reference and associate that reference with the current interaction and the underlying pending request. The interaction reference value is an ASCII string consisting of only unreserved characters per Section 2.3 of [RFC3986]. The interaction reference value MUST be sufficiently random so as not to be guessable by an attacker. The interaction reference MUST be one-time-use to prevent interception and replay attacks.
ASは、インタラクションリファレンスを作成し、その参照を現在の相互作用と保留中のリクエストと関連付けなければなりません。相互作用基準値は、[RFC3986]のセクション2.3ごとに予約されていない文字のみで構成されるASCII文字列です。攻撃者が推測しないように、相互作用の基準値は十分にランダムでなければなりません。インターセプトおよびリプレイ攻撃を防ぐために、相互作用の参照は1回限りの使用でなければなりません。
The AS MUST calculate a hash value based on the client instance, AS nonces, and the interaction reference, as described in Section 4.2.3. The client instance will use this value to validate the "finish" call.
ASは、セクション4.2.3で説明されているように、クライアントインスタンス、および相互作用リファレンスに基づいてハッシュ値を計算する必要があります。クライアントインスタンスは、この値を使用して「終了」コールを検証します。
All interaction finish methods MUST define a way to convey the hash and interaction reference back to the client instance. When an interaction finish method is used, the client instance MUST present the interaction reference back to the AS as part of its continuation request (Section 5.1).
すべてのインタラクション仕上げ方法は、ハッシュとインタラクションの参照をクライアントインスタンスに伝える方法を定義する必要があります。インタラクション仕上げ方式を使用する場合、クライアントインスタンスは、継続要求の一部としてASに相互作用の参照を提示する必要があります（セクション5.1）。
Note that in many error cases, such as when the RO has denied access, the "finish" method is still enacted by the AS. This pattern allows the client instance to potentially recover from the error state by modifying its request or providing additional information directly to the AS in a continuation request. The AS MUST NOT follow the "finish" method in the following circumstances:
ROがアクセスを拒否したときなど、多くのエラーの場合、「仕上げ」メソッドはASによってまだ制定されていることに注意してください。このパターンにより、クライアントインスタンスは、リクエストを変更するか、継続リクエストでASに追加情報を直接提供することにより、潜在的にエラー状態から回復することができます。ASは、次の状況で「仕上げ」メソッドに従ってはなりません。
* The AS has determined that any URIs involved with the finish method are dangerous or blocked.
* ASは、仕上げ方法に関係するURIが危険またはブロックされていると判断しました。
* The AS cannot determine which ongoing grant request is being referenced.
* ASは、どの継続中の助成金要求が参照されているかを決定することはできません。
* The ongoing grant request has been canceled or otherwise blocked.
* 継続的な助成金リクエストはキャンセルされたか、その他のブロックされています。
When using the redirect interaction finish method defined in Sections 2.5.2.1 and 3.3.5, the AS signals to the client instance that interaction is complete and the request can be continued by directing the RO (in their browser) back to the client instance's redirect URI.
セクション2.5.2.1および3.3.5で定義されているリダイレクトインタラクション仕上げメソッドを使用する場合、クライアントインスタンスが完了し、RO（ブラウザで）をクライアントインスタンスのリダイレクトに戻すことでリクエストを継続できるというクライアントインスタンスへのASのシグナルを継続することができます。uri。
The AS secures this redirect by adding the hash and interaction reference as query parameters to the client instance's redirect URI.
ASは、クライアントインスタンスのリダイレクトURIにクエリパラメーターとしてハッシュとインタラクションの参照を追加することにより、このリダイレクトを保護します。
hash:
ハッシュ：
The interaction hash value as described in Section 4.2.3. REQUIRED.
セクション4.2.3で説明した相互作用ハッシュ値。必須。
interact_ref:
interace_ref：
The interaction reference generated for this interaction. REQUIRED.
この相互作用のために生成された相互作用リファレンス。必須。
The means of directing the RO to this URI are outside the scope of this specification, but common options include redirecting the RO from a web page and launching the system browser with the target URI. See Section 11.19 for considerations on which HTTP status code to use when redirecting a request that potentially contains credentials.
ROをこのURIに向ける手段は、この仕様の範囲外ですが、一般的なオプションには、WebページからROをリダイレクトし、ターゲットURIでシステムブラウザーを起動することが含まれます。潜在的に資格情報を含むリクエストをリダイレクトするときに使用するHTTPステータスコードに関する考慮事項については、セクション11.19を参照してください。
NOTE: '\' line wrapping per RFC 8792
https://client.example.net/return/123455\
?hash=x-gguKWTj8rQf7d7i3w3UhzvuJ5bpOlKyAlVpLxBffY\
&interact_ref=4IFWWIKYBC2PQ6U56NL1
The client instance MUST be able to process a request on the URI. If the URI is HTTP, the request MUST be an HTTP GET.
クライアントインスタンスは、URIでリクエストを処理できる必要があります。URIがHTTPの場合、リクエストはHTTP GETでなければなりません。
When receiving the request, the client instance MUST parse the query parameters to extract the hash and interaction reference values. The client instance MUST calculate and validate the hash value as described in Section 4.2.3. If the hash validates, the client instance sends a continuation request to the AS as described in Section 5.1, using the interaction reference value received here. If the hash does not validate, the client instance MUST NOT send the interaction reference to the AS.
リクエストを受信する場合、クライアントインスタンスはクエリパラメーターを解析して、ハッシュおよびインタラクションの参照値を抽出する必要があります。クライアントインスタンスは、セクション4.2.3で説明されているように、ハッシュ値を計算して検証する必要があります。ハッシュ検証の場合、クライアントインスタンスは、ここで受信した相互作用基準値を使用して、セクション5.1で説明したとおりの通りに継続要求を送信します。ハッシュが検証しない場合、クライアントインスタンスはASに相互作用の参照を送信してはなりません。
When using the push interaction finish method defined in Sections 2.5.2.1 and 3.3.5, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URI.
セクション2.5.2.1および3.3.5で定義されているプッシュインタラクション仕上げメソッドを使用する場合、クライアントインスタンスが完了し、クライアントインスタンスのコールバックURIにHTTP POSTリクエストを送信することでリクエストを継続できるというクライアントインスタンスへのASシグナルを使用します。
The HTTP message content is a JSON object consisting of the following two fields:
HTTPメッセージコンテンツは、次の2つのフィールドで構成されるJSONオブジェクトです。
hash (string):
ハッシュ（文字列）：
The interaction hash value as described in Section 4.2.3. REQUIRED.
セクション4.2.3で説明した相互作用ハッシュ値。必須。
interact_ref (string):
interace_ref（string）：
The interaction reference generated for this interaction. REQUIRED.
この相互作用のために生成された相互作用リファレンス。必須。
POST /push/554321 HTTP/1.1
Host: client.example.net
Content-Type: application/json
{
"hash": "pjdHcrti02HLCwGU3qhUZ3wZXt8IjrV_BtE3oUyOuKNk",
"interact_ref": "4IFWWIKYBC2PQ6U56NL1"
}
Since the AS is making an outbound connection to a URI supplied by an outside party (the client instance), the AS MUST protect itself against Server-Side Request Forgery (SSRF) attacks when making this call, as discussed in Section 11.34.
セクション11.34で説明されているように、この呼び出しを行うとき、ASは、外部の当事者（クライアントインスタンス）から提供されるURIへのアウトバウンド接続を行っているため、サーバー側の要求偽造（SSRF）攻撃から保護する必要があります。
When receiving the request, the client instance MUST parse the JSON object and validate the hash value as described in Section 4.2.3. If either fails, the client instance MUST return an unknown_interaction error (Section 3.6). If the hash validates, the client instance sends a continuation request to the AS as described in Section 5.1, using the interaction reference value received here.
リクエストを受信する場合、クライアントインスタンスはJSONオブジェクトを解析し、セクション4.2.3で説明したようにハッシュ値を検証する必要があります。いずれかが失敗した場合、クライアントインスタンスは不明なinteractionエラー（セクション3.6）を返す必要があります。ハッシュ検証の場合、クライアントインスタンスは、ここで受信した相互作用基準値を使用して、セクション5.1で説明したとおりの通りに継続要求を送信します。
The "hash" parameter in the request to the client instance's callback URI ties the front-channel response to an ongoing request by using values known only to the parties involved. This security mechanism allows the client instance to protect itself against several kinds of session fixation and injection attacks as discussed in Section 11.25. The AS MUST always provide this hash, and the client instance MUST validate the hash when received.
クライアントインスタンスのコールバックURIへの要求の「ハッシュ」パラメーターは、関係者のみに既知の値を使用して、継続的な要求に対するフロントチャネル応答を結び付けます。このセキュリティメカニズムにより、クライアントインスタンスは、セクション11.25で説明したように、いくつかの種類のセッション固定と注入攻撃から身を守ることができます。ASは常にこのハッシュを提供する必要があり、クライアントインスタンスは受信時にハッシュを検証する必要があります。
To calculate the "hash" value, the party doing the calculation creates a hash base string by concatenating the following values in the following order using a single newline (0x0A) character to separate them:
「ハッシュ」値を計算するために、計算を行うパーティーは、単一の新しいライン（0x0a）文字を使用して次の順序で次の値を連結することにより、ハッシュベース文字列を作成します。
* the "nonce" value sent by the client instance in the interaction finish field of the initial request (Section 2.5.2)
* 最初のリクエストのインタラクション仕上げフィールドにクライアントインスタンスによって送信された「ノンセ」値（セクション2.5.2）
* the AS's nonce value from the interaction finish response (Section 3.3.5)
* インタラクション仕上げ応答からのASの非CE値（セクション3.3.5）
* the "interact_ref" returned from the AS as part of the interaction finish method (Section 4.2)
* 「interact_ref」は、インタラクション仕上げ方法の一部としてASから返されました（セクション4.2）
* the grant endpoint URI the client instance used to make its initial request (Section 2)
* グラントエンドポイントURIクライアントインスタンスは、最初のリクエストを行うために使用されていました（セクション2）
There is no padding or whitespace before or after any of the lines and no trailing newline character. The following non-normative example shows a constructed hash base string consisting of these four elements.
ラインの前後にパディングや空白はありません。次の非規範的な例は、これらの4つの要素で構成される構築されたハッシュベースストリングを示しています。
VJLO6A4CATR0KRO
MBDOFXG4Y5CVJCX821LH
4IFWWIKYB2PQ6U56NL1
https://server.example.com/tx
The party then hashes the bytes of the ASCII encoding of this string with the appropriate algorithm based on the "hash_method" parameter under the "finish" key of the interaction finish request (Section 2.5.2). The resulting byte array from the hash function is then encoded using URL-Safe base64 with no padding [RFC4648]. The resulting string is the hash value.
当事者は、インタラクション仕上げ要求の「仕上げ」キー（セクション2.5.2）の下にある「hash_method」パラメーターに基づいて、この文字列のASCIIエンコードのバイトをハッシュします。ハッシュ関数から得られたバイト配列は、パディングなしでURLセーフBase64を使用してエンコードされます[RFC4648]。結果の文字列はハッシュ値です。
If provided, the "hash_method" value MUST be one of the hash name strings defined in the IANA "Named Information Hash Algorithm Registry" [HASH-ALG]. If the "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha-256".
提供されている場合、「hash_method」値は、IANAで定義されているハッシュ名文字列の1つでなければなりません。クライアントインスタンスの要求に「hash_method」値が存在しない場合、アルゴリズムはデフォルト「SHA-256」になります。
For example, the "sha-256" hash method consists of hashing the input string with the 256-bit SHA2 algorithm. The following is the encoded "sha-256" hash of the hash base string in the example above.
たとえば、「SHA-256」ハッシュメソッドは、入力文字列を256ビットSHA2アルゴリズムでハッシュすることで構成されています。以下は、上記の例のハッシュベース文字列のエンコードされた「SHA-256」ハッシュです。
x-gguKWTj8rQf7d7i3w3UhzvuJ5bpOlKyAlVpLxBffY
As another example, the "sha3-512" hash method consists of hashing the input string with the 512-bit SHA3 algorithm. The following is the encoded "sha3-512" hash of the hash base string in the example above.
別の例として、「SHA3-512」ハッシュメソッドは、512ビットSHA3アルゴリズムで入力文字列をハッシュすることで構成されています。以下は、上記の例のハッシュベース文字列のエンコードされた「sha3-512」ハッシュです。
NOTE: '\' line wrapping per RFC 8792
pyUkVJSmpqSJMaDYsk5G8WCvgY91l-agUPe1wgn-cc5rUtN69gPI2-S_s-Eswed8iB4\
PJ_a5Hg6DNi7qGgKwSQ
While it is possible for the AS to return an approved grant response (Section 3) with all the client instance's requested information (including access tokens (Section 3.2) and subject information (Section 3.4)) immediately, it's more common that the AS will place the grant request into the _pending_ state and require communication with the client instance several times over the lifetime of a grant request. This is often part of facilitating interaction (Section 4), but it could also be used to allow the AS and client instance to continue negotiating the parameters of the original grant request (Section 2) through modification of the request.
すべてのクライアントインスタンスの要求された情報（アクセストークン（セクション3.2）を含む）を含むすべてのクライアントインスタンス（セクション3）をすぐに返すことは可能ですが、すぐにサブジェクト情報（セクション3.4）を含む）は、ASが配置することがより一般的です_pending_状態への助成金リクエストは、助成金要求の寿命にわたってクライアントインスタンスとの通信を数回必要とします。これは多くの場合、相互作用の促進の一部です（セクション4）が、ASおよびクライアントインスタンスがリクエストの変更を通じて元の助成金要求（セクション2）のパラメーターの交渉を継続できるようにするためにも使用できます。
The ability to continue an already-started request allows the client instance to perform several important functions, including presenting additional information from interaction, modifying the initial request, and revoking a grant request in progress.
すでに開始されたリクエストを継続する機能により、クライアントインスタンスは、インタラクションからの追加情報の提示、最初の要求の変更、進行中の助成金リクエストの取り消しなど、いくつかの重要な機能を実行できます。
To enable this ongoing negotiation, the AS provides a continuation API to the client software. The AS returns a continue field in the response (Section 3.1) that contains information the client instance needs to access this API, including a URI to access as well as a special access token to use during the requests, called the "continuation access token".
この継続的な交渉を可能にするために、ASはクライアントソフトウェアに継続APIを提供します。ASは、クライアントインスタンスがこのAPIにアクセスするために必要な情報（セクション3.1）の連続フィールドを返します。これには、「継続アクセストークン」と呼ばれるリクエスト中に使用する特別なアクセストークンが含まれます。。
All requests to the continuation API are protected by a bound continuation access token. The continuation access token is bound to the same key and method the client instance used to make the initial request (or its most recent rotation). As a consequence, when the client instance makes any calls to the continuation URI, the client instance MUST present the continuation access token as described in Section 7.2 and present proof of the client instance's key (or its most recent rotation) by signing the request as described in Section 7.3. The AS MUST validate the signature and ensure that it is bound to the appropriate key for the continuation access token.
継続APIへのすべての要求は、バウンド継続アクセストークンによって保護されます。継続アクセストークンは、クライアントインスタンスが最初のリクエスト（または最新の回転）を作成するために使用した同じキーとメソッドにバインドされています。結果として、クライアントインスタンスが継続URIに呼び出しを行う場合、クライアントインスタンスは、セクション7.2で説明されているように継続アクセストークンを提示し、クライアントインスタンスのキー（または最新の回転）の証明を提示する必要があります。セクション7.3で説明されています。ASは、署名を検証し、継続アクセストークンの適切なキーにバインドされていることを確認する必要があります。
Access tokens other than the continuation access tokens MUST NOT be usable for continuation requests. Conversely, continuation access tokens MUST NOT be usable to make authorized requests to RSs, even if co-located within the AS.
継続アクセストークン以外のアクセストークンは、継続リクエストに使用できない必要があります。逆に、継続アクセストークンは、AS内で共同住宅されていても、RSSに承認されたリクエストを行うために使用できない必要があります。
In the following non-normative example, the client instance makes a POST request to a unique URI and signs the request with HTTP message signatures:
次の非規範的な例では、クライアントインスタンスは一意のURIに投稿要求を行い、HTTPメッセージ署名でリクエストに署名します。
POST /continue/KSKUOMUKM HTTP/1.1
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Host: server.example.com
Content-Length: 0
Signature-Input: sig1=...
Signature: sig1=...
The AS MUST be able to tell from the client instance's request which specific ongoing request is being accessed, using a combination of the continuation URI and the continuation access token. If the AS cannot determine a single active grant request to map the continuation request to, the AS MUST return an invalid_continuation error (Section 3.6).
ASは、Continuation URIと継続アクセストークンの組み合わせを使用して、特定の継続的なリクエストにアクセスされるクライアントインスタンスの要求から伝えることができなければなりません。ASが継続要求をマッピングするための単一のアクティブな助成金要求を決定できない場合、ASは無効な_CONTINUATIONエラー（セクション3.6）を返す必要があります。
In the following non-normative example, the client instance makes a POST request to a stable continuation endpoint URI with the interaction reference (Section 5.1), includes the access token, and signs with HTTP message signatures:
以下の非規範的な例では、クライアントインスタンスは、インタラクションリファレンスを備えた安定した継続エンドポイントURI（セクション5.1）を備えたPOSTリクエストを行い、アクセストークン、およびHTTPメッセージ署名を備えたサインを含みます。
POST /continue HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"interact_ref": "4IFWWIKYBC2PQ6U56NL1"
}
In the following non-normative alternative example, the client instance had been provided a continuation URI unique to this ongoing grant request:
次の非規範的な代替例では、クライアントインスタンスには、この継続的な助成金リクエストに固有の継続URIが提供されていました。
POST /tx/rxgIIEVMBV-BQUO7kxbsp HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: GNAP eyJhbGciOiJub25lIiwidHlwIjoiYmFkIn0
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"interact_ref": "4IFWWIKYBC2PQ6U56NL1"
}
In both cases, the AS determines which grant is being asked for based on the URI and continuation access token provided.
どちらの場合も、ASは、提供されたURIおよび継続アクセストークンに基づいて、どの助成金が求められているかを決定します。
If a wait parameter was included in the continuation response (Section 3.1), the client instance MUST NOT call the continuation URI prior to waiting the number of seconds indicated. If no wait period is indicated, the client instance MUST NOT poll immediately and SHOULD wait at least 5 seconds. If the client instance does not respect the given wait period, the AS MUST return the too_fast error (Section 3.6).
待機パラメーターが継続応答に含まれている場合（セクション3.1）、クライアントインスタンスは、示されている秒数を待つ前に継続URIを呼び出してはなりません。待機期間がない場合、クライアントインスタンスはすぐに投票してはならず、少なくとも5秒待つ必要があります。クライアントインスタンスが指定された待機期間を尊重しない場合、ASはtoo_fastエラー（セクション3.6）を返す必要があります。
The response from the AS is a JSON object of a grant response and MAY contain any of the fields described in Section 3, as described in more detail in the subsections below.
ASからの応答は、付与応答のJSONオブジェクトであり、以下のサブセクションで詳細に説明されているように、セクション3で説明されているフィールドのいずれかを含む場合があります。
If the AS determines that the client instance can make further requests to the continuation API, the AS MUST include a new continuation response (Section 3.1). The new continuation response MUST include a continuation access token as well, and this token SHOULD be a new access token, invalidating the previous access token. If the AS does not return a new continuation response, the client instance MUST NOT make an additional continuation request. If a client instance does so, the AS MUST return an invalid_continuation error (Section 3.6).
ASがクライアントインスタンスが継続APIにさらにリクエストを行うことができると判断した場合、ASには新しい継続応答（セクション3.1）を含める必要があります。新しい継続応答には、継続アクセストークンも含める必要があり、このトークンは新しいアクセストークンである必要があり、以前のアクセストークンを無効にします。ASが新しい継続応答を返さない場合、クライアントインスタンスは追加の継続リクエストを作成してはなりません。クライアントインスタンスがそうする場合、ASはnivalid_continuationエラーを返す必要があります（セクション3.6）。
For continuation functions that require the client instance to send message content, the content MUST be a JSON object.
クライアントインスタンスがメッセージコンテンツを送信する必要がある継続関数の場合、コンテンツはJSONオブジェクトでなければなりません。
For all requests to the grant continuation API, the AS MAY make use of long polling mechanisms such as those discussed in [RFC6202]. That is to say, instead of returning the current status immediately, the long polling technique allows the AS additional time to process and fulfill the request before returning the HTTP response to the client instance. For example, when the AS receives a continuation request but the grant request is in the _processing_ state, the AS could wait until the grant request has moved to the _pending_ or _approved_ state before returning the response message.
助成金の継続APIへのすべての要求について、ASは[RFC6202]で議論されているような長いポーリングメカニズムを使用する可能性があります。つまり、現在のステータスをすぐに返す代わりに、長いポーリング手法により、クライアントインスタンスへのHTTP応答を返す前に、リクエストを処理および満たすための追加の時間を可能にします。たとえば、ASが継続要求を受信しているが、助成金要求が_Processing_状態にある場合、ASは応答メッセージを返す前に_Pending_または_Approved_状態に移動するまで待つことができます。
When the AS responds to the client instance's finish method as in Section 4.2.1, this response includes an interaction reference. The client instance MUST include that value as the field interact_ref in a POST request to the continuation URI.
ASがセクション4.2.1のようにクライアントインスタンスの仕上げ方式に応答する場合、この応答には相互作用リファレンスが含まれます。クライアントインスタンスは、継続URIへのPOSTリクエストにフィールドインタラクション_REFとしてその値を含める必要があります。
POST /continue HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"interact_ref": "4IFWWIKYBC2PQ6U56NL1"
}
Since the interaction reference is a one-time-use value as described in Section 4.2.1, if the client instance needs to make additional continuation calls after this request, the client instance MUST NOT include the interaction reference in subsequent calls. If the AS detects a client instance submitting an interaction reference when the request is not in the _pending_ state, the AS MUST return a too_many_attempts error (Section 3.6) and SHOULD invalidate the ongoing request by moving it to the _finalized_ state.
インタラクションリファレンスはセクション4.2.1で説明されているように1回限りの使用値であるため、クライアントインスタンスがこのリクエスト後に追加の継続コールを作成する必要がある場合、クライアントインスタンスは後続の呼び出しにインタラクションリファレンスを含めてはなりません。ASがクライアントインスタンスが_Pending_状態にない場合に相互作用リファレンスを送信するクライアントインスタンスを検出する場合、ASはTOO_MANY_ATTEMPTSエラー（セクション3.6）を返す必要があり、_Finalized_状態に移動して進行中のリクエストを無効にする必要があります。
If the grant request is in the _approved_ state, the grant response (Section 3) MAY contain any newly created access tokens (Section 3.2) or newly released subject information (Section 3.4). The response MAY contain a new continuation response (Section 3.1) as described above. The response SHOULD NOT contain any interaction responses (Section 3.3).
助成金要求が_Approved_状態にある場合、助成金の応答（セクション3）には、新しく作成されたアクセストークン（セクション3.2）または新たにリリースされた主題情報（セクション3.4）が含まれる場合があります。応答には、上記のように新しい継続応答（セクション3.1）が含まれる場合があります。応答には、相互作用応答を含めるべきではありません（セクション3.3）。
If the grant request is in the _pending_ state, the grant response (Section 3) MUST NOT contain access tokens or subject information and MAY contain a new interaction response (Section 3.3) to any interaction methods that have not been exhausted at the AS.
助成金要求が_Pending_状態にある場合、助成金の応答（セクション3）はアクセストークンまたはサブジェクト情報を含めてはならず、ASで使い果たされていない相互作用方法に対する新しい相互作用応答（セクション3.3）を含めることができます。
For example, if the request is successful in causing the AS to issue access tokens and release opaque subject claims, the response could look like this:
たとえば、リクエストがアクセストークンを発行し、不透明なサブジェクトのクレームをリリースするようになった場合、応答は次のようになります。
NOTE: '\' line wrapping per RFC 8792
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
}
},
"subject": {
"sub_ids": [ {
"format": "opaque",
"id": "J2G8G8O4AZ"
} ]
}
}
With the above example, the client instance cannot make an additional continuation request because a continue field is not included.
上記の例を使用すると、クライアントインスタンスは、継続フィールドが含まれていないため、追加の継続要求を行うことができません。
In the following non-normative example, the RO has denied the client instance's request, and the AS responds with the following response:
次の非規範的な例では、ROはクライアントインスタンスの要求を拒否し、ASは次の回答で応答します。
{
"error": "user_denied",
"continue": {
"access_token": {
"value": "33OMUKMKSKU80UPRY5NM"
},
"uri": "https://server.example.com/continue",
"wait": 30
}
}
In the preceding example, the AS includes the continue field in the response. Therefore, the client instance can continue the grant negotiation process, perhaps modifying the request as discussed in Section 5.3.
前の例では、ASには応答に連続フィールドが含まれます。したがって、クライアントインスタンスは助成金交渉プロセスを継続し、おそらくセクション5.3で説明したようにリクエストを変更することができます。
When the client instance does not include a finish parameter, the client instance will often need to poll the AS until the RO has authorized the request. To do so, the client instance makes a POST request to the continuation URI as in Section 5.1 but does not include message content.
クライアントインスタンスに終了パラメーターが含まれていない場合、クライアントインスタンスは、ROがリクエストを承認するまでASを投票する必要があることがよくあります。そのために、クライアントインスタンスはセクション5.1のように継続URIに投稿リクエストを行いますが、メッセージコンテンツは含まれていません。
POST /continue HTTP/1.1
Host: server.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
If the grant request is in the _approved_ state, the grant response (Section 3) MAY contain any newly created access tokens (Section 3.2) or newly released subject claims (Section 3.4). The response MAY contain a new continuation response (Section 3.1) as described above. If a continue field is included, it SHOULD include a wait field to facilitate a reasonable polling rate by the client instance. The response SHOULD NOT contain interaction responses (Section 3.3).
助成金要求が_Approved_状態にある場合、助成金の回答（セクション3）には、新しく作成されたアクセストークン（セクション3.2）または新たにリリースされた被験者のクレーム（セクション3.4）が含まれている場合があります。応答には、上記のように新しい継続応答（セクション3.1）が含まれる場合があります。続行フィールドが含まれている場合、クライアントインスタンスによる合理的な投票率を促進するための待機フィールドを含める必要があります。応答には、相互作用応答を含めるべきではありません（セクション3.3）。
If the grant request is in the _pending_ state, the grant response (Section 3) MUST NOT contain access tokens or subject information and MAY contain a new interaction response (Section 3.3) to any interaction methods that have not been exhausted at the AS.
助成金要求が_Pending_状態にある場合、助成金の応答（セクション3）はアクセストークンまたはサブジェクト情報を含めてはならず、ASで使い果たされていない相互作用方法に対する新しい相互作用応答（セクション3.3）を含めることができます。
For example, if the request has not yet been authorized by the RO, the AS could respond by telling the client instance to make another continuation request in the future. In the following non-normative example, a new, unique access token has been issued for the call, which the client instance will use in its next continuation request.
たとえば、リクエストがROによってまだ承認されていない場合、クライアントインスタンスに将来別の継続リクエストを行うように伝えることで応答できます。次の非規範的な例では、クライアントインスタンスが次の継続要求で使用する新しいユニークなアクセストークンがコールに対して発行されました。
{
"continue": {
"access_token": {
"value": "33OMUKMKSKU80UPRY5NM"
},
"uri": "https://server.example.com/continue",
"wait": 30
}
}
If the request is successful in causing the AS to issue access tokens and release subject information, the response could look like the following non-normative example:
リクエストがアクセストークンを発行し、サブジェクト情報をリリースするように成功した場合、応答は次の非規範的な例のように見える可能性があります。
NOTE: '\' line wrapping per RFC 8792
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
}
},
"subject": {
"sub_ids": [ {
"format": "opaque",
"id": "J2G8G8O4AZ"
} ]
}
}
See Section 11.23 for considerations on polling for continuation without an interaction finish method.
インタラクション仕上げ方法なしの継続に関する投票に関する考慮事項については、セクション11.23を参照してください。
In error conditions, the AS responds to the client instance with an error code as discussed in Section 3.6. For example, if the client instance has polled too many times before the RO has approved the request, the AS would respond with a message like the following:
エラー条件では、ASはセクション3.6で説明したように、エラーコードを使用してクライアントインスタンスに応答します。たとえば、ROがリクエストを承認する前にクライアントインスタンスが何度も投票した場合、次のようなメッセージで応答します。
{
"error": "too_many_attempts"
}
Since this response does not include a continue field, the client instance cannot continue to poll the AS for additional updates and the grant request is _finalized_. If the client instance still needs access to the resource, it will need to start with a new grant request.
この応答には継続フィールドが含まれていないため、クライアントインスタンスは追加の更新についてASを投票し続けることはできず、助成金リクエストは_Finalized_です。クライアントインスタンスがまだリソースにアクセスする必要がある場合は、新しい助成金リクエストから始める必要があります。
The client instance might need to modify an ongoing request, whether or not tokens have already been issued or subject information has already been released. In such cases, the client instance makes an HTTP PATCH request to the continuation URI and includes any fields it needs to modify. Fields that aren't included in the request are considered unchanged from the original request.
クライアントインスタンスは、トークンが既に発行されているかどうか、または件名情報が既にリリースされているかどうかにかかわらず、継続的なリクエストを変更する必要がある場合があります。そのような場合、クライアントインスタンスは継続URIにHTTPパッチ要求を行い、変更する必要があるフィールドを含みます。リクエストに含まれていないフィールドは、元のリクエストから変更されていないと見なされます。
A grant request associated with a modification request MUST be in the _approved_ or _pending_ state. When the AS receives a valid modification request, the AS MUST place the grant request into the _processing_ state and re-evaluate the authorization in the new context created by the update request, since the extent and context of the request could have changed.
変更リクエストに関連付けられた助成金リクエストは、_Approved_または_Pending_状態にある必要があります。ASが有効な変更要求を受信した場合、ASは、リクエストの範囲とコンテキストが変更された可能性があるため、ASが_Processing_状態に_Processing_状態に配置し、更新要求によって作成された新しいコンテキストで認可を再評価する必要があります。
The client instance MAY include the access_token and subject fields as described in Sections 2.1 and 2.2. Inclusion of these fields override any values in the initial request, which MAY trigger additional requirements and policies by the AS. For example, if the client instance is asking for more access, the AS could require additional interaction with the RO to gather additional consent. If the client instance is asking for more limited access, the AS could determine that sufficient authorization has been granted to the client instance and return the more limited access rights immediately. If the grant request was previously in the _approved_ state, the AS could decide to remember the larger scale of access rights associated with the grant request, allowing the client instance to make subsequent requests of different subsets of granted access. The details of this processing are out of scope for this specification, but a one possible approach is as follows:
クライアントインスタンスには、セクション2.1および2.2で説明されているように、Access_Tokenおよびサブジェクトフィールドが含まれる場合があります。これらのフィールドを含めることは、最初の要求の値をオーバーライドします。これにより、ASによる追加の要件とポリシーがトリガーされる場合があります。たとえば、クライアントインスタンスがより多くのアクセスを求めている場合、ROとの追加のやり取りが必要になる可能性がある場合、追加の同意を収集します。クライアントインスタンスがより限定的なアクセスを求めている場合、ASは、クライアントインスタンスに十分な承認が付与され、すぐにアクセス権がより限られた権利を返すことが判断される可能性があります。助成金の要求が以前_Approved_状態であった場合、ASは助成金要求に関連するより大きなアクセス権を覚えることを決定することができ、クライアントインスタンスが付与されたアクセスの異なるサブセットの後続の要求を行うことができます。この処理の詳細は、この仕様の範囲外ですが、1つの可能なアプローチは次のとおりです。
1. A client instance requests access to Foo, and this is granted by the RO. This results in an access token: AT1.
1. クライアントインスタンスはFOOへのアクセスを要求し、これはROによって付与されます。これにより、アクセストークンが発生します：AT1。
2. The client instance later modifies the grant request to include Foo and Bar together. Since the client instance was previously granted Foo under this grant request, the RO is prompted to allow the client instance access to Foo and Bar together. This results in a new access token: AT2. This access token has access to both Foo and Bar. The rights of the original access token AT1 are not modified.
2. クライアントインスタンスは、後でfooとbarを一緒に含めるための助成金リクエストを変更します。クライアントインスタンスは以前にこの助成金リクエストに基づいてFOOが付与されていたため、ROはクライアントインスタンスがFOOとバーへのアクセスを許可するように求められています。これにより、新しいアクセストークンが発生します：AT2。このアクセストークンは、FooとBarの両方にアクセスできます。元のアクセストークンAT1の権利は変更されていません。
3. The client instance makes another grant modification to ask only for Bar. Since the client instance was previously granted Foo and Bar together under this grant request, the RO is not prompted, and the access to Bar is granted in a new access token: AT3. This new access token does not allow access to Foo.
3. クライアントインスタンスは、バーだけを要求するために別の助成金を変更します。クライアントインスタンスは以前にこの助成金要求に基づいてFooとBarが一緒に付与されていたため、ROは促されず、BARへのアクセスは新しいアクセストークンAT3に付与されます。この新しいアクセストークンでは、FOOへのアクセスは許可されていません。
4. The original access token AT1 expires, and the client seeks a new access token to replace it. The client instance makes another grant modification to ask only for Foo. Since the client instance was previously granted Foo and Bar together under this grant request, the RO is not prompted, and the access to Foo is granted in a new access token: AT4. This new access token does not allow access to Bar.
4. 元のアクセストークンAT1は期限切れになり、クライアントはそれを交換するために新しいアクセストークンを探します。クライアントインスタンスは、Fooのみを求めるための別の助成金を変更します。クライアントインスタンスは以前にこの助成金要求に基づいてFooとBarが一緒に付与されていたため、ROは促されず、Fooへのアクセスは新しいアクセストークンAT4で許可されます。この新しいアクセストークンは、バーへのアクセスを許可しません。
All four access tokens are independent of each other and associated with the same underlying grant request. Each of these access tokens could possibly also be rotated using token management, if available. For example, instead of asking for a new token to replace AT1, the client instance could ask for a refresh of AT1 using the rotation method of the token management API. This would result in a refreshed AT1 with a different token value and expiration from the original AT1 but with the same access rights of allowing only access to Foo.
4つのアクセストークンはすべて互いに独立しており、同じ基礎となる助成金リクエストに関連付けられています。これらの各アクセストークンは、利用可能な場合はトークン管理を使用して回転する可能性があります。たとえば、AT1を置き換える新しいトークンを要求する代わりに、クライアントインスタンスは、トークン管理APIの回転方法を使用してAT1の更新を要求することができます。これにより、AT1が異なるトークン値と元のAT1からの有効期限を備えているが、FOOへのアクセスのみを許可するのと同じアクセス権を備えた更新されたAT1になります。
The client instance MAY include the interact field as described in Section 2.5. Inclusion of this field indicates that the client instance is capable of driving interaction with the end user, and this field replaces any values from a previous request. The AS MAY respond to any of the interaction responses as described in Section 3.3, just like it would to a new request.
クライアントインスタンスには、セクション2.5で説明されているように、相互作用フィールドが含まれる場合があります。このフィールドを含めることは、クライアントインスタンスがエンドユーザーとの相互作用を促進できることを示しており、このフィールドは以前のリクエストからの値を置き換えます。ASは、セクション3.3で説明されているように、新しいリクエストと同じように、相互作用応答のいずれかに応答する場合があります。
The client instance MAY include the user field as described in Section 2.4 to present new assertions or information about the end user. The AS SHOULD check that this presented user information is consistent with any user information previously presented by the client instance or otherwise associated with this grant request.
クライアントインスタンスには、セクション2.4で説明されているようにユーザーフィールドを含めると、エンドユーザーに関する新しいアサーションまたは情報を提示できます。ASは、これが提示されたユーザー情報が、クライアントインスタンスによって以前に提示された、またはこの助成金リクエストに関連付けられているユーザー情報と一致していることを確認する必要があります。
The client instance MUST NOT include the client field of the request, since the client instance is assumed not to have changed. Modification of client instance information, including rotation of keys associated with the client instance, is outside the scope of this specification.
クライアントインスタンスは、クライアントインスタンスが変更されていないと想定されるため、リクエストのクライアントフィールドを含めてはなりません。クライアントインスタンスに関連するキーの回転を含むクライアントインスタンス情報の変更は、この仕様の範囲外です。
The client instance MUST NOT include post-interaction responses such as those described in Section 5.1.
クライアントインスタンスには、セクション5.1で説明されているような相互作用後の応答を含めてはなりません。
Modification requests MUST NOT alter previously issued access tokens. Instead, any access tokens issued from a continuation are considered new, separate access tokens. The AS MAY revoke previously issued access tokens after a modification has occurred.
変更要求は、以前に発行されたアクセストークンを変更してはなりません。代わりに、継続から発行されたアクセストークンは、新しい個別のアクセストークンと見なされます。ASが変更された後、以前に発行されたASが以前に発行されたASは、変更が発生した後に発行されました。
If the modified request can be granted immediately by the AS (the grant request is in the _approved_ state), the grant response (Section 3) MAY contain any newly created access tokens (Section 3.2) or newly released subject claims (Section 3.4). The response MAY contain a new continuation response (Section 3.1) as described above. If interaction can occur, the response SHOULD contain interaction responses (Section 3.3) as well.
変更された要求がAS（補助金要求が_Approved_状態にある）によってすぐに付与できる場合、助成金の回答（セクション3）には、新しく作成されたアクセストークン（セクション3.2）または新しくリリースされた被験者の請求（セクション3.4）が含まれる場合があります。応答には、上記のように新しい継続応答（セクション3.1）が含まれる場合があります。相互作用が発生する可能性がある場合、応答には相互作用応答（セクション3.3）も含める必要があります。
For example, a client instance initially requests a set of resources using references:
たとえば、クライアントインスタンスは最初に参照を使用して一連のリソースを要求します。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
"read", "write"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
},
"client": "987YHGRT56789IOLK"
}
Access is granted by the RO, and a token is issued by the AS. In its final response, the AS includes a continue field, which includes a separate access token for accessing the continuation API:
アクセスはROによって付与され、トークンはASによって発行されます。最終的な応答では、ASが含まれます。これには、継続APIにアクセスするための個別のアクセストークンが含まれます。
{
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU"
},
"uri": "https://server.example.com/continue",
"wait": 30
},
"access_token": {
"value": "RP1LT0-OS9M2P_R64TB",
"access": [
"read", "write"
]
}
}
This continue field allows the client instance to make an eventual continuation call. Some time later, the client instance realizes that it no longer needs "write" access and therefore modifies its ongoing request, here asking for just "read" access instead of both "read" and "write" as before.
この連続フィールドにより、クライアントインスタンスは最終的な継続コールを行うことができます。しばらくして、クライアントインスタンスは、「書き込み」アクセスを必要としなくなることを認識しているため、継続的なリクエストを変更します。ここでは、以前のように「読み取り」と「書き込み」の両方ではなく「読み取り」アクセスを求めます。
PATCH /continue HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
"read"
]
}
...
}
The AS replaces the previous access from the first request, allowing the AS to determine if any previously granted consent already applies. In this case, the AS would determine that reducing the breadth of the requested access means that new access tokens can be issued to the client instance without additional interaction or consent. The AS would likely revoke previously issued access tokens that had the greater access rights associated with them, unless they had been issued with the durable flag.
ASは、最初の要求から以前のアクセスを置き換え、以前に付与された同意がすでに適用されているかどうかを判断できるようにします。この場合、ASは、要求されたアクセスの幅を減らすことは、追加の相互作用や同意なしに新しいアクセストークンをクライアントインスタンスに発行できることを意味することを決定します。耐久性のあるフラグが発行されていない限り、以前に発行されたアクセスのトークンが発行された可能性があります。
{
"continue": {
"access_token": {
"value": "M33OMUK80UPRY5NMKSKU"
},
"uri": "https://server.example.com/continue",
"wait": 30
},
"access_token": {
"value": "0EVKC7-2ZKwZM_6N760",
"access": [
"read"
]
}
}
As another example, the client instance initially requests read-only access but later needs to step up its access. The initial request could look like the following HTTP message:
別の例として、クライアントインスタンスは最初に読み取り専用アクセスを要求しますが、後でアクセスを強化する必要があります。最初のリクエストは、次のHTTPメッセージのように見える可能性があります。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
"read"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
},
"client": "987YHGRT56789IOLK"
}
Access is granted by the RO, and a token is issued by the AS. In its final response, the AS includes a continue field:
アクセスはROによって付与され、トークンはASによって発行されます。最終的な応答では、ASには続行フィールドが含まれます。
{
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU"
},
"uri": "https://server.example.com/continue",
"wait": 30
},
"access_token": {
"value": "RP1LT0-OS9M2P_R64TB",
"access": [
"read"
]
}
}
This allows the client instance to make an eventual continuation call. The client instance later realizes that it now needs "write" access in addition to the "read" access. Since this is an expansion of what it asked for previously, the client instance also includes a new interaction field in case the AS needs to interact with the RO again to gather additional authorization. Note that the client instance's nonce and callback are different from the initial request. Since the original callback was already used in the initial exchange and the callback is intended for one-time use, a new one needs to be included in order to use the callback again.
これにより、クライアントインスタンスが最終的に継続的な呼び出しを行うことができます。クライアントインスタンスは、後に「読み取り」アクセスに加えて「書き込み」アクセスが必要であることに気付きます。これは以前に要求されたものの拡張であるため、クライアントインスタンスには、ROと再び対話して追加の許可を収集する必要がある場合に備えて、新しい相互作用フィールドも含まれます。クライアントインスタンスのNONCEおよびコールバックは、最初のリクエストとは異なることに注意してください。元のコールバックは最初の交換で既に使用されており、コールバックは1回限りの使用を目的としているため、コールバックを再度使用するには新しいものを含める必要があります。
PATCH /continue HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
"read", "write"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return/654321",
"nonce": "K82FX4T4LKLTI25DQFZC"
}
}
}
From here, the AS can determine that the client instance is asking for more than it was previously granted, but since the client instance has also provided a mechanism to interact with the RO, the AS can use that to gather the additional consent. The protocol continues as it would with a new request. Since the old access tokens are good for a subset of the rights requested here, the AS might decide to not revoke them. However, any access tokens granted after this update process are new access tokens and do not modify the rights of existing access tokens.
ここから、ASは、クライアントインスタンスが以前に付与された以上のものを求めていると判断できますが、クライアントインスタンスはROと対話するメカニズムも提供しているため、Asは追加の同意を収集するために使用できます。プロトコルは、新しいリクエストと同じように継続します。古いアクセストークンはここで要求された権利のサブセットに適しているため、ASはそれらを取り消さないことを決定するかもしれません。ただし、この更新プロセスの後に付与されたアクセストークンは、新しいアクセストークンであり、既存のアクセストークンの権利を変更しません。
If the client instance wishes to cancel an ongoing grant request and place it into the _finalized_ state, the client instance makes an HTTP DELETE request to the continuation URI.
クライアントインスタンスが継続的な助成金リクエストをキャンセルし、_Finalized_状態に配置したい場合、クライアントインスタンスは継続URIにHTTP削除要求を行います。
DELETE /continue HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
If the request is successfully revoked, the AS responds with HTTP status code 204 (No Content). The AS SHOULD revoke all associated access tokens, if possible. The AS SHOULD disable all token rotation and other token management functions on such access tokens, if possible. Once the grant request is in the _finalized_ state, it MUST NOT be moved to any other state.
リクエストが正常に取り消された場合、ASはHTTPステータスコード204（コンテンツなし）で応答します。可能であれば、関連するすべてのアクセストークンを取り消す必要があります。可能であれば、そのようなアクセストークン上のすべてのトークン回転およびその他のトークン管理機能を無効にするはずです。助成金要求が_Finalized_状態になったら、他の状態に移動してはなりません。
If the request is not revoked, the AS responds with an invalid_continuation error (Section 3.6).
リクエストが取り消されていない場合、ASは無効_CONTINUATIONエラー（セクション3.6）で応答します。
If an access token response includes the manage field as described in Section 3.2.1, the client instance MAY call this URI to manage the access token with the rotate and revoke actions defined in the following subsections. Other actions are undefined by this specification.
セクション3.2.1で説明されているように、アクセストークン応答に管理フィールドが含まれている場合、クライアントインスタンスはこのURIを呼び出して、以下のサブセクションで定義された回転および取り消しアクションを使用してアクセストークンを管理することができます。他のアクションは、この仕様によって未定義です。
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"flags": ["bearer"],
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
}
}
}
The token management access token issued under the manage field is used to protect all calls to the token management API. The client instance MUST present proof of the key associated with the token along with the value of the token management access token.
Token Management Management APIへのすべての呼び出しを保護するために、管理フィールドで発行されたトークン管理アクセストークンが使用されます。クライアントインスタンスは、トークンに関連するキーの証明と、トークン管理アクセストークンの値を提示する必要があります。
The AS MUST validate the proof and ensure that it is associated with the token management access token.
ASは、証明を検証し、トークン管理アクセストークンに関連付けられていることを確認する必要があります。
The AS MUST uniquely identify the token being managed from the token management URI, the token management access token, or a combination of both.
ASは、トークン管理URI、トークン管理アクセストークン、または両方の組み合わせから管理されているトークンを一意に識別する必要があります。
If the client instance has an access token and that access token expires, the client instance might want to rotate the access token to a new value without expiration. Rotating an access token consists of issuing a new access token in place of an existing access token, with the same rights and properties as the original token, apart from an updated token value and expiration time.
クライアントインスタンスにアクセストークンがあり、そのアクセストークンが有効期限が切れる場合、クライアントインスタンスは、アクセストークンを有効期限なしに新しい値に回転させることをお勧めします。アクセストークンの回転は、更新されたトークン値と有効期限を除いて、元のトークンと同じ権利とプロパティを備えた既存のアクセストークンの代わりに新しいアクセストークンを発行することで構成されます。
To rotate an access token, the client instance makes an HTTP POST to the token management URI with no message content, sending the access token in the authorization header as described in Section 7.2 and signing the request with the appropriate key.
アクセストークンを回転させるために、クライアントインスタンスは、メッセージコンテンツのないトークン管理URIにHTTP投稿を行い、セクション7.2で説明されているように認証ヘッダーにアクセストークンを送信し、適切なキーでリクエストに署名します。
POST /token/PRY5NM33O HTTP/1.1
Host: server.example.com
Authorization: GNAP B8CDFONP21-4TB8N6.BW7ONM
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
The client instance cannot request to alter the access rights associated with the access token during a rotation request. To get an access token with different access rights for this grant request, the client instance has to call the continuation API's update functionality (Section 5.3) to get a new access token. The client instance can also create a new grant request with the required access rights.
クライアントインスタンスは、ローテーションリクエスト中にアクセストークンに関連するアクセス権を変更するように要求することはできません。この助成金リクエストの異なるアクセス権を持つアクセストークンを取得するには、クライアントインスタンスは継続APIの更新機能（セクション5.3）を呼び出して、新しいアクセストークンを取得する必要があります。クライアントインスタンスは、必要なアクセス権を備えた新しい助成金リクエストを作成することもできます。
The AS validates that the token management access token presented is associated with the management URI, that the AS issued the token to the given client instance, and that the presented key is the correct key for the token management access token. The AS determines which access token is being rotated from the token management URI, the token management access token, or both.
ASは、提示されたトークン管理アクセストークンが管理URIに関連付けられており、ASが指定されたクライアントインスタンスにトークンを発行し、提示されたキーがトークン管理アクセストークンの正しいキーであることを検証します。ASは、トークン管理URI、トークン管理アクセストークン、またはその両方からどのアクセストークンが回転しているかを決定します。
If the token is validated and the key is appropriate for the request, the AS MUST invalidate the current access token value associated with this URI, if possible. Note that stateless access tokens can make proactive revocation difficult within a system; see Section 11.32.
トークンが検証され、キーがリクエストに適している場合、可能であれば、このURIに関連付けられた現在のアクセストークン値を無効にする必要があります。ステートレスアクセストークンは、システム内でプロアクティブな取り消しを困難にする可能性があることに注意してください。セクション11.32を参照してください。
For successful rotations, the AS responds with an HTTP status code 200 (OK) with JSON-formatted message content consisting of the rotated access token in the access_token field described in Section 3.2.1. The value of the access token MUST NOT be the same as the current value of the access token used to access the management API. The response MUST include an access token management URI, and the value of this URI MAY be different from the URI used by the client instance to make the rotation call. The client instance MUST use this new URI to manage the rotated access token.
回転を成功させるために、ASは、セクション3.2.1で説明されているAccess_Tokenフィールドの回転アクセストークンで構成されるJSON形式のメッセージコンテンツを使用して、HTTPステータスコード200（OK）で応答します。アクセストークンの値は、管理APIへのアクセスに使用されるアクセストークンの現在の値と同じである必要があります。応答には、アクセストークン管理URIを含める必要があり、このURIの値は、クライアントインスタンスが使用するURIとは異なる場合があります。クライアントインスタンスは、この新しいURIを使用して、回転したアクセストークンを管理する必要があります。
The access rights in the access array for the rotated access token MUST be included in the response and MUST be the same as the token before rotation.
回転したアクセストークンのアクセス配列のアクセス権は、応答に含まれている必要があり、回転前にトークンと同じでなければなりません。
NOTE: '\' line wrapping per RFC 8792
{
"access_token": {
"value": "FP6A8H6HY37MH13CK76LBZ6Y1UADG6VEUPEER5H2",
"manage": {
"uri": "https://server.example.com/token/PRY5NM33O",
"access_token": {
"value": "B8CDFONP21-4TB8N6.BW7ONM"
}
},
"expires_in": 3600,
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"read", "dolphin-metadata"
]
}
}
If the AS is unable or unwilling to rotate the value of the access token, the AS responds with an invalid_rotation error (Section 3.6). Upon receiving such an error, the client instance MUST consider the access token to not have changed its state.
ASがアクセストークンの値を回転させることができない、または回転したくない場合、ASは無効なエラー（セクション3.6）で応答します。このようなエラーを受信すると、クライアントインスタンスは、アクセストークンが状態を変更していないと考える必要があります。
If the client instance wishes to bind a new presentation key to an access token, the client instance MUST present both the new key and the proof of previous key material in the access token rotation request. The client instance makes an HTTP POST as a JSON object with the following field:
クライアントインスタンスがアクセストークンの新しいプレゼンテーションキーをバインドしたい場合、クライアントインスタンスは、アクセストークン回転要求に新しいキーと以前のキー資料の証明の両方を提示する必要があります。クライアントインスタンスは、次のフィールドを持つJSONオブジェクトとしてHTTP投稿を作成します。
key:
key:
The new key value or reference in the format described in Section 7.1. Note that keys passed by value are always public keys. REQUIRED when doing key rotation.
セクション7.1で説明した形式の新しいキー値または参照。価値で渡されたキーは常にパブリックキーであることに注意してください。キーローテーションを行うときに必要です。
The proofing method and parameters for the new key MUST be the same as those established for the previous key.
新しいキーの校正方法とパラメーターは、前のキーに確立されたものと同じでなければなりません。
The client instance MUST prove possession of both the currently bound key and the newly requested key simultaneously in the rotation request. Specifically, the signature from the previous key MUST cover the value or reference of the new key, and the signature of the new key MUST cover the signature value of the old key. The means of doing so vary depending on the proofing method in use. For example, the HTTP message signatures proofing method uses multiple signatures in the request as described in Section 7.3.1.1. This is shown in the following example.
クライアントインスタンスは、現在バインドされたキーと新しく要求されたキーの両方が回転要求で同時に所有することを証明する必要があります。具体的には、前のキーからの署名は、新しいキーの値または参照をカバーする必要があり、新しいキーの署名は古いキーの署名値をカバーする必要があります。そうする手段は、使用中のプルーフ方法によって異なります。たとえば、HTTPメッセージシグネチャの校正方法は、セクション7.3.1.1で説明されているように、リクエストで複数の署名を使用します。これは、次の例に示されています。
POST /token/PRY5NM33O HTTP/1.1
Host: server.example.com
Authorization: GNAP B8CDFONP21-4TB8N6.BW7ONM
Signature-Input: \
sig1=("@method" "@target-uri" "content-digest" \
"authorization"),\
sig2=("@method" "@target-uri" "content-digest" \
"authorization" "signature";key="sig1" \
"signature-input";key="sig1")
Signature: sig1=..., sig2=...
Content-Digest: sha-256=...
{
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-2",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."
}
}
}
Failure to present the appropriate proof of either the new key or the previous key for the access token, as defined by the proofing method, MUST result in an invalid_rotation error code from the AS (Section 3.6).
プルーフメソッドで定義されているように、新しいキーまたはアクセストークンの前のキーの適切な証明を提示しないと、AS（セクション3.6）の無効なエラーコードが発生する必要があります。
An attempt to change the proofing method or parameters, including an attempt to rotate the key of a bearer token (which has no key), MUST result in an invalid_rotation error code returned from the AS (Section 3.6).
BEARERトークンのキー（キーがない）のキーを回転させる試みを含む、プルーフ方法またはパラメーターを変更する試みは、AS（セクション3.6）から返されるInvalid_rotationエラーコードをもたらす必要があります。
If the AS does not allow rotation of the access token's key for any reason, including but not limited to lack of permission for this client instance or lack of capability by the AS, the AS MUST return a key_rotation_not_supported error code (Section 3.6).
ASがアクセストークンのキーを何らかの理由で回転させない場合、このクライアントインスタンスの許可の欠如、またはASによる機能の欠如を含むがこれらに限定されない場合、ASはkey_rotation_not_not_supportedエラーコード（セクション3.6）を返す必要があります。
If the client instance wishes to revoke the access token proactively, such as when a user indicates to the client instance that they no longer wish for it to have access or the client instance application detects that it is being uninstalled, the client instance can use the token management URI to indicate to the AS that the AS SHOULD invalidate the access token for all purposes.
クライアントインスタンスがアクセストークンを積極的に取り消すことを希望する場合、ユーザーがクライアントインスタンスにアクセスを望まないことをクライアントインスタンスに示した場合、またはクライアントインスタンスアプリケーションがアンインストールされていることを検出する場合、クライアントインスタンスはトークン管理uriは、あらゆる目的でアクセストークンを無効にするべきであることを示すために。
The client instance makes an HTTP DELETE request to the token management URI, presenting the access token and signing the request with the appropriate key.
クライアントインスタンスにより、HTTP削除要求がトークン管理URIにリクエストを削除し、アクセストークンを提示し、適切なキーを使用してリクエストに署名します。
DELETE /token/PRY5NM33O HTTP/1.1
Host: server.example.com
Authorization: GNAP B8CDFONP21-4TB8N6.BW7ONM
Signature-Input: sig1=...
Signature: sig1=...
If the key presented is associated with the token (or the client instance, in the case of a bearer token), the AS MUST invalidate the access token, if possible, and return an HTTP response code 204.
提示されたキーがトークン（またはBearerトークンの場合にクライアントインスタンス）に関連付けられている場合、ASは可能であればアクセストークンを無効にし、HTTP応答コード204を返します。
204 No Content
Though the AS MAY revoke an access token at any time for any reason, the token management function is specifically for the client instance's use. If the access token has already expired or has been revoked through other means, the AS SHOULD honor the revocation request to the token management URI as valid, since the end result is that the token is still not usable.
ASは何らかの理由でいつでもアクセストークンを取り消す可能性がありますが、トークン管理機能は特にクライアントインスタンスの使用に向けています。アクセストークンがすでに期限切れになっているか、他の手段で取り消された場合、最終結果はトークンがまだ使用できないため、トークン管理URIへの取り消し要求を有効に尊重する必要があります。
In GNAP, the client instance secures its requests to an AS and RS by presenting an access token, proof of a key that it possesses (aka, a "key proof"), or both an access token and key proof together.
GNAPでは、クライアントインスタンスは、アクセストークン、所有するキー（別名、「キー証明」）、またはアクセストークンとキープルーフの両方を所有するキーの証明を提示することにより、ASとRSへの要求を確保します。
* When an access token is used with a key proof, this is a bound token request. This type of request is used for calls to the RS as well as the AS during grant negotiation.
* アクセストークンが重要な証明で使用される場合、これはバウンドトークンリクエストです。このタイプのリクエストは、RSへの呼び出しと、助成金交渉中のASに使用されます。
* When a key proof is used with no access token, this is a non-authorized signed request. This type of request is used for calls to the AS to initiate a grant negotiation.
* アクセストークンなしで重要な証明が使用される場合、これは非許可されていない署名済み要求です。このタイプのリクエストは、助成金交渉を開始するための呼び出しに使用されます。
* When an access token is used with no key proof, this is a bearer token request. This type of request is used only for calls to the RS and only with access tokens that are not bound to any key as described in Section 3.2.1.
* アクセストークンが重要な証明なしで使用される場合、これはベアラートークンリクエストです。このタイプのリクエストは、RSへの呼び出しにのみ使用され、セクション3.2.1で説明されているようにキーにバインドされていないアクセストークンのみが使用されます。
* When neither an access token nor key proof are used, this is an unsecured request. This type of request is used optionally for calls to the RS as part of an RS-first discovery process as described in Section 9.1.
* アクセストークンもキー証明も使用されていない場合、これは無担保リクエストです。このタイプのリクエストは、セクション9.1で説明されているRSファーストディスカバリープロセスの一部として、RSへの呼び出しに対してオプションで使用されます。
Several different places in GNAP require the presentation of key material by value or by reference. Key material sent by value is sent using a JSON object with several fields described in this section.
GNAPのいくつかの異なる場所では、価値または参照による重要な資料の提示が必要です。値によって送信される重要な資料は、このセクションで説明されているいくつかのフィールドを持つJSONオブジェクトを使用して送信されます。
All keys are associated with a specific key proofing method. The proofing method associated with the key is indicated using the proof field of the key object.
すべてのキーは、特定のキープルーフ方法に関連付けられています。キーに関連付けられたプルーフ方法は、キーオブジェクトの証明フィールドを使用して示されます。
proof (string or object):
証明（文字列またはオブジェクト）：
The form of proof that the client instance will use when presenting the key. The valid values of this field and the processing requirements for each are detailed in Section 7.3. REQUIRED.
キーを提示するときにクライアントインスタンスが使用する証明の形式。このフィールドの有効な値とそれぞれの処理要件については、セクション7.3で詳しく説明しています。必須。
A key presented by value MUST be a public key and MUST be presented in only one supported format, as discussed in Section 11.35. Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key. See additional discussion of the presentation of public keys in Section 11.7.
値によって提示されるキーは公開鍵でなければならず、セクション11.35で説明したように、サポートされた1つの形式でのみ提示する必要があります。ほとんどのフォーマットは公開キーの完全な値を示していますが、一部のフォーマットは公開鍵から暗号化された値を提示することに注意してください。セクション11.7のパブリックキーの提示に関する追加の議論を参照してください。
jwk (object):
JWK（オブジェクト）：
The public key and its properties represented as a JSON Web Key (JWK) [RFC7517]. A JWK MUST contain the alg (Algorithm) and kid (Key ID) parameters. The alg parameter MUST NOT be "none". The x5c (X.509 Certificate Chain) parameter MAY be used to provide the X.509 representation of the provided public key. OPTIONAL.
公開キーとそのプロパティは、JSON Webキー（JWK）[RFC7517]として表されました。JWKには、アルグ（アルゴリズム）とKID（キーID）パラメーターが含まれている必要があります。ALGパラメーターは「なし」であってはなりません。X5C（X.509証明書チェーン）パラメーターを使用して、提供された公開キーのX.509表現を提供できます。オプション。
cert (string):
cert（string）：
The Privacy-Enhanced Mail (PEM) serialized value of the certificate used to sign the request, with optional internal whitespace per [RFC7468]. The PEM header and footer are optionally removed. OPTIONAL.
プライバシー強化メール（PEM）は、リクエストに署名するために使用される証明書のシリアル化された値であり、[RFC7468]あたりのオプションの内部白色宇宙。PEMヘッダーとフッターはオプションで削除されます。オプション。
cert#S256 (string):
CERT＃S256（文字列）：
The certificate thumbprint calculated as per MTLS for OAuth [RFC8705] in base64url encoding. Note that this format does not include the full public key. OPTIONAL.
base64urlエンコーディングでOAuth [RFC8705]のMTLに従って計算された証明書のサムプリント。この形式には完全な公開キーは含まれていないことに注意してください。オプション。
Additional key formats can be defined in the "GNAP Key Formats" registry (Section 10.17).
追加のキー形式は、「GNAPキー形式」レジストリ（セクション10.17）で定義できます。
The following non-normative example shows a single key presented in two different formats. The example key is intended to be used with the HTTP message signatures proofing mechanism (Section 7.3.1), as indicated by the httpsig value of the proof field.
次の非規範的な例は、2つの異なる形式で提示された単一のキーを示しています。例キーは、証明フィールドのHTTPSIG値で示されるように、HTTPメッセージシグネチャの証明メカニズム（セクション7.3.1）で使用することを目的としています。
As a JWK:
JWKとして：
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-1",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."
}
}
As a certificate in PEM format:
PEM形式の証明書として：
"key": {
"proof": "httpsig",
"cert": "MIIEHDCCAwSgAwIBAgIBATANBgkqhkiG9w0BAQsFA..."
}
When the key is presented in GNAP, proof of this key material MUST be used to bind the request, the nature of which varies with the location in the protocol where the key is used. For a key used as part of a client instance's initial request in Section 2.3, the key value represents the client instance's public key, and proof of that key MUST be presented in that request. For a key used as part of an access token response in Section 3.2.1, the proof of that key MUST be used when the client instance later presents the access token to the RS.
キーがGNAPで提示される場合、このキー資料の証明を使用してリクエストをバインドする必要があります。その性質は、キーが使用されるプロトコルの場所によって異なります。セクション2.3のクライアントインスタンスの最初の要求の一部として使用されるキーの場合、キー値はクライアントインスタンスの公開キーを表し、そのキーの証明はその要求で提示する必要があります。セクション3.2.1のアクセストークン応答の一部として使用されるキーの場合、クライアントインスタンスが後でRSへのアクセストークンを提示する場合、そのキーの証明を使用する必要があります。
Keys in GNAP can also be passed by reference such that the party receiving the reference will be able to determine the appropriate keying material for use in that part of the protocol. A key reference is a single opaque string.
GNAPのキーは、参照を受け取る当事者がプロトコルのその部分で使用する適切なキーイング材料を決定できるように、参照によって渡すこともできます。重要な参照は、単一の不透明な文字列です。
"key": "S-P4XJQ_RYJCRTSU1.63N3E"
Keys referenced in this manner MAY be shared symmetric keys. See the additional considerations for symmetric keys in Section 11.7. The key reference MUST NOT contain any unencrypted private or shared symmetric key information.
この方法で参照されるキーは、対称キーを共有できます。セクション11.7の対称キーに関する追加の考慮事項を参照してください。キーリファレンスには、暗号化されていないプライベートまたは共有対称キー情報を含めてはなりません。
Keys referenced in this manner MUST be bound to a single proofing mechanism.
この方法で参照されるキーは、単一のプルーフメカニズムに拘束されなければなりません。
The means of dereferencing this reference to a key value and proofing mechanism are out of scope for this specification. Commonly, key references are created by the AS and do not necessarily need to be understood by the client. These types of key references are an internal reference to the AS, such as an identifier of a record in a database. In other applications, it can be useful to use key references that are resolvable by both clients and the AS, which could be accomplished by a client publishing a public key at a URI, for example. For interoperability, this method could later be described as an extension, but doing so is out of scope for this specification.
この参照を重要な値とプルーフメカニズムへの参照を参照する手段は、この仕様の範囲外です。一般的に、主要な参照はASによって作成され、必ずしもクライアントが理解する必要はありません。これらのタイプの重要な参照は、データベース内のレコードの識別子など、ASへの内部参照です。他のアプリケーションでは、クライアントとASの両方が解決できるキー参照を使用すると便利です。これは、クライアントがURIで公開キーを公開することで実現できます。相互運用性のために、この方法は後で拡張機能として説明できますが、そうすることはこの仕様の範囲外です。
The security of GNAP relies on the cryptographic security of the keys themselves. When symmetric keys are used in GNAP, a key management system or secure key derivation mechanism MUST be used to supply the keys. Symmetric keys MUST NOT be a human-memorable password or a value derived from one. Symmetric keys MUST NOT be passed by value from the client instance to the AS.
GNAPのセキュリティは、キー自体の暗号化セキュリティに依存しています。GNAPで対称キーを使用する場合、キーを提供するためにキー管理システムまたは安全なキー導入メカニズムを使用する必要があります。対称キーは、人間の感情的なパスワードや、1つから派生した値であってはなりません。対称キーは、クライアントインスタンスからASに値で渡さないでください。
Additional security considerations apply when rotating keys (see Section 11.22).
キーを回転させる場合、追加のセキュリティ上の考慮事項が適用されます（セクション11.22を参照）。
Access tokens are issued to client instances in GNAP to allow the client instance to make an authorized call to an API. The method the client instance uses to send an access token depends on whether the token is bound to a key and, if so, which proofing method is associated with the key. This information is conveyed by the key parameter and the bearer flag in the access token response structure (Section 3.2.1).
アクセストークンは、GNAPのクライアントインスタンスに発行され、クライアントインスタンスがAPIに承認された呼び出しを行うことができます。クライアントインスタンスがアクセストークンを送信するために使用するメソッドは、トークンがキーにバインドされているかどうかによって異なります。この情報は、アクセストークン応答構造（セクション3.2.1）のキーパラメーターとベアラーフラグによって伝えられます。
If the flags field does not contain the bearer flag and the key is absent, the access token MUST be sent using the same key and proofing mechanism that the client instance used in its initial request (or its most recent rotation).
FlagsフィールドにBearerフラグが含まれておらず、キーが存在しない場合、アクセストークンは、クライアントインスタンスが最初の要求（または最新の回転）で使用したのと同じキーとプルーフメカニズムを使用して送信する必要があります。
If the flags field does not contain the bearer flag and the key value is an object as described in Section 7.1, the access token MUST be sent using the key and proofing mechanism defined by the value of the proof field within the key object.
FlagsフィールドにBearerフラグが含まれておらず、キー値がセクション7.1で説明されているオブジェクトである場合、アクセストークンは、キーオブジェクト内のプルーフフィールドの値によって定義されたキーおよびプルーフメカニズムを使用して送信する必要があります。
The access token MUST be sent using the HTTP Authorization request header field and the "GNAP" authorization scheme along with a key proof as described in Section 7.3 for the key bound to the access token. For example, an access token bound using HTTP message signatures would be sent as follows:
Accessトークンは、HTTP認証要求ヘッダーフィールドと「GNAP」認証スキームと、アクセストークンに縛られたキーのセクション7.3で説明されているキー証明とともに、送信する必要があります。たとえば、HTTPメッセージ署名を使用してバインドされたアクセストークンは次のように送信されます。
NOTE: '\' line wrapping per RFC 8792
GET /stuff HTTP/1.1
Host: resource.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=("@method" "@target-uri" "authorization")\
;created=1618884473;keyid="gnap-rsa";nonce="NAOEJF12ER2";tag="gnap"
Signature: sig1=:FQ+EjWqc38uLFByKa5y+c4WyYYwCTGUhidWKfr5L1Cha8FiPEw\
DxG7nWttpBLS/B6VLfkZJogPbclySs9MDIsAIJwHnzlcJjwXWR2lfvm2z3X7EkJHm\
Zp4SmyKOS34luAiKR1xwf32NYFolHmZf/SbHZJuWvQuS4U33C+BbsXz8MflFH1Dht\
H/C1E5i244gSbdLCPxzABc/Q0NHVSLo1qaouYIvnxXB8OT3K7mwWjsLh1GC5vFThb\
3XQ363r6f0OPRa4qWHhubR/d/J/lNOjbBdjq9AJ69oqNJ+A2XT+ZCrVasEJE0OBvD\
auQoiywhb8BMB7+PEINsPk5/8UvaNxbw==:
If the flags field contains the bearer flag, the access token is a bearer token that MUST be sent using the Authorization request header field method defined in [RFC6750].
FlagsフィールドにBearerフラグが含まれている場合、アクセストークンは[RFC6750]で定義された承認要求ヘッダーフィールドメソッドを使用して送信する必要があるベアラートークンです。
Authorization: Bearer OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0
The Form-Encoded Body Parameter and URI Query Parameter methods of [RFC6750] MUST NOT be used for GNAP access tokens.
[RFC6750]のフォームエンコードボディパラメーターとURIクエリパラメーターメソッドは、GNAPアクセストークンに使用してはなりません。
Any keys presented by the client instance to the AS or RS MUST be validated as part of the request in which they are presented. The type of binding used is indicated by the proof parameter of the key object in Section 7.1. Key proofing methods are specified either by a string, which consists of the key proofing method name on its own, or by a JSON object with the required field method:
クライアントインスタンスによってASまたはRSに提示されたキーは、それらが提示される要求の一部として検証する必要があります。使用されるバインディングのタイプは、セクション7.1のキーオブジェクトの証明パラメーターによって示されます。キープルーフメソッドは、文字列によって指定されています。文字列は、それ自体のキープルーフメソッド名で構成されているか、必要なフィールド方法を備えたJSONオブジェクトで構成されています。
method:
方法：
The name of the key proofing method to be used. REQUIRED.
使用する重要な校正方法の名前。必須。
Individual methods defined as objects MAY define additional parameters as members in this object.
オブジェクトとして定義された個々のメソッドは、このオブジェクトのメンバーとして追加のパラメーターを定義できます。
Values for the method defined by this specification are as follows:
この仕様で定義された方法の値は次のとおりです。
"httpsig" (string or object):
「httpsig」（文字列またはオブジェクト）：
HTTP message signing. See Section 7.3.1.
HTTPメッセージ署名。セクション7.3.1を参照してください。
"mtls" (string):
「MTLS」（文字列）：
MTLS certificate verification. See Section 7.3.2.
MTLS証明書の確認。セクション7.3.2を参照してください。
"jwsd" (string):
「JWSD」（文字列）：
A detached JWS signature header. See Section 7.3.3.
独立したJWS署名ヘッダー。セクション7.3.3を参照してください。
"jws" (string):
「JWS」（文字列）：
Attached JWS Payload. See Section 7.3.4.
JWSペイロードが添付されています。セクション7.3.4を参照してください。
Additional proofing methods can be defined in the "GNAP Key Proofing Methods" registry (Section 10.16).
追加の校正方法は、「GNAPキープルーフメソッド」レジストリ（セクション10.16）で定義できます。
Proofing methods MAY be defined as both an object and a string. For example, the httpsig method can be specified as an object with its parameters explicitly declared, such as:
校正方法は、オブジェクトと文字列の両方として定義される場合があります。たとえば、HTTPSIGメソッドは、次のようなパラメーターを明示的に宣言したオブジェクトとして指定できます。
{
"proof": {
"method": "httpsig",
"alg": "ecdsa-p384-sha384",
"content-digest-alg": "sha-256"
}
}
The httpsig method also defines default behavior when it is passed as a string form, using the signature algorithm specified by the associated key material and the content digest is calculated using sha-256. This configuration can be selected using the following shortened form:
HTTPSIGメソッドは、関連するキーマテリアルで指定された署名アルゴリズムを使用して、SHA-256を使用して計算される署名アルゴリズムを使用して、文字列形式として渡されるときにデフォルトの動作も定義します。この構成は、次の短縮フォームを使用して選択できます。
{
"proof": "httpsig"
}
All key binding methods used by this specification MUST cover all relevant portions of the request, including anything that would change the nature of the request, to allow for secure validation of the request. Relevant aspects include the URI being called, the HTTP method being used, any relevant HTTP headers and values, and the HTTP message content itself. The verifier of the signed message MUST validate all components of the signed message to ensure that nothing has been tampered with or substituted in a way that would change the nature of the request. Definitions of key binding methods MUST enumerate how these requirements are fulfilled.
この仕様で使用されるすべての重要なバインディング方法は、リクエストの性質を変更するものを含め、リクエストの性質を変更するために、リクエストのすべての関連部分をカバーする必要があります。関連する側面には、URIが呼び出されること、使用されているHTTPメソッド、関連するHTTPヘッダーと値、およびHTTPメッセージコンテンツ自体が含まれます。署名されたメッセージの検証者は、署名されたメッセージのすべてのコンポーネントを検証して、リクエストの性質を変える方法で改ざんされたり、置換されたりしないことを確認する必要があります。重要なバインディング方法の定義は、これらの要件がどのように満たされるかを列挙する必要があります。
When a key proofing mechanism is bound to an access token, the key being presented MUST be the key associated with the access token, and the access token MUST be covered by the signature method of the proofing mechanism.
キープルーフメカニズムがアクセストークンに結合している場合、提示されるキーはアクセストークンに関連付けられているキーでなければならず、アクセストークンはプルーフメカニズムの署名方法でカバーする必要があります。
The key binding methods in this section MAY be used by other components making calls as part of GNAP, such as the extensions allowing the RS to make calls to the AS defined in [GNAP-RS]. To facilitate this extended use, "signer" and "verifier" are used as generic terms in the subsections below. In the core functions of GNAP specified in this document, the "signer" is the client instance, and the "verifier" is the AS (for grant requests) or RS (for resource requests), as appropriate.
このセクションの主要な結合方法は、RSが[GNAP-RS]で定義されているASに呼び出しを行うことを可能にする拡張機能など、GNAPの一部として呼び出しを行う他のコンポーネントで使用できます。この拡張された使用を容易にするために、以下のサブセクションでは「署名者」と「検証剤」が一般的な用語として使用されます。このドキュメントで指定されたGNAPのコア関数では、「署名者」はクライアントインスタンスであり、「検証者」は必要に応じてAS（付与要求の場合）またはRS（リソース要求の場合）です。
When used for delegation in GNAP, these key binding mechanisms allow the AS to ensure that the keys presented by the client instance in the initial request are in control of the party calling any follow-up or continuation requests. To facilitate this requirement, the continuation response (Section 3.1) includes an access token bound to the client instance's key (Section 2.3), and that key (or its most recent rotation) MUST be proved in all continuation requests (Section 5). Token management requests (Section 6) are similarly bound to either the access token's own key or, in the case of bearer tokens, the client instance's key.
GNAPの委任に使用すると、これらの重要な結合メカニズムにより、最初の要求でクライアントインスタンスによって提示されたキーが、フォローアップまたは継続要求を呼び出す当事者の制御にあることを保証することができます。この要件を容易にするために、継続応答（セクション3.1）には、クライアントインスタンスのキー（セクション2.3）にバインドされたアクセストークンが含まれ、そのキー（または最新の回転）はすべての継続要求（セクション5）で証明する必要があります。トークン管理リクエスト（セクション6）は、同様にアクセストークン独自のキーまたは、Bearer Tokensの場合、クライアントインスタンスのキーのいずれかに結合されます。
In the following subsections, unless otherwise noted, the RS256 JSON Object Signing and Encryption (JOSE) signature algorithm (defined in Section 3.3 of [RFC7518]) is applied using the following RSA key (presented here in JWK format):
次のサブセクションでは、特に明記しない限り、RS256 JSONオブジェクトの署名および暗号化（Jose）署名アルゴリズム（[RFC7518]のセクション3.3で定義）は、次のRSAキー（JWK形式で示されています）を使用して適用されます。
NOTE: '\' line wrapping per RFC 8792
{
"kid": "gnap-rsa",
"p": "xS4-YbQ0SgrsmcA7xDzZKuVNxJe3pCYwdAe6efSy4hdDgF9-vhC5gjaRk\
i1wWuERSMW4Tv44l5HNrL-Bbj_nCJxr_HAOaesDiPn2PnywwEfg3Nv95Nn-\
eilhqXRaW-tJKEMjDHu_fmJBeemHNZI412gBnXdGzDVo22dvYoxd6GM",
"kty": "RSA",
"q": "rVdcT_uy-CD0GKVLGpEGRR7k4JO6Tktc8MEHkC6NIFXihk_6vAIOCzCD6\
LMovMinOYttpRndKoGTNdJfWlDFDScAs8C5n2y1STCQPRximBY-bw39-aZq\
JXMxOLyPjzuVgiTOCBIvLD6-8-mvFjXZk_eefD0at6mQ5qV3U1jZt88",
"d": "FHlhdTF0ozTliDxMBffT6aJVKZKmbbFJOVNten9c3lXKB3ux3NAb_D2dB\
7inp9EV23oWrDspFtvCvD9dZrXgRKMHofkEpo_SSvBZfgtH-OTkbY_TqtPF\
FLPKAw0JX5cFPnn4Q2xE4n-dQ7tpRCKl59vZLHBrHShr90zqzFp0AKXU5fj\
b1gC9LPwsFA2Fd7KXmI1drQQEVq9R-o18Pnn4BGQNQNjO_VkcJTiBmEIVT_\
KJRPdpVJAmbgnYWafL_hAfeb_dK8p85yurEVF8nCK5oO3EPrqB7IL4UqaEn\
5Sl3u0j8x5or-xrrAoNz-gdOv7ONfZY6NFoa-3f8q9wBAHUuQ",
"e": "AQAB",
"qi": "ogpNEkDKg22Rj9cDV_-PJBZaXMk66Fp557RT1tafIuqJRHEufSOYnsto\
bWPJ0gHxv1gVJw3gm-zYvV-wTMNgr2wVsBSezSJjPSjxWZtmT2z68W1DuvK\
kZy15vz7Jd85hmDlriGcXNCoFEUsGLWkpHH9RwPIzguUHWmTt8y0oXyI",
"dp": "dvCKGI2G7RLh3WyjoJ_Dr6hZ3LhXweB3YcY3qdD9BnxZ71mrLiMQg4c_\
EBnwqCETN_5sStn2cRc2JXnvLP3G8t7IFKHTT_i_TSTacJ7uT04MSa053Y3\
RfwbvLjRNPR0UKAE3ZxROUoIaVNuU_6-QMf8-2ilUv2GIOrCN87gP_Vk",
"alg": "RS256",
"dq": "iMZmELaKgT9_W_MRT-UfDWtTLeFjIGRW8aFeVmZk9R7Pnyt8rNzyN-IQ\
M40ql8u8J6vc2GmQGfokLlPQ6XLSCY68_xkTXrhoU1f-eDntkhP7L6XawSK\
Onv5F2H7wyBQ75HUmHTg8AK2B_vRlMyFKjXbVlzKf4kvqChSGEz4IjQ",
"n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8BfYdHsFzAt\
YKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZGYX\
jHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZx\
e0jRETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0\
bunS0K3bA_3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kO\
zywzwPTuq-cVQDyEN7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"
}
Key proofing methods SHOULD define a mechanism to allow the rotation of keys discussed in Section 6.1.1. Key rotation mechanisms MUST define a way for presenting proof of two keys simultaneously with the following attributes:
キープルーフ方法は、セクション6.1.1で説明されているキーの回転を可能にするメカニズムを定義する必要があります。キーローテーションメカニズムは、次の属性と同時に2つのキーの証明を提示する方法を定義する必要があります。
* The value of or reference to the new key material MUST be signed by the existing key. Generally speaking, this amounts to using the existing key to sign the content of the message that contains the new key.
* 新しいキー資料の値または参照は、既存のキーによって署名する必要があります。一般的に言えば、これは既存のキーを使用して、新しいキーを含むメッセージのコンテンツに署名することになります。
* The signature of the old key MUST be signed by the new key. Generally speaking, this means including the signature value of the old key under the coverage of the new key.
* 古いキーの署名は、新しいキーによって署名する必要があります。一般的に言えば、これは、新しいキーのカバレッジの下で古いキーの署名値を含めることを意味します。
This method is indicated by the method value httpsig and can be declared in either object form or string form.
この方法は、メソッド値httpsigで示され、オブジェクト形式または文字列形式のいずれかで宣言できます。
When the proofing method is specified in object form, the following parameters are defined:
校正方法がオブジェクト形式で指定されている場合、次のパラメーターが定義されています。
alg:
alg:
The HTTP signature algorithm, from the "HTTP Signature Algorithms" registry. REQUIRED.
「HTTP署名アルゴリズム」レジストリからのHTTP署名アルゴリズム。必須。
content-digest-alg:
Content-Digest-Alg：
The algorithm used for the Content-Digest field, used to protect the content when present in the message. REQUIRED.
コンテンツダイジストフィールドに使用されるアルゴリズムは、メッセージに存在するときにコンテンツを保護するために使用されます。必須。
This example uses the Elliptic Curve Digital Signature Algorithm (ECDSA) signing algorithm over the P384 curve and the SHA-512 hashing algorithm for the content digest.
この例では、P384曲線とコンテンツダイジェストのSHA-512ハッシュアルゴリズムを介した楕円曲線デジタル署名アルゴリズム（ECDSA）署名アルゴリズムを使用しています。
{
"proof": {
"method": "httpsig",
"alg": "ecdsa-p384-sha384",
"content-digest-alg": "sha-512"
}
}
When the proofing method is specified in string form, the signing algorithm MUST be derived from the key material (such as using the JWS algorithm in a JWK formatted key), and the content digest algorithm MUST be sha-256.
校正方法が文字列形式で指定されている場合、署名アルゴリズムはキー素材（JWK形式のキーでJWSアルゴリズムを使用するなど）から導き出され、コンテンツダイジェストアルゴリズムはSHA-256でなければなりません。
{
"proof": "httpsig"
}
When using this method, the signer creates an HTTP message signature as described in [RFC9421]. The covered components of the signature MUST include the following:
この方法を使用する場合、署名者は[RFC9421]で説明されているようにHTTPメッセージ署名を作成します。署名の対象コンポーネントには、以下を含める必要があります。
"@method":
"@方法"：
The method used in the HTTP request.
HTTP要求で使用される方法。
"@target-uri":
「@target-uri」：
The full request URI of the HTTP request.
HTTP要求のフルリクエストURI。
When the message contains request content, the covered components MUST also include the following:
メッセージにリクエストコンテンツが含まれている場合、対象コンポーネントには次のものも含める必要があります。
"content-digest":
「コンテンツダイジェスト」：
The Content-Digest header as defined in [RFC9530]. When the request message has content, the signer MUST calculate this field value and include the field in the request. The verifier MUST validate this field value. REQUIRED when the message request contains message content.
[RFC9530]で定義されているコンテンツダイジストヘッダー。要求メッセージにコンテンツがある場合、署名者はこのフィールド値を計算し、リクエストにフィールドを含める必要があります。検証者は、このフィールド値を検証する必要があります。メッセージ要求にメッセージコンテンツが含まれている場合に必要です。
When the request is bound to an access token, the covered components MUST also include the following:
リクエストがアクセストークンにバインドされている場合、対象コンポーネントには以下も含める必要があります。
"authorization":
「承認」：
The Authorization header used to present the access token as discussed in Section 7.2.
セクション7.2で説明したように、アクセストークンを提示するために使用される承認ヘッダー。
Other message components MAY also be included.
他のメッセージコンポーネントも含めることができます。
The signer MUST include the tag signature parameter with the value gnap, and the verifier MUST verify that the parameter exists with this value. The signer MUST include the created signature parameter with a timestamp of when the signature was created, and the verifier MUST ensure that the creation timestamp is sufficiently close to the current time given expected network delay and clock skew. The signer SHOULD include the nonce parameter with a unique and unguessable value. When included, the verifier MUST determine that the nonce value is unique within a reasonably short time period such as several minutes.
署名者は、値GNAPを備えたタグ署名パラメーターを含める必要があり、検証者はこの値にパラメーターが存在することを確認する必要があります。署名者は、作成された署名パラメーターを作成した時期のタイムスタンプを含む必要があり、検証者は、予想されるネットワーク遅延とクロックスキューが与えられた現在の時間に、作成タイムスタンプが現在の時間に十分に近いことを確認する必要があります。署名者には、一意で不可能な値を持つNONCEパラメーターを含める必要があります。含まれている場合、検証者は、数分など、合理的に短い期間内にノンセ値が一意であると判断する必要があります。
If the signer's key presented is a JWK, the keyid parameter of the signature MUST be set to the kid value of the JWK, and the signing algorithm used MUST be the JWS algorithm denoted by the key's alg field of the JWK.
提示された署名者の鍵がJWKである場合、署名のKeyIDパラメーターはJWKのKID値に設定する必要があり、使用される署名アルゴリズムはJWKのキーのアルグフィールドで示されるJWSアルゴリズムでなければなりません。
The explicit alg signature parameter MUST NOT be included in the signature, since the algorithm will be derived from either the key material or the proof value.
アルゴリズムはキーマテリアルまたはプルーフ値のいずれかから導出されるため、明示的なアルグ署名パラメーターを署名に含めてはなりません。
In the following non-normative example, the message content is a JSON object:
次の非規範的な例では、メッセージコンテンツはJSONオブジェクトです。
NOTE: '\' line wrapping per RFC 8792
{
"access_token": {
"access": [
"dolphin-metadata"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.foo/callback",
"nonce": "VJLO6A4CAYLBXHTR0KRO"
}
},
"client": {
"key": {
"proof": "httpsig",
"jwk": {
"kid": "gnap-rsa",
"kty": "RSA",
"e": "AQAB",
"alg": "PS512",
"n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\
YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\
YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\
ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\
3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\
N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"
}
}
"display": {
"name": "My Client Display Name",
"uri": "https://client.foo/"
},
}
}
This content is hashed for the Content-Digest header using sha-256 into the following encoded value:
このコンテンツは、SHA-256を使用して、次のエンコード値にコンテンツダイジェストヘッダーにハッシュされています。
sha-256=:q2XBmzRDCREcS2nWo/6LYwYyjrlN1bRfv+HKLbeGAGg=:
The HTTP message signature input string is calculated to be the following:
HTTPメッセージ署名入力文字列は、次のように計算されます。
NOTE: '\' line wrapping per RFC 8792
"@method": POST
"@target-uri": https://server.example.com/gnap
"content-digest": \
sha-256=:q2XBmzRDCREcS2nWo/6LYwYyjrlN1bRfv+HKLbeGAGg=:
"content-length": 988
"content-type": application/json
"@signature-params": ("@method" "@target-uri" "content-digest" \
"content-length" "content-type");created=1618884473\
;keyid="gnap-rsa";nonce="NAOEJF12ER2";tag="gnap"
This leads to the following full HTTP message request:
これは、次の完全なHTTPメッセージリクエストにつながります。
NOTE: '\' line wrapping per RFC 8792
POST /gnap HTTP/1.1
Host: server.example.com
Content-Type: application/json
Content-Length: 988
Content-Digest: sha-256=:q2XBmzRDCREcS2nWo/6LYwYyjrlN1bRfv+HKLbeGAG\
g=:
Signature-Input: sig1=("@method" "@target-uri" "content-digest" \
"content-length" "content-type");created=1618884473\
;keyid="gnap-rsa";nonce="NAOEJF12ER2";tag="gnap"
Signature: sig1=:c2uwTa6ok3iHZsaRKl1ediKlgd5cCAYztbym68XgX8gSOgK0Bt\
+zLJ19oGjSAHDjJxX2gXP2iR6lh9bLMTfPzbFVn4Eh+5UlceP+0Z5mES7v0R1+eHe\
OqBl0YlYKaSQ11YT7n+cwPnCSdv/6+62m5zwXEEftnBeA1ECorfTuPtau/yrTYEvD\
9A/JqR2h9VzAE17kSlSSsDHYA6ohsFqcRJavX29duPZDfYgkZa76u7hJ23yVxoUpu\
2J+7VUdedN/72N3u3/z2dC8vQXbzCPTOiLru12lb6vnBZoDbUGsRR/zHPauxhj9T+\
218o5+tgwYXw17othJSxIIOZ9PkIgz4g==:
{
"access_token": {
"access": [
"dolphin-metadata"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.foo/callback",
"nonce": "VJLO6A4CAYLBXHTR0KRO"
}
},
"client": {
"key": {
"proof": "httpsig",
"jwk": {
"kid": "gnap-rsa",
"kty": "RSA",
"e": "AQAB",
"alg": "PS512",
"n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\
YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\
YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\
ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\
3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\
N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"
}
}
"display": {
"name": "My Client Display Name",
"uri": "https://client.foo/"
},
}
}
The verifier MUST ensure that the signature covers all required message components. If the HTTP message includes content, the verifier MUST calculate and verify the value of the Content-Digest header. The verifier MUST validate the signature against the expected key of the signer.
検証者は、署名が必要なすべてのメッセージコンポーネントをカバーすることを確認する必要があります。HTTPメッセージにコンテンツが含まれている場合、検証者はコンテンツダイジストヘッダーの値を計算して検証する必要があります。検証者は、署名者の予想されるキーに対して署名を検証する必要があります。
A received message MAY include multiple signatures, each with its own label. The verifier MUST examine all included signatures until it finds (at least) one that is acceptable according to its policy and meets the requirements in this section.
受信したメッセージには、それぞれが独自のラベルを備えた複数の署名が含まれる場合があります。検証者は、（少なくとも）その方針に従って許容され、このセクションの要件を満たす（少なくとも）署名が見つかるまで、すべての署名を検討する必要があります。
When rotating a key using HTTP message signatures, the message, which includes the new public key value or reference, is first signed with the old key following all of the requirements in Section 7.3.1. The message is then signed again with the new key by following all of the requirements in Section 7.3.1 again, with the following additional requirements:
HTTPメッセージ署名を使用してキーを回転させる場合、新しい公開キー値または参照を含むメッセージは、セクション7.3.1のすべての要件に従って古いキーで最初に署名されます。次の追加要件を使用して、セクション7.3.1のすべての要件に再び従うことにより、メッセージは新しいキーと再び署名されます。
* The covered components MUST include the Signature and Signature-Input values from the signature generated with the old key.
* 対象コンポーネントには、古いキーで生成された署名から署名と署名の入力値を含める必要があります。
* The tag value MUST be gnap-rotate.
* タグ値はGNAP-rotateでなければなりません。
For example, the following request to the token management endpoint for rotating a token value contains the new key in the request. The message is first signed using the old key, and the resulting signature is placed in "old-key":
たとえば、トークン値を回転させるためのトークン管理エンドポイントへの次の要求には、リクエストの新しいキーが含まれています。メッセージは最初に古いキーを使用して署名され、結果の署名は「オールドキー」に配置されます。
NOTE: '\' line wrapping per RFC 8792
POST /token/PRY5NM33 HTTP/1.1
Host: server.example.com
Authorization: GNAP 4398.34-12-asvDa.a
Content-Digest: sha-512=:Fb/A5vnawhuuJ5xk2RjGrbbxr6cvinZqd4+JPY85u/\
JNyTlmRmCOtyVhZ1Oz/cSS4tsYen6fzpCwizy6UQxNBQ==:
Signature-Input: old-key=("@method" "@target-uri" "content-digest" \
"authorization");created=1618884475;keyid="test-key-ecc-p256"\
;tag="gnap"
Signature: old-key=:vN4IKYsJl2RLFe+tYEm4dHM4R4BToqx5D2FfH4ge5WOkgxo\
dI2QRrjB8rysvoSEGvAfiVJOWsGcPD1lU639Amw==:
{
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-2",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."
}
}
}
The signer then creates a new signature using the new key, adding the signature input and value to the signature base.
署名者は、新しいキーを使用して新しい署名を作成し、署名の入力と値を署名ベースに追加します。
NOTE: '\' line wrapping per RFC 8792
"@method": POST
"@target-uri": https://server.example.com/token/PRY5NM33
"content-digest": sha-512=:Fb/A5vnawhuuJ5xk2RjGrbbxr6cvinZqd4+JPY85\
u/JNyTlmRmCOtyVhZ1Oz/cSS4tsYen6fzpCwizy6UQxNBQ==:
"authorization": GNAP 4398.34-12-asvDa.a
"signature";key="old-key": :YdDJjDn2Sq8FR82e5IcOLWmmf6wILoswlnRcz+n\
M+e8xjFDpWS2YmiMYDqUdri2UiJsZx63T1z7As9Kl6HTGkQ==:
"signature-input";key="old-key": ("@method" "@target-uri" \
"content-digest" "authorization");created=1618884475\
;keyid="test-key-ecc-p256";tag="gnap"
"@signature-params": ("@method" "@target-uri" "content-digest" \
"authorization" "signature";key="old-key" "signature-input"\
;key="old-key");created=1618884480;keyid="xyz-2"
;tag="gnap-rotate"
This signature is then added to the message:
次に、この署名がメッセージに追加されます。
NOTE: '\' line wrapping per RFC 8792
POST /token/PRY5NM33 HTTP/1.1
Host: server.example.com
Authorization: GNAP 4398.34-12-asvDa.a
Content-Digest: sha-512=:Fb/A5vnawhuuJ5xk2RjGrbbxr6cvinZqd4+JPY85u/\
JNyTlmRmCOtyVhZ1Oz/cSS4tsYen6fzpCwizy6UQxNBQ==:
Signature-Input: old-key=("@method" "@target-uri" "content-digest" \
"authorization");created=1618884475;keyid="test-key-ecc-p256"\
;tag="gnap", \
new-key=("@method" "@target-uri" "content-digest" \
"authorization" "signature";key="old-key" "signature-input"\
;key="old-key");created=1618884480;keyid="xyz-2"
;tag="gnap-rotate"
Signature: old-key=:vN4IKYsJl2RLFe+tYEm4dHM4R4BToqx5D2FfH4ge5WOkgxo\
dI2QRrjB8rysvoSEGvAfiVJOWsGcPD1lU639Amw==:, \
new-key=:VWUExXQ0geWeTUKhCfDT7WJyT++OHSVbfPA1ukW0o7mmstdbvIz9iOuH\
DRFzRBm0MQPFVMpLDFXQdE3vi2SL3ZjzcX2qLwzAtyRB9+RsV2caAA80A5ZGMoo\
gUsKPk4FFDN7KRUZ0vT9Mo9ycx9Dq/996TOWtAmq5z0YUYEwwn+T6+NcW8rFtms\
s1ZfXG0EoAfV6ve25p+x40Y1rvDHsfkakTRB4J8jWVDybSe39tjIKQBo3uicDVw\
twewBMNidIa+66iF3pWj8w9RSb0cncEgvbkHgASqaZeXmxxG4gM8p1HH9v/OqQT\
Oggm5gTWmCQs4oxEmWsfTOxefunfh3X+Qw==:
{
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-2",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8xY..."
}
}
}
The verifier MUST validate both signatures before processing the request for key rotation.
検証者は、キーローテーションのリクエストを処理する前に、両方の署名を検証する必要があります。
This method is indicated by the method value mtls in string form.
この方法は、文字列形式のメソッド値mtlで示されます。
{
"proof": "mtls"
}
The signer presents its TLS client certificate during TLS negotiation with the verifier.
署名者は、検証者とのTLS交渉中にTLSクライアント証明書を提示します。
In the following non-normative example, the certificate is communicated to the application through the Client-Cert header field from a TLS reverse proxy as per [RFC9440], leading to the following full HTTP request message:
次の非規範的な例では、証明書は[RFC9440]に従ってTLSリバースプロキシからクライアントキャットヘッダーフィールドを介してアプリケーションに通知され、次の完全なHTTP要求メッセージにつながります。
POST /gnap HTTP/1.1
Host: server.example.com
Content-Type: application/jose
Content-Length: 1567
Client-Cert: \
:MIIC6jCCAdKgAwIBAgIGAXjw74xPMA0GCSqGSIb3DQEBCwUAMDYxNDAyBgNVBAMM\
K05JWU15QmpzRGp5QkM5UDUzN0Q2SVR6a3BEOE50UmppOXlhcEV6QzY2bVEwHhcN\
MjEwNDIwMjAxODU0WhcNMjIwMjE0MjAxODU0WjA2MTQwMgYDVQQDDCtOSVlNeUJq\
c0RqeUJDOVA1MzdENklUemtwRDhOdFJqaTl5YXBFekM2Nm1RMIIBIjANBgkqhkiG\
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhYOJ+XOKISdMMShn/G4W9m20mT0VWtQBsmBB\
kI2cmRt4Ai8BfYdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8I\
kZ8NMwSrcUIBZGYXjHpwjzvfGvXH/5KJlnR3/uRUp4Z4Ujk2bCaKegDn11V2vxE4\
1hqaPUnhRZxe0jRETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo+\
uv4BC0bunS0K3bA/3UgVp7zBlQFoFnLTO2uWp/muLEWGl67gBq9MO3brKXfGhi3k\
OzywzwPTuq+cVQDyEN7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQIDAQABMA0GCSqG\
SIb3DQEBCwUAA4IBAQBnYFK0eYHy+hVf2D58usj39lhL5znb/q9G35GBd/XsWfCE\
wHuLOSZSUmG71bZtrOcx0ptle9bp2kKl4HlSTTfbtpuG5onSa3swRNhtKtUy5NH9\
W/FLViKWfoPS3kwoEpC1XqKY6l7evoTCtS+kTQRSrCe4vbNprCAZRxz6z1nEeCgu\
NMk38yTRvx8ihZpVOuU+Ih+dOtVe/ex5IAPYxlQsvtfhsUZqc7IyCcy72WHnRHlU\
fn3pJm0S5270+Yls3Iv6h3oBAP19i906UjiUTNH3g0xMW+V4uLxgyckt4wD4Mlyv\
jnaQ7Z3sR6EsXMocAbXHIAJhwKdtU/fLgdwL5vtx:
{
"access_token": {
"access": [
"dolphin-metadata"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.foo/callback",
"nonce": "VJLO6A4CAYLBXHTR0KRO"
}
},
"client": {
"key": {
"proof": "mtls",
"cert": "MIIC6jCCAdKgAwIBAgIGAXjw74xPMA0GCSqGSIb3DQEBCwUAMD\
YxNDAyBgNVBAMMK05JWU15QmpzRGp5QkM5UDUzN0Q2SVR6a3BEOE50UmppOXlhcEV\
6QzY2bVEwHhcNMjEwNDIwMjAxODU0WhcNMjIwMjE0MjAxODU0WjA2MTQwMgYDVQQD\
DCtOSVlNeUJqc0RqeUJDOVA1MzdENklUemtwRDhOdFJqaTl5YXBFekM2Nm1RMIIBI\
jANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhYOJ+XOKISdMMShn/G4W9m20mT\
0VWtQBsmBBkI2cmRt4Ai8BfYdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8\
KowlyVy8IkZ8NMwSrcUIBZGYXjHpwjzvfGvXH/5KJlnR3/uRUp4Z4Ujk2bCaKegDn\
11V2vxE41hqaPUnhRZxe0jRETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDad\
z8BkPo+uv4BC0bunS0K3bA/3UgVp7zBlQFoFnLTO2uWp/muLEWGl67gBq9MO3brKX\
fGhi3kOzywzwPTuq+cVQDyEN7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQIDAQABMA0\
GCSqGSIb3DQEBCwUAA4IBAQBnYFK0eYHy+hVf2D58usj39lhL5znb/q9G35GBd/Xs\
WfCEwHuLOSZSUmG71bZtrOcx0ptle9bp2kKl4HlSTTfbtpuG5onSa3swRNhtKtUy5\
NH9W/FLViKWfoPS3kwoEpC1XqKY6l7evoTCtS+kTQRSrCe4vbNprCAZRxz6z1nEeC\
guNMk38yTRvx8ihZpVOuU+Ih+dOtVe/ex5IAPYxlQsvtfhsUZqc7IyCcy72WHnRHl\
Ufn3pJm0S5270+Yls3Iv6h3oBAP19i906UjiUTNH3g0xMW+V4uLxgyckt4wD4Mlyv\
jnaQ7Z3sR6EsXMocAbXHIAJhwKdtU/fLgdwL5vtx"
}
"display": {
"name": "My Client Display Name",
"uri": "https://client.foo/"
},
},
"subject": {
"formats": ["iss_sub", "opaque"]
}
}
The verifier compares the TLS client certificate presented during MTLS negotiation to the expected key of the signer. Since the TLS connection covers the entire message, there are no additional requirements to check.
Verifierは、MTLS交渉中に提示されたTLSクライアント証明書を、署名者の予想されるキーと比較します。TLS接続はメッセージ全体をカバーするため、確認する追加の要件はありません。
Note that in many instances, the verifier will not do a full certificate chain validation of the presented TLS client certificate, as the means of trust for this certificate could be in something other than a PKI system, such as a static registration or trust-on-first-use. See Sections 11.3 and 11.4 for some additional considerations for this key proofing method.
多くの場合、この証明書の信頼の手段は、静的登録や信頼範囲などのPKIシステム以外のものである可能性があるため、検証者は提示されたTLSクライアント証明書の完全な証明書チェーン検証を行わないことに注意してください。- 最初の使用。この重要な校正方法については、いくつかの追加の考慮事項については、セクション11.3および11.4を参照してください。
Since it is not possible to present two client authenticated certificates to a MTLS connection simultaneously, dynamic key rotation for this proofing method is not defined. Instead, key rotation for MTLS-based client instances is expected to be managed through deployment practices, as discussed in Section 11.4.
2つのクライアント認証された証明書をMTLS接続に同時に提示することはできないため、このプルーフメソッドの動的キー回転は定義されていません。代わりに、セクション11.4で説明したように、MTLSベースのクライアントインスタンスの重要な回転は、展開プラクティスを通じて管理されると予想されます。
This method is indicated by the method value jwsd in string form.
この方法は、文字列形式のメソッド値JWSDで示されます。
{
"proof": "jwsd"
}
The signer creates a JSON Web Signature (JWS) [RFC7515] object as follows.
署名者は、次のようにJSON Web Signature（JWS）[RFC7515]オブジェクトを作成します。
To protect the request, the JOSE header of the signature contains the following claims:
リクエストを保護するために、署名のホセヘッダーには次のクレームが含まれています。
kid (string):
キッド（文字列）：
The key identifier. REQUIRED if the key is presented in JWK format. This MUST be the value of the kid field of the key.
キー識別子。キーがJWK形式で表示されている場合に必要です。これは、キーの子供フィールドの価値でなければなりません。
alg (string):
アルグ（文字列）：
The algorithm used to sign the request. The algorithm MUST be appropriate to the key presented. If the key is presented as a JWK, this MUST be equal to the alg parameter of the key. The algorithm MUST NOT be none. REQUIRED.
リクエストに署名するために使用されるアルゴリズム。アルゴリズムは、提示されたキーに適している必要があります。キーがJWKとして提示されている場合、これはキーのアルグパラメーターに等しくなければなりません。アルゴリズムは誰でもないはずです。必須。
typ (string):
typ（文字列）：
The type header, value "gnap-binding-jwsd". REQUIRED.
タイプヘッダー、値「GNAPバインディング-JWSD」。必須。
htm (string):
HTM（文字列）：
The HTTP method used to make this request, as a case-sensitive ASCII string. Note that most public HTTP methods are in uppercase ASCII by convention. REQUIRED.
ケースに敏感なASCII文字列として、この要求を行うために使用されるHTTPメソッド。ほとんどのパブリックHTTPメソッドは、慣習により大文字のASCIIにあることに注意してください。必須。
uri (string):
uri（string）：
The HTTP URI used for this request. This value MUST be an absolute URI, including all path and query components and no fragment components. REQUIRED.
このリクエストに使用されるHTTP URI。この値は、すべてのパスとクエリコンポーネントやフラグメントコンポーネントなしを含む絶対的なURIでなければなりません。必須。
created (integer):
作成（整数）：
A timestamp of when the signature was created, in integer seconds since UNIX Epoch. REQUIRED.
Unix Epochから数秒以内に、署名が作成されたときのタイムスタンプ。必須。
When the request is bound to an access token, the JOSE header MUST also include the following:
リクエストがアクセストークンにバインドされている場合、ホセヘッダーには次のものも含める必要があります。
ath (string):
ATH（文字列）：
The hash of the access token. The value MUST be the result of base64url encoding (with no padding) the SHA-256 digest of the ASCII encoding of the associated access token's value. REQUIRED.
アクセストークンのハッシュ。値は、関連するアクセストークンの値のASCIIエンコードのSHA-256ダイジェストを（パディングなしで）base64urlエンコードの結果でなければなりません。必須。
If the HTTP request has content (such as an HTTP POST or PUT method), the payload of the JWS object is the base64url encoding (without padding) of the SHA-256 digest of the bytes of the content. If the request being made does not have content (such as an HTTP GET, OPTIONS, or DELETE method), the JWS signature is calculated over an empty payload.
HTTP要求にコンテンツ（HTTP投稿やPUTメソッドなど）がある場合、JWSオブジェクトのペイロードは、コンテンツのバイトのSHA-256ダイジェストのbase64urlエンコード（パディングなし）です。行われているリクエストにコンテンツがない場合（HTTP GET、オプション、削除メソッドなど）、JWS署名は空のペイロードで計算されます。
The signer presents the signed object in compact form [RFC7515] in the Detached-JWS header field.
署名者は、Detached-JWSヘッダーフィールドにコンパクトな形式[RFC7515]で署名されたオブジェクトを提示します。
In the following non-normative example, the JOSE header contains the following parameters:
次の非規範的な例では、ホセヘッダーには次のパラメーターが含まれています。
{
"alg": "RS256",
"kid": "gnap-rsa",
"uri": "https://server.example.com/gnap",
"htm": "POST",
"typ": "gnap-binding-jwsd",
"created": 1618884475
}
The request content is the following JSON object:
リクエストコンテンツは次のJSONオブジェクトです。
NOTE: '\' line wrapping per RFC 8792
{
"access_token": {
"access": [
"dolphin-metadata"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.foo/callback",
"nonce": "VJLO6A4CAYLBXHTR0KRO"
}
},
"client": {
"key": {
"proof": "jwsd",
"jwk": {
"kid": "gnap-rsa",
"kty": "RSA",
"e": "AQAB",
"alg": "RS256",
"n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\
YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\
YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\
ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\
3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\
N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"
}
}
"display": {
"name": "My Client Display Name",
"uri": "https://client.foo/"
},
}
}
This is hashed to the following base64-encoded value:
これは、次のBase64エンコード値にハッシュされます。
PGiVuOZUcN1tRtUS6tx2b4cBgw9mPgXG3IPB3wY7ctc
This leads to the following full HTTP request message:
これにより、次の完全なHTTPリクエストメッセージが表示されます。
NOTE: '\' line wrapping per RFC 8792
POST /gnap HTTP/1.1
Host: server.example.com
Content-Type: application/json
Content-Length: 983
Detached-JWS: eyJhbGciOiJSUzI1NiIsImNyZWF0ZWQiOjE2MTg4ODQ0NzUsImh0b\
SI6IlBPU1QiLCJraWQiOiJnbmFwLXJzYSIsInR5cCI6ImduYXAtYmluZGluZytqd3\
NkIiwidXJpIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vZ25hcCJ9.PGiVuO\
ZUcN1tRtUS6tx2b4cBgw9mPgXG3IPB3wY7ctc.fUq-SV-A1iFN2MwCRW_yolVtT2_\
TZA2h5YeXUoi5F2Q2iToC0Tc4drYFOSHIX68knd68RUA7yHqCVP-ZQEd6aL32H69e\
9zuMiw6O_s4TBKB3vDOvwrhYtDH6fX2hP70cQoO-47OwbqP-ifkrvI3hVgMX9TfjV\
eKNwnhoNnw3vbu7SNKeqJEbbwZfpESaGepS52xNBlDNMYBQQXxM9OqKJaXffzLFEl\
-Xe0UnfolVtBraz3aPrPy1C6a4uT7wLda3PaTOVtgysxzii3oJWpuz0WP5kRujzDF\
wX_EOzW0jsjCSkL-PXaKSpZgEjNjKDMg9irSxUISt1C1T6q3SzRgfuQ
{
"access_token": {
"access": [
"dolphin-metadata"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.foo/callback",
"nonce": "VJLO6A4CAYLBXHTR0KRO"
}
},
"client": {
"key": {
"proof": "jwsd",
"jwk": {
"kid": "gnap-rsa",
"kty": "RSA",
"e": "AQAB",
"alg": "RS256",
"n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\
YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\
YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\
ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\
3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\
N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"
}
}
"display": {
"name": "My Client Display Name",
"uri": "https://client.foo/"
},
}
}
When the verifier receives the Detached-JWS header, it MUST parse and validate the JWS object. The signature MUST be validated against the expected key of the signer. If the HTTP message request contains content, the verifier MUST calculate the hash of the content just as the signer does, with no normalization or transformation of the request. All required fields MUST be present, and their values MUST be valid. All fields MUST match the corresponding portions of the HTTP message. For example, the htm field of the JWS header has to be the same as the HTTP verb used in the request.
検証器が分離したJWSヘッダーを受信した場合、JWSオブジェクトを解析および検証する必要があります。署名は、署名者の予想されるキーに対して検証する必要があります。HTTPメッセージ要求にコンテンツが含まれている場合、検証者は、署名者が行うようにコンテンツのハッシュを計算する必要があり、要求の正規化または変換はありません。必要なすべてのフィールドが存在する必要があり、その値は有効でなければなりません。すべてのフィールドは、HTTPメッセージの対応する部分と一致する必要があります。たとえば、JWSヘッダーのHTMフィールドは、リクエストで使用されているHTTP動詞と同じでなければなりません。
Note that this proofing method depends on a specific cryptographic algorithm, SHA-256, in two ways: 1) the ath hash algorithm is hardcoded and 2) the payload of the detached/attached signature is computed using a hardcoded hash. A future version of this document may address crypto-agility for both these uses by replacing ath with a new header that upgrades the algorithm and possibly defining a new JWS header that indicates the HTTP content's hash method.
この校正方法は、2つの方法で特定の暗号化アルゴリズムSHA-256に依存していることに注意してください。このドキュメントの将来のバージョンは、ATHをアルゴリズムをアップグレードする新しいヘッダーに置き換え、HTTPコンテンツのハッシュメソッドを示す新しいJWSヘッダーを定義することにより、これらの両方の用途の暗号能力に対処する場合があります。
When rotating a key using detached JWS, the message, which includes the new public key value or reference, is first signed with the old key as described above using a JWS object with typ header value "gnap-binding-rotation-jwsd". The value of the JWS object is then taken as the payload of a new JWS object, to be signed by the new key using the parameters above.
分離されたJWSを使用してキーを回転させるとき、新しい公開キー値または参照を含むメッセージは、型ヘッダー値「GNAPバインディング-Rotation-JWSD」を持つJWSオブジェクトを使用して上記のように古いキーで最初に署名されます。JWSオブジェクトの値は、上記のパラメーターを使用して新しいキーによって署名されるように、新しいJWSオブジェクトのペイロードと見なされます。
The value of the new JWS object is sent in the Detached-JWS header.
新しいJWSオブジェクトの値は、Detached-JWSヘッダーで送信されます。
This method is indicated by the method value jws in string form.
この方法は、文字列形式のメソッド値JWSで示されます。
{
"proof": "jws"
}
The signer creates a JWS [RFC7515] object as follows.
署名者は、次のようにJWS [RFC7515]オブジェクトを作成します。
To protect the request, the JWS header contains the following claims:
リクエストを保護するために、JWSヘッダーには次のクレームが含まれています。
kid (string):
キッド（文字列）：
The key identifier. REQUIRED if the key is presented in JWK format. This MUST be the value of the kid field of the key.
キー識別子。キーがJWK形式で表示されている場合に必要です。これは、キーの子供フィールドの価値でなければなりません。
alg (string):
アルグ（文字列）：
The algorithm used to sign the request. MUST be appropriate to the key presented. If the key is presented as a JWK, this MUST be equal to the alg parameter of the key. MUST NOT be none. REQUIRED.
リクエストに署名するために使用されるアルゴリズム。提示されたキーに適している必要があります。キーがJWKとして提示されている場合、これはキーのアルグパラメーターに等しくなければなりません。誰ではないに違いない。必須。
typ (string):
typ（文字列）：
The type header, value "gnap-binding-jws". REQUIRED.
タイプヘッダー、値「GNAPバインディング-JWS」。必須。
htm (string):
HTM（文字列）：
The HTTP method used to make this request, as a case-sensitive ASCII string. (Note that most public HTTP methods are in uppercase.) REQUIRED.
ケースに敏感なASCII文字列として、この要求を行うために使用されるHTTPメソッド。（ほとんどのパブリックHTTPメソッドは大文字であることに注意してください。）必要です。
uri (string):
uri（string）：
The HTTP URI used for this request, including all path and query components and no fragment components. REQUIRED.
すべてのパスとクエリコンポーネントとフラグメントコンポーネントなしを含む、このリクエストに使用されるHTTP URI。必須。
created (integer):
作成（整数）：
A timestamp of when the signature was created, in integer seconds since UNIX Epoch. REQUIRED.
Unix Epochから数秒以内に、署名が作成されたときのタイムスタンプ。必須。
When the request is bound to an access token, the JOSE header MUST also include the following:
リクエストがアクセストークンにバインドされている場合、ホセヘッダーには次のものも含める必要があります。
ath (string):
ATH（文字列）：
The hash of the access token. The value MUST be the result of base64url encoding (with no padding) the SHA-256 digest of the ASCII encoding of the associated access token's value. REQUIRED.
アクセストークンのハッシュ。値は、関連するアクセストークンの値のASCIIエンコードのSHA-256ダイジェストを（パディングなしで）base64urlエンコードの結果でなければなりません。必須。
If the HTTP request has content (such as an HTTP POST or PUT method), the payload of the JWS object is the JSON serialized content of the request, and the object is signed according to JWS and serialized into compact form [RFC7515]. The signer presents the JWS as the content of the request along with a content type of application/jose. The verifier MUST extract the payload of the JWS and treat it as the request content for further processing.
HTTPリクエストにコンテンツ（HTTP投稿やPUTメソッドなど）がある場合、JWSオブジェクトのペイロードはリクエストのJSONシリアル化コンテンツであり、オブジェクトはJWSに従って署名され、コンパクト形式にシリアル化されます[RFC7515]。署名者は、JWSをリクエストのコンテンツとして提示し、コンテンツタイプのアプリケーション/ホセを提示します。検証者は、JWSのペイロードを抽出し、さらに処理するための要求コンテンツとして扱う必要があります。
If the request being made does not have content (such as an HTTP GET, OPTIONS, or DELETE method), the JWS signature is calculated over an empty payload and passed in the Detached-JWS header as described in Section 7.3.3.
行われているリクエストにコンテンツがない場合（HTTP Get、Options、Deleteメソッドなど）、JWS署名は空のペイロードで計算され、セクション7.3.3で説明されている独立したJWSヘッダーに渡されます。
In the following non-normative example, the JOSE header contains the following parameters:
次の非規範的な例では、ホセヘッダーには次のパラメーターが含まれています。
{
"alg": "RS256",
"kid": "gnap-rsa",
"uri": "https://server.example.com/gnap",
"htm": "POST",
"typ": "gnap-binding-jws",
"created": 1618884475
}
The request content, used as the JWS Payload, is the following JSON object:
JWSペイロードとして使用されるリクエストコンテンツは、次のJSONオブジェクトです。
NOTE: '\' line wrapping per RFC 8792
{
"access_token": {
"access": [
"dolphin-metadata"
]
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.foo/callback",
"nonce": "VJLO6A4CAYLBXHTR0KRO"
}
},
"client": {
"key": {
"proof": "jws",
"jwk": {
"kid": "gnap-rsa",
"kty": "RSA",
"e": "AQAB",
"alg": "RS256",
"n": "hYOJ-XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf\
YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG\
YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR\
ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_\
3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE\
N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ"
}
}
"display": {
"name": "My Client Display Name",
"uri": "https://client.foo/"
},
},
"subject": {
"formats": ["iss_sub", "opaque"]
}
}
This leads to the following full HTTP request message:
これにより、次の完全なHTTPリクエストメッセージが表示されます。
NOTE: '\' line wrapping per RFC 8792
POST /gnap HTTP/1.1
Host: server.example.com
Content-Type: application/jose
Content-Length: 1047
eyJhbGciOiJSUzI1NiIsImNyZWF0ZWQiOjE2MTg4ODQ0NzUsImh0bSI6IlBPU1QiLCJ\
raWQiOiJnbmFwLXJzYSIsInR5cCI6ImduYXAtYmluZGluZytqd3NkIiwidXJpIjoiaH\
R0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vZ25hcCJ9.CnsKICAgICJhY2Nlc3NfdG9r\
ZW4iOiB7CiAgICAgICAgImFjY2VzcyI6IFsKICAgICAgICAgICAgImRvbHBoaW4tbWV\
0YWRhdGEiCiAgICAgICAgXQogICAgfSwKICAgICJpbnRlcmFjdCI6IHsKICAgICAgIC\
Aic3RhcnQiOiBbInJlZGlyZWN0Il0sCiAgICAgICAgImZpbmlzaCI6IHsKICAgICAgI\
CAgICAgIm1ldGhvZCI6ICJyZWRpcmVjdCIsCiAgICAgICAgICAgICJ1cmkiOiAiaHR0\
cHM6Ly9jbGllbnQuZm9vL2NhbGxiYWNrIiwKICAgICAgICAgICAgIm5vbmNlIjogIlZ\
KTE82QTRDQVlMQlhIVFIwS1JPIgogICAgICAgIH0KICAgIH0sCiAgICAiY2xpZW50Ij\
ogewogICAgICAicHJvb2YiOiAiandzIiwKICAgICAgImtleSI6IHsKICAgICAgICAia\
ndrIjogewogICAgICAgICAgICAia2lkIjogImduYXAtcnNhIiwKICAgICAgICAgICAg\
Imt0eSI6ICJSU0EiLAogICAgICAgICAgICAiZSI6ICJBUUFCIiwKICAgICAgICAgICA\
gImFsZyI6ICJSUzI1NiIsCiAgICAgICAgICAgICJuIjogImhZT0otWE9LSVNkTU1TaG\
5fRzRXOW0yMG1UMFZXdFFCc21CQmtJMmNtUnQ0QWk4QmZZZEhzRnpBdFlLT2pwQlIxU\
nBLcEptVkt4SUdOeTBnNlozYWQyWFlzaDhLb3dseVZ5OElrWjhOTXdTcmNVSUJaR1lY\
akhwd2p6dmZHdlhIXzVLSmxuUjNfdVJVcDRaNFVqazJiQ2FLZWdEbjExVjJ2eEU0MWh\
xYVBVbmhSWnhlMGpSRVRkZHpzRTNtdTFTSzhkVENST2p3VWwxNG1VTm84aVRyVG00bj\
BxRGFkejhCa1BvLXV2NEJDMGJ1blMwSzNiQV8zVWdWcDd6QmxRRm9GbkxUTzJ1V3Bfb\
XVMRVdHbDY3Z0JxOU1PM2JyS1hmR2hpM2tPenl3endQVHVxLWNWUUR5RU43YUwwU3hD\
YjNIYzRJZHFEYU1nOHFIVXlPYnBQaXREUSIKICAgICAgICB9CiAgICAgIH0KICAgICA\
gImRpc3BsYXkiOiB7CiAgICAgICAgIm5hbWUiOiAiTXkgQ2xpZW50IERpc3BsYXkgTm\
FtZSIsCiAgICAgICAgInVyaSI6ICJodHRwczovL2NsaWVudC5mb28vIgogICAgICB9L\
AogICAgfSwKICAgICJzdWJqZWN0IjogewogICAgICAgICJmb3JtYXRzIjogWyJpc3Nf\
c3ViIiwgIm9wYXF1ZSJdCiAgICB9Cn0K.MwNoVMQp5hVxI0mCs9LlOUdFtkDXaA1_eT\
vOXq7DOGrtDKH7q4vP2xUq3fH2jRAZqnobo0WdPP3eM3NH5QUjW8pa6_QpwdIWkK7r-\
u_52puE0lPBp7J4U2w4l9gIbg8iknsmWmXeY5F6wiGT8ptfuEYGgmloAJd9LIeNvD3U\
LW2h2dz1Pn2eDnbyvgB0Ugae0BoZB4f69fKWj8Z9wvTIjk1LZJN1PcL7_zT8Lrlic9a\
PyzT7Q9ovkd1s-4whE7TrnGUzFc5mgWUn_gsOpsP5mIIljoEEv-FqOW2RyNYulOZl0Q\
8EnnDHV_vPzrHlUarbGg4YffgtwkQhdK72-JOxYQ
When the verifier receives an attached JWS request, it MUST parse and validate the JWS object. The signature MUST be validated against the expected key of the signer. All required fields MUST be present, and their values MUST be valid. All fields MUST match the corresponding portions of the HTTP message. For example, the htm field of the JWS header has to be the same as the HTTP verb used in the request.
Verifierが添付されたJWSリクエストを受信した場合、JWSオブジェクトを解析および検証する必要があります。署名は、署名者の予想されるキーに対して検証する必要があります。必要なすべてのフィールドが存在する必要があり、その値は有効でなければなりません。すべてのフィールドは、HTTPメッセージの対応する部分と一致する必要があります。たとえば、JWSヘッダーのHTMフィールドは、リクエストで使用されているHTTP動詞と同じでなければなりません。
Note that this proofing method depends on a specific cryptographic algorithm, SHA-256, in two ways: the ath hash algorithm is hardcoded, and computing the payload of the detached/attached signature also uses a hardcoded hash. A future version of this document may address crypto-agility for both these uses by replacing ath with a new header that upgrades the algorithm and possibly defining a new header that indicates the HTTP content's hash method.
この校正方法は、2つの方法で特定の暗号化アルゴリズムSHA-256に依存していることに注意してください。ATHハッシュアルゴリズムがハードコードされており、分離/付属の署名のペイロードを計算して、ハードコーディングされたハッシュも使用します。このドキュメントの将来のバージョンは、ATHをアルゴリズムをアップグレードする新しいヘッダーに置き換え、HTTPコンテンツのハッシュメソッドを示す新しいヘッダーを定義することにより、これらの両方の用途の暗号性能力に対処する場合があります。
When rotating a key using attached JWS, the message, which includes the new public key value or reference, is first signed with the old key using a JWS object with typ header value "gnap-binding-rotation-jws". The value of the JWS object is then taken as the payload of a new JWS object, to be signed by the new key.
添付のJWSを使用してキーを回転させるとき、新しい公開キー値またはリファレンスを含むメッセージは、型ヘッダー値「GNAPバインディングrotation-JWS」を持つJWSオブジェクトを使用して古いキーで最初に署名されます。JWSオブジェクトの値は、新しいJWSオブジェクトのペイロードとして使用され、新しいキーによって署名されます。
GNAP provides a rich structure for describing the protected resources hosted by RSs and accessed by client software. This structure is used when the client instance requests an access token (Section 2.1) and when an access token is returned (Section 3.2). GNAP's structure is designed to be analogous to the OAuth 2.0 Rich Authorization Requests data structure defined in [RFC9396].
GNAPは、RSSによってホストされ、クライアントソフトウェアによってアクセスされる保護されたリソースを記述するための豊富な構造を提供します。この構造は、クライアントインスタンスがアクセストークン（セクション2.1）を要求し、アクセストークンが返されたとき（セクション3.2）に使用されます。GNAPの構造は、[RFC9396]で定義されたデータ構造を要求するOAUTH 2.0リッチリクエストに類似するように設計されています。
The root of this structure is a JSON array. The elements of the JSON array represent rights of access that are associated with the access token. Individual rights of access can be defined by the RS as either an object or a string. The resulting access is the union of all elements within the array.
この構造のルートはJSONアレイです。JSONアレイの要素は、アクセストークンに関連付けられているアクセス権を表します。アクセスの個々の権利は、RSによってオブジェクトまたは文字列のいずれかとして定義できます。結果のアクセスは、配列内のすべての要素の結合です。
The access associated with the access token is described using objects that each contain multiple dimensions of access. Each object contains a REQUIRED type property that determines the type of API that the token is used for and the structure of the rest of the object. There is no expected interoperability between different type definitions.
アクセストークンに関連付けられたアクセスは、それぞれにアクセスの複数の寸法が含まれているオブジェクトを使用して説明されています。各オブジェクトには、トークンが使用されるAPIのタイプとオブジェクトの残りの構造を決定する必要なタイププロパティが含まれています。異なるタイプ定義間に相互運用性が予想されることはありません。
type (string):
タイプ（文字列）：
The type of resource request as a string. This field MAY define which other fields are allowed in the request object. REQUIRED.
文字列としてのリソース要求のタイプ。このフィールドは、リクエストオブジェクトで許可されている他のフィールドを定義する場合があります。必須。
The value of the type field is under the control of the AS. This field MUST be compared using an exact byte match of the string value against known types by the AS. The AS MUST ensure that there is no collision between different authorization data types that it supports. The AS MUST NOT do any collation or normalization of data types during comparison. It is RECOMMENDED that designers of general-purpose APIs use a URI for this field to avoid collisions between multiple API types protected by a single AS.
タイプフィールドの値は、ASの制御下にあります。このフィールドは、ASによる既知の型に対して文字列値の正確なバイトマッチを使用して比較する必要があります。ASは、サポートする異なる承認データ型の間に衝突がないことを確認する必要があります。ASは、比較中にデータ型の照合または正規化を実行してはなりません。汎用APIの設計者は、このフィールドにURIを使用して、単一のASで保護されている複数のAPIタイプ間の衝突を避けることをお勧めします。
While it is expected that many APIs will have their own properties, this specification defines a set of common data fields that are designed to be usable across different types of APIs. This specification does not require the use of these common fields by an API definition but, instead, provides them as reusable generic components for API designers to make use of. The allowable values of all fields are determined by the API being protected, as defined by a particular type value.
多くのAPIが独自のプロパティを持つことが予想されますが、この仕様は、さまざまなタイプのAPIで使用可能になるように設計された共通データフィールドのセットを定義します。この仕様では、API定義でこれらの一般的なフィールドを使用する必要はありませんが、代わりに、APIデザイナーが使用するための再利用可能なジェネリックコンポーネントとして提供されます。すべてのフィールドの許容値は、特定のタイプ値で定義されているように、APIが保護されていることによって決定されます。
actions (array of strings):
アクション（文字列の配列）：
The types of actions the client instance will take at the RS as an array of strings (for example, a client instance asking for a combination of "read" and "write" access).
クライアントインスタンスがRSで一連の文字列として実行するアクションの種類（たとえば、「読み取り」と「書き込み」アクセスの組み合わせを要求するクライアントインスタンス）。
locations (array of strings):
場所（文字列の配列）：
The location of the RS as an array of strings. These strings are typically URIs identifying the location of the RS.
文字列の配列としてのRSの位置。これらの文字列は通常、Rsの位置を識別しています。
datatypes (array of strings):
データタイプ（文字列の配列）：
The kinds of data available to the client instance at the RS's API as an array of strings (for example, a client instance asking for access to raw "image" data and "metadata" at a photograph API).
RSのAPIのクライアントインスタンスが一連の文字列として利用できる種類（たとえば、写真APIで生の「画像」データと「メタデータ」へのアクセスを要求するクライアントインスタンス）。
identifier (string):
識別子（文字列）：
A string identifier indicating a specific resource at the RS (for example, a patient identifier for a medical API or a bank account number for a financial API).
RSの特定のリソースを示す文字列識別子（たとえば、医療APIの患者識別子または金融APIの銀行口座番号）。
privileges (array of strings):
特権（文字列の配列）：
The types or levels of privilege being requested at the resource (for example, a client instance asking for administrative-level access or access when the RO is no longer online).
リソースで要求される特権の種類またはレベル（たとえば、ROがオンラインでなくなったときに管理レベルのアクセスまたはアクセスを要求するクライアントインスタンス）。
The following non-normative example describes three kinds of access (read, write, and delete) to each of two different locations and two different data types (metadata and images) for a single access token using the fictitious photo-api type definition.
次の非規範的な例では、2つの異なる場所への3種類のアクセス（読み取り、書き込み、削除）と、架空のPhoto-APIタイプ定義を使用した単一のアクセストークンの2つの異なるデータタイプ（メタデータと画像）を説明します。
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"delete"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
}
]
While the exact semantics of interpreting the fields of an access request object are subject to the definition of the type, it is expected that the access requested for each object in the array is the cross-product of all fields of the object. That is to say, the object represents a request for all actions listed to be used at all locations listed for all possible datatypes listed within the object. Assuming the request above was granted, the client instance could assume that it would be able to do a read action against the images on the first server as well as a delete action on the metadata of the second server, or any other combination of these fields, using the same access token.
アクセス要求オブジェクトのフィールドを解釈するという正確なセマンティクスは、タイプの定義の対象となりますが、配列内の各オブジェクトに要求されるアクセスがオブジェクトのすべてのフィールドのクロスプロダクトであると予想されます。つまり、オブジェクトは、オブジェクト内にリストされているすべての可能なデータ型に対してリストされているすべての場所で使用されるすべてのアクションのリクエストを表します。上記のリクエストが許可されたと仮定すると、クライアントインスタンスは、最初のサーバーの画像に対して読み取りアクションを実行できること、および2番目のサーバーのメタデータまたはこれらのフィールドのその他の組み合わせの削除アクションを実行できると想定できます。、同じアクセストークンを使用します。
To request a different combination of access, such as requesting one of the possible actions against one of the possible locations and a different choice of possible actions against a different one of the possible locations, the client instance can include multiple separate objects in the resources array. The total access rights for the resulting access token are the union of all objects. The following non-normative example uses the same fictitious photo-api type definition to request a single access token with more specifically targeted access rights by using two discrete objects within the request.
可能な場所のいずれかに対する可能なアクションの1つを要求し、可能な場所の別の1つに対して可能なアクションの異なる選択を要求するなど、アクセスの異なる組み合わせを要求するには、クライアントインスタンスにはリソースアレイに複数の個別のオブジェクトを含めることができます。結果のアクセストークンの総アクセス権は、すべてのオブジェクトの結合です。次の非規範的な例では、同じ架空の写真APIタイプ定義を使用して、リクエスト内で2つの個別のオブジェクトを使用して、より具体的にターゲットを絞ったアクセス権を持つ単一のアクセストークンを要求します。
"access": [
{
"type": "photo-api",
"actions": [
"read"
],
"locations": [
"https://server.example.net/"
],
"datatypes": [
"images"
]
},
{
"type": "photo-api",
"actions": [
"write",
"delete"
],
"locations": [
"https://resource.local/other"
],
"datatypes": [
"metadata"
]
}
]
The access requested here is for read access to images on one server as well as write and delete access for metadata on a different server (importantly, without requesting write or delete access to images on the first server).
ここで要求されるアクセスは、1つのサーバーの画像への読み取りアクセスと、別のサーバー上のメタデータのアクセスを書き込みおよび削除することです（重要なことには、最初のサーバーの画像への書き込みまたは削除を要求することなく）。
It is anticipated that API designers will use a combination of common fields defined in this specification as well as fields specific to the API itself. The following non-normative example shows the use of both common and API-specific fields as part of two different fictitious API type values. The first access request includes the actions, locations, and datatypes fields specified here as well as the API-specific geolocation field. The second access request includes the actions and identifier fields specified here as well as the API-specific currency field.
APIデザイナーは、この仕様で定義された共通フィールドと、API自体に固有のフィールドの組み合わせを使用することが予想されます。次の非規範的な例は、2つの異なる架空のAPIタイプ値の一部として、一般的なフィールドとAPI固有のフィールドの両方の使用を示しています。最初のアクセス要求には、ここで指定されたアクション、場所、およびデータ型フィールドと、API固有のジオロケーションフィールドが含まれます。2番目のアクセス要求には、ここで指定されたアクションと識別子フィールド、およびAPI固有の通貨フィールドが含まれます。
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
],
"geolocation": [
{ lat: -32.364, lng: 153.207 },
{ lat: -35.364, lng: 158.207 }
]
},
{
"type": "financial-transaction",
"actions": [
"withdraw"
],
"identifier": "account-14-32-32-3",
"currency": "USD"
}
]
If this request is approved, the resulting access token's access rights will be the union of the requested types of access for each of the two APIs, just as above.
この要求が承認された場合、結果のアクセストークンのアクセス権は、上記のように、2つのAPIのそれぞれの要求されたタイプのアクセスの連合となります。
Instead of sending an object describing the requested resource (Section 8), access rights MAY be communicated as a string known to the AS representing the access being requested. Just like access rights communicated as an object, access rights communicated as reference strings indicate a specific access at a protected resource. In the following non-normative example, three distinct resource access rights are being requested.
要求されたリソース（セクション8）を記述するオブジェクトを送信する代わりに、アクセス権は、要求されているアクセスを表すASに知られている文字列として伝達される場合があります。オブジェクトとして伝達されるアクセス権と同様に、参照文字列として伝達されるアクセス権は、保護されたリソースでの特定のアクセスを示します。次の非規範的な例では、3つの異なるリソースアクセス権が要求されています。
"access": [
"read", "dolphin-metadata", "some other thing"
]
This value is opaque to the client instance and MAY be any valid JSON string; therefore, it could include spaces, Unicode characters, and properly escaped string sequences. However, in some situations, the value is intended to be seen and understood by the client software's developer. In such cases, the API designer choosing any such human-readable strings SHOULD take steps to ensure the string values are not easily confused by a developer, such as by limiting the strings to easily disambiguated characters.
この値はクライアントインスタンスに不透明であり、有効なJSON文字列である場合があります。したがって、スペース、ユニコード文字、および適切に逃げた文字列シーケンスを含めることができます。ただし、状況によっては、値はクライアントソフトウェアの開発者が見て理解することを目的としています。このような場合、APIデザイナーは、そのような人間が読み取る文字列を選択する必要があります。文字列値を簡単に曖昧にした文字に制限するなど、開発者が文字列値を簡単に混同しないようにする必要があります。
This functionality is similar in practice to OAuth 2.0's scope parameter [RFC6749], where a single string represents the set of access rights requested by the client instance. As such, the reference string could contain any valid OAuth 2.0 scope value, as in Appendix B.5. Note that the reference string here is not bound to the same character restrictions as OAuth 2.0's scope definition.
この機能は、実際にはOAUTH 2.0のスコープパラメーター[RFC6749]と類似しています。単一の文字列は、クライアントインスタンスが要求するアクセス権のセットを表します。そのため、付録B.5のように、参照文字列には有効なOAUTH 2.0スコープ値を含めることができます。ここの参照文字列は、OAUTH 2.0のスコープ定義と同じ文字制限にバインドされていないことに注意してください。
A single access array MAY include both object-type and string-type resource items. In this non-normative example, the client instance is requesting access to a photo-api and financial-transaction API type as well as the reference values of read, dolphin-metadata, and some other thing.
単一のアクセス配列には、オブジェクトタイプと文字列タイプのリソースアイテムの両方が含まれる場合があります。この非規範的な例では、クライアントインスタンスは、写真と財務取引のAPIタイプ、および読み取り値、イルカメタダタ、その他の参照値へのアクセスを要求しています。
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"delete"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"read",
"dolphin-metadata",
{
"type": "financial-transaction",
"actions": [
"withdraw"
],
"identifier": "account-14-32-32-3",
"currency": "USD"
},
"some other thing"
]
The requested access is the union of all elements of the array, including both objects and reference strings.
要求されたアクセスは、オブジェクトと参照文字列の両方を含む、配列のすべての要素の結合です。
In order to facilitate the use of both object and reference strings to access the same kind of APIs, the API designer can define a clear mapping between these forms. One possible approach for choosing reference string values is to use the same value as the type parameter from the fully specified object, with the API defining a set of default behaviors in this case. For example, an API definition could declare the following string:
オブジェクト文字列と参照文字列の両方を使用して同じ種類のAPIにアクセスするために、APIデザイナーはこれらのフォーム間の明確なマッピングを定義できます。参照文字列値を選択するための可能なアプローチの1つは、完全に指定されたオブジェクトのタイプパラメーターと同じ値を使用することです。この場合、APIはデフォルトの動作のセットを定義します。たとえば、API定義は次の文字列を宣言できます。
"access": [
"photo-api"
]
As being equivalent to the following fully defined object:
次の完全に定義されたオブジェクトに相当するものとして：
"access": [
{
"type": "photo-api",
"actions": [ "read", "write", "delete" ],
"datatypes": [ "metadata", "image" ]
}
]
The exact mechanisms for relating reference strings is up to the API designer. These are enforced by the AS, and the details are out of scope for this specification.
参照文字列を関連付けるための正確なメカニズムは、APIデザイナー次第です。これらはASによって施行されており、詳細はこの仕様の範囲外です。
By design, GNAP minimizes the need for any pre-flight discovery. To begin a request, the client instance only needs to know the grant endpoint of the AS (a single URI) and which keys it will use to sign the request. Everything else can be negotiated dynamically in the course of the protocol.
設計上、GNAPは飛行前の発見の必要性を最小限に抑えます。リクエストを開始するには、クライアントインスタンスは、AS（単一のURI）の助成金エンドポイントと、リクエストに署名するために使用するキーのみを知る必要があります。他のすべては、プロトコルの過程で動的に交渉できます。
However, the AS can have limits on its allowed functionality. If the client instance wants to optimize its calls to the AS before making a request, it MAY send an HTTP OPTIONS request to the grant request endpoint to retrieve the server's discovery information. The AS MUST respond with a JSON document with Content-Type application/json containing a single object with the following fields:
ただし、ASは許可された機能に制限があります。クライアントインスタンスがリクエストを行う前に通話を最適化したい場合、サーバーの発見情報を取得するために、助成金リクエストエンドポイントにHTTPオプションリクエストを送信する場合があります。ASは、コンテンツタイプのアプリケーション/JSONを使用してJSONドキュメントで応答する必要があります。
grant_request_endpoint (string):
grant_request_endpoint（string）：
The location of the AS's grant request endpoint. The location MUST be an absolute URL [RFC3986] with a scheme component (which MUST be "https"), a host component, and optionally port, path, and query components and no fragment components. This URL MUST match the URL the client instance used to make the discovery request. REQUIRED.
ASの助成金要求エンドポイントの位置。場所は、スキームコンポーネント（「HTTPS」）、ホストコンポーネント、およびオプションでポート、パス、クエリコンポーネント、およびフラグメントコンポーネントなしの絶対URL [RFC3986]でなければなりません。このURLは、ディスカバリーリクエストを作成するために使用されるクライアントインスタンスのURLと一致する必要があります。必須。
interaction_start_modes_supported (array of strings):
interaction_start_modes_supported（文字列の配列）：
A list of the AS's interaction start methods. The values of this list correspond to the possible values for the interaction start field of the request (Section 2.5.1) and MUST be values from the "GNAP Interaction Start Modes" registry (Section 10.9). OPTIONAL.
ASのインタラクション開始方法のリスト。このリストの値は、要求のインタラクション開始フィールド（セクション2.5.1）の可能な値に対応し、「GNAPインタラクション開始モード」レジストリ（セクション10.9）の値でなければなりません。オプション。
interaction_finish_methods_supported (array of strings):
interaction_finish_methods_supported（文字列の配列）：
A list of the AS's interaction finish methods. The values of this list correspond to the possible values for the method element of the interaction finish field of the request (Section 2.5.2) and MUST be values from the "GNAP Interaction Finish Methods" registry (Section 10.10). OPTIONAL.
ASのインタラクション仕上げ方法のリスト。このリストの値は、要求のインタラクション仕上げフィールドのメソッド要素の可能な値（セクション2.5.2）に対応し、「GNAPインタラクション仕上げ方法」レジストリ（セクション10.10）の値でなければなりません。オプション。
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 (Section 7.1) and MUST be values from the "GNAP Key Proofing Methods" registry (Section 10.16). OPTIONAL.
ASのサポートされている主要な校正メカニズムのリスト。このリストの値は、要求のキーセクション（セクション7.1）の証明フィールドの可能な値に対応し、「GNAPキープルーフメソッド」レジストリ（セクション10.16）の値でなければなりません。オプション。
sub_id_formats_supported (array of strings):
sub_id_formats_supported（文字列の配列）：
A list of the AS's supported Subject Identifier formats. The values of this list correspond to possible values of the Subject Identifier field of the request (Section 2.2) and MUST be values from the "Subject Identifier Formats" registry [Subj-ID-Formats]. OPTIONAL.
ASのサポートされているサポートされている識別子形式のリスト。このリストの値は、要求のサブジェクト識別子フィールドの可能な値（セクション2.2）に対応し、「サブジェクト識別子形式」レジストリ[subj-id-formats]の値でなければなりません。オプション。
assertion_formats_supported (array of strings):
assertion_formats_supported（文字列の配列）：
A list of the AS's supported assertion formats. The values of this list correspond to possible values of the subject assertion field of the request (Section 2.2) and MUST be values from the "GNAP Assertion Formats" registry (Section 10.6). OPTIONAL.
ASのサポートされているアサーション形式のリスト。このリストの値は、要求の主題アサーションフィールド（セクション2.2）の可能な値に対応し、「GNAPアサーション形式」レジストリ（セクション10.6）の値でなければなりません。オプション。
key_rotation_supported (boolean):
key_rotation_supported（boolean）：
The boolean "true" indicates that rotation of access token bound keys by the client (Section 6.1.1) is supported by the AS. The absence of this field or a boolean "false" value indicates that this feature is not supported.
ブールの「真」は、クライアントによるアクセストークンバインドキーの回転（セクション6.1.1）がASによってサポートされていることを示しています。このフィールドまたはブール値の「偽」値がないことは、この機能がサポートされていないことを示しています。
The information returned from this method is for optimization purposes only. The AS MAY deny any request, or any portion of a request, even if it lists a capability as supported. For example, if a given client instance can be registered with the mtls key proofing mechanism but the AS also returns other proofing methods from the discovery document, then the AS will still deny a request from that client instance using a different proofing mechanism. Similarly, an AS with key_rotation_supported set to "true" can still deny any request for rotating any access token's key for a variety of reasons.
この方法から返される情報は、最適化のみを目的としています。サポートされている機能がリストされていても、リクエストまたはリクエストの一部を拒否する場合があります。たとえば、特定のクライアントインスタンスをMTLSキープルーフメカニズムに登録できるが、ASがディスカバリードキュメントから他の校正方法も返す場合、ASは別のプルーフ化メカニズムを使用してそのクライアントインスタンスからの要求を拒否します。同様に、key_rotation_supportedセットを「true」にすると、さまざまな理由でアクセストークンのキーを回転させるリクエストを拒否できます。
Additional fields can be defined in the "GNAP Authorization Server Discovery Fields" registry (Section 10.18).
追加のフィールドは、「GNAP認証サーバーディスカバリーフィールド」レジストリ（セクション10.18）で定義できます。
If the client instance calls an RS without an access token or with an invalid access token, the RS SHOULD be explicit about the fact that GNAP needs to be used to access the resource by responding with the WWW-Authenticate header field and a GNAP challenge.
クライアントインスタンスがアクセストークンまたは無効なアクセストークンを使用してRSを呼び出す場合、RSは、www-authenticateヘッダーフィールドとGNAPチャレンジで応答することにより、GNAPを使用してリソースへのアクセスに使用する必要があるという事実について明示的でなければなりません。
In some situations, the client instance might want to know with which specific AS it needs to negotiate for access to that RS. The RS MAY additionally return the following OPTIONAL parameters:
状況によっては、クライアントインスタンスは、そのRsへのアクセスのために交渉するために必要な具体的なものを知りたいと思うかもしれません。RSはさらに、次のオプションパラメーターを返す場合があります。
as_uri:
as_uri：
The URI of the grant endpoint of the GNAP AS. Used by the client instance to call the AS to request an access token.
GNAP ASの助成金エンドポイントのURI。クライアントインスタンスで使用されて、アクセストークンを要求するように呼び出します。
referrer:
リファラー：
The URI of the GNAP RS. Sent by the client instance in the Referer header as part of the grant request.
GNAP RsのURI。助成金リクエストの一部として、クライアントインスタンスがリファラーヘッダーに送信します。
access:
アクセス：
An opaque access reference as defined in Section 8.1. MUST be sufficient for at least the action the client instance was attempting to take at the RS and MAY allow additional access rights as well. Sent by the client as an access right in the grant request.
セクション8.1で定義されている不透明なアクセス参照。少なくともクライアントインスタンスがRSで取得しようとしていたアクションには十分である必要があり、追加のアクセス権も許可する場合があります。クライアントが助成金リクエストでアクセス権として送信します。
The client instance SHOULD then use both the referrer and access parameters in its access token request. The client instance MUST check that the referrer parameter is equal to the URI of the RS using the simple string comparison method in Section 6.2.1 of [RFC3986].
クライアントインスタンスは、アクセストークンリクエストのリファラーパラメーターとアクセスパラメーターの両方を使用する必要があります。クライアントインスタンスは、[RFC3986]のセクション6.2.1の単純な文字列比較方法を使用して、リファラーパラメーターがRSのURIに等しいことを確認する必要があります。
The means for the RS to determine the value for the access reference are out of scope of this specification, but some dynamic methods are discussed in [GNAP-RS].
RSがアクセス参照の値を決定する手段はこの仕様の範囲外ですが、[GNAP-RS]でいくつかの動的な方法が議論されています。
When receiving the following response from the RS:
RSから次の回答を受信するとき：
NOTE: '\' line wrapping per RFC 8792
WWW-Authenticate: \
GNAP as_uri=https://as.example/tx\
;access=FWWIKYBQ6U56NL1\
;referrer=https://rs.example
The client instance then makes a request to the as_uri as described in Section 2, with the value of referrer passed as an HTTP Referer header field and the access reference passed unchanged into the access array in the access_token portion of the request. The client instance MAY request additional resources and other information.
クライアントインスタンスは、セクション2で説明されているようにAS_URIにリクエストを行います。リファラーの値はHTTP参照ヘッダーフィールドとして渡され、アクセス参照はリクエストのAccess_token部分のアクセス配列に変更されません。クライアントインスタンスは、追加のリソースやその他の情報を要求する場合があります。
In the following non-normative example, the client instance is requesting a single access token using the opaque access reference FWWIKYBQ6U56NL1 received from the RS in addition to the dolphin-metadata that the client instance has been configured with out of band.
以下の非規範的な例では、クライアントインスタンスは、クライアントインスタンスがバンド外で構成されているイルカメタデータに加えて、RSから受け取ったOpaque Access Reference FWWIKYBQ6U56NL1を使用して、単一のアクセストークンを要求しています。
POST /tx HTTP/1.1
Host: as.example
Referer: https://rs.example/resource
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
"FWWIKYBQ6U56NL1",
"dolphin-metadata"
]
},
"client": "KHRS6X63AJ7C7C4AZ9AO"
}
The client instance includes the Referer header field as a way for the AS to know that the process is initiated through a discovery process at the RS.
クライアントインスタンスには、RSでの発見プロセスを通じてプロセスが開始されることを知る方法として、参照ヘッダーフィールドが含まれています。
If issued, the resulting access token would contain sufficient access to be used at both referenced resources.
発行された場合、結果のアクセストークンには、参照された両方のリソースで十分なアクセスが含まれます。
Security considerations, especially related to the potential of a compromised RS (Section 11.37) redirecting the requests of an otherwise properly authenticated client, need to be carefully considered when allowing such a discovery process. This risk can be mitigated by an alternative pre-registration process so that the client knows which AS protects which RS. There are also privacy considerations related to revealing which AS is protecting a given resource; these are discussed in Section 12.4.1.
特に、妥協したRs（セクション11.37）の可能性に関連するセキュリティ上の考慮事項は、そのような発見プロセスを許可する際に、適切に認証されたクライアントの要求をリダイレクトする必要があります。このリスクは、代替の事前登録プロセスによって軽減される可能性があり、クライアントがどのRsを保護するかをクライアントが知っているようにします。また、特定のリソースを保護しているものを明らかにすることに関連するプライバシーに関する考慮事項もあります。これらについては、セクション12.4.1で説明します。
Additional methods of discovering the appropriate grant endpoint for a given application are outside the scope of this specification. This limitation is intentional, as many applications rely on static configuration between the client instance and AS, as is common in OAuth 2.0. However, the dynamic nature of GNAP makes it a prime candidate for other extensions defining methods for discovery of the appropriate AS grant endpoint at runtime. Advanced use cases could define contextual methods for securely providing this endpoint to the client instance. Furthermore, GNAP's design intentionally requires the client instance to only know the grant endpoint and not additional parameters, since other functions and values can be disclosed and negotiated during the grant process.
特定のアプリケーションの適切な助成金エンドポイントを発見する追加の方法は、この仕様の範囲外です。多くのアプリケーションは、OAUTH 2.0で一般的であるように、クライアントインスタンスとASの間の静的な構成に依存しているため、この制限は意図的です。ただし、GNAPの動的な性質により、実行時に適切なグラントエンドポイントを発見するための方法を定義する他の拡張機能の主要な候補になります。高度なユースケースは、クライアントインスタンスにこのエンドポイントを安全に提供するためのコンテキスト方法を定義できます。さらに、GNAPの設計では、他の機能と値を助成プロセス中に開示および交渉できるため、クライアントインスタンスは追加のパラメーターではなく、付与エンドポイントのみを知る必要があります。
IANA has added values to existing registries as well as created 16 registries for GNAP [GNAP-REG] and populated those registries with initial values as described in this section.
IANAは既存のレジストリに値を追加し、GNAP [GNAP-REG]の16のレジストリを作成し、このセクションで説明したように、これらのレジストリに初期値を入力しました。
All use of value typing is based on data types in [RFC8259] and MUST be one of the following: number, object, string, boolean, or array. When the type is array, the contents of the array MUST be specified, as in "array of objects" when one subtype is allowed or "array of strings/objects" when multiple simultaneous subtypes are allowed. When the type is object, the structure of the object MUST be specified in the definition. If a parameter is available in different types, each type SHOULD be registered separately.
値タイピングのすべての使用は、[RFC8259]のデータ型に基づいており、次のいずれかでなければなりません：数字、オブジェクト、文字列、ブール、または配列。タイプが配列の場合、1つのサブタイプが許可されている場合の「オブジェクトの配列」または複数の同時サブタイプが許可されている場合の「文字列/オブジェクトの配列」のように、配列の内容を指定する必要があります。タイプがオブジェクトの場合、オブジェクトの構造を定義で指定する必要があります。パラメーターが異なるタイプで使用可能な場合、各タイプは個別に登録する必要があります。
General guidance for extension parameters is found in Appendix D.
拡張パラメーターの一般的なガイダンスは、付録Dにあります。
IANA has registered of the following scheme in the "HTTP Authentication Schemes" registry [Auth-Schemes] defined in Section 18.5 of [HTTP]:
IANAは、[HTTP]のセクション18.5で定義されている「HTTP認証スキーム」レジストリ[Auth-Schemes]に次のスキームを登録しました。
Authentication Scheme Name:
認証スキーム名：
GNAP
gnap
Reference:
参照：
Section 7.2 of RFC 9635
RFC 9635のセクション7.2
Per this section, IANA has registered the following media types [RFC2046] in the "Media Types" registry [MediaTypes] as described in [RFC6838].
このセクションに従って、IANAは[RFC6838]で説明されているように、「メディアタイプ」レジストリ[メディアタイプ]に次のメディアタイプ[RFC2046]を登録しています。
This media type indicates that the content is a GNAP message to be bound with a detached JWS mechanism.
このメディアタイプは、コンテンツがDetached JWSメカニズムにバインドされるGNAPメッセージであることを示しています。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
gnap-binding-jwsd
GNAPバインディング-JWSD
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary
バイナリバイナリー二進
Security considerations:
セキュリティ上の考慮事項：
See Section 11 of RFC 9635.
RFC 9635のセクション11を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9635
RFC 9635
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
GNAP
gnap
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なしのどれも
Author:
著者：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Change Controller:
Change Controller：
IETF
IETF
This media type indicates that the content is a GNAP message to be bound with an attached JWS mechanism.
このメディアタイプは、コンテンツが添付されたJWSメカニズムにバインドされるGNAPメッセージであることを示しています。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
gnap-binding-jws
GNAPバインディングJWS
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary
バイナリバイナリー二進
Security considerations:
セキュリティ上の考慮事項：
See Section 11 of RFC 9635.
RFC 9635のセクション11を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9635
RFC 9635
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
GNAP
gnap
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なしのどれも
Author:
著者：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Change Controller:
Change Controller：
IETF
IETF
This media type indicates that the content is a GNAP token rotation message to be bound with a detached JWS mechanism.
このメディアタイプは、コンテンツがDepached JWSメカニズムと結合するGNAPトークン回転メッセージであることを示しています。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
gnap-binding-rotation-jwsd
GNAPバインディングrotation-JWSD
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary
バイナリバイナリー二進
Security considerations:
セキュリティ上の考慮事項：
See Section 11 of RFC 9635.
RFC 9635のセクション11を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9635
RFC 9635
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
GNAP
gnap
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なしのどれも
Author:
著者：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Change Controller:
Change Controller：
IETF
IETF
This media type indicates that the content is a GNAP token rotation message to be bound with an attached JWS mechanism.
このメディアタイプは、コンテンツが添付されたJWSメカニズムにバインドされるGNAPトークン回転メッセージであることを示しています。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
gnap-binding-rotation-jws
GNAPバインディングrotation-JWS
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary
バイナリバイナリー二進
Security considerations:
セキュリティ上の考慮事項：
See Section 11 of RFC 9635.
RFC 9635のセクション11を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9635
RFC 9635
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
GNAP
gnap
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なしのどれも
Author:
著者：
IETF GNAP Working Group (txauth@ietf.org)
ietf gnapワーキンググループ（txauth@ietf.org）
Change Controller:
Change Controller：
IETF
IETF
This document defines a GNAP grant request, for which IANA has created and maintains a new registry titled "GNAP Grant Request Parameters". Initial values for this registry are given in Section 10.3.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAP助成金要求パラメーター」というタイトルの新しいレジストリを作成および維持しているGNAP助成金リクエストを定義します。このレジストリの初期値は、セクション10.3.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The designated expert (DE) is expected to ensure the following:
指定された専門家（DE）は、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.3.1.
* すべての登録は、セクション10.3.1に示されているテンプレートに従います。
* The request parameter's definition is sufficiently orthogonal to existing functionality provided by existing parameters.
* 要求パラメーターの定義は、既存のパラメーターによって提供される既存の機能に対して十分に直交しています。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
* The request parameter's definition specifies the expected behavior of the AS in response to the request parameter for each potential state of the grant request.
* リクエストパラメーターの定義は、助成金要求の各潜在的状態のリクエストパラメーターに応じて、ASの予想される動作を指定します。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+==============+==================+===========================+
| Name | Type | Reference |
+==============+==================+===========================+
| access_token | object | Section 2.1.1 of RFC 9635 |
+--------------+------------------+---------------------------+
| access_token | array of objects | Section 2.1.2 of RFC 9635 |
+--------------+------------------+---------------------------+
| subject | object | Section 2.2 of RFC 9635 |
+--------------+------------------+---------------------------+
| client | object | Section 2.3 of RFC 9635 |
+--------------+------------------+---------------------------+
| client | string | Section 2.3.1 of RFC 9635 |
+--------------+------------------+---------------------------+
| user | object | Section 2.4 of RFC 9635 |
+--------------+------------------+---------------------------+
| user | string | Section 2.4.1 of RFC 9635 |
+--------------+------------------+---------------------------+
| interact | object | Section 2.5 of RFC 9635 |
+--------------+------------------+---------------------------+
| interact_ref | string | Section 5.1 of RFC 9635 |
+--------------+------------------+---------------------------+
Table 1
This document defines GNAP access token flags, for which IANA has created and maintains a new registry titled "GNAP Access Token Flags". Initial values for this registry are given in Section 10.4.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、GNAPアクセストークンフラグを定義します。IANAは、「GNAPアクセストークンフラグ」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション10.4.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.4.1.
* すべての登録は、セクション10.4.1に示されているテンプレートに従います。
* The flag specifies whether it applies to requests for tokens to the AS, responses with tokens from the AS, or both.
* フラグは、ASへのトークンのリクエスト、ASからのトークンを使用した応答、または両方に適用されるかどうかを指定します。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Allowed Use:
使用許可：
Where the flag is allowed to occur. Possible values are "Request", "Response", and "Request, Response".
フラグの発生が許可されている場合。考えられる値は、「リクエスト」、「応答」、「リクエスト、応答」です。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+=========+===================+====================+
| Name | Allowed Use | Reference |
+=========+===================+====================+
| bearer | Request, Response | Sections 2.1.1 and |
| | | 3.2.1 of RFC 9635 |
+---------+-------------------+--------------------+
| durable | Response | Section 3.2.1 of |
| | | RFC 9635 |
+---------+-------------------+--------------------+
Table 2
This document defines a means to request subject information from the AS to the client instance, for which IANA has created and maintains a new registry titled "GNAP Subject Information Request Fields". Initial values for this registry are given in Section 10.5.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAPサブジェクト情報リクエストフィールド」というタイトルの新しいレジストリを作成および維持しているクライアントインスタンスに関する主題情報を要求する手段を定義しています。このレジストリの初期値は、セクション10.5.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.5.1.
* すべての登録は、セクション10.5.1に示されているテンプレートに従います。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+===================+==================+=========================+
| Name | Type | Reference |
+===================+==================+=========================+
| sub_id_formats | array of strings | Section 2.2 of RFC 9635 |
+-------------------+------------------+-------------------------+
| assertion_formats | array of strings | Section 2.2 of RFC 9635 |
+-------------------+------------------+-------------------------+
| sub_ids | array of objects | Section 2.2 of RFC 9635 |
+-------------------+------------------+-------------------------+
Table 3
This document defines a means to pass identity assertions between the AS and client instance, for which IANA has created and maintains a new registry titled "GNAP Assertion Formats". Initial values for this registry are given in Section 10.6.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントは、IANAが「GNAPアサーションフォーマット」というタイトルの新しいレジストリを作成および維持しているASとクライアントインスタンスの間でIDアサーションを渡す手段を定義しています。このレジストリの初期値は、セクション10.6.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.6.1.
* すべての登録は、セクション10.6.1に示されているテンプレートに従います。
* The definition specifies the serialization format of the assertion value as used within GNAP.
* 定義は、GNAP内で使用されるアサーション値のシリアル化形式を指定します。
Name:
名前：
An identifier for the assertion format.
アサーション形式の識別子。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+==========+===========================+
| Name | Reference |
+==========+===========================+
| id_token | Section 3.4.1 of RFC 9635 |
+----------+---------------------------+
| saml2 | Section 3.4.1 of RFC 9635 |
+----------+---------------------------+
Table 4
This document defines a means to send information about the client instance, for which IANA has created and maintains a new registry titled "GNAP Client Instance Fields". Initial values for this registry are given in Section 10.7.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントは、IANAが「GNAP Client Instance Fields」というタイトルの新しいレジストリを作成および維持しているクライアントインスタンスに関する情報を送信する手段を定義しています。このレジストリの初期値は、セクション10.7.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.7.1.
* すべての登録は、セクション10.7.1に示されているテンプレートに従います。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+==========+========+===========================+
| Name | Type | Reference |
+==========+========+===========================+
| key | object | Section 7.1 of RFC 9635 |
+----------+--------+---------------------------+
| key | string | Section 7.1.1 of RFC 9635 |
+----------+--------+---------------------------+
| class_id | string | Section 2.3 of RFC 9635 |
+----------+--------+---------------------------+
| display | object | Section 2.3.2 of RFC 9635 |
+----------+--------+---------------------------+
Table 5
This document defines a means to send end-user-facing displayable information about the client instance, for which IANA has created and maintains a new registry titled "GNAP Client Instance Display Fields". Initial values for this registry are given in Section 10.8.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントは、IANAが「GNAPクライアントインスタンスディスプレイフィールド」というタイトルの新しいレジストリを作成および維持しているクライアントインスタンスに関するエンドユーザー向けの表示可能な情報を送信する手段を定義しています。このレジストリの初期値は、セクション10.8.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.8.1.
* すべての登録は、セクション10.8.1に示されているテンプレートに従います。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+==========+========+===========================+
| Name | Type | Reference |
+==========+========+===========================+
| name | string | Section 2.3.2 of RFC 9635 |
+----------+--------+---------------------------+
| uri | string | Section 2.3.2 of RFC 9635 |
+----------+--------+---------------------------+
| logo_uri | string | Section 2.3.2 of RFC 9635 |
+----------+--------+---------------------------+
Table 6
This document defines a means for the client instance to begin interaction between the end user and the AS, for which IANA has created and maintains a new registry titled "GNAP Interaction Start Modes". Initial values for this registry are given in Section 10.9.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントは、クライアントインスタンスがエンドユーザーとASの間の相互作用を開始する手段を定義します。IANAは、「GNAPインタラクションスタートモード」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション10.9.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.9.1.
* すべての登録は、セクション10.9.1に示されているテンプレートに従います。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
* Any registration using an "object" type declares all additional parameters, their optionality, and their purpose.
* 「オブジェクト」タイプを使用した登録は、すべての追加パラメーター、オプション、およびその目的を宣言します。
* The start mode clearly defines what actions the client is expected to take to begin interaction, what the expected user experience is, and any security considerations for this communication from either party.
* スタートモードは、相互作用を開始するためにクライアントがどのようなアクションを実行するか、予想されるユーザーエクスペリエンスとは何か、およびいずれかの当事者からのこのコミュニケーションに関するセキュリティ上の考慮事項を明確に定義します。
* The start mode documents incompatibilities with other start modes or finish methods, if applicable.
* Start Modeは、該当する場合、他のStart ModesまたはFinishメソッドとの非互換性を文書化します。
* The start mode provides enough information to uniquely identify the grant request during the interaction. For example, in the redirect and app modes, this is done using a unique URI (including its parameters). In the user_code and user_code_uri modes, this is done using the value of the user code.
* 開始モードは、インタラクション中に助成金要求を一意に識別するのに十分な情報を提供します。たとえば、リダイレクトモードとAPPモードでは、これは一意のURI（パラメーターを含む）を使用して行われます。user_codeおよびuser_code_uriモードでは、これはユーザーコードの値を使用して実行されます。
Mode:
モード：
An identifier for the interaction start mode.
インタラクション開始モードの識別子。
Type:
タイプ：
The JSON type for the value, either "string" or "object", as described in Section 2.5.1.
セクション2.5.1で説明されているように、「文字列」または「オブジェクト」の値のJSONタイプ。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+===============+========+=============================+
| Mode | Type | Reference |
+===============+========+=============================+
| redirect | string | Section 2.5.1.1 of RFC 9635 |
+---------------+--------+-----------------------------+
| app | string | Section 2.5.1.2 of RFC 9635 |
+---------------+--------+-----------------------------+
| user_code | string | Section 2.5.1.3 of RFC 9635 |
+---------------+--------+-----------------------------+
| user_code_uri | string | Section 2.5.1.4 of RFC 9635 |
+---------------+--------+-----------------------------+
Table 7
This document defines a means for the client instance to be notified of the end of interaction between the end user and the AS, for which IANA has created and maintains a new registry titled "GNAP Interaction Finish Methods". Initial values for this registry are given in Section 10.10.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、クライアントインスタンスがエンドユーザーとASの間の相互作用の終了を通知する手段を定義します。IANAは、「GNAPインタラクション仕上げメソッド」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション10.10.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.10.1.
* すべての登録は、セクション10.10.1に示されているテンプレートに従います。
* All finish methods clearly define what actions the AS is expected to take, what listening methods the client instance needs to enable, and any security considerations for this communication from either party.
* すべての仕上げ方法は、予想されるアクションがどのようなアクションを実行するか、クライアントインスタンスが有効にするために必要なリスニング方法、およびいずれかの当事者からのこのコミュニケーションに関するセキュリティ上の考慮事項を明確に定義します。
* All finish methods document incompatibilities with any start modes, if applicable.
* すべての仕上げ方法は、該当する場合、任意の開始モードと非互換性を文書化します。
Method:
方法：
An identifier for the interaction finish method.
インタラクション仕上げ方法の識別子。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+==========+=============================+
| Method | Reference |
+==========+=============================+
| redirect | Section 2.5.2.1 of RFC 9635 |
+----------+-----------------------------+
| push | Section 2.5.2.2 of RFC 9635 |
+----------+-----------------------------+
Table 8
This document defines a set of hints that a client instance can provide to the AS to facilitate interaction with the end user, for which IANA has created and maintains a new registry titled "GNAP Interaction Hints". Initial values for this registry are given in Section 10.11.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、クライアントインスタンスがエンドユーザーとのやり取りを促進するために提供できる一連のヒントを定義します。これは、IANAが「GNAPインタラクションヒント」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション10.11.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.11.1.
* すべての登録は、セクション10.11.1に示されているテンプレートに従います。
* All interaction hints clearly document the expected behaviors of the AS in response to the hint, and an AS not processing the hint does not impede the operation of the AS or client instance.
* すべての相互作用のヒントは、ヒントに応じてASの予想される動作を明確に文書化し、ヒントを処理しないとASまたはクライアントインスタンスの動作を妨げません。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+============+===========================+
| Name | Reference |
+============+===========================+
| ui_locales | Section 2.5.3 of RFC 9635 |
+------------+---------------------------+
Table 9
This document defines a GNAP grant response, for which IANA has created and maintains a new registry titled "GNAP Grant Response Parameters". Initial values for this registry are given in Section 10.12.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAP助成金対応パラメーター」というタイトルの新しいレジストリを作成および維持しているGNAP助成金応答を定義しています。このレジストリの初期値は、セクション10.12.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.12.1.
* すべての登録は、セクション10.12.1に示されているテンプレートに従います。
* The response parameter's definition is sufficiently orthogonal to existing functionality provided by existing parameters.
* 応答パラメーターの定義は、既存のパラメーターによって提供される既存の機能に対して十分に直交しています。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
* The response parameter's definition specifies grant states for which the client instance can expect this parameter to appear in a response message.
* 応答パラメーターの定義は、クライアントインスタンスがこのパラメーターが応答メッセージに表示されることを期待できる付与状態を指定します。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+==============+==================+===========================+
| Name | Type | Reference |
+==============+==================+===========================+
| continue | object | Section 3.1 of RFC 9635 |
+--------------+------------------+---------------------------+
| access_token | object | Section 3.2.1 of RFC 9635 |
+--------------+------------------+---------------------------+
| access_token | array of objects | Section 3.2.2 of RFC 9635 |
+--------------+------------------+---------------------------+
| interact | object | Section 3.3 of RFC 9635 |
+--------------+------------------+---------------------------+
| subject | object | Section 3.4 of RFC 9635 |
+--------------+------------------+---------------------------+
| instance_id | string | Section 3.5 of RFC 9635 |
+--------------+------------------+---------------------------+
| error | object | Section 3.6 of RFC 9635 |
+--------------+------------------+---------------------------+
Table 10
This document defines a means for the AS to provide the client instance with information that is required to complete a particular interaction mode, for which IANA has created and maintains a new registry titled "GNAP Interaction Mode Responses". Initial values for this registry are given in Section 10.13.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントは、IANAが「GNAPインタラクションモード応答」というタイトルの新しいレジストリを作成および維持している特定のインタラクションモードを完了するために必要な情報をクライアントインスタンスに提供する手段を定義します。このレジストリの初期値は、セクション10.13.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.13.1.
* すべての登録は、セクション10.13.1に示されているテンプレートに従います。
* If the name of the registration matches the name of an interaction start mode, the response parameter is unambiguously associated with the interaction start mode of the same name.
* 登録の名前がインタラクション開始モードの名前と一致する場合、応答パラメーターは同じ名前のインタラクション開始モードに明確に関連付けられています。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+===============+=========================+
| Name | Reference |
+===============+=========================+
| redirect | Section 3.3 of RFC 9635 |
+---------------+-------------------------+
| app | Section 3.3 of RFC 9635 |
+---------------+-------------------------+
| user_code | Section 3.3 of RFC 9635 |
+---------------+-------------------------+
| user_code_uri | Section 3.3 of RFC 9635 |
+---------------+-------------------------+
| finish | Section 3.3 of RFC 9635 |
+---------------+-------------------------+
| expires_in | Section 3.3 of RFC 9635 |
+---------------+-------------------------+
Table 11
This document defines a means to return subject information from the AS to the client instance, for which IANA has created and maintains a new registry titled "GNAP Subject Information Response Fields". Initial values for this registry are given in Section 10.14.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAPサブジェクト情報応答フィールド」というタイトルの新しいレジストリを作成および維持しているクライアントインスタンスから主題情報を返す手段を定義しています。このレジストリの初期値は、セクション10.14.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.14.1.
* すべての登録は、セクション10.14.1に示されているテンプレートに従います。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+============+==================+=========================+
| Name | Type | Reference |
+============+==================+=========================+
| sub_ids | array of objects | Section 3.4 of RFC 9635 |
+------------+------------------+-------------------------+
| assertions | array of objects | Section 3.4 of RFC 9635 |
+------------+------------------+-------------------------+
| updated_at | string | Section 3.4 of RFC 9635 |
+------------+------------------+-------------------------+
Table 12
This document defines a set of errors that the AS can return to the client instance, for which IANA has created and maintains a new registry titled "GNAP Error Codes". Initial values for this registry are given in Section 10.15.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、ASがクライアントインスタンスに戻ることができる一連のエラーを定義します。これは、IANAが「GNAPエラーコード」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション10.15.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.15.1.
* すべての登録は、セクション10.15.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 the client instance's expected action.
* エラー応答の定義は、エラー応答が返されるすべての条件とクライアントインスタンスの予想アクションを指定します。
Error:
エラー：
A unique string code for the error.
エラー用の一意の文字列コード。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+============================+=========================+
| Error | Reference |
+============================+=========================+
| invalid_request | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| invalid_client | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| invalid_interaction | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| invalid_flag | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| invalid_rotation | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| key_rotation_not_supported | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| invalid_continuation | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| user_denied | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| request_denied | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| unknown_user | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| unknown_interaction | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| too_fast | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
| too_many_attempts | Section 3.6 of RFC 9635 |
+----------------------------+-------------------------+
Table 13
This document defines methods that the client instance can use to prove possession of a key, for which IANA has created and maintains a new registry titled "GNAP Key Proofing Methods". Initial values for this registry are given in Section 10.16.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、クライアントインスタンスがキーの所有を証明するために使用できる方法を定義します。これには、IANAが「GNAPキープルーフメソッド」というタイトルの新しいレジストリを作成および維持しています。このレジストリの初期値は、セクション10.16.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.16.1.
* すべての登録は、セクション10.16.1に示されているテンプレートに従います。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
* The proofing method provides sufficient coverage of and binding to the protocol messages to which it is applied.
* 校正方法は、適用されるプロトコルメッセージの十分なカバレッジとバインディングを提供します。
* The proofing method definition clearly enumerates how all requirements in Section 7.3 are fulfilled by the definition.
* 校正方法の定義は、セクション7.3のすべての要件が定義によってどのように満たされるかを明確に列挙しています。
Method:
方法：
A unique string code for the key proofing method.
キープルーフメソッドの一意の文字列コード。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+=========+========+===========================+
| Method | Type | Reference |
+=========+========+===========================+
| httpsig | string | Section 7.3.1 of RFC 9635 |
+---------+--------+---------------------------+
| httpsig | object | Section 7.3.1 of RFC 9635 |
+---------+--------+---------------------------+
| mtls | string | Section 7.3.2 of RFC 9635 |
+---------+--------+---------------------------+
| jwsd | string | Section 7.3.3 of RFC 9635 |
+---------+--------+---------------------------+
| jws | string | Section 7.3.4 of RFC 9635 |
+---------+--------+---------------------------+
Table 14
This document defines formats for a public key value, for which IANA has created and maintains a new registry titled "GNAP Key Formats". Initial values for this registry are given in Section 10.17.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAPキー形式」というタイトルの新しいレジストリを作成および維持している公開キー値のフォーマットを定義しています。このレジストリの初期値は、セクション10.17.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.17.1.
* すべての登録は、セクション10.17.1に示されているテンプレートに従います。
* The key format specifies the structure and serialization of the key material.
* キー形式は、キーマテリアルの構造とシリアル化を指定します。
Format:
形式：
A unique string code for the key format.
キー形式の一意の文字列コード。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+===========+=========================+
| Format | Reference |
+===========+=========================+
| jwk | Section 7.1 of RFC 9635 |
+-----------+-------------------------+
| cert | Section 7.1 of RFC 9635 |
+-----------+-------------------------+
| cert#S256 | Section 7.1 of RFC 9635 |
+-----------+-------------------------+
Table 15
This document defines a discovery document for an AS, for which IANA has created and maintains a new registry titled "GNAP Authorization Server Discovery Fields". Initial values for this registry are given in Section 10.18.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントでは、IANAが「GNAP Authorization Server Discoveryフィールド」というタイトルの新しいレジストリを作成および維持しているASの発見ドキュメントを定義しています。このレジストリの初期値は、セクション10.18.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to ensure the following:
DEは、次のことを確実にすることが期待されています。
* All registrations follow the template presented in Section 10.18.1.
* すべての登録は、セクション10.18.1に示されているテンプレートに従います。
* Registrations for the same name with different types are sufficiently close in functionality so as not to cause confusion for developers.
* さまざまなタイプの同じ名前の登録は、開発者に混乱を引き起こさないように、機能が十分に近いです。
* The values in the discovery document are sufficient to provide optimization and hints to the client instance, but knowledge of the discovered value is not required for starting a transaction with the AS.
* ディスカバリードキュメントの値は、クライアントインスタンスに最適化とヒントを提供するのに十分ですが、ASとのトランザクションを開始するには発見された価値の知識は必要ありません。
Name:
名前：
An identifier for the parameter.
パラメーターの識別子。
Type:
タイプ：
The JSON type allowed for the value.
JSONタイプは値を許可しました。
Reference:
参照：
Reference to one or more documents that specify 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.
値を指定する1つ以上のドキュメントを参照してください。できれば、ドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
+======================================+==========+=============+
| Name | Type | Reference |
+======================================+==========+=============+
| grant_request_endpoint | string | Section 9 |
| | | of RFC 9635 |
+--------------------------------------+----------+-------------+
| interaction_start_modes_supported | array of | Section 9 |
| | strings | of RFC 9635 |
+--------------------------------------+----------+-------------+
| interaction_finish_methods_supported | array of | Section 9 |
| | strings | of RFC 9635 |
+--------------------------------------+----------+-------------+
| key_proofs_supported | array of | Section 9 |
| | strings | of RFC 9635 |
+--------------------------------------+----------+-------------+
| sub_id_formats_supported | array of | Section 9 |
| | strings | of RFC 9635 |
+--------------------------------------+----------+-------------+
| assertion_formats_supported | array of | Section 9 |
| | strings | of RFC 9635 |
+--------------------------------------+----------+-------------+
| key_rotation_supported | boolean | Section 9 |
| | | of RFC 9635 |
+--------------------------------------+----------+-------------+
Table 16
In addition to the normative requirements in this document, implementors are strongly encouraged to consider these additional security considerations in implementations and deployments of 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 AS, all requests from the client instance to an RS, and any requests back to a client instance such as the push-based interaction finish method. Additionally, all requests between a browser and other components, such as during redirect-based interaction, need to be made over TLS or use equivalent protection such as a network connection local to the browser ("localhost").
[BCP195]で概説されているように、信頼されていないネットワーク接続を介して行われたGNAPのすべての要求は、攻撃者による操作と傍受からの要求と応答の内容を保護するために、TLSを介して行う必要があります。これには、クライアントインスタンスからASへのすべての要求、クライアントインスタンスからRSへのすべての要求、およびプッシュベースのインタラクション仕上げ方式などのクライアントインスタンスへのすべてのリクエストが含まれます。さらに、リダイレクトベースのインタラクション中など、ブラウザと他のコンポーネントとの間のすべての要求は、TLSを介して行うか、ブラウザにローカルするネットワーク接続（ "LocalHost"）などの同等の保護を使用する必要があります。
Even though requests from the client instance to the AS are signed, the signature method alone does not protect the request from interception by an attacker. TLS protects the response as well as the request, preventing an attacker from intercepting requested information as it is returned. This is particularly important in this specification for security artifacts such as nonces and for personal information such as subject information.
クライアントインスタンスからASに署名されているリクエストは、署名方法だけでは攻撃者による傍受からの要求を保護しません。TLSは、応答とリクエストを保護し、攻撃者が返されると要求された情報を傍受するのを防ぎます。これは、Noncesなどのセキュリティアーティファクトやサブジェクト情報などの個人情報のこの仕様において特に重要です。
The use of key-bound access tokens does not negate the requirement for protecting calls to the RS with TLS. The keys and signatures associated with a bound access token will prevent an attacker from using a stolen token; however, without TLS, an attacker would be able to watch the data being sent to the RS and returned from the RS during legitimate use of the client instance under attack. Additionally, without TLS, an attacker would be able to profile the calls made between the client instance and RS, possibly gaining information about the functioning of the API between the client software and RS software that would otherwise be unknown to the attacker.
キーバウンドアクセストークンの使用は、TLSを使用してRSへのコールを保護するための要件を無効にしません。バインドされたアクセストークンに関連付けられたキーと署名は、攻撃者が盗まれたトークンを使用することを防ぎます。ただし、TLSがなければ、攻撃者はRSに送信されるデータを視聴し、攻撃中のクライアントインスタンスの正当な使用中にRSから返されることができます。さらに、TLSがなければ、攻撃者はクライアントインスタンスとRSの間で行われた呼び出しをプロファイルでき、攻撃者には知られていないクライアントソフトウェアとRSソフトウェアの間のAPIの機能に関する情報を得ることができます。
Note that connections from the end user and RO's browser also need to be protected with TLS. This applies during initial redirects to an AS's components during interaction, during any interaction with the RO, and during any redirect back to the client instance. Without TLS protection on these portions of the process, an attacker could wait for a valid request to start and then take over the RO's interaction session.
エンドユーザーとROのブラウザからの接続もTLSで保護する必要があることに注意してください。これは、インタラクション中のASのコンポーネントへの最初のリダイレクト、ROとの相互作用中、およびクライアントインスタンスへのリダイレクト中に適用されます。プロセスのこれらの部分についてTLS保護がなければ、攻撃者は有効なリクエストが開始するのを待ってからROのインタラクションセッションを引き継ぐことができます。
Even though all requests in GNAP need to be transmitted over TLS or its equivalent, the use of TLS alone is not sufficient to protect all parts of a multi-party and multi-stage protocol like GNAP, and TLS is not targeted at tying multiple requests to each other over time. To account for this, GNAP makes use of message-level protection and key presentation mechanisms that strongly associate a request with a key held by the client instance (see Section 7).
GNAPのすべての要求はTLSまたはその同等物を介して送信する必要がありますが、TLSのみの使用は、GNAPのようなマルチパーティおよびマルチステージプロトコルのすべての部分を保護するのに十分ではなく、TLSは複数のリクエストを結び付けることではありません時間の経過とともにお互いに。これを説明するために、GNAPは、リクエストをクライアントインスタンスが保持しているキーに強く関連付けるメッセージレベルの保護とキープレゼンテーションメカニズムを使用します（セクション7を参照）。
During the initial request from a client instance to the AS, the client instance has to identify and prove possession of a cryptographic key. If the key is known to the AS, e.g., previously registered or dereferenceable to a trusted source, the AS can associate a set of policies to the client instance identified by the key. Without the requirement that the client instance prove that it holds that key, the AS could not trust that the connection came from any particular client and could not apply any associated policies.
クライアントインスタンスからASへの最初の要求中、クライアントインスタンスは暗号化キーの所有を特定して証明する必要があります。キーが、以前に登録されていない、または信頼できるソースに登録可能なASに知られている場合、ASは、キーによって識別されたクライアントインスタンスに一連のポリシーを関連付けることができます。クライアントインスタンスがそのキーを保持していることを証明するという要件がなければ、接続が特定のクライアントから来て、関連するポリシーを適用できなかったことを信頼できませんでした。
Even more importantly, the client instance proving possession of a key on the first request allows the AS to associate future requests with each other by binding all future requests in that transaction to the same key. The access token used for grant continuation is bound to the same key and proofing mechanism used by the client instance in its initial request; this means that the client instance needs to prove possession of that same key in future requests, which allows the AS to be sure that the same client instance is executing the follow-ups for a given ongoing grant request. Therefore, the AS has to ensure that all subsequent requests for a grant are associated with the same key that started the grant or with the most recent rotation of that key. This need holds true even if the initial key is previously unknown to the AS, such as would be the case when a client instance creates an ephemeral key for its request. Without this ongoing association, an attacker would be able to impersonate a client instance in the midst of a grant request, potentially stealing access tokens and subject information with impunity.
さらに重要なことは、最初のリクエストでキーの所有を証明するクライアントインスタンスにより、そのトランザクションのすべての将来の要求を同じキーにバインドすることにより、将来の要求を互いに関連付けることができます。助成金の継続に使用されるアクセストークンは、クライアントインスタンスが最初の要求で使用する同じキーとプルーフメカニズムに拘束されます。これは、クライアントインスタンスが将来のリクエストでその同じキーの所有を証明する必要があることを意味します。これにより、同じクライアントインスタンスが特定の継続的な助成金リクエストのフォローアップを実行していることを確認できます。したがって、ASは、助成金の後続のすべての要求が、助成金を開始したのと同じキーまたはそのキーの最新のローテーションに関連付けられていることを確認する必要があります。クライアントインスタンスがリクエストのために一時的なキーを作成する場合、初期キーが以前にASに不明であっても、この必要性は当てはまります。この継続的な協会がなければ、攻撃者は助成金要求の最中にクライアントインスタンスになりすまし、アクセストークンと免責を伴う主題情報を盗む可能性があります。
Additionally, all access tokens in GNAP default to be associated with the key that was presented during the grant request that created the access token. This association allows an RS to know that the presenter of the access token is the same party that the token was issued to, as identified by their keys. While non-bound bearer tokens are an option in GNAP, these types of tokens have their own trade-offs, which are discussed in Section 11.9.
さらに、GNAPのすべてのアクセストークンは、アクセストークンを作成した助成金リクエスト中に提示されたキーにデフォルトであることがデフォルトです。この協会により、RSはアクセストークンのプレゼンターが、キーによって特定されたように、トークンが発行されたのと同じパーティーであることを知ることができます。非結合ベアラートークンはGNAPのオプションですが、これらのタイプのトークンには独自のトレードオフがあり、セクション11.9で説明されています。
TLS functions at the transport layer, ensuring that only the parties on either end of that connection can read the information passed along that connection. Each time a new connection is made, such as for a new HTTP request, a new trust that is mostly unrelated to previous connections is re-established. While modern TLS does make use of session resumption, this still needs to be augmented with authentication methods to determine the identity of parties on the connections. In other words, it is not possible with TLS alone to know that the same party is making a set of calls over time, since each time a new TLS connection is established, both the client and the server (or the server only when using MTLS (Section 7.3.2)) have to validate the other party's identity. Such a verification can be achieved via methods described in [RFC9525], but these are not enough to establish the identity of the client instance in many cases.
TLSは輸送層で機能し、その接続の両端にある当事者のみがその接続に沿って渡された情報を読み取ることができるようにします。新しいHTTP要求など、新しい接続が行われるたびに、以前の接続とほとんど関係のない新しい信頼が再確立されます。最新のTLSはセッション再開を利用していますが、これはまだ接続上の当事者の身元を決定するための認証方法で補強する必要があります。言い換えれば、TLSだけでは、新しいTLS接続が確立されるたびに、クライアントとサーバーの両方（またはMTLSを使用する場合にのみサーバーのみが確立されるため、同じパーティが時間の経過とともに一連の呼び出しを行っていることを知ることはできません。（セクション7.3.2））相手の身元を検証する必要があります。このような検証は、[RFC9525]で説明されている方法で達成できますが、これらは多くの場合、クライアントインスタンスのIDを確立するには十分ではありません。
To counter this, GNAP defines a set of key binding methods in Section 7.3 that allows authentication and proof of possession by the caller, which is usually the client instance. These methods are intended to be used in addition to TLS on all connections.
これに対抗するために、GNAPはセクション7.3の重要なバインディング方法のセットを定義します。これにより、通常はクライアントインスタンスである発信者による認証と所持の証明が可能です。これらの方法は、すべての接続でTLSに加えて使用することを目的としています。
The MTLS key proofing mechanism (Section 7.3.2) provides a means for a client instance to present a key using a certificate at the TLS layer. Since TLS protects the entire HTTP message in transit, verification of the TLS client certificate presented with the message provides a sufficient binding between the two. However, since TLS is functioning at a separate layer from HTTP, there is no direct connection between the TLS key presentation and the message itself, other than the fact that the message was presented over the TLS channel. That is to say, any HTTP message can be presented over the TLS channel in question with the same level of trust. The verifier is responsible for ensuring the key in the TLS client certificate is the one expected for a particular request. For example, if the request is a grant request (Section 2), the AS needs to compare the TLS client certificate presented at the TLS layer to the key identified in the request content itself (either by value or through a referenced identifier).
MTLSキープルーフメカニズム（セクション7.3.2）は、クライアントインスタンスがTLSレイヤーで証明書を使用してキーを提示する手段を提供します。TLSはトランジットでHTTPメッセージ全体を保護するため、メッセージに提示されたTLSクライアント証明書の検証は、2つの間に十分なバインディングを提供します。ただし、TLSはHTTPから別のレイヤーで機能しているため、TLSチャネルでメッセージが表示されたという事実を除いて、TLSキープレゼンテーションとメッセージ自体の間に直接的な接続はありません。つまり、同じレベルの信頼を持って、問題のTLSチャネルを介してHTTPメッセージを提示できます。Verifierは、TLSクライアント証明書のキーが特定のリクエストに期待されるものであることを確認する責任があります。たとえば、要求が助成金要求（セクション2）である場合、ASは、TLSレイヤーで提示されたTLSクライアント証明書をリクエストコンテンツ自体で（値または参照識別子を介して）識別したキーと比較する必要があります。
Furthermore, the prevalence of the TLS terminating reverse proxy (TTRP) pattern in deployments adds a wrinkle to the situation. In this common pattern, the TTRP validates the TLS connection and then forwards the HTTP message contents onward to an internal system for processing. The system processing the HTTP message no longer has access to the original TLS connection's information and context. To compensate for this, the TTRP could inject the TLS client certificate into the forwarded request using the HTTP Client-Cert header field [RFC9111], giving the downstream system access to the certificate information. The TTRP has to be trusted to provide accurate certificate information, and the connection between the TTRP and the downstream system also has to be protected. The TTRP could provide some additional assurance, for example, by adding its own signature to the Client-Cert header field using HTTP message signatures [RFC9421]. This signature would be effectively ignored by GNAP (since it would not use GNAP's tag parameter value) but would be understood by the downstream service as part of its deployment.
さらに、展開の逆プロキシ（TTRP）パターンを終了するTLSの有病率は、状況にしわを追加します。この共通パターンでは、TTRPはTLS接続を検証し、HTTPメッセージコンテンツを処理のために内部システムに転送します。HTTPメッセージを処理するシステムは、元のTLS接続の情報とコンテキストにアクセスできなくなりました。これを補うために、TTRPは、HTTPクライアントキャットヘッダーフィールド[RFC9111]を使用して、TLSクライアント証明書を転送要求に挿入し、下流システムに証明書情報にアクセスできるようにします。TTRPは、正確な証明書情報を提供するために信頼する必要があり、TTRPとダウンストリームシステムの間の接続も保護する必要があります。TTRPは、HTTPメッセージ署名[RFC9421]を使用して、クライアントキャットヘッダーフィールドに独自の署名を追加することにより、追加の保証を提供できます。この署名は、GNAPによって効果的に無視されます（GNAPのタグパラメーター値は使用しないため）が、展開の一部としてダウンストリームサービスによって理解されます。
Additional considerations for different types of deployment patterns and key distribution mechanisms for MTLS are found in Section 11.4.
さまざまなタイプの展開パターンとMTLの主要な分布メカニズムについての追加の考慮事項は、セクション11.4にあります。
GNAP does not specify how a client instance's keys could be made known to the AS ahead of time. The Public Key Infrastructure (PKI) can be used to manage the keys used by client instances when calling the AS, allowing the AS to trust a root key from a trusted authority. This method is particularly relevant to the MTLS key proofing method, where the client instance presents its certificate to the AS as part of the TLS connection. An AS using PKI to validate the MTLS connection would need to ensure that the presented certificate was issued by a trusted certificate authority before allowing the connection to continue. PKI-based certificates would allow a key to be revoked and rotated through management at the certificate authority without requiring additional registration or management at the AS. The PKI required to manage mutually authenticated TLS has historically been difficult to deploy, especially at scale, but it remains an appropriate solution for systems where the required management overhead is not an impediment.
GNAPでは、クライアントインスタンスのキーを事前に把握する方法を指定していません。公開キーインフラストラクチャ（PKI）を使用して、ASを呼び出すときにクライアントインスタンスが使用するキーを管理し、信頼できる当局からルートキーを信頼できるようにします。この方法は、クライアントインスタンスが証明書をTLS接続の一部として提示するMTLSキープルーフ方法に特に関連しています。AS PKIを使用してMTLS接続を検証するには、接続を継続する前に、提示された証明書が信頼できる証明書当局によって発行されるようにする必要があります。PKIベースの証明書は、ASで追加の登録や管理を必要とせずに、証明書当局の管理を通じてキーを取り消し、回転させることができます。相互に認証されたTLSを管理するために必要なPKIは、特に大規模に展開することが歴史的に困難でしたが、必要な管理オーバーヘッドが障害ではないシステムにとって適切なソリューションのままです。
MTLS in GNAP need not use a PKI backing, as self-signed certificates and certificates from untrusted authorities can still be presented as part of a TLS connection. In this case, the verifier would validate the connection but accept whatever certificate was presented by the client software. This specific certificate can then be bound to all future connections from that client software by being bound to the resulting access tokens, in a trust-on-first-use pattern. See Section 11.3 for more considerations on MTLS as a key proofing mechanism.
GNAPのMTLSは、信頼されていない当局からの自己署名証明書と証明書をTLS接続の一部として提示できるため、PKIバッキングを使用する必要はありません。この場合、Verifierは接続を検証しますが、クライアントソフトウェアによって提示された証明書を受け入れます。この特定の証明書は、結果のアクセストークンにバインドされることにより、そのクライアントソフトウェアからのすべての将来の接続にバインドできます。重要な校正メカニズムとしてMTLの詳細については、セクション11.3を参照してください。
Client instances are identified by their unique keys, and anyone with access to a client instance's key material will be able to impersonate that client instance to all parties. This is true for both calls to the AS as well as calls to an RS using an access token bound to the client instance's unique key. As a consequence, it is of utmost importance for a client instance to protect its private key material.
クライアントインスタンスは独自のキーによって識別され、クライアントインスタンスのキー資料にアクセスできる人なら誰でも、すべての関係者にそのクライアントインスタンスになりすまします。これは、ASへの呼び出しと、クライアントインスタンスの一意のキーにバインドされたアクセストークンを使用したRSへの呼び出しの両方に当てはまります。結果として、クライアントのインスタンスが秘密のキー資料を保護することが最も重要です。
Different types of client software have different methods for creating, managing, and registering keys. GNAP explicitly allows for ephemeral clients such as single-page applications (SPAs) and single-user clients (such as mobile applications) to create and present their own keys during the initial grant request without any explicit pre-registration step. The client software can securely generate a key pair on the device and present the public key, along with proof of holding the associated private key, to the AS as part of the initial request. To facilitate trust in these ephemeral keys, GNAP further allows for an extensible set of client information to be passed with the request. This information can include device posture and third-party attestations of the client software's provenance and authenticity, depending on the needs and capabilities of the client software and its deployment.
さまざまな種類のクライアントソフトウェアには、キーの作成、管理、登録のさまざまな方法があります。GNAPは、明示的な事前登録ステップなしで、最初の助成金リクエスト中に独自のキーを作成および提示するために、シングルページアプリケーション（SPA）やシングルユーザークライアント（モバイルアプリケーションなど）などの短命クライアントを明示的に許可します。クライアントソフトウェアは、デバイス上のキーペアを安全に生成し、関連する秘密鍵を保持することの証明とともに、最初の要求の一部として公開キーを提示できます。これらのはかないキーへの信頼を促進するために、GNAPはさらに、クライアント情報の拡張セットをリクエストに合わせて渡すことができます。この情報には、クライアントソフトウェアのニーズと能力とその展開に応じて、クライアントソフトウェアの出所と信頼性のデバイス姿勢とサードパーティの証明を含めることができます。
From GNAP's perspective, each distinct key is a different client instance. However, multiple client instances can be grouped together by an AS policy and treated similarly to each other. For instance, if an AS knows of several different keys for different servers within a cluster, the AS can decide that authorization of one of these servers applies to all other servers within the cluster. An AS that chooses to do this needs to be careful with how it groups different client keys together in its policy, since the breach of one instance would have direct effects on the others in the cluster.
GNAPの観点から見ると、それぞれの異なるキーは異なるクライアントインスタンスです。ただし、複数のクライアントインスタンスをAS ASポリシーによってグループ化し、互いに同様に扱うことができます。たとえば、クラスター内の異なるサーバーのいくつかの異なるキーをASが知っている場合、これらのサーバーのいずれかの許可がクラスター内の他のすべてのサーバーに適用されることを決定できます。これを行うことを選択すると、あるインスタンスの違反はクラスター内の他のインスタンスに直接的な影響を与えるため、これを行うことを選択する必要があります。
Additionally, if an end user controls multiple instances of a single type of client software, such as having an application installed on multiple devices, each of these instances is expected to have a separate key and be issued separate access tokens. However, if the AS is able to group these separate instances together as described above, it can streamline the authorization process for new instances of the same client software. For example, if two client instances can present proof of a valid installation of a piece of client software, the AS would be able to associate the approval of the first instance of this software to all related instances. The AS could then choose to bypass an explicit prompt of the RO for approval during authorization, since such approval has already been given. An AS doing such a process would need to take assurance measures that the different instances are in fact correlated and authentic, as well as ensure that the expected RO is in control of the client instance.
さらに、エンドユーザーが複数のデバイスにアプリケーションをインストールするなど、単一のタイプのクライアントソフトウェアの複数のインスタンスを制御する場合、これらの各インスタンスには個別のキーがあり、個別のアクセストークンが発行されると予想されます。ただし、上記のようにこれらの個別のインスタンスをグループ化できる場合、同じクライアントソフトウェアの新しいインスタンスの承認プロセスを合理化できます。たとえば、2つのクライアントインスタンスがクライアントソフトウェアの有効なインストールの証明を提示できる場合、このソフトウェアの最初のインスタンスの承認を関連するすべてのインスタンスに関連付けることができます。そのような承認がすでに与えられているため、ASは、承認中に承認のためにROの明示的なプロンプトをバイパスすることを選択できます。そのようなプロセスを行うと、さまざまなインスタンスが実際に相関して本物であるという保証措置を講じる必要があり、予想されるROがクライアントインスタンスを制御していることを確認する必要があります。
Finally, if multiple instances of client software each have the same key, then from GNAP's perspective, these are functionally the same client instance as GNAP has no reasonable way to differentiate between them. This situation could happen if multiple instances within a cluster can securely share secret information among themselves. Even though there are multiple copies of the software, the shared key makes these copies all present as a single instance. It is considered bad practice to share keys between copies of software unless they are very tightly integrated with each other and can be closely managed. It is particularly bad practice to allow an end user to copy keys between client instances and to willingly use the same key in multiple instances.
最後に、クライアントソフトウェアの複数のインスタンスがそれぞれ同じキーを持っている場合、GNAPの観点からは、GNAPがそれらを区別する合理的な方法がないため、これらは機能的に同じクライアントインスタンスです。この状況は、クラスター内の複数のインスタンスが秘密情報を安全に共有できる場合に発生する可能性があります。ソフトウェアには複数のコピーがありますが、共有キーはこれらのコピーをすべて単一のインスタンスとして存在させます。ソフトウェアが非常に緊密に統合されており、綿密に管理できる場合を除き、ソフトウェアのコピー間でキーを共有することは悪い習慣と考えられています。エンドユーザーがクライアントインスタンス間でキーをコピーし、複数のインスタンスで同じキーを喜んで使用できるようにすることは特に悪い習慣です。
The AS performs critical functions in GNAP, including authenticating client software, managing interactions with end users to gather consent and provide notice, and issuing access tokens for client instances to present to RSs. As such, protecting the AS is central to any GNAP deployment.
ASは、クライアントソフトウェアの認証、エンドユーザーとの対話の管理に同意を収集して通知を提供すること、RSSに提示するクライアントインスタンスのアクセストークンを発行するなど、GNAPで重要な機能を実行します。そのため、GNAPの展開の中心であるASを保護します。
If an attacker is able to gain control over an AS, they would be able to create fraudulent tokens and manipulate registration information to allow for malicious clients. These tokens and clients would be trusted by other components in the ecosystem under the protection of the AS.
攻撃者がASを制御できる場合、不正なトークンを作成し、登録情報を操作して悪意のあるクライアントを許可することができます。これらのトークンとクライアントは、ASの保護下にある生態系の他のコンポーネントによって信頼されます。
If the AS uses signed access tokens, an attacker in control of the AS's signing keys would be able to manufacture fraudulent tokens for use at RSs under the protection of the AS.
ASが署名されたAccess Tokenを使用する場合、ASの署名キーを制御する攻撃者は、ASの保護下でRSSで使用するために不正なトークンを製造することができます。
If an attacker is able to impersonate an AS, they would be able to trick legitimate client instances into making signed requests for information that could potentially be proxied to a real AS. To combat this, all communications to the AS need to be made over TLS or its equivalent, and the software making the connection has to validate the certificate chain of the host it is connecting to.
攻撃者がASになりすましている場合、正当なクライアントインスタンスをだまして、潜在的に実際のASにプロキシできる可能性のある情報の署名されたリクエストを作成することができます。これに対処するために、TLSまたはその同等物を介して行う必要があるASのすべての通信、および接続を作成するソフトウェアは、接続しているホストの証明書チェーンを検証する必要があります。
Consequently, protecting, monitoring, and auditing the AS is paramount to preserving the security of a GNAP-protected ecosystem. The AS presents attackers with a valuable target for attack. Fortunately, the core focus and function of the AS is to provide security for the ecosystem, unlike the RS whose focus is to provide an API or the client software whose focus is to access the API.
その結果、GNAPで保護されたエコシステムのセキュリティを維持するために最も重要なASを保護、監視、監査します。ASは、攻撃者を攻撃の貴重なターゲットで提示します。幸いなことに、ASの中心的な焦点と機能は、APIまたはAPIにアクセスすることに焦点を当てるAPIまたはクライアントソフトウェアを提供するRSとは異なり、エコシステムにセキュリティを提供するためです。
Many of the cryptographic methods used by GNAP for key proofing can support both asymmetric and symmetric cryptography, and they can be extended to use a wide variety of mechanisms. Implementors will find the available guidelines on cryptographic key management provided in [RFC4107] useful. While symmetric cryptographic systems have some benefits in speed and simplicity, they have a distinct drawback -- both parties need access to the same key in order to do both signing and verification of the message. When more than two parties share the same symmetric key, data origin authentication is not provided. Any party that knows the symmetric key can compute a valid MAC; therefore, the contents could originate from any one of the parties.
GNAPがキープルーフに使用する暗号化方法の多くは、非対称および対称的な暗号化の両方をサポートでき、拡張してさまざまなメカニズムを使用できます。実装者は、[RFC4107]で提供される暗号化キー管理に関する利用可能なガイドラインが有用であることがわかります。対称的な暗号化システムには速度とシンプルさにいくつかの利点がありますが、それらには明確な欠点があります。両方の当事者は、メッセージの署名と検証の両方を行うために同じキーにアクセスする必要があります。2つ以上の当事者が同じ対称キーを共有している場合、データオリジン認証は提供されません。対称キーを知っている当事者は、有効なMacを計算できます。したがって、内容は当事者のいずれかに由来する可能性があります。
Use of symmetric cryptography means that when the client instance calls the AS to request a token, the AS needs to know the exact value of the client instance's key (or be able to derive it) in order to validate the key proof signature. With asymmetric keys, the client needs to only send its public key to the AS to allow for verification that the client holds the associated private key, regardless of whether or not that key was pre-registered with the AS.
対称暗号化の使用とは、クライアントインスタンスがトークンを要求するように呼び出す場合、必要なASがクライアントインスタンスのキーの正確な値を知る（または導き出すことができる）ことを意味します。非対称キーを使用すると、クライアントは、そのキーがASで事前登録されているかどうかに関係なく、クライアントが関連する秘密鍵を保持することを確認できるように、公開鍵のみを送信する必要があります。
Symmetric keys also have the expected advantage of providing better protection against quantum threats in the future. Also, these types of keys (and their secure derivations) are widely supported among many cloud-based key management systems.
対称キーには、将来の量子脅威に対するより良い保護を提供するという期待される利点もあります。また、これらのタイプのキー（およびその安全な派生）は、多くのクラウドベースのキー管理システムの間で広くサポートされています。
When used to bind to an access token, a key value must be known by the RS in order to validate the proof signature on the request. Common methods for communicating these proofing keys include putting information in a structured access token and allowing the RS to look up the associated key material against the value of the access token. With symmetric cryptography, both of these methods would expose the signing key to the RS and, in the case of a structured access token, potentially to any party that can see the access token itself unless the token's payload has been encrypted. Any of these parties would then be able to make calls using the access token by creating a valid signature using the shared key. With asymmetric cryptography, the RS needs to only know the public key associated with the token in order to validate the request; therefore, the RS cannot create any new signed calls.
アクセストークンにバインドするために使用する場合、リクエストの証明署名を検証するために、RSによってキー値を把握する必要があります。これらの校正キーを通信するための一般的な方法には、構造化されたアクセストークンに情報を入力し、RSがアクセストークンの値に対して関連するキー資料を検索できるようにすることが含まれます。対称的な暗号化により、これらの方法は両方ともRSに署名キーを公開し、構造化されたアクセストークンの場合、トークンのペイロードが暗号化されていない限り、アクセストークン自体を見ることができる当事者に潜在的に。これらの当事者は、共有キーを使用して有効な署名を作成することにより、アクセストークンを使用して通話を行うことができます。非対称の暗号化では、RSはリクエストを検証するためにトークンに関連する公開鍵のみを知る必要があります。したがって、RSは新しい署名された呼び出しを作成することはできません。
While both signing approaches are allowed, GNAP treats these two classes of keys somewhat differently. Only the public portion of asymmetric keys are allowed to be sent by value in requests to the AS when establishing a connection. Since sending a symmetric key (or the private portion of an asymmetric key) would expose the signing material to any parties on the request path, including any attackers, sending these kinds of keys by value is prohibited. Symmetric keys can still be used by client instances, but only if the client instance can send a reference to the key and not its value. This approach allows the AS to use pre-registered symmetric keys as well as key derivation schemes to take advantage of symmetric cryptography without requiring key distribution at runtime, which would expose the keys in transit.
両方の署名アプローチは許可されていますが、GNAPはこれら2つのクラスのキーを多少異なって扱います。非対称キーの公共部分のみが、接続を確立するときにリクエストで値によって値によって送信されることが許可されています。対称キー（または非対称キーの私的部分）を送信すると、攻撃者を含むリクエストパスの任意の当事者に署名資料を公開するため、これらの種類のキーを価値で送信することは禁止されています。対称キーは、クライアントインスタンスで引き続き使用できますが、クライアントインスタンスがその値ではなくキーに参照を送信できる場合のみです。このアプローチにより、事前に登録された対称キーとキー派生スキームを使用して、実行時にキー分布を必要とせずに対称的な暗号化を利用して、輸送中にキーを露出させることができます。
Both the AS and client software can use systems such as hardware security modules to strengthen their key security storage and generation for both asymmetric and symmetric keys (see also Section 7.1.2).
ASとクライアントソフトウェアの両方が、ハードウェアセキュリティモジュールなどのシステムを使用して、非対称キーと対称キーの両方の主要なセキュリティストレージと生成を強化できます（セクション7.1.2も参照）。
The contents of access tokens need to be such that only the generating AS would be able to create them, and the contents cannot be manipulated by an attacker to gain different or additional access rights.
アクセストークンの内容は、それらを作成できるように生成するだけであり、コンテンツを攻撃者が操作して異なるまたは追加のアクセス権を獲得することはできません。
One method for accomplishing this is to use a cryptographically random value for the access token, generated by the AS using a secure randomization function with sufficiently high entropy. The odds of an attacker guessing the output of the randomization function to collide with a valid access token are exceedingly small, and even then, the attacker would not have any control over what the access token would represent since that information would be held close by the AS.
これを達成するための1つの方法は、十分に高いエントロピーを備えた安全なランダム化関数を使用するASによって生成されるアクセストークンに暗号化的にランダムな値を使用することです。有効なアクセストークンと衝突するランダム化関数の出力を推測する攻撃者の確率は非常に小さく、それでも攻撃者は、その情報が近くに保持されるため、アクセストークンが表すものを制御できません。として。
Another method for accomplishing this is to use a structured token that is cryptographically signed. In this case, the payload of the access token declares to the RS what the token is good for, but the signature applied by the AS during token generation covers this payload. Only the AS can create such a signature; therefore, only the AS can create such a signed token. The odds of an attacker being able to guess a signature value with a useful payload are exceedingly small. This technique only works if all targeted RSs check the signature of the access token. Any RS that does not validate the signature of all presented tokens would be susceptible to injection of a modified or falsified token. Furthermore, an AS has to carefully protect the keys used to sign access tokens, since anyone with access to these signing keys would be able to create seemingly valid access tokens using them.
これを達成するためのもう1つの方法は、暗号化された構造化されたトークンを使用することです。この場合、アクセストークンのペイロードは、トークンが何に適しているかをRSに宣言しますが、トークン生成中のように適用される署名はこのペイロードをカバーしています。ASのみがそのような署名を作成できます。したがって、ASのみがそのような署名されたトークンを作成できます。攻撃者が有用なペイロードを使用して署名値を推測できる可能性は非常に少ないです。この手法は、すべてのターゲットRSSがアクセストークンの署名をチェックした場合にのみ機能します。提示されたすべてのトークンの署名を検証しないRSは、修正または偽造されたトークンの注入の影響を受けやすくなります。さらに、ASはアクセストークンに署名するために使用されるキーを慎重に保護する必要があります。これらの署名キーにアクセスできる人なら誰でも、それらを使用して一見有効なアクセストークンを作成できるからです。
Bearer access tokens can be used by any party that has access to the token itself, without any additional information. As a natural consequence, any RS that a bearer token is presented to has the technical capability of presenting that bearer token to another RS, as long as the token is valid. It also means that any party that is able to capture the token value in storage or in transit is able to use the access token. While bearer tokens are inherently simpler, this simplicity has been misapplied and abused in making needlessly insecure systems. The downsides of bearer tokens have become more pertinent lately as stronger authentication systems have caused some attacks to shift to target tokens and APIs.
Bearer Access Tokenは、追加情報なしで、トークン自体にアクセスできる当事者が使用できます。自然な結果として、ベアラートークンが提示されているRSには、トークンが有効である限り、そのベアラートークンを別のRSに提示する技術的能力があります。また、ストレージや輸送中にトークン値をキャプチャできる当事者が、アクセストークンを使用できることを意味します。ベアラーのトークンは本質的にシンプルですが、このシンプルさは不必要に不安定なシステムを作ることに誤って適用され、乱用されています。ベアラートークンの欠点は、より強力な認証システムがターゲットトークンとAPIにシフトするためにいくつかの攻撃を引き起こしたため、最近より適切になっています。
In GNAP, key-bound access tokens are the default due to their higher security properties. While bearer tokens can be used in GNAP, their use should be limited to cases where the simplicity benefits outweigh the significant security downsides. One common deployment pattern is to use a gateway that takes in key-bound tokens on the outside and verifies the signatures on the incoming requests but translates the requests to a bearer token for use by trusted internal systems. The bearer tokens are never issued or available outside of the internal systems, greatly limiting the exposure of the less-secure tokens but allowing the internal deployment to benefit from the advantages of bearer tokens.
GNAPでは、キーバウンドアクセストークンがセキュリティプロパティが高いためデフォルトです。Bearer TokensはGNAPで使用できますが、それらの使用は、シンプルさの利点が重要なセキュリティの欠点を上回る場合に限定する必要があります。一般的な展開パターンの1つは、外側にキーバウンドトークンを取り入れ、着信要求の署名を検証するが、信頼できる内部システムが使用するためにリクエストをBearerトークンに変換するゲートウェイを使用することです。ベアラーのトークンは、内部システムの外部で発行または利用可能になることはなく、安全性の低いトークンの露出を大幅に制限しますが、内部展開はベアラートークンの利点から利益を得ることができます。
Key-bound access tokens, as the name suggests, are bound to a specific key and must be presented along with proof of that key during use. The key itself is not presented at the same time as the token, so even if a token value is captured, it cannot be used to make a new request. This is particularly true for an RS, which will see the token value but will not see the keys used to make the request (assuming asymmetric cryptography is in use, see Section 11.7).
名前が示唆するように、キーバウンドアクセストークンは特定のキーにバインドされており、使用中にそのキーの証明とともに提示する必要があります。キー自体はトークンと同時に提示されていないため、トークン値がキャプチャされていても、新しいリクエストを行うために使用することはできません。これは、トークン値が表示されますが、リクエストを行うために使用されるキーが表示されないRSに特に当てはまります（非対称の暗号化が使用されていると仮定して、セクション11.7を参照）。
Key-bound access tokens provide this additional layer of protection only when the RS checks the signature of the message presented with the token. Acceptance of an invalid presentation signature, or failure to check the signature entirely, would allow an attacker to make calls with a captured access token without having access to the related signing key material.
キーバウンドアクセストークンは、RSがトークンで提示されたメッセージの署名をチェックした場合にのみ、この追加の保護層を提供します。無効なプレゼンテーションの署名を受け入れること、または署名を完全に確認できなかったため、攻撃者は、関連する署名キー資料にアクセスすることなく、キャプチャされたアクセストークンで電話をかけることができます。
In addition to validating the signature of the presentation message itself, the RS also needs to ensure that the signing key used is appropriate for the presented token. If an RS does not ensure that the right keys were used to sign a message with a specific token, an attacker would be able to capture an access token and sign the request with their own keys, thereby negating the benefits of using key-bound access tokens.
プレゼンテーションメッセージ自体の署名を検証することに加えて、RSは、使用される署名キーが提示されたトークンに適していることを確認する必要があります。RSが特定のトークンでメッセージに署名するために適切なキーを使用していない場合、攻撃者はアクセストークンをキャプチャして独自のキーでリクエストに署名することができ、それによってキーバウンドアクセスを使用することの利点を無効にすることができますトークン。
The RS also needs to ensure that sufficient portions of the message are covered by the signature. Any items outside the signature could still affect the API's processing decisions, but these items would not be strongly bound to the token presentation. As such, an attacker could capture a valid request and then manipulate portions of the request outside of the signature envelope in order to cause unwanted actions at the protected API.
また、RSは、メッセージの十分な部分が署名でカバーされるようにする必要があります。署名以外のアイテムはAPIの処理決定に依然として影響する可能性がありますが、これらのアイテムはトークンプレゼンテーションに強く縛られません。そのため、攻撃者は有効なリクエストをキャプチャし、保護されたAPIで不要なアクションを引き起こすために、署名エンベロープの外側でリクエストの一部を操作できます。
Some key-bound tokens are susceptible to replay attacks, depending on the details of the signing method used. Therefore, key proofing mechanisms used with access tokens need to use replay-protection mechanisms covered under the signature such as a per-message nonce, a reasonably short time validity window, or other uniqueness constraints. The details of using these will vary depending on the key proofing mechanism in use. For example, HTTP message signatures have both a created and nonce signature parameter as well as the ability to cover significant portions of the HTTP message. All of these can be used to limit the attack surface.
一部のキーバウンドトークンは、使用される署名方法の詳細に応じて、攻撃を再生しやすくなります。したがって、アクセストークンで使用される重要なプルーフメカニズムは、署名の範囲で覆われたリプレイ保護メカニズムを使用する必要があります。これらの使用の詳細は、使用中の主要なプルーフメカニズムによって異なります。たとえば、HTTPメッセージ署名には、作成された署名パラメーターとNonCE署名パラメーターの両方と、HTTPメッセージの重要な部分をカバーする機能があります。これらはすべて、攻撃面を制限するために使用できます。
As a delegation protocol, one of the main goals of GNAP is to prevent the client software from being exposed to any credentials or information about the end user or RO as a requirement of the delegation process. By using the variety of interaction mechanisms, the RO can interact with the AS without ever authenticating to the client software and without the client software having to impersonate the RO through replay of their credentials.
委任プロトコルとして、GNAPの主な目標の1つは、クライアントソフトウェアが委任プロセスの要件としてエンドユーザーまたはROに関する資格情報または情報にさらされるのを防ぐことです。さまざまな相互作用メカニズムを使用することにより、ROはクライアントソフトウェアを認証することなく、クライアントソフトウェアが資格情報のリプレイを介してROになりすまさなければASと対話できます。
Consequently, no interaction methods defined in this specification require the end user to enter their credentials, but it is technologically possible for an extension to be defined to carry such values. Such an extension would be dangerous as it would allow rogue client software to directly collect, store, and replay the end user's credentials outside of any legitimate use within a GNAP request.
したがって、この仕様で定義されたインタラクション方法は、エンドユーザーが資格情報を入力する必要はありませんが、拡張機能をそのような値を運ぶために定義することは技術的に可能です。このような拡張機能は、RogueクライアントソフトウェアがGNAPリクエスト内の正当な使用以外のエンドユーザーの資格情報を直接収集、保存、再生できるようにするため、危険です。
The concerns of such an extension could be mitigated through use of a challenge and response unlocked by the end user's credentials. For example, the AS presents a challenge as part of an interaction start method, and the client instance signs that challenge using a key derived from a password presented by the end user. It would be possible for the client software to collect this password in a secure software enclave without exposing the password to the rest of the client software or putting it across the wire to the AS. The AS can validate this challenge response against a known password for the identified end user. While an approach such as this does not remove all of the concerns surrounding such a password-based scheme, it is at least possible to implement in a more secure fashion than simply collecting and replaying the password. Even so, such schemes should only ever be used by trusted clients due to the ease of abusing them.
このような拡張機能の懸念は、エンドユーザーの資格情報によってロック解除された課題と応答を使用することで軽減できます。たとえば、ASはインタラクション開始方法の一部として課題を提示し、クライアントインスタンスは、エンドユーザーが提示したパスワードから派生したキーを使用して挑戦する兆候です。クライアントソフトウェアは、パスワードを残りのクライアントソフトウェアに公開したり、ASにワイヤーに配置することなく、安全なソフトウェアエンクレーブでこのパスワードを収集することができます。ASは、特定されたエンドユーザーの既知のパスワードに対するこのチャレンジ応答を検証できます。このようなアプローチでは、このようなパスワードベースのスキームを取り巻くすべての懸念を削除するわけではありませんが、単にパスワードを収集して再生するよりも、より安全な方法で実装することは少なくとも可能です。それでも、そのようなスキームは、信頼できるクライアントを虐待しやすいためにのみ使用する必要があります。
If a client instance is able to work with multiple ASes simultaneously, it is possible for an attacker to add a compromised AS to the client instance's configuration and cause the client software to start a request at the compromised AS. This AS could then proxy the client's request to a valid AS in order to attempt to get the RO to approve access for the legitimate client instance.
クライアントインスタンスが複数のASEを同時に操作できる場合、攻撃者がクライアントインスタンスの構成に関して妥協したものを追加し、クライアントソフトウェアが妥協したASでリクエストを開始する可能性があります。これは、正当なクライアントインスタンスへのアクセスを承認するためにROに承認しようとするために、クライアントの有効な要求を有効なものにプロキシできるようにします。
A client instance needs to always be aware of which AS it is talking to throughout a grant process and ensure that any callback for one AS does not get conflated with the callback to different AS. The interaction finish hash calculation in Section 4.2.3 allows a client instance to protect against this kind of substitution, but only if the client instance validates the hash. If the client instance does not use an interaction finish method or does not check the interaction finish hash value, the compromised AS can be granted a valid access token on behalf of the RO. See Sections 4.5.5 and 5.5 of [AXELAND2021] for details of one such attack, which has been addressed in this document by including the grant endpoint in the interaction hash calculation. Note that the client instance still needs to validate the hash for the attack to be prevented.
クライアントのインスタンスは、助成金プロセス全体で話し合っているため、常にどのようなものであるかを常に認識し、別のASへのコールバックと混同されないようにすることを確認する必要があります。セクション4.2.3のインタラクション仕上げハッシュ計算により、クライアントインスタンスはこの種の置換から保護できますが、クライアントインスタンスがハッシュを検証する場合のみです。クライアントインスタンスがインタラクション仕上げメソッドを使用せず、インタラクション仕上げハッシュ値を確認しない場合、ROに代わって有効なアクセストークンを付与できるように妥協します。[Axeland2021]のセクション4.5.5および5.5を参照してください。このような攻撃の詳細については、相互作用ハッシュ計算に付与エンドポイントを含めることでこのドキュメントで扱われています。クライアントインスタンスは、攻撃を防ぐためにハッシュを検証する必要があることに注意してください。
GNAP allows the client instance to present assertions and identifiers of the current user to the AS as part of the initial request. This information should only ever be taken by the AS as a hint, since the AS has no way to tell if the represented person is present at the client software without using an interaction mechanism. This information does not guarantee the given user is there, but it does constitute a statement by the client software that the AS can take into account.
GNAPを使用すると、クライアントインスタンスは、現在のユーザーのアサーションと識別子を最初のリクエストの一部として提示することができます。この情報は、ASがインタラクションメカニズムを使用せずに代表者がクライアントソフトウェアに存在するかどうかを判断する方法がないため、ヒントとしてのみ取得されるべきです。この情報は、指定されたユーザーがそこにあることを保証するものではありませんが、ASが考慮に入れることができるクライアントソフトウェアによるステートメントを構成します。
For example, if a specific user is claimed to be present prior to interaction, but a different user is shown to be present during interaction, the AS can either determine this to be an error or signal to the client instance through returned subject information that the current user has changed from what the client instance thought. This user information can also be used by the AS to streamline the interaction process when the user is present. For example, instead of having the user type in their account identifier during interaction at a redirected URI, the AS can immediately challenge the user for their account credentials. Alternatively, if an existing session is detected, the AS can determine that it matches the identifier provided by the client and subsequently skip an explicit authentication event by the RO.
たとえば、特定のユーザーが相互作用の前に存在すると主張されているが、相互作用中に別のユーザーが存在することが示されている場合、ASは、これを返したサブジェクト情報を介してクライアントインスタンスへのエラーまたは信号であると判断することができます。現在のユーザーは、クライアントインスタンスが考えたものから変更されました。このユーザー情報は、ユーザーが存在するときにインタラクションプロセスを合理化するために、ASが使用することもできます。たとえば、リダイレクトされたURIでのインタラクション中にアカウント識別子にユーザーを入力する代わりに、ASはすぐにアカウントの資格情報に対してユーザーに挑戦することができます。あるいは、既存のセッションが検出された場合、ASは、クライアントが提供する識別子と一致し、その後ROによる明示的な認証イベントをスキップすることを決定できます。
In cases where the AS trusts the client software more completely, due to policy or previous approval of a given client instance, the AS can take this user information as a statement that the user is present and could issue access tokens and release subject information without interaction. The AS should only take such action in very limited circumstances, as a client instance could assert whatever it likes for the user's identifiers in its request. The AS can limit the possibility of this by issuing randomized opaque identifiers to client instances to represent different end-user accounts after an initial login.
ASが特定のクライアントインスタンスのポリシーまたは以前の承認により、クライアントソフトウェアをより完全に信頼する場合、ASはこのユーザー情報をユーザーが存在し、アクセストークンを発行し、インタラクションなしでサブジェクト情報をリリースすることができるというステートメントとして取得できます。。クライアントのインスタンスは、そのリクエストでユーザーの識別子に好きなものを主張できるため、非常に限られた状況でのみそのような措置を講じるべきです。ASは、最初のログイン後に異なるエンドユーザーアカウントを表すために、クライアントインスタンスにランダム化不透明な識別子を発行することにより、この可能性を制限できます。
When a client instance presents an assertion to the AS, the AS needs to evaluate that assertion. Since the AS is unlikely to be the intended audience of an assertion held by the client software, the AS will need to evaluate the assertion in a different context. Even in this case, the AS can still evaluate that the assertion was generated by a trusted party, was appropriately signed, and is within any time validity windows stated by the assertion. If the client instance's audience identifier is known to the AS and can be associated with the client instance's presented key, the AS can also evaluate that the appropriate client instance is presenting the claimed assertion. All of this will prevent an attacker from presenting a manufactured assertion or one captured from an untrusted system. However, without validating the audience of the assertion, a captured assertion could be presented by the client instance to impersonate a given end user. In such cases, the assertion offers little more protection than a simple identifier would.
クライアントインスタンスがASにアサーションを提示する場合、ASはそのアサーションを評価する必要があります。ASは、クライアントソフトウェアが保有する主張の対象となる視聴者である可能性が低いため、ASは別のコンテキストでアサーションを評価する必要があります。この場合でさえ、ASは、信頼できる当事者によってアサーションが生成され、適切に署名されたことをまだ評価できます。クライアントインスタンスのオーディエンス識別子がASに知られており、クライアントインスタンスの提示キーに関連付けられる可能性がある場合、ASは、適切なクライアントインスタンスが請求されたアサーションを提示していることを評価できます。これはすべて、攻撃者が製造されたアサーションまたは信頼できないシステムから捕獲されたものを提示することを妨げます。ただし、アサーションの視聴者を検証せずに、特定のエンドユーザーになりすまして、クライアントインスタンスによってキャプチャされたアサーションを提示することができます。そのような場合、このアサーションは、単純な識別子よりもほとんど保護を提供しません。
A special case exists where the AS is the generator of the assertion being presented by the client instance. In these cases, the AS can validate that it did issue the assertion and it is associated with the client instance presenting the assertion.
ASがクライアントインスタンスによって提示されているアサーションのジェネレーターである場合、特別なケースが存在します。これらの場合、ASは、それがアサーションを発行したことを検証することができ、それはアサーションを提示するクライアントインスタンスに関連付けられています。
Each client instance is identified by its own unique key, and for some kinds of client software such as a web server or backend system, this identification can be facilitated by registering a single key for a piece of client software ahead of time. This registration can be associated with a set of display attributes to be used during the authorization process to identify the client software to the user. In these cases, it can be assumed that only one instance of client software will exist, likely to serve many different users.
各クライアントインスタンスは、独自のキーによって識別され、Webサーバーやバックエンドシステムなどのある種のクライアントソフトウェアの場合、この識別は、クライアントソフトウェアの単一のキーを事前に登録することで促進できます。この登録は、クライアントソフトウェアをユーザーに識別するために、許可プロセス中に使用する一連の表示属性に関連付けられます。これらの場合、多くの異なるユーザーにサービスを提供する可能性が高いクライアントソフトウェアの1つのインスタンスのみが存在すると想定できます。
A client's registration record needs to include its identifying key. Furthermore, it is the case that any clients using symmetric cryptography for key proofing mechanisms need to have their keys pre-registered. The registration should also include any information that would aid in the authorization process, such as a display name and logo. The registration record can also limit a given client to ask for certain kinds of information or use specific interaction mechanisms at runtime.
クライアントの登録記録には、識別キーを含める必要があります。さらに、キープルーフメカニズムに対称的な暗号化を使用しているクライアントは、キーを事前に登録する必要がある場合があります。登録には、表示名やロゴなどの承認プロセスを支援する情報も含める必要があります。また、登録記録は、特定のクライアントが特定の種類の情報を要求したり、実行時に特定の相互作用メカニズムを使用したりすることもできます。
It also is sensible to pre-register client instances when the software is acting autonomously, without the need for a runtime approval by an RO or any interaction with an end user. In these cases, an AS needs to rely on the trust decisions that have been determined prior to runtime to determine what rights and tokens to grant to a given client instance.
また、ROによるランタイム承認やエンドユーザーとのやり取りを必要とせずに、ソフトウェアが自律的に行動しているときに、クライアントインスタンスを事前登録することも賢明です。これらの場合、ASは、特定のクライアントインスタンスに付与する権利とトークンを決定するために、ランタイムの前に決定された信頼の決定に依存する必要があります。
However, it does not make sense to pre-register many types of clients. Single-page applications (SPAs) and mobile/desktop applications in particular present problems with pre-registration. For SPAs, the instances are ephemeral in nature, and long-term registration of a single instance leads to significant storage and management overhead at the AS. For mobile applications, each installation of the client software is a separate instance, and sharing a key among all instances would be detrimental to security as the compromise of any single installation would compromise all copies for all users.
ただし、多くのタイプのクライアントを事前登録することは意味がありません。特に登録前の問題を提示するシングルページアプリケーション（SPA）およびモバイル/デスクトップアプリケーション。SPAの場合、インスタンスは本質的には短いものであり、単一のインスタンスの長期登録は、ASで重要なストレージと管理のオーバーヘッドにつながります。モバイルアプリケーションの場合、クライアントソフトウェアの各インストールは個別のインスタンスであり、すべてのインストールの妥協がすべてのユーザーのすべてのコピーを損なうため、すべてのインスタンスの間でキーを共有することはセキュリティに有害です。
An AS can treat these classes of client software differently from each other, perhaps by allowing access to certain high-value APIs only to pre-registered known clients or by requiring an active end-user delegation of authority to any client software not pre-registered.
これらのクラスのクライアントソフトウェアを互いに異なる方法で扱うことができます。おそらく、特定の高価値APIへのアクセスが事前に登録されているクライアントにのみアクセスできるか、事前に登録されていないクライアントソフトウェアへのアクティブなエンドユーザー委任を要求することにより。
An AS can also provide warnings and caveats to ROs during the authorization process, allowing the user to make an informed decision regarding the software they are authorizing. For example, if the AS has vetted the client software and this specific instance, it can present a different authorization screen compared to a client instance that is presenting all of its information at runtime.
AS ASは、認可プロセス中にROSに警告と警告を提供し、ユーザーが許可しているソフトウェアに関して情報に基づいた決定を下すことができます。たとえば、ASがクライアントソフトウェアとこの特定のインスタンスを審査した場合、実行時にすべての情報を提示しているクライアントインスタンスと比較して、異なる承認画面を提示できます。
Finally, an AS can use platform attestations and other signals from the client instance at runtime to determine whether or not the software making the request is legitimate. The details of such attestations are outside the scope of this specification, but the client portion of a grant request provides a natural extension point to such information through the "GNAP Client Instance Fields" registry (Section 10.7).
最後に、ASは、実行時にクライアントインスタンスからプラットフォームの証明やその他の信号を使用して、リクエストを作成するソフトウェアが合法かどうかを判断できます。このような証明の詳細は、この仕様の範囲外ですが、助成金要求のクライアント部分は、「GNAPクライアントインスタンスフィールド」レジストリ（セクション10.7）を介してそのような情報に自然な拡張ポイントを提供します。
If client instances are allowed to set their own user-facing display information, such as a display name and website URL, a malicious client instance could impersonate legitimate client software for the purposes of tricking users into authorizing the malicious client.
クライアントインスタンスが表示名やWebサイトURLなどの独自のユーザー向けディスプレイ情報を設定できる場合、悪意のあるクライアントインスタンスは、ユーザーに悪意のあるクライアントを承認する目的で合法的なクライアントソフトウェアになりすまします。
Requiring clients to pre-register does not fully mitigate this problem since many pre-registration systems have self-service portals for management of client registration, allowing authenticated developers to enter self-asserted information into the management portal.
多くの事前登録システムにはクライアント登録の管理のためのセルフサービスポータルがあるため、クライアントに事前登録を要求しても、この問題は完全に緩和されません。
An AS can mitigate this by actively filtering all self-asserted values presented by client software, both dynamically as part of GNAP and through a registration portal, to limit the kinds of impersonation that could be done.
ASは、GNAPの一部としても登録ポータルを介しても、クライアントソフトウェアによって提示されたすべての自己容認値を積極的にフィルタリングして、実行可能ななりすましの種類を制限することにより、これを軽減できます。
An AS can also warn the RO about the provenance of the information it is displaying, allowing the RO to make a more informed delegation decision. For example, an AS can visually differentiate between a client instance that can be traced back to a specific developer's registration and an instance that has self-asserted its own display information.
ASは、ROに表示されている情報の出所について警告することもでき、ROはより情報に基づいた代表団の決定を下すことができます。たとえば、ASは、特定の開発者の登録にまでさかのぼることができるクライアントインスタンスと、独自のディスプレイ情報を自己アサートしたインスタンスを視覚的に区別できます。
The logo_uri client display field defined in Section 2.3.2 allows the client instance to specify a URI from which an image can be fetched for display during authorization decisions. When the URI points to an externally hosted resource (as opposed to a data: URI), the logo_uri field presents challenges in addition to the considerations in Section 11.15.
セクション2.3.2で定義されているlogo_uriクライアントディスプレイフィールドを使用すると、クライアントインスタンスは、許可決定中に表示のために画像を取得できるURIを指定できます。URIが外部ホストされたリソースを指している場合（データとは対照的に）、logo_uriフィールドはセクション11.15の考慮事項に加えて課題を提示します。
When a logo_uri is externally hosted, the client software (or the host of the asset) can change the contents of the logo without informing the AS. Since the logo is considered an aspect of the client software's identity, this flexibility allows for a more dynamically managed client instance that makes use of the distributed systems.
logo_uriが外部からホストされている場合、クライアントソフトウェア（またはアセットのホスト）は、ASを通知せずにロゴの内容を変更できます。ロゴはクライアントソフトウェアのアイデンティティの側面と見なされるため、この柔軟性により、分散システムを利用するより動的に管理されたクライアントインスタンスが可能になります。
However, this same flexibility allows the host of the asset to change the hosted file in a malicious way, such as replacing the image content with malicious software for download or imitating a different piece of client software. Additionally, the act of fetching the URI could accidentally leak information to the image host in the HTTP Referer header field, if one is sent. Even though GNAP intentionally does not include security parameters in front-channel URIs wherever possible, the AS still should take steps to ensure that this information does not leak accidentally, such as setting a referrer policy on image links or displaying images only from pages served from a URI with no sensitive security or identity information.
ただし、この同じ柔軟性により、アセットのホストは、画像コンテンツを悪意のあるソフトウェアに置き換えて、異なるクライアントソフトウェアを模倣するために悪意のあるソフトウェアに置き換えるなど、悪意のある方法で悪意のある方法で変更できます。さらに、URIを取得する行為は、送信された場合、HTTP参照ヘッダーフィールドの画像ホストに誤って情報を漏らす可能性があります。GNAPには、可能な限りフロントチャネルURIのセキュリティパラメーターは意図的には含まれていませんが、画像リンクにリファラーポリシーを設定したり、からの画像を表示したりするなど、この情報が誤って漏れないようにするための手順を実行する必要があります。デリケートなセキュリティまたはID情報のないURI。
To avoid these issues, the AS can insist on the use of data: URIs, though that might not be practical for all types of client software. Alternatively, the AS could pre-fetch the content of the URI and present its own copy to the RO instead. This practice opens the AS to potential SSRF attacks, as discussed in Section 11.34.
これらの問題を回避するために、ASはデータの使用を主張することができます。あるいは、URIのコンテンツを事前に解放し、代わりに独自のコピーをROに提示することができます。このプラクティスは、セクション11.34で説明したように、潜在的なSSRF攻撃について開きます。
Most information passed through the web browser is susceptible to interception and possible manipulation by elements within the browser such as scripts loaded within pages. Information in the URI is exposed through browser and server logs, and it can also leak to other parties through HTTP Referer headers.
Webブラウザを介して渡されたほとんどの情報は、ページ内にロードされたスクリプトなど、ブラウザ内の要素による傍受および操作の可能性があります。URIの情報はブラウザとサーバーログを介して公開され、HTTP参照ヘッダーを介して他の関係者に漏れることもあります。
GNAP's design limits the information passed directly through the browser, allowing for opaque URIs in most circumstances. For the redirect-based interaction finish mechanism, named query parameters are used to carry unguessable opaque values. For these, GNAP requires creation and validation of a cryptographic hash to protect the query parameters added to the URI and associate them with an ongoing grant process and values not passed in the URI. The client instance has to properly validate this hash to prevent an attacker from injecting an interaction reference intended for a different AS or client instance.
GNAPの設計により、情報がブラウザを介して直接渡され、ほとんどの状況で不透明なURIが可能になります。リダイレクトベースのインタラクション仕上げメカニズムの場合、名前付きクエリパラメーターは、不適格な不透明値を運ぶために使用されます。これらのために、GNAPは、URIに追加されたクエリパラメーターを保護し、URIで渡されない継続的な助成金プロセスとそれらを関連付けるために、暗号化ハッシュの作成と検証が必要です。クライアントインスタンスは、このハッシュを適切に検証して、攻撃者が別のASまたはクライアントインスタンスを対象としたインタラクションリファレンスを注入できないようにする必要があります。
Several interaction start mechanisms use URIs created by the AS and passed to the client instance. While these URIs are opaque to the client instance, it's possible for the AS to include parameters, paths, and other pieces of information that could leak security data or be manipulated by a party in the middle of the transaction. An AS implementation can avoid this problem by creating URIs using unguessable values that are randomized for each new grant request.
いくつかの相互作用開始メカニズムは、ASによって作成されたURIを使用し、クライアントインスタンスに渡されます。これらのURIはクライアントインスタンスに不透明ですが、セキュリティデータを漏らしたり、取引の途中でパーティーによって操作される可能性のあるパラメーター、パス、およびその他の情報を含めることができます。AS ASの実装は、新しい助成金要求ごとにランダム化された非適切な値を使用してURIを作成することにより、この問題を回避できます。
The callback URI used in interaction finish mechanisms is defined by the client instance. This URI is opaque to the AS but can contain information relevant to the client instance's operations. In particular, the client instance can include state information to allow the callback request to be associated with an ongoing grant request.
インタラクション仕上げメカニズムで使用されるコールバックURIは、クライアントインスタンスによって定義されます。このURIはASに不透明ですが、クライアントインスタンスの操作に関連する情報を含めることができます。特に、クライアントインスタンスには、継続的な助成金リクエストにコールバックリクエストを関連付けることができる状態情報を含めることができます。
Since this URI is exposed to the end user's browser, it is susceptible to both logging and manipulation in transit before the request is made to the client software. As such, a client instance should never put security-critical or private information into the callback URI in a cleartext form. For example, if the client software includes a post-redirect target URI in its callback URI to the AS, this target URI could be manipulated by an attacker, creating an open redirector at the client. Instead, a client instance can use an unguessable identifier in the URI that can then be used by the client software to look up the details of the pending request. Since this approach requires some form of statefulness by the client software during the redirection process, clients that are not capable of holding state through a redirect should not use redirect-based interaction mechanisms.
このURIはエンドユーザーのブラウザにさらされているため、クライアントソフトウェアにリクエストが行われる前に、輸送中のロギングと操作の両方に敏感です。そのため、クライアントインスタンスは、セキュリティクリティカルまたは個人情報をクリアテキストフォームにコールバックURIに入れることは決してありません。たとえば、クライアントソフトウェアにASへのコールバックURIにリディレクトターゲットURIが含まれている場合、このターゲットURIは攻撃者によって操作され、クライアントにオープンリダイレクターを作成できます。代わりに、クライアントインスタンスはURIで非整備不可能な識別子を使用して、クライアントソフトウェアが使用して保留中のリクエストの詳細を調べることができます。このアプローチには、リダイレクトプロセス中にクライアントソフトウェアによる何らかの形の状態性が必要なため、リダイレクトを介して状態を保持できないクライアントは、リダイレクトベースの相互作用メカニズムを使用してはなりません。
As described in [OAUTH-SEC-TOPICS], a server should never use HTTP status code 307 (Temporary Redirect) to redirect a request that potentially contains user credentials. If an HTTP redirect is used for such a request, HTTP status code 303 (See Other) should be used instead.
[oauth-sec-topics]で説明されているように、サーバーはHTTPステータスコード307（一時リダイレクト）を使用して、ユーザーの資格情報を潜在的に含む要求をリダイレクトしないでください。このようなリクエストにHTTPリダイレクトが使用される場合、代わりにHTTPステータスコード（他を参照）を使用する必要があります。
Status code 307 (Temporary Redirect), as defined in the HTTP standard [HTTP], requires the user agent to preserve the method and content of a request, thus submitting the content of the POST request to the redirect target. In the HTTP standard [HTTP], only status code 303 (See Other) unambiguously enforces rewriting the HTTP POST request to an HTTP GET request, which eliminates the POST content from the redirected request. For all other status codes, including status code 302 (Found), user agents are allowed to keep a redirected POST request as a POST and thus can resubmit the content.
HTTP標準[HTTP]で定義されているステータスコード307（一時リダイレクト）では、ユーザーエージェントにリクエストのメソッドとコンテンツを保持する必要があります。HTTP標準[HTTP]では、ステータスコード303のみ（他を参照）は、HTTP POSTリクエストをHTTP GETリクエストに書き換えることを明確に強制します。ステータスコード302（見つかった）を含む他のすべてのステータスコードについて、ユーザーエージェントはリダイレクトされたPOSTリクエストを投稿として保持することができ、したがってコンテンツを再提出できます。
The use of status code 307 (Temporary Redirect) results in a vulnerability when using the redirect interaction finish method (Section 3.3.5). With this method, the AS potentially prompts the RO to enter their credentials in a form that is then submitted back to the AS (using an HTTP POST request). The AS checks the credentials and, if successful, may immediately redirect the RO to the client instance's redirect URI. Due to the use of status code 307 (Temporary Redirect), the RO's user agent now transmits the RO's credentials to the client instance. A malicious client instance can then use the obtained credentials to impersonate the RO at the AS.
ステータスコード307（一時リダイレクト）を使用すると、リダイレクトインタラクション仕上げ方式（セクション3.3.5）を使用すると、脆弱性が生じます。この方法を使用すると、ASはROがフォームで資格情報を入力するように潜在的に促します。ASは資格情報をチェックし、成功した場合、ROをクライアントインスタンスのリダイレクトURIにすぐにリダイレクトする場合があります。ステータスコード307（一時リダイレクト）の使用により、ROのユーザーエージェントはROの資格情報をクライアントインスタンスに送信するようになりました。悪意のあるクライアントインスタンスは、取得した資格情報を使用して、ASでROになりすまします。
Redirection away from the initial URI in an interaction session could also leak information found in that initial URI through the HTTP Referer header field, which would be sent by the user agent to the redirect target. To avoid such leakage, a server can first redirect to an internal interstitial page without any identifying or sensitive information on the URI before processing the request. When the user agent is ultimately redirected from this page, no part of the original interaction URI will be found in the Referer header.
インタラクションセッションでの最初のURIから離れたリダイレクトは、ユーザーエージェントがリダイレクトターゲットに送信するHTTP参照ヘッダーフィールドを介してその最初のURIにある情報をリークする可能性もあります。このような漏れを回避するために、サーバーは、リクエストを処理する前に、URIに関する識別または機密情報なしで、最初に内部間質ページにリダイレクトできます。ユーザーエージェントが最終的にこのページからリダイレクトされると、元のインタラクションURIの一部は参照ヘッダーにありません。
Responses from the AS contain information vital to both the security and privacy operations of GNAP. This information includes nonces used in cryptographic calculations, Subject Identifiers, assertions, public keys, and information about what client software is requesting and was granted.
ASからの応答には、GNAPのセキュリティおよびプライバシー運用の両方に不可欠な情報が含まれています。この情報には、暗号化の計算、主題識別子、アサーション、パブリックキー、およびクライアントソフトウェアが要求して付与されたものに関する情報で使用される非速度が含まれます。
In addition, if bearer tokens are used or keys are issued alongside a bound access token, the response from the AS contains all information necessary for use of the contained access token. Any party that is capable of viewing such a response, such as an intermediary proxy, would be able to exfiltrate and use this token. If the access token is instead bound to the client instance's presented key, intermediaries no longer have sufficient information to use the token. They can still, however, gain information about the end user as well as the actions of the client software.
さらに、ベアラートークンが使用されている場合、またはキーがバインドされたアクセストークンと一緒に発行された場合、ASからの応答には、含まれているアクセストークンの使用に必要なすべての情報が含まれています。仲介者のプロキシなど、このような応答を見ることができる当事者は、このトークンを除去して使用することができます。アクセストークンが代わりにクライアントインスタンスの提示キーにバインドされている場合、仲介者はトークンを使用するのに十分な情報を持っていません。ただし、クライアントソフトウェアのアクションだけでなく、エンドユーザーに関する情報を取得することもできます。
GNAP does not define ways for the client instances keys to be provided to the client instances, particularly in light of how those keys are made known to the AS. These keys could be generated dynamically on the client software or pre-registered at the AS in a static developer portal. The keys for client instances could also be distributed as part of the deployment process of instances of the client software. For example, an application installation framework could generate a key pair for each copy of client software and then both install it into the client software upon installation and register that instance with the AS.
GNAPは、クライアントインスタンスキーがクライアントインスタンスに提供されるキーの方法を定義しません。特に、それらのキーがASにどのように知られているかを考慮して。これらのキーは、クライアントソフトウェアで動的に生成したり、静的な開発者ポータルでASで事前登録されたりすることができます。クライアントインスタンスのキーは、クライアントソフトウェアのインスタンスの展開プロセスの一部として分散することもできます。たとえば、アプリケーションインストールフレームワークは、クライアントソフトウェアのコピーごとにキーペアを生成し、インストール時にクライアントソフトウェアにインストールし、そのインスタンスをASに登録することができます。
Alternatively, it's possible for the AS to generate keys to be used with access tokens that are separate from the keys used by the client instance to request tokens. In this method, the AS would generate the asymmetric key pair or symmetric key and return the public key or key reference to the client instance alongside the access token itself. The means for the AS to return generated key values to the client instance are out of scope, since GNAP does not allow the transmission of private or shared key information within the protocol itself.
または、クライアントインスタンスがトークンを要求するために使用するキーとは別のアクセストークンで使用されるキーを生成することができます。この方法では、ASが非対称キーペアまたは対称キーを生成し、アクセストークン自体とともにクライアントインスタンスへの公開キーまたはキー参照を返します。GNAPはプロトコル自体内でプライベートまたは共有キー情報の送信を許可しないため、生成されたキー値をクライアントインスタンスに返す手段は範囲外です。
Additionally, if the token is bound to a key other than the client instance's presented key, this opens a possible attack surface for an attacker's AS to request an access token and then substitute their own key material in the response to the client instance. The attacker's AS would need to be able to use the same key as the client instance, but this setup would allow an attacker's AS to make use of a compromised key within a system. This attack can be prevented by only binding access tokens to the client instance's presented keys and by having client instances have a strong association between which keys they expect to use and the AS they expect to use them on. This attack is also only able to be propagated on client instances that talk to more than one AS at runtime, which can be limited by the client software.
さらに、トークンがクライアントインスタンスの提示キー以外のキーにバインドされている場合、これにより、アクセストークンを要求し、クライアントインスタンスへの応答で独自のキー資料を置き換えるために、攻撃者の可能性のある攻撃面が開きます。攻撃者は、クライアントインスタンスと同じキーを使用できる必要がありますが、このセットアップにより、システム内の侵害されたキーを使用するように攻撃者が可能になります。この攻撃は、クライアントインスタンスの提示されたキーにアクセストークンのみをバインドするだけで、クライアントインスタンスが使用することを期待するキーとそれらを使用することを期待するように強力な関連性を持たせることにより、防止できます。この攻撃は、クライアントソフトウェアによって制限される可能性のある実行時に複数の通話をするクライアントインスタンスでのみ伝播することができます。
When keys are rotated, there could be a delay in the propagation of that rotation to various components in the AS's ecosystem. The AS can define its own policy regarding the timeout of the previously bound key, either making it immediately obsolete or allowing for a limited grace period during which both the previously bound key and the current key can be used for signing requests. Such a grace period can be useful when there are multiple running copies of the client that are coordinated with each other. For example, the client software could be deployed as a cloud service with multiple orchestrated nodes. Each of these copies is deployed using the same key; therefore, all the nodes represent the same client instance to the AS. In such cases, it can be difficult, or even impossible, to update the keys on all these copies in the same instant.
キーが回転すると、ASのエコシステム内のさまざまなコンポーネントへのその回転の伝播が遅れている可能性があります。ASは、以前にバインドされたキーのタイムアウトに関する独自のポリシーを定義することができます。これにより、すぐに廃止されるか、以前にバインドされたキーと現在のキーの両方をリクエストに署名するために使用できる限られた猶予期間を可能にします。このような猶予期間は、互いに調整されたクライアントの複数の実行コピーがある場合に役立ちます。たとえば、クライアントソフトウェアは、複数のオーケストレーションノードを備えたクラウドサービスとして展開できます。これらの各コピーは、同じキーを使用して展開されます。したがって、すべてのノードは、ASと同じクライアントインスタンスを表します。そのような場合、これらすべてのコピーのキーを同じ瞬間に更新することは難しい、または不可能です。
The need to accommodate such known delays in the system needs to be balanced with the risk of allowing an old key to still be used. Narrowly restricting the exposure opportunities for exploit at the AS in terms of time, place, and method makes exploit significantly more difficult, especially if the exception happens only once. For example, the AS can reject requests from the previously bound key (or any previous one before it) to cause rotation to a new key or at least ensure that the rotation happens in an idempotent way to the same new key.
システムのこのような既知の遅延に対応する必要性は、古いキーを使用するリスクとバランスをとる必要があります。特に例外が1回だけ行われた場合、時間、場所、および方法のように、エクスプロイトの露出の機会を狭く制限することで、エクスプロイトは非常に困難になります。たとえば、ASは、以前にバインドされたキー（またはその前の以前のもの）からのリクエストを拒否して、新しいキーへの回転を引き起こすか、少なくとも回転が同じ新しいキーまでの等式で発生することを確認します。
See also the related considerations for token values in Section 11.33.
セクション11.33のトークン値に関する関連する考慮事項も参照してください。
During the interaction process, the client instance usually hands control of the user experience over to another component, be it the system browser, another application, or some action the RO is instructed to take on another device. By using an interaction finish method, the client instance can be securely notified by the AS when the interaction is completed and the next phase of the protocol should occur. This process includes information that the client instance can use to validate the finish call from the AS and prevent some injection, session hijacking, and phishing attacks.
インタラクションプロセス中、クライアントインスタンスは通常、システムブラウザー、別のアプリケーション、またはROが別のデバイスを使用するように指示されている別のアプリケーションなど、別のコンポーネントへのユーザーエクスペリエンスの制御を手渡します。インタラクション仕上げ方式を使用することにより、クライアントインスタンスは、インタラクションが完了し、プロトコルの次のフェーズが発生するときに、AS ASによって安全に通知できます。このプロセスには、クライアントインスタンスがASからの終了コールを検証するために使用できる情報が含まれ、注入、セッションのハイジャック、フィッシング攻撃を防ぎます。
Some types of client deployment are unable to receive an interaction finish message. Without an interaction finish method to notify it, the client instance will need to poll the grant continuation API while waiting for the RO to approve or deny the request. An attacker could take advantage of this situation by capturing the interaction start parameters and phishing a legitimate user into authorizing the attacker's waiting client instance, which would in turn have no way of associating the completed interaction from the targeted user with the start of the request from the attacker.
一部のタイプのクライアント展開では、インタラクション仕上げメッセージを受信できません。通知するインタラクション仕上げ方法がなければ、クライアントインスタンスは、ROがリクエストを承認または拒否するのを待っている間に、助成金の継続APIを投票する必要があります。攻撃者は、インタラクション開始パラメーターをキャプチャし、正当なユーザーをフィッシングして攻撃者の待機クライアントインスタンスを承認することにより、この状況を活用できます。攻撃者。
However, it is important to note that this pattern is practically indistinguishable from some legitimate use cases. For example, a smart device emits a code for the RO to enter on a separate device. The smart device has to poll because the expected behavior is that the interaction will take place on the separate device, without a way to return information to the original device's context.
ただし、このパターンは、いくつかの正当なユースケースと実質的に区別できないことに注意することが重要です。たとえば、スマートデバイスは、ROが別のデバイスに入力するコードを発します。予想される動作は、元のデバイスのコンテキストに情報を返す方法なしに、予想される動作が別々のデバイスで相互作用が行われることであるため、スマートデバイスが投票する必要があります。
As such, developers need to weigh the risks of forgoing an interaction finish method against the deployment capabilities of the client software and its environment. Due to the increased security, an interaction finish method should be employed whenever possible.
そのため、開発者は、クライアントソフトウェアとその環境の展開機能に対してインタラクション仕上げ方式を放棄するリスクを比較検討する必要があります。セキュリティの増加により、可能な限りインタラクション仕上げ方法を使用する必要があります。
When using an interaction finish method such as redirect or push, the client instance receives an unsolicited inbound request from an unknown party over HTTPS. The client instance needs to be able to successfully associate this incoming request with a specific pending grant request being managed by the client instance. If the client instance is not careful and precise about this, an attacker could associate their own session at the client instance with a stolen interaction response. The means of preventing this vary by the type of client software and interaction methods in use. Some common patterns are enumerated here.
リダイレクトやプッシュなどのインタラクション仕上げメソッドを使用する場合、クライアントインスタンスは、HTTPSを介した未知の当事者から未承諾のインバウンドリクエストを受信します。クライアントインスタンスは、この着信要求をクライアントインスタンスによって管理されている特定の保留中の助成金リクエストに成功裏に関連付けることができる必要があります。クライアントインスタンスがこれについて慎重かつ正確でない場合、攻撃者はクライアントインスタンスでのセッションを盗まれた相互作用応答に関連付けることができます。これを防ぐ手段は、使用中のクライアントソフトウェアとインタラクション方法のタイプによって異なります。ここにはいくつかの一般的なパターンが列挙されています。
If the end user interacts with the client instance through a web browser and the redirect interaction finish method is used, the client instance can ensure that the incoming HTTP request from the finish method is presented in the same browser session that the grant request was started in. This technique is particularly useful when the redirect interaction start mode is used as well, since in many cases, the end user will follow the redirection with the same browser that they are using to interact with the client instance. The client instance can then store the relevant pending grant information in the session, either in the browser storage directly (such as with a single-page application) or in an associated session store on a backend server. In both cases, when the incoming request reaches the client instance, the session information can be used to ensure that the same party that started the request is present as the request finishes.
エンドユーザーがWebブラウザーを介してクライアントインスタンスと対話し、リダイレクトインタラクション仕上げメソッドを使用すると、クライアントインスタンスは、完了メソッドからの着信HTTP要求が、グラントリクエストが開始されたのと同じブラウザセッションで表示されることを確認できます。多くの場合、エンドユーザーはクライアントインスタンスと対話するために使用している同じブラウザでリダイレクトに従うため、この手法は特に役立ちます。クライアントインスタンスは、ブラウザストレージ（シングルページアプリケーションなど）またはバックエンドサーバーの関連するセッションストアのいずれかで、関連する保留中の付与情報をセッションに保存できます。どちらの場合も、着信要求がクライアントインスタンスに到達すると、セッション情報を使用して、リクエストを開始した同じパーティがリクエストの終了時に存在することを確認できます。
Ensuring that the same party that started a request is present when that request finishes can prevent phishing attacks, where an attacker starts a request at an honest client instance and tricks an honest RO into authorizing it. For example, if an honest end user (that also acts as the RO) wants to start a request through a client instance controlled by the attacker, the attacker can start a request at an honest client instance and then redirect the honest end user to the interaction URI from the attackers session with the honest client instance. If the honest end user then fails to realize that they are not authorizing the attacker-controlled client instance (with which it started its request) but instead the honest client instance when interacting with the AS, the attacker's session with the honest client instance would be authorized. This would give the attacker access to the honest end user's resources that the honest client instance is authorized to access. However, if after the interaction, the AS redirects the honest end user back to the client instance whose grant request the end user just authorized, the honest end user is redirected to the honest client instance. The honest client instance can then detect that the end user is not the party that started the request, since the request at the honest client instance was started by the attacker. This detection can prevent the attack. This is related to the discussion in Section 11.15, because again the attack can be prevented by the AS informing the user as much as possible about the client instance that is to be authorized.
リクエストが終了するとフィッシング攻撃を防ぐことができたときにリクエストを開始したのと同じ当事者が存在するようにします。攻撃者は正直なクライアントインスタンスでリクエストを開始し、正直なROがそれを承認するようにします。たとえば、正直なエンドユーザー（ROとしても機能する）が、攻撃者が制御するクライアントインスタンスを介してリクエストを開始したい場合、攻撃者は正直なクライアントインスタンスでリクエストを開始し、正直なエンドユーザーをリダイレクトすることができます。攻撃者セッションからの相互作用URI正直なクライアントインスタンスとのセッション。正直なエンドユーザーが、攻撃者が制御するクライアントインスタンス（リクエストを開始した）を許可していないことを認識できない場合、代わりにASと対話するときに、正直なクライアントインスタンスとの攻撃者のセッションは許可。これにより、攻撃者は、正直なクライアントインスタンスがアクセスを許可されている正直なエンドユーザーのリソースにアクセスできます。ただし、インタラクションの後、ASが正直なエンドユーザーをクライアントインスタンスにリダイレクトした場合、その助成金要求がエンドユーザーを認定したばかりのクライアントインスタンスに戻します。正直なエンドユーザーは、正直なクライアントインスタンスにリダイレクトされます。正直なクライアントインスタンスは、正直なクライアントインスタンスでのリクエストが攻撃者によって開始されたため、エンドユーザーがリクエストを開始したパーティーではないことを検出できます。この検出は攻撃を防ぐことができます。これは、セクション11.15の議論に関連しています。これは、攻撃が許可されるクライアントインスタンスについて可能な限りユーザーに通知することによって防止できるためです。
If the end user does not interact with the client instance through a web browser or the interaction start method does not use the same browser or device that the end user is interacting through (such as the launch of a second device through a scannable code or presentation of a user code), the client instance will not be able to strongly associate an incoming HTTP request with an established session with the end user. This is also true when the push interaction finish method is used, since the HTTP request comes directly from the interaction component of the AS. In these circumstances, the client instance can at least ensure that the incoming HTTP request can be uniquely associated with an ongoing grant request by making the interaction finish callback URI unique for the grant when making the interaction request (Section 2.5.2). Mobile applications and other client instances that generally serve only a single end user at a time can use this unique incoming URL to differentiate between a legitimate incoming request and an attacker's stolen request.
エンドユーザーがWebブラウザーを介してクライアントインスタンスと対話しない場合、またはインタラクション開始方法は、エンドユーザーが対話している同じブラウザまたはデバイスを使用しません（スキャン可能なコードやプレゼンテーションを介して2番目のデバイスの起動などユーザーコードのうち、クライアントインスタンスは、着信HTTP要求をエンドユーザーとの確立されたセッションに強く関連付けることができません。HTTP要求はASの相互作用コンポーネントから直接来るため、プッシュインタラクション仕上げ方式を使用する場合にもこれが当てはまります。これらの状況では、クライアントインスタンスは、少なくとも、着信HTTP要求が、インタラクションリクエストを行う際に、インタラクションフィニッシュコールバックURIを助成金と一意にすることにより、継続的な助成金リクエストと一意に関連付けることができることを保証できます（セクション2.5.2）。通常、一度に単一のエンドユーザーのみを提供するモバイルアプリケーションやその他のクライアントインスタンスは、この一意の着信URLを使用して、正当な着信要求と攻撃者の盗まれたリクエストを区別できます。
While the use of GNAP's signing mechanisms and token-protected grant API provides significant security protections to the protocol, the interaction reference mechanism is susceptible to monitoring, capture, and injection by an attacker. To combat this, GNAP requires the calculation and verification of an interaction hash. A client instance might be tempted to skip this step, but doing so leaves the client instance open to injection and manipulation by an attacker that could lead to additional issues.
GNAPの署名メカニズムとトークンで保護されたGrant APIの使用は、プロトコルに大きなセキュリティ保護を提供しますが、相互作用参照メカニズムは攻撃者による監視、捕獲、および注入の影響を受けやすくなります。これと戦うために、GNAPは相互作用ハッシュの計算と検証を必要とします。クライアントインスタンスはこのステップをスキップしようとするかもしれませんが、そうすることで、追加の問題につながる可能性のある攻撃者による注射と操作にクライアントインスタンスが開かれます。
The calculation of the interaction hash value provides defense in depth, allowing a client instance to protect itself from spurious injection of interaction references when using an interaction finish method. The AS is protected during this attack through the continuation access token being bound to the expected interaction reference, but without hash calculation, the attacker could cause the client to make an HTTP request on command, which could itself be manipulated -- for example, by including a malicious value in the interaction reference designed to attack the AS. With both of these in place, an attacker attempting to substitute the interaction reference is stopped in several places.
相互作用ハッシュ値の計算は、ディフェンスを詳細に提供し、クライアントインスタンスが相互作用仕上げ方法を使用する場合の相互作用参照の偽の注入から自分自身を保護できるようにします。ASは、この攻撃中に継続アクセストークンが予想されるインタラクションリファレンスにバインドされていることを介して保護されていますが、ハッシュ計算がなければ、攻撃者はクライアントにコマンドでHTTPリクエストを作成する可能性があります。ASを攻撃するように設計されたインタラクションリファレンスに悪意のある値を含めます。これらの両方が配置されていると、攻撃者が相互作用の参照を置き換えようとします。いくつかの場所で停止します。
.----. .------. +--------+ +--------+
| User | |Attacker| | Client | | AS |
| | | | |Instance| | |
| | | | | | | |
| | | +=(1)=>| | | |
| | | | | +-(2)->| |
| | | | | |<-(3)-+ |
| | | |<=(4)=+ | | |
| | | | | | | |
| | | +==(5)================>| |
| | | | | | | |
| | | |<================(6)==+ |
| | | | | | | |
| +==(A)================>| | | |
| | | | | +-(B)->| |
| | | | | |<-(C)-+ |
| |<=================(D)=+ | | |
| | | | | | | |
| +==(E)================================>| |
| | | | | | | |
| |<=(7)=+ | | | | |
| | | | | | | |
| +==(F)================>| | | |
| | | | | +-(G)->| |
| | | | | | | |
`----` `------` +--------+ +--------+
Figure 11: Interaction Hash Attack
図11：相互作用ハッシュ攻撃
Prerequisites: The client instance can allow multiple end users to access the same AS. The attacker is attempting to associate their rights with the target user's session.
前提条件：クライアントインスタンスは、複数のエンドユーザーが同じようにアクセスできるようにすることができます。攻撃者は、権利をターゲットユーザーのセッションに関連付けようとしています。
* (1) The attacker starts a session at the client instance.
* （1）攻撃者は、クライアントインスタンスでセッションを開始します。
* (2) The client instance creates a grant request with nonce CN1.
* （2）クライアントインスタンスは、NonCE CN1を使用して助成金リクエストを作成します。
* (3) The AS responds to the grant request with a need to interact, nonce SN1, and a continuation token, CT1.
* （3）ASは、NonCE SN1と継続トークンCT1の相互作用の必要性を備えた助成金要求に応答します。
* (4) The client instructs the attacker to interact at the AS.
* （4）クライアントは、ASで対話するように攻撃者に指示します。
* (5) The attacker interacts at the AS.
* （5）攻撃者はASで対話します。
* (6) The AS completes the interact finish with interact reference IR1 and interact hash IH1 calculated from (CN1 + SN1 + IR1 + AS). The attacker prevents IR1 from returning to the client instance.
* （6）ASは、（CN1 + SN1 + IR1 + AS）から計算された相互作用リファレンスIR1と相互作用ハッシュIH1との相互作用仕上げを完了します。攻撃者は、IR1がクライアントインスタンスに戻ることを防ぎます。
* (A) The target user starts a session at the client instance.
* （a）ターゲットユーザーは、クライアントインスタンスでセッションを開始します。
* (B) The client instance creates a grant request with nonce CN2.
* （b）クライアントインスタンスは、NonCE CN2を使用して助成金リクエストを作成します。
* (C) The AS responds to the grant request with a need to interact, nonce SN2, and a continuation token, CT2.
* （c）ASは、相互作用の必要性であるNonCe SN2、および継続トークンCT2を伴う助成金要求に応答します。
* (D) The client instance instructs the user to interact at the AS.
* （d）クライアントインスタンスは、ASで対話するようにユーザーに指示します。
* (E) The target user interacts at the AS.
* （e）ターゲットユーザーはASで対話します。
* (7) Before the target user can complete their interaction, the attacker delivers their own interact reference IR1 into the user's session. The attacker cannot calculate the appropriate hash because the attacker does not have access to CN2 and SN2.
* （7）ターゲットユーザーがインタラクションを完了する前に、攻撃者は独自のインタラクションリファレンスIR1をユーザーのセッションに配信します。攻撃者はCN2およびSN2にアクセスできないため、適切なハッシュを計算できません。
* (F) The target user triggers the interaction finish in their own session with the attacker's IR1.
* （f）ターゲットユーザーは、攻撃者のIR1との独自のセッションでインタラクション仕上げをトリガーします。
* (G) If the client instance is checking the interaction hash, the attack stops here because the hash calculation of (CN2 + SN2 + IR1 + AS) will fail. If the client instance does not check the interaction hash, the client instance will be tricked into submitting the interaction reference to the AS. Here, the AS will reject the interaction request because it is presented against CT2 and not CT1 as expected. However, an attacker who has potentially injected CT1 as the value of CT2 would be able to continue the attack.
* （g）クライアントインスタンスが相互作用のハッシュをチェックしている場合、（CN2 + SN2 + IR1 + AS）のハッシュ計算が失敗するため、攻撃はここで停止します。クライアントインスタンスがインタラクションハッシュをチェックしない場合、クライアントインスタンスはtrickされ、ASへの相互作用の参照を提出します。ここで、ASは、CT1に対して提示され、CT1に対して予想どおりに提示されているため、ASは相互作用要求を拒否します。ただし、CT2の値としてCT1を潜在的に注入した攻撃者は、攻撃を続けることができます。
Even with additional checks in place, client instances using interaction finish mechanisms are responsible for checking the interaction hash to provide security to the overall system.
追加のチェックが整っていても、インタラクションフィニッシュメカニズムを使用したクライアントインスタンスは、システム全体にセキュリティを提供するためにインタラクションハッシュをチェックする責任があります。
When starting an interactive grant request, a client application has a number of protocol elements that it needs to manage, including nonces, references, keys, access tokens, and other elements. During the interaction process, the client instance usually hands control of the user experience over to another component, be it the system browser, another application, or some action the RO is instructed to take on another device. In order for the client instance to make its continuation call, it will need to recall all of these protocol elements at a future time. Usually, this means the client instance will need to store these protocol elements in some retrievable fashion.
インタラクティブな助成金リクエストを開始するとき、クライアントアプリケーションには、Nonces、参照、キー、アクセストークン、その他の要素など、管理する必要があるプロトコル要素が多数あります。インタラクションプロセス中、クライアントインスタンスは通常、システムブラウザー、別のアプリケーション、またはROが別のデバイスを使用するように指示されている別のアプリケーションなど、別のコンポーネントへのユーザーエクスペリエンスの制御を手渡します。クライアントインスタンスが継続的な呼び出しを行うには、将来のこれらすべてのプロトコル要素を思い出す必要があります。通常、これは、クライアントインスタンスがこれらのプロトコル要素をある程度取得可能な方法で保存する必要があることを意味します。
If the security protocol elements are stored on the end user's device, such as in browser storage or in local application data stores, capture and exfiltration of this information could allow an attacker to continue a pending transaction instead of the client instance. Client software can make use of secure storage mechanisms, including hardware-based key and data storage, to prevent such exfiltration.
セキュリティプロトコル要素が、ブラウザストレージやローカルアプリケーションデータストアなど、エンドユーザーのデバイスに保存されている場合、この情報のキャプチャと除去により、攻撃者はクライアントインスタンスの代わりに保留中のトランザクションを続けることができます。クライアントソフトウェアは、ハードウェアベースのキーやデータストレージなどの安全なストレージメカニズムを利用して、そのような除去を防ぐことができます。
Note that in GNAP, the client instance has to choose its interaction finish URI prior to making the first call to the AS. As such, the interaction finish URI will often have a unique identifier for the ongoing request, allowing the client instance to access the correct portion of its storage. Since this URI is passed to other parties and often used through a browser, this URI should not contain any security-sensitive information that would be valuable to an attacker, such as any token identifier, nonce, or user information. Instead, a cryptographically random value is suggested, and that value should be used to index into a secure session or storage mechanism.
GNAPでは、クライアントインスタンスは、ASに最初の呼び出しを行う前に、インタラクションを完了する必要があることに注意してください。そのため、インタラクション仕上げのURIには、継続的なリクエストのための一意の識別子があることが多く、クライアントインスタンスがストレージの正しい部分にアクセスできるようになります。このURIは他の関係者に渡され、ブラウザでよく使用されるため、このURIは、トークン識別子、NONCE、ユーザー情報など、攻撃者にとって価値のあるセキュリティに敏感な情報を含めるべきではありません。代わりに、暗号化的にランダムな値が提案されており、その値を使用して安全なセッションまたはストレージメカニズムにインデックスを作成する必要があります。
When a client instance starts off an interactive process, it will eventually need to continue the grant request in a subsequent message to the AS. It's possible for a naive client implementation to continuously send continuation requests to the AS while waiting for approval, especially if no interaction finish method is used. Such constant requests could overwhelm the AS's ability to respond to both these and other requests.
クライアントインスタンスがインタラクティブなプロセスから始まると、最終的にはASへの後続のメッセージで助成金リクエストを継続する必要があります。ナイーブなクライアントの実装では、特にインタラクション仕上げ方法が使用されていない場合、承認を待っている間に継続的に継続要求を継続的に送信することができます。このような一定の要求は、これらの要求と他の要求の両方に応答するASの能力を圧倒する可能性があります。
To mitigate this for well-behaved client software, the continuation response contains a wait parameter that is intended to tell the client instance how long it should wait until making its next request. This value can be used to back off client software that is checking too quickly by returning increasing wait times for a single client instance.
行儀の良いクライアントソフトウェアについてこれを軽減するために、継続応答には、クライアントインスタンスに次のリクエストを行うまで待機する時間を伝えることを目的とする待機パラメーターが含まれています。この値は、単一のクライアントインスタンスの待ち時間の増加を返すことにより、速すぎるクライアントソフトウェアをバックアウトするために使用できます。
If client software ignores the wait value and makes its continuation calls too quickly or if the client software assumes the absence of the wait values means it should poll immediately, the AS can choose to return errors to the offending client instance, including possibly canceling the ongoing grant request. With well-meaning client software, these errors can indicate a need to change the client software's programmed behavior.
クライアントソフトウェアが待機値を無視し、継続コールを迅速に行う場合、またはクライアントソフトウェアが待機値の欠如を想定している場合、すぐに投票する必要がある場合、継続中のキャンセルを含む、問題のあるクライアントインスタンスにエラーを返すことを選択できます。許可リクエスト。善意のクライアントソフトウェアを使用すると、これらのエラーは、クライアントソフトウェアのプログラムされた動作を変更する必要性を示しています。
Several parts of the GNAP process make use of unguessable randomized values, such as nonces, tokens, user codes, and randomized URIs. Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number generation space. While this attack is particularly applicable to the AS, client software could likewise be targeted by an attacker triggering new grant requests against an AS.
GNAPプロセスのいくつかの部分は、Nonces、Tokens、ユーザーコード、ランダム化されたURIなど、非緊急のランダム化値を使用しています。これらの値は一意であることを意図しているため、十分に強力な攻撃者は、乱数生成スペースを使い果たして、ランダム化値の生成をトリガーするように多数のリクエストを行うことができます。この攻撃はASに特に適用されますが、クライアントソフトウェアも同様に、ASに対する新しい助成金リクエストをトリガーする攻撃者によって標的にされる可能性があります。
To mitigate this, software can ensure that its random values are chosen from a significantly large pool so that exhaustion of that pool is prohibitive for an attacker. Additionally, the random values can be time-boxed in such a way that their validity windows are reasonably short. Since many of the random values used within GNAP are used within limited portions of the protocol, it is reasonable for a particular random value to be valid for only a small amount of time. For example, the nonces used for interaction finish hash calculation need only to be valid while the client instance is waiting for the finish callback and can be functionally expired when the interaction has completed. Similarly, artifacts like access tokens and the interaction reference can be limited to have lifetimes tied to their functional utility. Finally, each different category of artifact (nonce, token, reference, identifier, etc.) can be generated from a separate random pool of values instead of a single global value space.
これを緩和するために、ソフトウェアは、そのランダム値が大幅に大きなプールから選択されるようにし、そのプールの疲労が攻撃者にとって法外なものになるようにすることができます。さらに、ランダムな値は、有効性のウィンドウがかなり短くなるようにタイムボックス化できます。GNAP内で使用されるランダム値の多くは、プロトコルの限られた部分内で使用されるため、特定のランダム値がわずかな時間しか有効であることが合理的です。たとえば、インタラクションフィニッシュハッシュ計算に使用されるNoncesは、クライアントインスタンスがフィニッシュコールバックを待っている間に有効である必要があり、インタラクションが完了したときに機能的に期限切れになる可能性があります。同様に、アクセストークンや相互作用の参照などのアーティファクトは、寿命を機能させるために制限できます。最後に、それぞれの異なるカテゴリのアーティファクト（Nonce、Token、Reference、Identifierなど）は、単一のグローバル値空間ではなく、個別のランダムな値のプールから生成できます。
Some interaction methods in GNAP make use of URIs accessed through the end user's browser, known collectively as front-channel communication. These URIs are most notably present in the redirect interaction start method and the redirect interaction finish mode. Since these URIs are intended to be given to the end user, the end user and their browser will be subjected to anything hosted at that URI including viruses, malware, and phishing scams. This kind of risk is inherent to all redirection-based protocols, including GNAP, when used in this way.
GNAPのいくつかの相互作用方法は、エンドユーザーのブラウザを介してアクセスされるURIを使用して、フロントチャネル通信としてまとめて知られています。これらのURIは、特にリダイレクトインタラクション開始方法とリダイレクトインタラクション仕上げモードに存在します。これらのURIはエンドユーザーに与えられることを目的としているため、エンドユーザーとそのブラウザは、ウイルス、マルウェア、フィッシング詐欺など、そのURIでホストされているものにさらされます。この種のリスクは、この方法で使用する場合、GNAPを含むすべてのリダイレクトベースのプロトコルに固有のものです。
When talking to a new or unknown AS, a client instance might want to check the URI from the interaction start against a blocklist and warn the end user before redirecting them. Many client instances will provide an interstitial message prior to redirection in order to prepare the user for control of the user experience being handed to the domain of the AS, and such a method could be used to warn the user of potential threats (for instance, a rogue AS impersonating a well-known service provider). Client software can also prevent this by managing an allowlist of known and trusted ASes.
新しいまたは未知のASと話すとき、クライアントインスタンスは、ブロックリストに対してインタラクション開始からURIを確認し、リダイレクトする前にエンドユーザーに警告することをお勧めします。多くのクライアントインスタンスは、ASのドメインに渡されるユーザーエクスペリエンスの制御のためにユーザーを準備するためにリダイレクトの前に間質メッセージを提供します。そのような方法は、潜在的な脅威をユーザーに警告するために使用できます（たとえば、たとえば、有名なサービスプロバイダーになりすましている不正）。クライアントソフトウェアは、既知の信頼できるASEのAllowlistを管理することにより、これを防ぐこともできます。
Alternatively, an attacker could start a GNAP request with a known and trusted AS but include their own attack site URI as the callback for the redirect finish method. The attacker would then send the interaction start URI to the victim and get them to click on it. Since the URI is at the known AS, the victim is inclined to do so. The victim will then be prompted to approve the attacker's application, and in most circumstances, the victim will then be redirected to the attacker's site whether or not the user approved the request. The AS could mitigate this partially by using a blocklist and allowlist of interaction finish URIs during the client instance's initial request, but this approach can be especially difficult if the URI has any dynamic portion chosen by the client software. The AS can couple these checks with policies associated with the client instance that has been authenticated in the request. If the AS has any doubt about the interaction finish URI, the AS can provide an interstitial warning to the end user before processing the redirect.
あるいは、攻撃者は、既知と信頼できるものを使用してGNAPリクエストを開始できますが、リダイレクト仕上げ方式のコールバックとして独自の攻撃サイトURIを含めることができます。攻撃者は、インタラクションスタートURIを被害者に送信し、クリックしてもらいます。URIは知られているので、被害者はそうする傾向があります。その後、被害者は攻撃者の申請を承認するよう促され、ほとんどの場合、被害者はユーザーがリクエストを承認したかどうかにかかわらず攻撃者のサイトにリダイレクトされます。クライアントインスタンスの最初のリクエスト中に、インタラクションのブロックリストとAllowAlistのurisを使用することにより、これを部分的に軽減できますが、URIがクライアントソフトウェアによって選択された動的部分がある場合、このアプローチは特に困難になる可能性があります。これらのチェックは、リクエストで認証されているクライアントインスタンスに関連付けられたポリシーと関連付けられます。ASがインタラクションがURIを終了することについて疑問がある場合、ASはリダイレクトを処理する前にエンドユーザーに間質性警告を提供できます。
Ultimately, all protocols that use redirect-based communication through the user's browser are susceptible to having an attacker try to co-opt one or more of those URIs in order to harm the user. It is the responsibility of the AS and the client software to provide appropriate warnings, education, and mitigation to protect end users.
最終的に、ユーザーのブラウザを介してリダイレクトベースの通信を使用するすべてのプロトコルは、攻撃者にユーザーに害を及ぼすために1つ以上のURIを採用させようとする可能性があります。エンドユーザーを保護するための適切な警告、教育、および緩和を提供することは、ASおよびクライアントソフトウェアの責任です。
Identity assertions can be used in GNAP to convey subject information, both from the AS to the client instance in a response (Section 3.4) and from the client instance to the AS in a request (Section 2.2). In both of these circumstances, when an assertion is passed in GNAP, the receiver of the assertion needs to parse and process the assertion. As assertions are complex artifacts with their own syntax and security, special care needs to be taken to prevent the assertion values from being used as an attack vector.
IDのアサーションは、gnapで使用されて、応答（セクション3.4）のクライアントインスタンス（セクション3.4）およびクライアントインスタンスからASリクエスト（セクション2.2）の両方を伝えるために使用できます。これらの両方の状況では、GNAPでアサーションが渡されると、アサーションの受信者は、アサーションを解析して処理する必要があります。アサーションは独自の構文とセキュリティを備えた複雑なアーティファクトであるため、アサーション値が攻撃ベクトルとして使用されるのを防ぐために特別な注意が必要です。
All assertion processing needs to account for the security aspects of the assertion format in use. In particular, the processor needs to parse the assertion from a JSON string object and apply the appropriate cryptographic processes to ensure the integrity of the assertion.
すべてのアサーション処理は、使用中のアサーション形式のセキュリティ側面を説明する必要があります。特に、プロセッサは、JSON文字列オブジェクトからアサーションを解析し、適切な暗号プロセスを適用して、アサーションの完全性を確保する必要があります。
For example, when SAML 2.0 assertions are used, the receiver has to parse an XML document. There are many well-known security vulnerabilities in XML parsers, and the XML standard itself can be attacked through the use of processing instructions and entity expansions to cause problems with the processor. Therefore, any system capable of processing SAML 2.0 assertions also needs to have a secure and correct XML parser. In addition to this, the SAML 2.0 specification uses XML Signatures, which have their own implementation problems that need to be accounted for. Similar requirements exist for OpenID Connect ID Token, which is based on the JWT format and the related JOSE cryptography suite.
たとえば、SAML 2.0アサーションを使用する場合、受信者はXMLドキュメントを解析する必要があります。XMLパーサーには多くの有名なセキュリティの脆弱性があり、XML標準自体は、処理命令とエンティティの拡張を使用してプロセッサに問題を引き起こすことで攻撃することができます。したがって、SAML 2.0アサーションを処理できるシステムには、安全で正しいXMLパーサーが必要です。これに加えて、SAML 2.0仕様はXML署名を使用します。XML署名は、考慮する必要がある独自の実装の問題を抱えています。JWT形式と関連するJose Cryptography Suiteに基づいたOpenID Connect IDトークンには同様の要件が存在します。
If a client instance can request tokens at multiple ASes and the client instance uses the same keys to make its requests across those different ASes, then it is possible for an attacker to replay a stolen token issued by an honest AS from a compromised AS, thereby binding the stolen token to the client instance's key in a different context. The attacker can manipulate the client instance into using the stolen token at an RS, particularly at an RS that is expecting a token from the honest AS. Since the honest AS issued the token and the client instance presents the token with its expected bound key, the attack succeeds.
クライアントインスタンスが複数のASEでトークンを要求し、クライアントインスタンスが同じキーを使用してそれらの異なるASEでリクエストを行うことができる場合、攻撃者は妥協したように正直な盗まれたトークンを再生することができます。盗まれたトークンを、別のコンテキストでクライアントインスタンスのキーにバインドします。攻撃者は、クライアントインスタンスを操作して、特に正直なASからトークンを期待しているRSで、盗まれたトークンをRSで使用します。トークンとクライアントインスタンスが予想されるバウンドキーを備えたトークンを提示する正直さは、攻撃が成功するためです。
This attack has several preconditions. In this attack, the attacker does not need access to the client instance's key and cannot use the stolen token directly at the RS, but the attacker is able to get the access token value in some fashion. The client instance also needs to be configured to talk to multiple ASes, including the attacker's controlled AS. Finally, the client instance needs to be able to be manipulated by the attacker to call the RS while using a token issued from the stolen AS. The RS does not need to be compromised or made to trust the attacker's AS.
この攻撃にはいくつかの前提条件があります。この攻撃では、攻撃者はクライアントインスタンスのキーへのアクセスを必要とせず、RSで盗まれたトークンを直接使用することはできませんが、攻撃者は何らかの方法でアクセストークン値を取得することができます。また、クライアントインスタンスは、攻撃者の制御されたASを含む複数のASEと通信するように構成する必要があります。最後に、クライアントインスタンスは、盗まれたASから発行されたトークンを使用しながら、RSを呼び出すために攻撃者によって操作できる必要があります。RSは、攻撃者のASを信頼するために妥協したり、作成する必要はありません。
To protect against this attack, the client instance can use a different key for each AS that it talks to. Since the replayed token will be bound to the key used at the honest AS, the uncompromised RS will reject the call since the client instance will be using the key used at the attacker's AS instead with the same token. When the MTLS key proofing method is used, a client instance can use self-signed certificates to use a different key for each AS that it talks to, as discussed in Section 11.4.
この攻撃から保護するために、クライアントインスタンスは、それが話しているように、それぞれに異なるキーを使用できます。リプレイされたトークンは正直なASで使用されるキーにバインドされるため、クライアントインスタンスは代わりに同じトークンで攻撃者で使用されるキーを使用するため、妥協のないRSはコールを拒否します。MTLSキープルーフ方法を使用すると、クライアントインスタンスは、セクション11.4で説明したように、それぞれに異なるキーを使用するために、自己署名証明書を使用して使用できます。
Additionally, the client instance can keep a strong association between the RS and a specific AS that it trusts to issue tokens for that RS. This strong binding also helps against some forms of AS mix-up attacks (Section 11.12). Managing this binding is outside the scope of this specification, but it can be managed either as a configuration element for the client instance or dynamically through discovering the AS from the RS (Section 9.1).
さらに、クライアントインスタンスは、RSとそのRSのトークンを発行すると信頼するため、RSと特定の関係との間の強力な関連性を維持できます。この強力な結合は、何らかの形のASミックスアップ攻撃に対しても役立ちます（セクション11.12）。このバインディングの管理は、この仕様の範囲外ですが、クライアントインスタンスの構成要素として、またはRSからASを発見して動的に管理できます（セクション9.1）。
The details of this attack, with additional discussion and considerations, are available in Section 3.2 of [HELMSCHMIDT2022].
この攻撃の詳細は、追加の議論と考慮事項を含めて、[helmschmidt2022]のセクション3.2で入手できます。
The contents and format of the access token are at the discretion of the AS and are opaque to the client instance within GNAP. As discussed in [GNAP-RS], the AS and RS can make use of stateless access tokens with an internal structure and format. These access tokens allow an RS to validate the token without having to make any external calls at runtime, allowing for benefits in some deployments, the discussion of which is outside the scope of this specification.
アクセストークンの内容と形式は、ASの裁量であり、GNAP内のクライアントインスタンスに不透明です。[GNAP-RS]で説明したように、ASとRSは、内部構造と形式を備えたステートレスアクセストークンを利用できます。これらのアクセストークンにより、RSは実行時に外部呼び出しを行うことなくトークンを検証することができ、一部の展開でメリットが可能になります。その議論は、この仕様の範囲外です。
However, the use of such self-contained access tokens has an effect on the ability of the AS to provide certain functionality defined within this specification. Specifically, since the access token is self-contained, it is difficult or impossible for an AS to signal to all RSs within an ecosystem when a specific access token has been revoked. Therefore, an AS in such an ecosystem should probably not offer token revocation functionality to client instances, since the client instance's calls to such an endpoint are effectively meaningless. However, a client instance calling the token revocation function will also throw out its copy of the token, so such a placebo endpoint might not be completely meaningless. Token rotation is similarly difficult because the AS has to revoke the old access token after a rotation call has been made. If the access tokens are completely self-contained and non-revocable, this means that there will be a period of time during which both the old and new access tokens are valid and usable, which is an increased security risk for the environment.
ただし、このような自己完結型アクセストークンの使用は、この仕様内で定義された特定の機能を提供する能力に影響を与えます。具体的には、アクセストークンは自己完結型であるため、特定のアクセストークンが取り消されたときに、生態系内のすべてのRSSにASを通知することは困難または不可能です。したがって、そのようなエコシステムのように、クライアントインスタンスのそのようなエンドポイントへの呼び出しは事実上無意味であるため、クライアントインスタンスにトークンの取り消し機能を提供するべきではないでしょう。ただし、トークンの取り消し関数を呼び出すクライアントインスタンスは、トークンのコピーを捨てるため、このようなプラセボエンドポイントは完全に意味がない場合があります。トークンの回転も同様に困難です。なぜなら、ASは回転コールが行われた後に古いアクセストークンを取り消さなければならないからです。アクセストークンが完全に自己完結型で革新的でない場合、これは、古いアクセストークンと新しいアクセストークンの両方が有効で使用可能である期間があることを意味します。これは環境のセキュリティリスクの増加です。
These problems can be mitigated by keeping the validity time windows of self-contained access tokens reasonably short, limiting the time after a revocation event that a revoked token could be used. Additionally, the AS could proactively signal to RSs under its control identifiers for revoked tokens that have yet to expire. This type of information push would be expected to be relatively small and infrequent, and its implementation is outside the scope of this specification.
これらの問題は、自己完結型のアクセストークンの有効時間のウィンドウを合理的に短く保ち、取り消されたトークンを使用できる取り消しイベントの後の時間を制限することで軽減できます。さらに、ASは、まだ期限切れになっていない取り！このタイプの情報プッシュは比較的小さく、まれであると予想され、その実装はこの仕様の範囲外です。
If a client instance makes a call to rotate an access token but the network connection is dropped before the client instance receives the response with the new access token, the system as a whole can end up in an inconsistent state, where the AS has already rotated the old access token and invalidated it, but the client instance only has access to the invalidated access token and not the newly rotated token value. If the client instance retries the rotation request, it would fail because the client is no longer presenting a valid and current access token. A similar situation can occur during grant continuation, where the same client instance calls to continue or update a grant request without successfully receiving the results of the update.
クライアントインスタンスがアクセストークンを回転させるために呼び出しを行うが、クライアントインスタンスが新しいアクセストークンで応答を受信する前にネットワーク接続がドロップされた場合、システム全体としては、ASがすでに回転している一貫性のない状態になります。古いアクセストークンはそれを無効にしましたが、クライアントインスタンスは、新しく回転したトークン値ではなく、無効なアクセストークンにのみアクセスできます。クライアントインスタンスが回転要求を取得すると、クライアントが有効なアクセストークンを提示しなくなっているために失敗します。同様の状況が、付与の継続中に発生する可能性があります。この場合、同じクライアントインスタンスがアップデートの結果を正常に受信せずに助成金リクエストを継続または更新するように呼びます。
To combat this, both grant management (Section 5) and token management (Section 6) can be designed to be idempotent, where subsequent calls to the same function with the same credentials are meant to produce the same results. For example, multiple calls to rotate the same access token need to result in the same rotated token value, within a reasonable time window.
これに対処するために、助成金管理（セクション5）とトークン管理（セクション6）の両方を設計することができます。同じ機能を持つ同じ関数への後続の呼び出しは、同じ結果を生成することを目的としています。たとえば、同じアクセストークンを回転させるための複数の呼び出しは、合理的な時間ウィンドウ内で同じ回転トークン値になる必要があります。
In practice, an AS can hold onto an old token value for such limited purposes. For example, to support rotating access tokens over unreliable networks, the AS receives the initial request to rotate an access token and creates a new token value and returns it. The AS also marks the old token value as having been used to create the newly rotated token value. If the AS sees the old token value within a small enough time window, such as a few seconds since the first rotation attempt, the AS can return the same rotated access token value. Furthermore, once the system has seen the newly rotated token in use, the original token can be discarded because the client instance has proved that it did receive the token. The result of this is a system that is eventually self-consistent without placing an undue complexity burden on the client instance to manage problematic networks.
実際には、このような限られた目的のために、古いトークンの価値を保持できるようになりました。たとえば、信頼性の低いネットワーク上の回転アクセストークンをサポートするために、ASはアクセストークンを回転させる最初の要求を受信し、新しいトークン値を作成して返します。ASは、新しく回転したトークン値を作成するために使用された古いトークン値をマークします。ASが最初の回転試行から数秒後、ASが同じ回転アクセストークン値を返すことができるように、十分な十分な時間ウィンドウ内で古いトークン値を見る場合。さらに、システムが使用されている新しく回転したトークンを見れば、クライアントインスタンスがトークンを受け取ったことを証明したため、元のトークンを破棄することができます。これの結果は、問題のあるネットワークを管理するためにクライアントインスタンスに過度の複雑さの負担をかけることなく、最終的に自己整合するシステムです。
There are several places within GNAP where a URI can be given to a party, causing it to fetch that URI during normal operation of the protocol. If an attacker is able to control the value of one of these URIs within the protocol, the attacker could cause the target system to execute a request on a URI that is within reach of the target system but normally unavailable to the attacker. Examples include an attacker sending a URL of http://localhost/admin to cause the server to access an internal function on itself or https://192.168.0.14/ to call a service behind a firewall. Even if the attacker does not gain access to the results of the call, the side effects of such requests coming from a trusted host can be problematic to the security and sanctity of such otherwise unexposed endpoints. This can be particularly problematic if such a URI is used to call non-HTTP endpoints, such as remote code execution services local to the AS.
GNAP内には、URIをパーティーに与えることができる場所がいくつかあり、プロトコルの通常の操作中にそのURIを取得します。攻撃者がプロトコル内のこれらのURIの1つの値を制御できる場合、攻撃者はターゲットシステムにターゲットシステムの範囲内にあるが通常攻撃者が利用できないURIでリクエストを実行する可能性があります。例には、攻撃者がhttp：// localhost/adminのURLを送信して、サーバーがそれ自体またはhttps://192.168.0.14/の内部関数にアクセスするようにします。攻撃者がコールの結果にアクセスできない場合でも、信頼できるホストからのそのような要求の副作用は、そのような暴露されたエンドポイントのセキュリティと神聖さに問題がある可能性があります。このようなURIを使用して、ASにローカルなリモートコード実行サービスなどの非HTTPエンドポイントを呼び出すために使用される場合、これは特に問題があります。
The most vulnerable place in this specification is the push-based post-interaction finish method (Section 4.2.2), as the client instance is less trusted than the AS and can use this method to make the AS call an arbitrary URI. While it is not required by the protocol, the AS can fetch other URIs provided by the client instance, such as the logo image or home page, for verification or privacy-preserving purposes before displaying them to the RO as part of a consent screen. Even if the AS does not fetch these URIs, their use in GNAP's normal operation could cause an attack against the end user's browser as it fetches these same attack URIs. Furthermore, extensions to GNAP that allow or require URI fetch could also be similarly susceptible, such as a system for having the AS fetch a client instance's keys from a presented URI instead of the client instance presenting the key by value. Such extensions are outside the scope of this specification, but any system deploying such an extension would need to be aware of this issue.
この仕様で最も脆弱な場所は、クライアントインスタンスがASよりも信頼されていないため、プッシュベースの相互作用後仕上げ方式（セクション4.2.2）です。プロトコルでは必須ではありませんが、同意画面の一部としてROに表示する前に、検証またはプライバシー提示の目的のために、ロゴ画像やホームページなどのクライアントインスタンスによって提供される他のURIを取得できます。ASがこれらのURIを取得しない場合でも、GNAPの通常の操作での使用は、これらの同じ攻撃URIを取得する際にエンドユーザーのブラウザに対する攻撃を引き起こす可能性があります。さらに、URIフェッチを許可または要求するGNAPへの拡張も同様に影響を受けやすい場合があります。たとえば、AS AS AS AS Fetch a Client Aのキーを表示します。このような拡張機能はこの仕様の範囲外ですが、このような拡張機能を展開するシステムは、この問題に注意する必要があります。
To help mitigate this problem, similar approaches that protect parties against malicious redirects (Section 11.29) can be used. For example, all URIs that can result in a direct request being made by a party in the protocol can be filtered through an allowlist or blocklist. For example, an AS that supports the push-based interaction finish method can compare the callback URI in the interaction request to a known URI for a pre-registered client instance, or it can ensure that the URI is not on a blocklist of sensitive URLs such as internal network addresses. However, note that because these types of calls happen outside of the view of human interaction, it is not usually feasible to provide notification and warning to someone before the request needs to be executed, as is the case with redirection URLs. As such, SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URI if unsure.
この問題を軽減するために、悪意のあるリダイレクトからパーティーを保護する同様のアプローチ（セクション11.29）を使用できます。たとえば、プロトコル内のパーティーが直接リクエストを行う可能性のあるすべてのURIは、AlowListまたはブロックリストを介してフィルタリングできます。たとえば、プッシュベースのインタラクション仕上げ方式をサポートするASは、事前に登録されたクライアントインスタンスのインタラクションリクエストのコールバックURIを既知のURIと比較することができます。内部ネットワークアドレスなど。ただし、これらのタイプの呼び出しは、人間の相互作用の見解の外で発生するため、リダイレクトURLの場合のように、リクエストを実行する前に誰かに通知と警告を提供することは通常実行不可能であることに注意してください。そのため、SSRFは実行時に管理がやや困難であり、システムが不確かな場合はURIの取得を拒否する必要があります。
All keys presented by value are only allowed to be in a single format. While it would seem beneficial to allow keys to be sent in multiple formats in case the receiver doesn't understand one or more of the formats used, there are security issues with such a feature. If multiple keys formats are allowed, receivers of these key definitions would need to be able to make sure that it's the same key represented in each field and not simply use one of the key formats without checking for equivalence. If equivalence is not carefully checked, it is possible for an attacker to insert their own key into one of the formats without needing to have control over the other formats. This could potentially lead to a situation where one key is used by part of the system (such as identifying the client instance) and a different key in a different format in the same message is used for other things (such as calculating signature validity). However, in such cases, it is impossible for the receiver to ensure that all formats contain the same key information since it is assumed that the receiver cannot understand all of the formats.
値によって提示されるすべてのキーは、単一の形式でのみ許可されます。レシーバーが使用されている形式の1つ以上を理解していない場合に、キーを複数の形式で送信できるようにすることは有益に思えますが、そのような機能にはセキュリティの問題があります。複数のキー形式が許可されている場合、これらのキー定義の受信機は、各フィールドで表現された同じキーであり、同等性をチェックせずにキー形式のいずれかを使用するだけではないことを確認できる必要があります。同等性が慎重にチェックされていない場合、攻撃者は他の形式を制御する必要なく、自分のキーをフォーマットの1つに挿入することができます。これは、システムの一部（クライアントインスタンスの識別など）で1つのキーが使用され、同じメッセージの異なる形式の異なるキーが他のもの（署名の妥当性の計算など）に使用される状況につながる可能性があります。ただし、そのような場合、受信者はすべての形式がすべての形式を理解できないと想定されるため、すべてのフォーマットが同じ重要な情報を含めることを保証することは不可能です。
To combat this, all keys presented by value have to be in exactly one supported format known by the receiver as discussed in Section 7.1. In most cases, a client instance is going to be configured with its keys in a single format, and it will simply present that format as is to the AS in its request. A client instance capable of multiple formats can use AS discovery (Section 9) to determine which formats are supported, if desired. An AS should be generous in supporting many different key formats to allow different types of client software and client instance deployments. An AS implementation should try to support multiple formats to allow a variety of client software to connect.
これに対処するには、値によって提示されたすべてのキーは、セクション7.1で説明したように、受信機が知っている正確に1つのサポートされた形式である必要があります。ほとんどの場合、クライアントインスタンスは単一の形式でキーを使用して構成され、その形式をそのようにリクエストのように表示するだけです。複数の形式で可能なクライアントインスタンスは、必要に応じてサポートされている形式を決定するために、ディスカバリー（セクション9）として使用できます。さまざまなタイプのクライアントソフトウェアとクライアントインスタンスの展開を許可するために、さまざまなキー形式をサポートするのに寛大になるはずです。AS AS実装は、さまざまなクライアントソフトウェアが接続できるように、複数の形式をサポートしようとする必要があります。
GNAP allows the RO to be contacted by the AS asynchronously, outside the regular flow of the protocol. This allows for some advanced use cases, such as cross-user authentication or information release, but such advanced use cases have some distinct issues that implementors need to be fully aware of before using these features.
GNAPにより、ROは、プロトコルの通常の流れの外側で、非同期に連絡することができます。これにより、クロスユーザー認証や情報リリースなど、一部の高度なユースケースが可能になりますが、このような高度なユースケースには、これらの機能を使用する前に実装者が完全に認識する必要がある明確な問題があります。
First, in many applications, the return of subject information to the client instance could indicate to the client instance that the end user is the party represented by that information, functionally allowing the end user to authenticate to the client application. While the details of a fully functional authentication protocol are outside the scope of GNAP, it is a common exercise for a client instance to request information about the end user. This is facilitated by several interaction methods (Section 4.1) defined in GNAP that allow the end user to begin interaction directly with the AS. However, when the subject of the information is intentionally not the end user, the client application will need some way to differentiate between requests for authentication of the end user and requests for information about a different user. Confusing these states could lead to an attacker having their account associated with a privileged user. Client instances can mitigate this by having distinct code paths for primary end-user authentication and for requesting subject information about secondary users, such as in a call center. In such use cases, the client software used by the RO (the caller) and the end user (the agent) are generally distinct, allowing the AS to differentiate between the agent's corporate device making the request and the caller's personal device approving the request.
まず、多くのアプリケーションで、クライアントインスタンスへのサブジェクト情報の返品は、エンドユーザーがその情報に代表されるパーティであることをクライアントインスタンスに示すことができ、エンドユーザーがクライアントアプリケーションに認証できるようにします。完全に機能的な認証プロトコルの詳細はGNAPの範囲外ですが、クライアントインスタンスがエンドユーザーに関する情報を要求するのは一般的な演習です。これは、GNAPで定義されたいくつかの相互作用方法（セクション4.1）によって促進され、エンドユーザーがASとの相互作用を直接開始できます。ただし、情報の主題が意図的にエンドユーザーではない場合、クライアントアプリケーションは、エンドユーザーの認証要求と別のユーザーに関する情報のリクエストを区別する何らかの方法が必要です。これらの状態を混乱させると、攻撃者が特権ユーザーに関連付けられていることにつながる可能性があります。クライアントインスタンスは、プライマリエンドユーザー認証のための個別のコードパスを持つことと、コールセンターなどのセカンダリユーザーに関する主題情報を要求することにより、これを軽減できます。このようなユースケースでは、RO（発信者）とエンドユーザー（エージェント）が使用するクライアントソフトウェアは一般に異なり、エージェントの企業デバイスがリクエストを作成することと、リクエストを承認する発信者の個人デバイスを区別できるようにします。
Second, ROs that interact asynchronously do not usually have the same context as an end user in an application attempting to perform the task needing authorization. As such, the asynchronous requests for authorization coming to the RO from the AS might have very little to do with what the RO is doing at the time. This situation can consequently lead to authorization fatigue on the part of the RO, where any incoming authorization request is quickly approved and dispatched without the RO making a proper verification of the request. An attacker can exploit this fatigue and get the RO to authorize the attacker's system for access. To mitigate this, AS systems deploying asynchronous authorization should only prompt the RO when the RO is expecting such a request, and significant user experience engineering efforts need to be employed to ensure that the RO can clearly make the appropriate security decision. Furthermore, audit capability and the ability to undo access decisions that may be ongoing are particularly important in the asynchronous case.
第二に、非同期に相互作用するROSは、通常、許可を必要とするタスクを実行しようとするアプリケーションでエンドユーザーと同じコンテキストを持たない。そのため、ROからROから来る認可に対する非同期要求は、ROが当時行っていることとはほとんど関係がないかもしれません。したがって、この状況は、ROがリクエストを適切に検証することなく、着信承認要求が迅速に承認および派遣されるRO側の承認疲労につながる可能性があります。攻撃者は、この疲労を悪用し、ROにアクセスのために攻撃者のシステムを許可することができます。これを緩和するために、非同期認可を展開するシステムは、ROがそのような要求を期待している場合にのみROを促す必要があるため、ROが適切なセキュリティ決定を明確に行えるようにするために、重要なユーザーエクスペリエンスエンジニアリングの努力を採用する必要があります。さらに、監査機能と進行中のアクセス決定を元に戻す能力は、非同期の場合に特に重要です。
An attacker may aim to gain access to confidential or sensitive resources. The measures for hardening and monitoring RS systems (beyond protection with access tokens) are out of the scope of this document, but the use of GNAP to protect a system does not absolve the RS of following best practices. GNAP generally considers that a breach can occur and therefore advises to prefer key-bound tokens whenever possible, which at least limits the impact of access token leakage by a compromised or malicious RS.
攻撃者は、機密リソースまたは機密性の高いリソースへのアクセスを目指している場合があります。RSシステムを強化および監視するための対策（アクセストークンを使用した保護を超えて）はこのドキュメントの範囲外ですが、システムを保護するためのGNAPを使用しても、以下のベストプラクティスのRSを免除しません。GNAPは一般に、違反が発生する可能性があると考えているため、可能な限りキーバウンドトークンを好むことをお勧めします。これにより、少なくとも侵害または悪意のあるRSによるアクセストークンリークの影響が制限されます。
While the most common token-issuance pattern is to bind the access token to the client instance's presented key, it is possible for the AS to provide a binding key along with an access token, as shown by the key field of the token response in Section 3.2.1. This practice allows for an AS to generate and manage the keys associated with tokens independently of the keys known to client instances.
最も一般的なトークン発行パターンは、アクセストークンをクライアントインスタンスの提示キーにバインドすることですが、セクションのトークン応答のキーフィールドで示されるように、アクセストークンとともにバインディングキーを提供することが可能です。3.2.1。このプラクティスにより、クライアントインスタンスに既知のキーとは無関係にトークンに関連するキーを生成および管理することができます。
If the key material is returned by value from the AS, then the client instance will simply use this key value when presenting the token. This can be exploited by an attacker to issue a compromised token to an unsuspecting client, assuming that the client instance trusts the attacker's AS to issue tokens for the target RS. In this attack, the attacker first gets a token bound to a key under the attacker's control. This token is likely bound to an authorization or account controlled by the attacker. The attacker then reissues that same token to the client instance, this time acting as an AS. The attacker can return their own key to the client instance, tricking the client instance into using the attacker's token. Such an attack is also possible when the key is returned by reference, if the attacker is able to provide a reference meaningful to the client instance that references a key under the attacker's control. This substitution attack is similar to some of the main issues found with bearer tokens as discussed in Section 11.9.
キー資料がASから値によって返される場合、クライアントインスタンスは、トークンを提示するときにこのキー値を使用するだけです。これは、クライアントインスタンスがターゲットRSのトークンを発行するように攻撃者を信頼していると仮定して、攻撃者が侵害したトークンを疑いを持たないクライアントに発行することができます。この攻撃では、攻撃者は最初に攻撃者のコントロールの下でキーにバインドされたトークンを取得します。このトークンは、攻撃者によって管理されている許可またはアカウントに拘束される可能性があります。その後、攻撃者はクライアントインスタンスに同じトークンを再発行し、今回はASとして機能します。攻撃者は、クライアントインスタンスに独自のキーを返すことができ、クライアントインスタンスを攻撃者のトークンの使用にトリックできます。このような攻撃は、攻撃者が攻撃者のコントロールの下でキーを参照するクライアントインスタンスに意味のある参照を提供できる場合、参照によってキーを返す場合にも可能です。この置換攻撃は、セクション11.9で説明したように、ベアラートークンで見られる主な問題のいくつかに似ています。
Returning a key with an access token should be limited to circumstances where both the client and AS can be verified to be honest and when the trade-off of not using a client instance's own keys is worth the additional risk.
アクセストークンでキーを返すことは、クライアントとASの両方が正直であることを検証できる状況に限定され、クライアントインスタンスのキーを使用しないというトレードオフが追加のリスクに見合う価値がある場合があります。
The privacy considerations in this section are modeled after the list of privacy threats in "Privacy Considerations for Internet Protocols" [RFC6973] and either explain how these threats are mitigated or advise how the threats relate to GNAP.
このセクションのプライバシーに関する考慮事項は、「インターネットプロトコルのプライバシーに関する考慮事項」[RFC6973]のプライバシー脅威のリストをモデルにし、これらの脅威がどのように緩和されるかを説明するか、脅威がGNAPにどのように関連するかをアドバイスします。
Surveillance is the observation or monitoring of an individual's communications or activities. Surveillance can be conducted by observers or eavesdroppers at any point along the communications path.
監視とは、個人のコミュニケーションまたは活動の観察または監視です。監視は、通信経路に沿った任意の時点で、オブザーバーまたは盗聴者によって行うことができます。
GNAP assumes the TLS protection used throughout the spec is intact. Without the protection of TLS, there are many points throughout the use of GNAP that could lead to possible surveillance. Even with the proper use of TLS, surveillance could occur by several parties outside of the TLS-protected channels, as discussed in the subsections below.
GNAPは、仕様全体で使用されるTLS保護が無傷であると仮定します。TLSの保護がなければ、GNAPの使用全体にわたって多くのポイントがあり、監視の可能性につながる可能性があります。TLSを適切に使用しても、以下のサブセクションで説明するように、TLS保護チャネル以外のいくつかの関係者によって監視が発生する可能性があります。
The purpose of GNAP is to authorize clients to be able to access information on behalf of a user. So while it is expected that the client may be aware of the user's identity as well as data being fetched for that user, in some cases, the extent of the client may be beyond what the user is aware of. For example, a client may be implemented as multiple distinct pieces of software, such as a logging service or a mobile application that reports usage data to an external backend service. Each of these pieces could gain information about the user without the user being aware of this action.
GNAPの目的は、ユーザーに代わって情報にアクセスできるようにクライアントに承認することです。そのため、クライアントはユーザーのアイデンティティとそのユーザーのためにフェッチされているデータだけでなく、場合によっては、クライアントの範囲がユーザーが認識しているものを超えている可能性があると予想されますが。たとえば、クライアントは、ロギングサービスや、使用データを外部バックエンドサービスに報告するモバイルアプリケーションなど、複数の異なるソフトウェアとして実装できます。これらの各ピースは、ユーザーがこのアクションを認識せずにユーザーに関する情報を得ることができます。
When the client software uses a hosted asset for its components, such as its logo image, the fetch of these assets can reveal user actions to the host. If the AS presents the logo URI to the RO in a browser page, the browser will fetch the logo URL from the authorization screen. This fetch will tell the host of the logo image that someone is accessing an instance of the client software and requesting access for it. This is particularly problematic when the host of the asset is not the client software itself, such as when a content delivery network is used.
クライアントソフトウェアがロゴイメージなどのコンポーネントにホストされたアセットを使用すると、これらの資産のフェッチはホストにユーザーアクションを明らかにすることができます。ASがブラウザページでROにロゴURIを提示する場合、ブラウザは[承認]画面からロゴURLを取得します。このフェッチは、誰かがクライアントソフトウェアのインスタンスにアクセスし、アクセスを要求していることをロゴ画像のホストに伝えます。これは、コンテンツ配信ネットワークを使用するときなど、資産のホストがクライアントソフトウェア自体ではない場合に特に問題があります。
The role of the AS is to manage the authorization of client instances to protect access to the user's data. In this role, the AS is by definition aware of each authorization of a client instance by a user. When the AS shares user information with the client instance, it needs to make sure that it has the permission from that user to do so.
ASの役割は、ユーザーのデータへのアクセスを保護するためにクライアントインスタンスの承認を管理することです。この役割では、ASは定義上、ユーザーによるクライアントインスタンスの各許可を認識しています。ASがクライアントインスタンスとユーザー情報を共有する場合、そのユーザーからそうする許可があることを確認する必要があります。
Additionally, as part of the authorization grant process, the AS may be aware of which RSs the client intends to use an access token at. However, it is possible to design a system using GNAP in which this knowledge is not made available to the AS, such as by avoiding the use of the locations object in the authorization request.
さらに、承認助成金プロセスの一環として、クライアントがアクセストークンを使用することを意図していることが認識される場合があります。ただし、承認要求での場所オブジェクトの使用を回避するなど、この知識がASが利用できるようになっていないGNAPを使用してシステムを設計することができます。
If the AS's implementation of access tokens is such that it requires an RS callback to the AS to validate them, then the AS will be aware of which RSs are actively in use and by which users and clients. To avoid this possibility, the AS would need to structure access tokens in such a way that they can be validated by the RS without notifying the AS that the token is being validated.
ASのアクセストークンの実装が、それらを検証するためにRSコールバックを必要とするようなものである場合、ASはどのRSSが積極的に使用されているか、ユーザーとクライアントによって認識されます。この可能性を回避するために、トークンが検証されていることを通知せずにRSによって検証できるように、アクセストークンを構造化する必要があります。
Several parties in the GNAP process are expected to persist data at least temporarily, if not semi-permanently, for the normal functioning of the system. If compromised, this could lead to exposure of sensitive information. This section documents the potentially sensitive information each party in GNAP is expected to store for normal operation. Naturally, it is possible for any party to store information related to protocol mechanics (such as audit logs, etc.) for longer than is technically necessary.
GNAPプロセスのいくつかの当事者は、システムの通常の機能のために、少なくとも半永続的ではないにしても、少なくとも一時的にデータを持続することが期待されています。侵害された場合、これは機密情報の露出につながる可能性があります。このセクションでは、GNAPの各当事者が通常の操作のために保存することが期待される潜在的に機密情報を文書化します。当然のことながら、あらゆる当事者がプロトコルメカニクス（監査ログなど）に関連する情報を技術的に必要なよりも長く保存する可能性があります。
The AS is expected to store Subject Identifiers for users indefinitely, in order to be able to include them in the responses to clients. The AS is also expected to store client key identifiers associated with display information about the client, such as its name and logo.
クライアントへの応答にそれらを含めることができるように、ユーザーのサブジェクト識別子を無期限に保存することが予想されます。ASは、クライアントの名前やロゴなど、クライアントに関する表示情報に関連付けられたクライアントキー識別子を保存することも期待されています。
The client is expected to store its client instance key indefinitely, in order to authenticate to the AS for the normal functioning of the GNAP flows. Additionally, the client will be temporarily storing artifacts issued by the AS during a flow, and these artifacts ought to be discarded by the client when the transaction is complete.
クライアントは、GNAPフローの通常の機能についてASに認証するために、クライアントインスタンスのキーを無期限に保存することが期待されます。さらに、クライアントはフロー中にASによって発行されたアーティファクトを一時的に保存し、これらのアーティファクトはトランザクションが完了したときにクライアントが破棄する必要があります。
The RS is not required to store any state for its normal operation, as far as its part in implementing GNAP. Depending on the implementation of access tokens, the RS may need to cache public keys from the AS in order to validate access tokens.
RSは、GNAPの実装において、通常の操作のためにどのような状態を保存する必要はありません。アクセストークンの実装に応じて、RSはアクセストークンを検証するためにASからパブリックキーをキャッシュする必要がある場合があります。
Intrusion refers to the ability of various parties to send unsolicited messages or cause denial of service for unrelated parties.
侵入とは、さまざまな当事者が未承諾のメッセージを送信したり、無関係な関係者のサービスの拒否を引き起こす能力を指します。
If the RO is different from the end user, there is an opportunity for the end user to cause unsolicited messages to be sent to the RO if the system prompts the RO for consent when an end user attempts to access their data.
ROがエンドユーザーと異なる場合、エンドユーザーがエンドユーザーがデータにアクセスしようとしたときにシステムがROに同意を求めた場合、エンドユーザーがROに未承諾メッセージを送信する機会があります。
The format and contents of Subject Identifiers are intentionally not defined by GNAP. If the AS uses values for Subject Identifiers that are also identifiers for communication channels (e.g., an email address or phone number), this opens up the possibility for a client to learn this information when it was not otherwise authorized to access this kind of data about the user.
サブジェクト識別子の形式と内容は、GNAPによって意図的に定義されていません。ASが通信チャネルの識別子でもあるサブジェクト識別子の値（電子メールアドレスや電話番号など）を使用する場合、これにより、この種のデータにアクセスすることが許可されていない場合にクライアントがこの情報を学習する可能性が開きます。ユーザーについて。
The threat of correlation is the combination of various pieces of information related to an individual in a way that defies their expectations of what others know about them.
相関の脅威は、他の人が知っていることに対する彼らの期待に反する方法で、個人に関連するさまざまな情報の組み合わせです。
The biggest risk of correlation in GNAP is when an AS returns stable, consistent user identifiers to multiple different applications. In this case, applications created by different parties would be able to correlate these user identifiers out of band in order to know which users they have in common.
GNAPの相関の最大のリスクは、A asが複数の異なるアプリケーションに安定した一貫したユーザー識別子を返す場合です。この場合、さまざまな関係者によって作成されたアプリケーションは、これらのユーザー識別子をバンドから相関させることができ、共通のユーザーを知ることができます。
The most common example of this in practice is tracking for advertising purposes, such that a client shares their list of user IDs with an ad platform that is then able to retarget ads to applications created by other parties. In contrast, a positive example of correlation is a corporate acquisition where two previously unrelated clients now do need to be able to identify the same user between the two clients, such as when software systems are intentionally connected by the end user.
実際にこの最も一般的な例は、広告目的で追跡することです。そのため、クライアントはユーザーIDのリストを広告プラットフォームと共有し、他の当事者が作成したアプリケーションに広告をリタークすることができます。対照的に、相関の肯定的な例は、ソフトウェアシステムがエンドユーザーによって意図的に接続されている場合など、2人のクライアント間で同じユーザーを識別できるようにする必要がある企業獲得です。
Another means of correlation comes from the use of RS-first discovery (Section 9.1). A client instance that knows nothing other than an RS's URL could make an unauthenticated call to the RS and learn which AS protects the resources there. If the client instance knows something about the AS, such as it being a single-user AS or belonging to a specific organization, the client instance could, through association, learn things about the resource without ever gaining access to the resource itself.
別の相関手段は、RSファーストディスカバリー（セクション9.1）の使用に起因します。RSのURL以外に何も知らないクライアントインスタンスは、RSに無許可の呼び出しを行い、そこにあるリソースを保護するものを学習することができます。クライアントインスタンスがASについて何かを知っている場合、特定の組織としてシングルユーザーである、または特定の組織に属しているなど、クライアントインスタンスは、関連性を通じて、リソース自体にアクセスすることなくリソースに関することを学ぶことができます。
Unrelated RSs also have an opportunity to correlate users if the AS includes stable user identifiers in access tokens or in access token introspection responses.
無関係なRSSには、ASがアクセストークンに安定したユーザー識別子やアクセストークン内注文応答が含まれている場合、ユーザーを相関させる機会もあります。
In some cases, an RS may not actually need to be able to identify users (such as an RS providing access to a company cafeteria menu, which only needs to validate whether the user is a current employee), so ASes should be thoughtful of when user identifiers are actually necessary to communicate to RSs for the functioning of the system.
場合によっては、RSは実際にユーザーを識別できる必要がない場合があります（ユーザーが現在の従業員であるかどうかのみを検証する必要がある会社カフェテリアメニューへのアクセスを提供するRSなど）。システムの機能についてRSSと通信するには、実際にユーザー識別子が必要です。
However, note that the lack of inclusion of a user identifier in an access token may be a risk if there is a concern that two users may voluntarily share access tokens between them in order to access protected resources. For example, if a website wants to limit access to only people over 18, and such does not need to know any user identifiers, an access token may be issued by an AS contains only the claim "over 18". If the user is aware that this access token doesn't reference them individually, they may be willing to share the access token with a user who is under 18 in order to let them get access to the website. (Note that the binding of an access token to a non-extractable client instance key also prevents the access token from being voluntarily shared.)
ただし、2人のユーザーが保護されたリソースにアクセスするために自発的にアクセストークンを共有できるという懸念がある場合、アクセストークンにユーザー識別子を含めることが不足している場合は、リスクになる可能性があることに注意してください。たとえば、Webサイトが18歳以上の人のみへのアクセスを制限したい場合、ユーザー識別子を知る必要がない場合、ASは「18歳以上」というクレームのみを含むASによって発行される場合があります。このアクセストークンが個別にそれらを参照していないことをユーザーが認識している場合、Webサイトにアクセスできるようにするために、18歳未満のユーザーとアクセストークンを喜んで共有することができます。（アクセストークンの抽出不可能なクライアントインスタンスキーへのバインディングにより、アクセストークンが自発的に共有されるのを防ぐこともできます。）
Clients are expected to be identified by their client instance key. If a particular client instance key is used at more than one AS, this could open up the possibility for multiple unrelated ASes to correlate client instances. This is especially a problem in the common case where a client instance is used by a single individual, as it would allow the ASes to correlate that individual between them. If this is a concern of a client, the client should use distinct keys with each AS.
クライアントは、クライアントインスタンスキーによって識別されることが期待されています。特定のクライアントインスタンスキーが複数のASで使用されている場合、これにより、複数の無関係なASEがクライアントインスタンスを相関させる可能性が開かれる可能性があります。これは、クライアントインスタンスが1人の個人によって使用される一般的なケースでは特に問題です。ASESがそれらの間にその個人を相関させることができるためです。これがクライアントの懸念である場合、クライアントはそれぞれの個別のキーを使用する必要があります。
Throughout many parts of GNAP, the parties pass shared references between each other, sometimes in place of the values themselves (for example, the interact_ref value used throughout the flow). These references are intended to be random strings and should not contain any private or sensitive data that could potentially leak information between parties.
GNAPの多くの部分を通して、当事者は互いに共有された参照を渡し、時には値自体の代わりに（たとえば、フロー全体で使用されるinteration_ref値）。これらの参照は、ランダムな文字列であることを目的としており、当事者間で情報を漏らす可能性のあるプライベートまたは機密データを含めるべきではありません。
[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>.
[HASH-ALG] IANA, "Named Information Hash Algorithm Registry",
<https://www.iana.org/assignments/named-information/>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 2", December 2023,
<https://openid.net/specs/openid-connect-core-1_0.html>.
[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>.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
DOI 10.17487/RFC2397, August 1998,
<https://www.rfc-editor.org/info/rfc2397>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[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>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject
Identifiers for Security Event Tokens", RFC 9493,
DOI 10.17487/RFC9493, December 2023,
<https://www.rfc-editor.org/info/rfc9493>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/info/rfc9530>.
[SAML2] Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E.
Maler, Ed., "Assertions and Protocol for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS
Standard, March 2005, <https://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[Auth-Schemes]
IANA, "HTTP Authentication Schemes",
<https://www.iana.org/assignments/http-authschemes>.
[AXELAND2021]
Axeland, Å. and O. Oueidat, "Security Analysis of Attack
Surfaces on the Grant Negotiation and Authorization
Protocol", Master's thesis, Department of Computer Science
and Engineering, Chalmers University of Technology and
University of Gothenburg, 2021,
<https://hdl.handle.net/20.500.12380/304105>.
[GNAP-REG] IANA, "Grant Negotiation and Authorization Protocol
(GNAP)", <https://www.iana.org/assignments/gnap>.
[GNAP-RS] Richer, J., Ed. and F. Imbault, "Grant Negotiation and
Authorization Protocol Resource Server Connections", Work
in Progress, Internet-Draft, draft-ietf-gnap-resource-
servers-09, 23 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-gnap-
resource-servers-09>.
[HELMSCHMIDT2022]
Helmschmidt, F., "Security Analysis of the Grant
Negotiation and Authorization Protocol", Master's thesis,
Institute of Information Security, University of Stuggart,
DOI 10.18419/opus-12203, 2022,
<http://dx.doi.org/10.18419/opus-12203>.
[MediaTypes]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[OAUTH-SEC-TOPICS]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", Work in
Progress, Internet-Draft, draft-ietf-oauth-security-
topics-29, 3 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
security-topics-29>.
[promise-theory]
Bergstra, J. and M. Burgess, "Promise Theory: Principles
and Applications", Second Edition, XtAxis Press, 2019,
<http://markburgess.org/promises.html>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins,
"Known Issues and Best Practices for the Use of Long
Polling and Streaming in Bidirectional HTTP", RFC 6202,
DOI 10.17487/RFC6202, April 2011,
<https://www.rfc-editor.org/info/rfc6202>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[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>.
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols",
RFC 8264, DOI 10.17487/RFC8264, October 2017,
<https://www.rfc-editor.org/info/rfc8264>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[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>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9440] Campbell, B. and M. Bishop, "Client-Cert HTTP Header
Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
<https://www.rfc-editor.org/info/rfc9440>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[SP80063C] Grassi, P., Richer, J., Squire, S., Fenton, J., Nadeau,
E., Lefkovitz, N., Danker, J., Choong, Y., Greene, K., and
M. Theofanos, "Digital Identity Guidelines: Federation and
Assertions", NIST SP 800-63C, DOI 10.6028/NIST.SP.800-63c,
June 2017,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-63c.pdf>.
[Subj-ID-Formats]
IANA, "Subject Identifier Formats",
<https://www.iana.org/assignments/secevent>.
GNAP's protocol design differs from OAuth 2.0's in several fundamental ways:
GNAPのプロトコル設計は、いくつかの基本的な方法でOAuth 2.0と異なります。
1. *Consent and authorization flexibility:*
1. *同意と承認の柔軟性：*
OAuth 2.0 generally assumes the user has access to a web browser. The type of interaction available is fixed by the grant type, and the most common interactive grant types start in the browser. OAuth 2.0 assumes that the user using the client software is the same user that will interact with the AS to approve access.
OAUTH 2.0は通常、ユーザーがWebブラウザーにアクセスできることを想定しています。利用可能なインタラクションのタイプは助成金タイプによって修正され、最も一般的なインタラクティブな助成金タイプはブラウザで始まります。OAUTH 2.0は、クライアントソフトウェアを使用しているユーザーがアクセスを承認するために対話するユーザーと同じユーザーであると想定しています。
GNAP allows various patterns to manage authorizations and consents required to fulfill this requested delegation, including information sent by the client instance, information supplied by external parties, and information gathered through the interaction process. GNAP allows a client instance to list different ways that it can start and finish an interaction, and these can be mixed together as needed for different use cases. GNAP interactions can use a browser, but they don't have to. Methods can use inter-application messaging protocols, out-of-band data transfer, or anything else. GNAP allows extensions to define new ways to start and finish an interaction, as new methods and platforms are expected to become available over time. GNAP is designed to allow the end user and the RO to be two different people, but it still works in the optimized case of them being the same party.
GNAPは、さまざまなパターンが、クライアントインスタンスから送信された情報、外部関係者から提供された情報、および相互作用プロセスを通じて収集された情報など、この要求された代表団を満たすために必要な承認と同意を管理できるようにします。GNAPを使用すると、クライアントインスタンスが相互作用を開始および終了できるさまざまな方法をリストすることができます。これらは、さまざまなユースケースで必要に応じて混合できます。GNAPインタラクションはブラウザを使用できますが、必要はありません。メソッドは、アプリケーション間のメッセージングプロトコル、帯域外データ転送、またはその他のものを使用できます。GNAPを使用すると、拡張機能は、新しい方法とプラットフォームが時間の経過とともに利用可能になると予想されるため、相互作用を開始および終了するための新しい方法を定義できます。GNAPは、エンドユーザーとROが2人の異なる人になるように設計されていますが、それでも同じパーティーであるという最適化されたケースで機能します。
2. *Intent registration and inline negotiation:*
2. *意図登録とインラインネゴシエーション：*
OAuth 2.0 uses different "grant types" that start at different endpoints for different purposes. Many of these require discovery of several interrelated parameters.
OAUTH 2.0は、異なる目的で異なるエンドポイントで始まるさまざまな「グラントタイプ」を使用します。これらの多くは、いくつかの相互に関連するパラメーターの発見を必要とします。
GNAP requests all start with the same type of request to the same endpoint at the AS. Next steps are negotiated between the client instance and AS based on software capabilities, policies surrounding requested access, and the overall context of the ongoing request. GNAP defines a continuation API that allows the client instance and AS to request and send additional information from each other over multiple steps. This continuation API uses the same access token protection that other GNAP-protected APIs use. GNAP allows discovery to optimize the requests, but it isn't required thanks to the negotiation capabilities.
GNAP要求はすべて、ASの同じエンドポイントへの同じタイプのリクエストから始まります。次のステップは、クライアントインスタンスと、ソフトウェア機能、要求されたアクセスを取り巻くポリシー、および進行中の要求の全体的なコンテキストに基づいて交渉されます。GNAPは、クライアントインスタンスを許可し、複数のステップで互いに追加情報を要求して送信する継続APIを定義します。この継続APIは、他のGNAPで保護されたAPIが使用するのと同じアクセストークン保護を使用します。GNAPを使用すると、Discoveryはリクエストを最適化できますが、交渉機能のおかげで必須ではありません。
GNAP is able to handle the life cycle of an authorization request and therefore simplifies the mental model surrounding OAuth2. For instance, there's no need for refresh tokens when the API enables proper rotation of access tokens.
GNAPは、承認要求のライフサイクルを処理できるため、OAUTH2を取り巻くメンタルモデルを簡素化します。たとえば、APIがアクセストークンの適切な回転を可能にする場合、更新トークンは必要ありません。
3. *Client instances:*
3. *クライアントインスタンス：*
OAuth 2.0 requires all clients to be registered at the AS and to use a client_id known to the AS as part of the protocol. This client_id is generally assumed to be assigned by a trusted authority during a registration process, and OAuth places a lot of trust on the client_id as a result. Dynamic registration allows different classes of clients to get a client_id at runtime, even if they only ever use it for one request.
OAUTH 2.0では、すべてのクライアントをASに登録し、プロトコルの一部として既知のクライアント_IDを使用する必要があります。このclient_idは一般に、登録プロセス中に信頼できる当局によって割り当てられると想定されており、その結果、Oauthはclient_idに多くの信頼を置いています。動的登録により、さまざまなクラスのクライアントが、1つのリクエストに対してのみ使用しても、実行時にクライアント_IDを取得できます。
GNAP allows the client instance to present an unknown key to the AS and use that key to protect the ongoing request. GNAP's client instance identifier mechanism allows for pre-registered clients and dynamically registered clients to exist as an optimized case without requiring the identifier as part of the protocol at all times.
GNAPを使用すると、クライアントインスタンスがASに未知のキーを提示し、そのキーを使用して進行中の要求を保護できます。GNAPのクライアントインスタンス識別子メカニズムにより、事前に登録されたクライアントと動的に登録されたクライアントが、常にプロトコルの一部として識別子を要求することなく、最適化されたケースとして存在することができます。
4. *Expanded delegation:*
4. *拡張委任：*
OAuth 2.0 defines the "scope" parameter for controlling access to APIs. This parameter has been coopted to mean a number of different things in different protocols, including flags for turning special behavior on and off and the return of data apart from the access token. The "resource" indicator (defined in [RFC8707]) and Rich Authorization Request (RAR) extensions (as defined in [RFC9396]) expand on the "scope" concept in similar but different ways.
OAUTH 2.0は、APIへのアクセスを制御するための「スコープ」パラメーターを定義します。このパラメーターは、特別な動作をオンとオフにするためのフラグやアクセストークンとは別にデータの返品を含む、さまざまなプロトコルでさまざまなものを意味するように協力されています。「リソース」インジケーター（[RFC8707]で定義）および豊富な承認要求（RAR）拡張（[RFC9396]で定義）は、「スコープ」概念を同様だが異なる方法で拡張します。
GNAP defines a rich structure for requesting access (analogous to RAR), with string references as an optimization (analogous to scopes). GNAP defines methods for requesting directly returned user information, separate from API access. This information includes identifiers for the current user and structured assertions. GNAP makes no assumptions or demands on the format or contents of the access token, but the RS extension allows a negotiation of token formats between the AS and RS.
GNAPは、文字列参照を最適化（スコープに類似）として、アクセスを要求するための豊富な構造（RARに類似）を定義します。GNAPは、APIアクセスとは別に、直接返されたユーザー情報を要求する方法を定義します。この情報には、現在のユーザーの識別子と構造化されたアサーションが含まれています。GNAPは、アクセストークンの形式またはコンテンツについて仮定や要求を行いませんが、RS拡張により、ASとRSの間のトークン形式の交渉が許可されています。
5. *Cryptography-based security:*
5. *暗号化ベースのセキュリティ：*
OAuth 2.0 uses shared bearer secrets, including the client_secret and access token, and advanced authentication and sender constraints have been built on after the fact in inconsistent ways.
OAUTH 2.0は、Client_SecretやAccess Tokenを含む共有Bearer Secretsを使用し、Advanced認証と送信者の制約は、一貫性のない方法で事実の後に構築されています。
In GNAP, all communication between the client instance and AS is bound to a key held by the client instance. GNAP uses the same cryptographic mechanisms for both authenticating the client (to the AS) and binding the access token (to the RS and the AS). GNAP allows extensions to define new cryptographic protection mechanisms, as new methods are expected to become available over time. GNAP does not have the notion of "public clients" because key information can always be sent and used dynamically.
GNAPでは、クライアントインスタンスとAS間のすべての通信が、クライアントインスタンスが保持しているキーにバインドされています。GNAPは、クライアントを認証する（AS）とアクセストークン（RSおよびAS）を結合するために同じ暗号化メカニズムを使用します。GNAPは、新しい方法が時間の経過とともに利用可能になると予想されるため、拡張機能が新しい暗号保護メカニズムを定義できるようにします。GNAPには「パブリッククライアント」の概念はありません。なぜなら、重要な情報は常に動的に送信および使用できるためです。
6. *Privacy and usable security:*
6. *プライバシーと使用可能なセキュリティ：*
OAuth 2.0's deployment model assumes a strong binding between the AS and the RS.
OAUTH 2.0の展開モデルは、ASとRSの間の強力な結合を想定しています。
GNAP is designed to be interoperable with decentralized identity standards and to provide a human-centric authorization layer. In addition to this specification, GNAP supports various patterns of communication between RSs and ASes through extensions. GNAP tries to limit the odds of a consolidation to just a handful of popular AS services.
GNAPは、分散型のアイデンティティ基準と相互運用可能になり、人間中心の認可レイヤーを提供するように設計されています。この仕様に加えて、GNAPは拡張機能を介してRSSとASEの間のさまざまな通信パターンをサポートしています。GNAPは、統合のオッズを、少数の人気のあるサービスとしてのみに制限しようとします。
The protocol defined in this specification provides a number of features that can be combined to solve many different kinds of authentication scenarios. This section seeks to show examples of how the protocol could be applied for different situations.
この仕様で定義されているプロトコルは、さまざまな種類の認証シナリオを解決するために組み合わせることができる多くの機能を提供します。このセクションでは、さまざまな状況にプロトコルをどのように適用できるかの例を示します。
Some longer fields, particularly cryptographic information, have been truncated for display purposes in these examples.
いくつかの長いフィールド、特に暗号化情報は、これらの例では表示目的で切り捨てられています。
In this scenario, the user is the RO and has access to a web browser, and the client instance can take front-channel callbacks on the same device as the user. This combination is analogous to the OAuth 2.0 Authorization Code grant type.
このシナリオでは、ユーザーはROであり、Webブラウザーにアクセスでき、クライアントインスタンスはユーザーと同じデバイスでフロントチャネルコールバックを実行できます。この組み合わせは、OAUTH 2.0認証コード助成金タイプに類似しています。
The client instance initiates the request to the AS. Here, the client instance identifies itself using its public key.
クライアントインスタンスは、ASへの要求を開始します。ここで、クライアントインスタンスは、公開キーを使用して自分自身を識別します。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
{
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
}
],
},
"client": {
"key": {
"proof": "httpsig",
"jwk": {
"kty": "RSA",
"e": "AQAB",
"kid": "xyz-1",
"alg": "RS256",
"n": "kOB5rR4Jv0GMeLaY6_It_r3ORwdf8ci_JtffXyaSx8..."
}
}
},
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return/123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
}
}
The AS processes the request and determines that the RO needs to interact. The AS returns the following response that gives the client instance the information it needs to connect. The AS has also indicated to the client instance that it can use the given instance identifier to identify itself in future requests (Section 2.3.1).
ASは要求を処理し、ROが相互作用する必要があると判断します。ASは、クライアントインスタンスに接続する必要がある情報を提供する次の応答を返します。ASは、特定のインスタンス識別子を使用して将来の要求で自分自身を識別できることをクライアントインスタンスに示しています（セクション2.3.1）。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"interact": {
"redirect":
"https://server.example.com/interact/4CF492MLVMSW9MKM",
"finish": "MBDOFXG4Y5CVJCX821LH"
}
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU"
},
"uri": "https://server.example.com/continue"
},
"instance_id": "7C7C4AZ9KHRS6X63AJAO"
}
The client instance saves the response and redirects the user to the interaction start mode's "redirect" URI by sending the following HTTP message to the user's browser.
クライアントインスタンスは応答を保存し、ユーザーのブラウザに次のHTTPメッセージを送信することにより、インタラクションスタートモードの「リダイレクト」URIにリダイレクトします。
HTTP 303 Found
Location: https://server.example.com/interact/4CF492MLVMSW9MKM
The user's browser fetches the AS's interaction URI. The user logs in, is identified as the RO for the resource being requested, and approves the request. Since the AS has a callback parameter that was sent in the initial request's interaction finish method, the AS generates the interaction reference, calculates the hash, and redirects the user back to the client instance with these additional values added as query parameters.
ユーザーのブラウザは、ASのインタラクションURIを取得します。ユーザーがログインし、要求されているリソースのROとして識別され、リクエストを承認します。ASには、初期リクエストのインタラクション仕上げメソッドで送信されたコールバックパラメーターがあるため、ASはインタラクションリファレンスを生成し、ハッシュを計算し、クエリパラメーターとして追加されたこれらの追加値を使用してユーザーをクライアントインスタンスにリダイレクトします。
NOTE: '\' line wrapping per RFC 8792
HTTP 302 Found
Location: https://client.example.net/return/123455\
?hash=x-gguKWTj8rQf7d7i3w3UhzvuJ5bpOlKyAlVpLxBffY\
&interact_ref=4IFWWIKYBC2PQ6U56NL1
The client instance receives this request from the user's browser. The client instance ensures that this is the same user that was sent out by validating session information and retrieves the stored pending request. The client instance uses the values in this to validate the hash parameter. The client instance then calls the continuation URI using the associated continuation access token and presents the interaction reference in the request content. The client instance signs the request as above.
クライアントインスタンスは、ユーザーのブラウザからこのリクエストを受信します。クライアントインスタンスは、これがセッション情報を検証して送信されたユーザーと同じユーザーであることを保証し、保存されている保留中のリクエストを取得します。クライアントインスタンスは、これの値を使用してハッシュパラメーターを検証します。クライアントインスタンスは、関連する継続アクセストークンを使用して継続URIを呼び出し、リクエストコンテンツに相互作用リファレンスを提示します。クライアントインスタンスは、上記のようにリクエストに署名します。
POST /continue HTTP/1.1
Host: server.example.com
Content-Type: application/json
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"interact_ref": "4IFWWIKYBC2PQ6U56NL1"
}
The AS retrieves the pending request by looking up the pending grant request associated with the presented continuation access token. Seeing that the grant is approved, the AS issues an access token and returns this to the client instance.
ASは、提示された継続アクセストークンに関連付けられた保留中の助成金リクエストを調べることにより、保留中の要求を取得します。助成金が承認されていることを確認すると、AS AS AS ASCACKES TOKENを発行し、これをクライアントインスタンスに返します。
NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": "https://server.example.com/token/PRY5NM33O\
M4TB8N6BW7OZB8CDFONP219RP1L",
"access": [{
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
}]
},
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU"
},
"uri": "https://server.example.com/continue"
}
}
In this scenario, the user does not have access to a web browser on the device and must use a secondary device to interact with the AS. The client instance can display a user code or a printable QR code. The client instance is not able to accept callbacks from the AS and needs to poll for updates while waiting for the user to authorize the request.
このシナリオでは、ユーザーはデバイス上のWebブラウザにアクセスできず、ASと対話するためにセカンダリデバイスを使用する必要があります。クライアントインスタンスは、ユーザーコードまたは印刷可能なQRコードを表示できます。クライアントインスタンスは、ASからのコールバックを受け入れることができず、ユーザーがリクエストを承認するのを待っている間に更新を投票する必要があります。
The client instance initiates the request to the AS.
クライアントインスタンスは、ASへの要求を開始します。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
"dolphin-metadata", "some other thing"
],
},
"client": "7C7C4AZ9KHRS6X63AJAO",
"interact": {
"start": ["redirect", "user_code"]
}
}
The AS processes this and determines that the RO needs to interact. The AS supports both redirect URIs and user codes for interaction, so it includes both. Since there is no interaction finish mode, the AS does not include a nonce but does include a "wait" parameter on the continuation section because it expects the client instance to poll for results.
ASはこれを処理し、ROが相互作用する必要があると判断します。ASは、urisとユーザーコードのリダイレクトとインタラクションの両方をサポートするため、両方が含まれます。インタラクションフィニッシュモードがないため、ASにはNONCEが含まれていませんが、クライアントインスタンスが結果を投票することを期待するため、継続セクションに「待機」パラメーターが含まれます。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"interact": {
"redirect": "https://srv.ex/MXKHQ",
"user_code": {
"code": "A1BC3DFF"
}
},
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU"
},
"uri": "https://server.example.com/continue/VGJKPTKC50",
"wait": 60
}
}
The client instance saves the response and displays the user code visually on its screen along with the static device URI. The client instance also displays the short interaction URI as a QR code to be scanned.
クライアントインスタンスは応答を保存し、ユーザーコードを画面に視覚的に表示し、静的デバイスURIを表示します。クライアントインスタンスは、スキャンするQRコードとして短い相互作用URIを表示します。
If the user scans the code, they are taken to the interaction endpoint, and the AS looks up the current pending request based on the incoming URI. If the user instead goes to the static page and enters the code manually, the AS looks up the current pending request based on the value of the user code. In both cases, the user logs in, is identified as the RO for the resource being requested, and approves the request. Once the request has been approved, the AS displays to the user a message to return to their device.
ユーザーがコードをスキャンすると、それらはインタラクションエンドポイントに取得され、ASは着信URIに基づいて現在の保留リクエストを調べます。代わりにユーザーが静的ページに移動して手動でコードを入力すると、ユーザーコードの値に基づいて現在の保留リクエストを調べます。どちらの場合も、ユーザーがログインし、要求されているリソースのROとして識別され、リクエストを承認します。リクエストが承認されると、AS ASはユーザーにデバイスに戻るメッセージを表示します。
Meanwhile, the client instance polls the AS every 60 seconds at the continuation URI. The client instance signs the request using the same key and method that it did in the first request.
一方、クライアントインスタンスは、継続URIで60秒ごとに投票します。クライアントインスタンスは、最初のリクエストで行ったのと同じキーと方法を使用して要求に署名します。
POST /continue/VGJKPTKC50 HTTP/1.1
Host: server.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
The AS retrieves the pending request based on the pending grant request associated with the continuation access token and determines that it has not yet been authorized. The AS indicates to the client instance that no access token has yet been issued but it can continue to call after another 60-second timeout.
ASは、継続アクセストークンに関連する保留中の助成金要求に基づいて保留中の要求を取得し、まだ承認されていないと判断します。ASは、クライアントインスタンスに、アクセストークンがまだ発行されていないことを示していますが、さらに60秒のタイムアウト後も呼び出し続ける可能性があります。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"continue": {
"access_token": {
"value": "G7YQT4KQQ5TZY9SLSS5E"
},
"uri": "https://server.example.com/continue/ATWHO4Q1WV",
"wait": 60
}
}
Note that the continuation URI and access token have been rotated since they were used by the client instance to make this call. The client instance polls the continuation URI after a 60-second timeout using this new information.
継続URIとアクセストークンは、クライアントインスタンスがこの呼び出しを行うために使用されたため、回転していることに注意してください。クライアントインスタンスは、この新しい情報を使用して60秒のタイムアウトの後、継続URIを投票します。
POST /continue/ATWHO4Q1WV HTTP/1.1
Host: server.example.com
Authorization: GNAP G7YQT4KQQ5TZY9SLSS5E
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
The AS retrieves the pending request based on the URI and access token, determines that it has been approved, and issues an access token for the client to use at the RS.
ASは、URIおよびアクセストークンに基づいて保留中の要求を取得し、承認されたと判断し、クライアントがRSで使用するアクセストークンを発行します。
NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": "https://server.example.com/token/PRY5NM33O\
M4TB8N6BW7OZB8CDFONP219RP1L",
"access": [
"dolphin-metadata", "some other thing"
]
}
}
In this scenario, the client instance is requesting access on its own behalf, with no user to interact with.
このシナリオでは、クライアントインスタンスは、ユーザーがやり取りすることなく、独自のアクセスを要求しています。
The client instance creates a request to the AS, identifying itself with its public key and using MTLS to make the request.
クライアントインスタンスは、ASへのリクエストを作成し、その公開キーで自分自身を識別し、MTLを使用してリクエストを行います。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
{
"access_token": {
"access": [
"backend service", "nightly-routine-3"
],
},
"client": {
"key": {
"proof": "mtls",
"cert#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
}
}
}
The AS processes this, determines that the client instance can ask for the requested resources, and issues an access token.
これを処理すると、クライアントインスタンスが要求されたリソースを要求できることを決定し、アクセストークンを発行します。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": "https://server.example.com/token",
"access": [
"backend service", "nightly-routine-3"
]
}
}
In this scenario, the client instance is requesting on behalf of a specific RO but has no way to interact with the user. The AS can asynchronously reach out to the RO for approval in this scenario.
このシナリオでは、クライアントインスタンスは特定のROに代わって要求していますが、ユーザーと対話する方法はありません。ASは、このシナリオで承認のためにROに非同期に手を差し伸べることができます。
The client instance starts the request at the AS by requesting a set of resources. The client instance also identifies a particular user.
クライアントインスタンスは、リソースのセットを要求することにより、ASでリクエストを開始します。クライアントインスタンスは、特定のユーザーも識別します。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
{
"type": "photo-api",
"actions": [
"read",
"write",
"dolphin"
],
"locations": [
"https://server.example.net/",
"https://resource.local/other"
],
"datatypes": [
"metadata",
"images"
]
},
"read", "dolphin-metadata",
{
"type": "financial-transaction",
"actions": [
"withdraw"
],
"identifier": "account-14-32-32-3",
"currency": "USD"
},
"some other thing"
],
},
"client": "7C7C4AZ9KHRS6X63AJAO",
"user": {
"sub_ids": [ {
"format": "opaque",
"id": "J2G8G8O4AZ"
} ]
}
}
The AS processes this and determines that the RO needs to interact. The AS determines that it can reach the identified user asynchronously and that the identified user does have the ability to approve this request. The AS indicates to the client instance that it can poll for continuation.
ASはこれを処理し、ROが相互作用する必要があると判断します。ASは、特定されたユーザーに非同期に到達できること、および識別されたユーザーがこのリクエストを承認する機能を持っていることを決定します。ASは、クライアントインスタンスに継続のために投票できることを示しています。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"continue": {
"access_token": {
"value": "80UPRY5NM33OMUKMKSKU"
},
"uri": "https://server.example.com/continue",
"wait": 60
}
}
The AS reaches out to the RO and prompts them for consent. In this example scenario, the AS has an application that it can push notifications to for the specified account.
AsはROに手を伸ばし、同意を求めます。この例のシナリオでは、ASには、指定されたアカウントの通知をプッシュできるアプリケーションがあります。
Meanwhile, the client instance periodically polls the AS every 60 seconds at the continuation URI.
一方、クライアントインスタンスは、継続URIで60秒ごとに定期的にポーリングします。
POST /continue HTTP/1.1
Host: server.example.com
Authorization: GNAP 80UPRY5NM33OMUKMKSKU
Signature-Input: sig1=...
Signature: sig1=...
The AS retrieves the pending request based on the continuation access token and determines that it has not yet been authorized. The AS indicates to the client instance that no access token has yet been issued but it can continue to call after another 60-second timeout.
ASは、継続アクセストークンに基づいて保留中の要求を取得し、まだ承認されていないと判断します。ASは、クライアントインスタンスに、アクセストークンがまだ発行されていないことを示していますが、さらに60秒のタイムアウト後も呼び出し続ける可能性があります。
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"continue": {
"access_token": {
"value": "BI9QNW6V9W3XFJK4R02D"
},
"uri": "https://server.example.com/continue",
"wait": 60
}
}
Note that the continuation access token value has been rotated since it was used by the client instance to make this call. The client instance polls the continuation URI after a 60-second timeout using the new token.
継続アクセストークン値は、クライアントインスタンスがこの呼び出しを行うために使用されたため、回転していることに注意してください。クライアントインスタンスは、新しいトークンを使用した60秒のタイムアウトの後、継続URIを投票します。
POST /continue HTTP/1.1
Host: server.example.com
Authorization: GNAP BI9QNW6V9W3XFJK4R02D
Signature-Input: sig1=...
Signature: sig1=...
The AS retrieves the pending request based on the handle, determines that it has been approved, and issues an access token.
ASは、ハンドルに基づいて保留中のリクエストを取得し、承認されたことを決定し、アクセストークンを発行します。
NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token": {
"value": "OS9M2PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
"manage": "https://server.example.com/token/PRY5NM33O\
M4TB8N6BW7OZB8CDFONP219RP1L",
"access": [
"dolphin-metadata", "some other thing"
]
}
}
While GNAP is not designed to be directly compatible with OAuth 2.0 [RFC6749], considerations have been made to enable the use of OAuth 2.0 concepts and constructs more smoothly within GNAP.
GNAPはOAUTH 2.0 [RFC6749]と直接互換性があるように設計されていませんが、GNAP内でOAUTH 2.0の概念とよりスムーズに構築できるようにするために考慮されています。
In this scenario, the client developer has a client_id and set of scope values from their OAuth 2.0 system and wants to apply them to the new protocol. In OAuth 2.0, the client developer would put their client_id and scope values as parameters into a redirect request to the authorization endpoint.
このシナリオでは、クライアント開発者はOAUTH 2.0システムのクライアント_IDとスコープ値のセットを持ち、それらを新しいプロトコルに適用したいと考えています。OAUTH 2.0では、クライアント開発者は、クライアント_IDとスコープ値をパラメーターとして承認エンドポイントにリダイレクトリクエストに配置します。
NOTE: '\' line wrapping per RFC 8792
HTTP 302 Found
Location: https://server.example.com/authorize\
?client_id=7C7C4AZ9KHRS6X63AJAO\
&scope=read%20write%20dolphin\
&redirect_uri=https://client.example.net/return\
&response_type=code\
&state=123455
Now the developer wants to make an analogous request to the AS using GNAP. To do so, the client instance makes an HTTP POST and places the OAuth 2.0 values in the appropriate places.
これで、開発者はGNAPを使用してASに類似したリクエストを行いたいと考えています。そのために、クライアントインスタンスはHTTP投稿を作成し、OAUTH 2.0値を適切な場所に配置します。
POST /tx HTTP/1.1
Host: server.example.com
Content-Type: application/json
Signature-Input: sig1=...
Signature: sig1=...
Content-Digest: sha-256=...
{
"access_token": {
"access": [
"read", "write", "dolphin"
],
"flags": [ "bearer" ]
},
"client": "7C7C4AZ9KHRS6X63AJAO",
"interact": {
"start": ["redirect"],
"finish": {
"method": "redirect",
"uri": "https://client.example.net/return?state=123455",
"nonce": "LKLTI25DK82FX4T4QFZC"
}
}
}
The client_id can be used to identify the client instance's keys that it uses for authentication, the scopes represent resources that the client instance is requesting, and the redirect_uri and state value are pre-combined into a finish URI that can be unique per request. The client instance additionally creates a nonce to protect the callback, separate from the state parameter that it has added to its return URI.
client_idを使用して、認証に使用するクライアントインスタンスのキーを識別することができます。スコープは、クライアントインスタンスが要求しているリソースを表し、Redirect_uriと状態値は、リクエストごとに一意にできるフィニッシュURIに事前に結合されます。クライアントインスタンスは、return URIに追加された状態パラメーターとは別に、コールバックを保護するためにノンセを作成します。
From here, the protocol continues as above.
ここから、プロトコルは上記のように続きます。
The GNAP specification has many different modes, options, and mechanisms, allowing it to solve a wide variety of problems in a wide variety of deployments. The wide applicability of GNAP makes it difficult, if not impossible, to define a set of mandatory-to-implement features, since one environment's required feature would be impossible to do in another environment. While this is a large problem in many systems, GNAP's back-and-forth negotiation process allows parties to declare at runtime everything that they support and then have the other party select from that the subset of items that they also support, leading to functional compatibility in many parts of the protocol even in an open world scenario.
GNAP仕様には、さまざまなモード、オプション、およびメカニズムがあり、さまざまな展開でさまざまな問題を解決できます。GNAPの幅広い適用性は、不可能ではないにしても、1つの環境の必要な機能を別の環境で行うことは不可能であるため、不可能ではないにしても困難になります。これは多くのシステムで大きな問題ですが、GNAPの前後の交渉プロセスにより、当事者は実行時にサポートするすべてのものを宣言し、他のパーティにサポートするアイテムのサブセットから選択し、機能的互換性につながることができます。オープンな世界のシナリオでも、プロトコルの多くの部分で。
In addition, GNAP defines a set of interoperability profiles that gather together core requirements to fix options into common configurations that are likely to be useful to large populations of similar applications.
さらに、GNAPは、類似のアプリケーションの大部分に役立つ可能性が高い一般的な構成にオプションを修正するために、コア要件をまとめる一連の相互運用性プロファイルを定義します。
Conformant AS implementations of these profiles MUST implement at least the features as specified in the profile and MAY implement additional features or profiles. Conformant client implementations of these profiles MUST implement at least the features as specified, except where a subset of the features allows the protocol to function (such as using polling instead of a push finish method for the Secondary Device profile).
これらのプロファイルの実装としての適合性は、少なくともプロファイルで指定されている機能を実装し、追加の機能またはプロファイルを実装する必要があります。これらのプロファイルのコンフォーマントクライアント実装は、少なくとも指定された機能を実装する必要があります。ただし、機能のサブセットがプロトコルを機能させる場合（セカンダリデバイスプロファイルのプッシュ仕上げメソッドの代わりにポーリングを使用するなど）。
Implementations conformant to the web-based redirection profile of GNAP MUST implement all of the following features:
GNAPのWebベースのリダイレクトプロファイルに準拠した実装は、次のすべての機能を実装する必要があります。
* Interaction Start Methods: redirect
* 相互作用開始方法：リダイレクト
* Interaction Finish Methods: redirect
* インタラクション仕上げ方法：リダイレクト
* Interaction Hash Algorithms: sha-256
* 相互作用ハッシュアルゴリズム：SHA-256
* Key Proofing Methods: httpsig with no additional parameters
* 主要な校正方法：追加のパラメーターがないHTTPSIG
* Key Formats: jwks with signature algorithm included in the key's alg parameter
* キー形式：キーのアルグパラメーターに含まれる署名アルゴリズムを備えたJWK
* JOSE Signature Algorithm: PS256
* ホセ署名アルゴリズム：PS256
* Subject Identifier Formats: opaque
* サブジェクト識別子形式：不透明
* Assertion Formats: id_token
* アサーション形式：ID_TOKEN
Implementations conformant to the Secondary Device profile of GNAP MUST implement all of the following features:
GNAPのセカンダリデバイスプロファイルに準拠する実装は、次のすべての機能を実装する必要があります。
* Interaction Start Methods: user_code and user_code_uri
* インタラクション開始方法：user_codeとuser_code_uri
* Interaction Finish Methods: push
* インタラクション仕上げ方法：プッシュ
* Interaction Hash Algorithms: sha-256
* 相互作用ハッシュアルゴリズム：SHA-256
* Key Proofing Methods: httpsig with no additional parameters
* 主要な校正方法：追加のパラメーターがないHTTPSIG
* Key Formats: jwks with signature algorithm included in the key's alg parameter
* キー形式：キーのアルグパラメーターに含まれる署名アルゴリズムを備えたJWK
* JOSE Signature Algorithm: PS256
* ホセ署名アルゴリズム：PS256
* Subject Identifier Formats: opaque
* サブジェクト識別子形式：不透明
* Assertion Formats: id_token
* アサーション形式：ID_TOKEN
Extensions to this specification have a variety of places to alter the protocol, including many fields and objects that can have additional values in a registry (Section 10) established by this specification. For interoperability and to preserve the security of the protocol, extensions should register new values with IANA by following the specified mechanism. While it may technically be possible to extend the protocol by adding elements to JSON objects that are not governed by an IANA registry, a recipient may ignore such values but is also allowed to reject them.
この仕様の拡張には、この仕様によって確立されたレジストリ（セクション10）に追加の値を持つことができる多くのフィールドやオブジェクトなど、プロトコルを変更するさまざまな場所があります。相互運用性とプロトコルのセキュリティを維持するために、拡張機能は指定されたメカニズムに従ってIANAに新しい値を登録する必要があります。IANAレジストリによって支配されていないJSONオブジェクトに要素を追加することにより、プロトコルを技術的に拡張することが可能かもしれませんが、受信者はそのような値を無視するかもしれませんが、それらを拒否することもできます。
Most object fields in GNAP are specified with types, and those types can allow different but related behavior. For example, the access array can include either strings or objects, as discussed in Section 8. The use of JSON polymorphism (Appendix E) within GNAP allows extensions to define new fields by not only choosing a new name but also by using an existing name with a new type. However, the extension's definition of a new type for a field needs to fit the same kind of item being extended. For example, a hypothetical extension could define a string value for the access_token request field, with a URL to download a hosted access token request. Such an extension would be appropriate as the access_token field still defines the access tokens being requested. However, if an extension were to define a string value for the access_token request field, with the value instead being something unrelated to the access token request such as a value or key format, this would not be an appropriate means of extension. (Note that this specific extension example would create another form of SSRF attack surface as discussed in Section 11.34.)
GNAPのほとんどのオブジェクトフィールドはタイプで指定されており、これらのタイプは異なるが関連する動作を可能にすることができます。たとえば、セクション8で説明したように、アクセス配列には文字列またはオブジェクトのいずれかを含めることができます。GNAP内のJSON多型（付録E）の使用により、新しい名前を選択するだけでなく、既存の名前を使用して新しいフィールドを定義できるようになります。新しいタイプで。ただし、フィールドの新しいタイプの拡張機能の定義は、同じ種類のアイテムを拡張する必要があります。たとえば、仮説的な拡張機能は、HOSTED ACCESS TOKERリクエストをダウンロードするURLを使用して、Access_Tokenリクエストフィールドの文字列値を定義できます。Access_Tokenフィールドは、要求されているアクセストークンをまだ定義しているため、このような拡張機能が適切です。ただし、拡張子がAccess_Tokenリクエストフィールドの文字列値を定義する場合、値は値やキー形式などのアクセストークン要求とは無関係なものである場合、これは適切な拡張手段ではありません。（この特定の拡張例は、セクション11.34で説明したように、SSRF攻撃面の別の形式を作成することに注意してください。）
As another example, both interaction start modes (Section 2.5.1) and key proofing methods (Section 7.3) can be defined as either strings or objects. An extension could take a method defined as a string, such as app, and define an object-based version with additional parameters. This extension should still define a method to launch an application on the end user's device, just like app does when specified as a string.
別の例として、相互作用の開始モード（セクション2.5.1）とキープルーフ方法（セクション7.3）の両方が、文字列またはオブジェクトのいずれかとして定義できます。拡張機能は、アプリなどの文字列として定義されたメソッドを使用し、追加のパラメーターを持つオブジェクトベースのバージョンを定義できます。この拡張子は、文字列として指定されたときにAPPが行うのと同じように、エンドユーザーのデバイスでアプリケーションを起動する方法を定義する必要があります。
Additionally, the ability to deal with different types for a field is not expected to be equal between an AS and client software, with the client software being assumed to be both more varied and more simplified than the AS. Furthermore, the nature of the negotiation process in GNAP allows the AS more chance of recovery from unknown situations and parameters. As such, any extensions that change the type of any field returned to a client instance should only do so when the client instance has indicated specific support for that extension through some kind of request parameter.
さらに、フィールドの異なるタイプを処理する機能は、ASとクライアントソフトウェアの間で等しくなるとは予想されていません。クライアントソフトウェアは、ASよりも多様で単純化されていると想定されています。さらに、GNAPの交渉プロセスの性質により、未知の状況やパラメーターから回復する可能性が高くなります。そのため、クライアントインスタンスに返されるフィールドのタイプを変更する拡張機能は、クライアントインスタンスが何らかのリクエストパラメーターを介してその拡張機能の特定のサポートを示している場合にのみ、そうする必要があります。
GNAP makes use of polymorphism within the JSON [RFC8259] structures used for the protocol. Each portion of this protocol is defined in terms of the JSON data type that its values can take, whether it's a string, object, array, boolean, or number. For some fields, different data types offer different descriptive capabilities and are used in different situations for the same field. Each data type provides a different syntax to express the same underlying semantic protocol element, which allows for optimization and simplification in many common cases.
GNAPは、プロトコルに使用されるJSON [RFC8259]構造内の多型を使用します。このプロトコルの各部分は、文字列、オブジェクト、配列、ブール波、または数字であろうと、その値がとることができるJSONデータ型の観点から定義されます。一部のフィールドでは、さまざまなデータ型が異なる記述機能を提供し、同じフィールドのさまざまな状況で使用されます。各データ型は、同じ基礎となるセマンティックプロトコル要素を表現するための異なる構文を提供します。これにより、多くの一般的なケースで最適化と簡素化が可能になります。
Even though JSON is often used to describe strongly typed structures, JSON on its own is naturally polymorphic. In JSON, the named members of an object have no type associated with them, and any data type can be used as the value for any member. In practice, each member has a semantic type that needs to make sense to the parties creating and consuming the object. Within this protocol, each object member is defined in terms of its semantic content, and this semantic content might have expressions in different concrete data types for different specific purposes. Since each object member has exactly one value in JSON, each data type for an object member field is naturally mutually exclusive with other data types within a single JSON object.
JSONは強く型付けされた構造を記述するためによく使用されますが、JSON自体は自然に多型です。JSONでは、オブジェクトの指名されたメンバーにはそれらに関連付けられたタイプがなく、データタイプはすべてのメンバーの値として使用できます。実際には、各メンバーには、オブジェクトを作成および消費する当事者にとって意味をなす必要があるセマンティックタイプがあります。このプロトコル内では、各オブジェクトメンバーはセマンティックコンテンツの観点から定義されており、このセマンティックコンテンツには、さまざまな特定の目的で異なる具体的なデータ型に式がある場合があります。各オブジェクトメンバーはJSONで正確に1つの値を持っているため、オブジェクトメンバーフィールドの各データ型は、単一のJSONオブジェクト内の他のデータ型と自然に相互に排他的です。
For example, a resource request for a single access token is composed of an object of resource request descriptions, while a request for multiple access tokens is composed of an array whose member values are all objects. Both of these represent requests for access, but the difference in syntax allows the client instance and AS to differentiate between the two request types in the same request.
たとえば、単一のアクセストークンのリソース要求は、リソース要求の説明のオブジェクトで構成されていますが、複数アクセストークンのリクエストは、メンバー値がすべてオブジェクトである配列で構成されます。これらはどちらもアクセスの要求を表していますが、構文の違いにより、クライアントインスタンスが可能になり、同じ要求の2つの要求タイプを区別できます。
Another form of polymorphism in JSON comes from the fact that the values within JSON arrays need not all be of the same JSON data type. However, within this protocol, each element within the array needs to be of the same kind of semantic element for the collection to make sense, even when the data types are different from each other.
JSONの別の形式の多型は、JSONアレイ内の値がすべて同じJSONデータ型である必要はないという事実に由来しています。ただし、このプロトコル内では、配列内の各要素は、データ型が互いに異なる場合でも、コレクションが意味をなさないために同じ種類の意味要素である必要があります。
For example, each aspect of a resource request can be described using an object with multiple dimensional components, or the aspect can be requested using a string. In both cases, the resource request is being described in a way that the AS needs to interpret, but with different levels of specificity and complexity for the client instance to deal with. An API designer can provide a set of common access scopes as simple strings but still allow client software developers to specify custom access when needed for more complex APIs.
たとえば、リソース要求の各側面は、複数の寸法コンポーネントを持つオブジェクトを使用して説明することができます。または、文字列を使用してアスペクトを要求できます。どちらの場合も、リソース要求は、ASが解釈する必要がある方法で説明されていますが、クライアントインスタンスが対処するための特異性と複雑さのレベルが異なります。APIデザイナーは、単純な文字列として共通アクセススコープのセットを提供できますが、より複雑なAPIに必要なときにクライアントソフトウェア開発者がカスタムアクセスを指定できるようにします。
Extensions to this specification can use different data types for defined fields, but each extension needs to not only declare what the data type means but also provide justification for the data type representing the same basic kind of thing it extends. For example, an extension declaring an "array" representation for a field would need to explain how the array represents something akin to the non-array element that it is replacing. See additional discussion in Appendix D.
この仕様の拡張は、定義されたフィールドに異なるデータ型を使用できますが、各拡張機能は、データ型の意味を宣言するだけでなく、拡張する同じ基本的なものを表すデータ型の正当化も提供する必要があります。たとえば、フィールドの「配列」表現を宣言する拡張機能は、配列が置き換えられている非アレイ要素に似たものをどのように表すかを説明する必要があります。付録Dで追加の議論を参照してください
The authors would like to thank the following individuals for their reviews, implementations, and contributions: Åke Axeland, Aaron Parecki, Adam Omar Oueidat, Andrii Deinega, Annabelle Backman, Dick Hardt, Dmitri Zagidulin, Dmitry Barinov, Florian Helmschmidt, Francis Pouatcha, George Fletcher, Haardik Haardik, Hamid Massaoud, Jacky Yuan, Joseph Heenan, Kathleen Moriarty, Leif Johansson, Mike Jones, Mike Varley, Nat Sakimura, Takahiko Kawasaki, Takahiro Tsuchiya, and Yaron Sheffer.
著者は、以下の個人にレビュー、実装、貢献について感謝したいと思います：ÅkeAxanled、Aaron Parecki、Adam Omar Oueidat、Andrii Deinega、Annabelle Backman、Dick Hardt、Dmitri Zagidulin、Dmitry Barinov、Florian Helmschmidt、Francis Pouatcha、Georgeフレッチャー、ハーディク・ハーディク、ハミド・マッサウド、ジャッキー・ユアン、ジョセフ・ヒーナン、キャスリーン・モリアーティ、レイフ・ヨハンソン、マイク・ジョーンズ、マイク・ヴァーリー、ナット・サキムラ、川崎川崎、高地ツキヤ、ヤロン・シェファー。
The authors would also like to thank the GNAP Working Group design team (Kathleen Moriarty, Dick Hardt, Mike Jones, and the authors), who incorporated elements from the XAuth and XYZ proposals to create the first draft version of this document.
著者はまた、XauthとXYZの提案を組み込んだこのドキュメントの最初のドラフトバージョンを作成するためにXyzの要素を取り入れたGNAPワーキンググループデザインチーム（Kathleen Moriarty、Dick Hardt、Mike Jones、および著者）にも感謝したいと思います。
In addition, the authors would like to thank Aaron Parecki and Mike Jones for insights into how to integrate identity and authentication systems into the core protocol. Both Justin Richer and Dick Hardt developed the use cases, diagrams, and insights provided in the XYZ and XAuth proposals that have been incorporated here. The authors would like to especially thank Mike Varley and the team at SecureKey for feedback and development of early versions of the XYZ protocol that fed into this standards work.
さらに、著者は、アイデンティティと認証システムをコアプロトコルに統合する方法に関する洞察について、アーロンパレッキとマイクジョーンズに感謝します。Justin RicherとDick Hardtの両方が、ここに組み込まれているXyzとXauthの提案で提供されているユースケース、図、および洞察を開発しました。著者は、この標準作業に供給されたXYZプロトコルの初期バージョンのフィードバックと開発について、特にMike VarleyとSecureKeyのチームに感謝します。
Finally, the authors 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.
最後に、著者は、この文書の内容に対するアーロン・パレッキの計り知れない貢献を認めたいと考えています。私たちは彼の洞察、意見、勤勉に感謝しますが、それなしでは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/