[要約] RFC 9200は、リソース制約環境での認証と認可をOAuth 2.0フレームワークを使用して実現するACE-OAuthに関するものです。この文書の目的は、限られたリソースを持つデバイス間でのセキュアな通信を可能にすることです。主に、IoTデバイスや組み込みシステムなど、リソースが限られている環境で利用されます。
Internet Engineering Task Force (IETF) L. Seitz
Request for Comments: 9200 Combitech
Category: Standards Track G. Selander
ISSN: 2070-1721 Ericsson
E. Wahlstroem
S. Erdtman Spotify AB H. Tschofenig Arm Ltd. August 2022
S. Erdtman Spotify AB H. Tschofenig Arm Ltd. 2022年8月
Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)
OAUTH 2.0フレームワーク（ACE-OAUTH）を使用した制約された環境の認証と承認
Abstract
概要
This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases.
この仕様は、ACE-Oauthと呼ばれるモノのインターネット（IoT）環境での認証と認証のフレームワークを定義します。フレームワークは、OAUTH 2.0および制約付きアプリケーションプロトコル（COAP）を含む一連のビルディングブロックに基づいているため、よく知られている広く使用されている承認ソリューションをIoTデバイスに適した形式に変換します。可能な場合は既存の仕様が使用されますが、拡張機能が追加され、IoTのユースケースにより適切に対応するためにプロファイルが定義されています。
Status of This Memo
本文書の位置付け
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/rfc9200.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9200で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology
3. Overview
3.1. OAuth 2.0
3.2. CoAP
4. Protocol Interactions
5. Framework
5.1. Discovering Authorization Servers
5.2. Unauthorized Resource Request Message
5.3. AS Request Creation Hints
5.3.1. The Client-Nonce Parameter
5.4. Authorization Grants
5.5. Client Credentials
5.6. AS Authentication
5.7. The Authorization Endpoint
5.8. The Token Endpoint
5.8.1. Client-to-AS Request
5.8.2. AS-to-Client Response
5.8.3. Error Response
5.8.4. Request and Response Parameters
5.8.4.1. Grant Type
5.8.4.2. Token Type
5.8.4.3. Profile
5.8.4.4. Client-Nonce
5.8.5. Mapping Parameters to CBOR
5.9. The Introspection Endpoint
5.9.1. Introspection Request
5.9.2. Introspection Response
5.9.3. Error Response
5.9.4. Mapping Introspection Parameters to CBOR
5.10. The Access Token
5.10.1. The Authorization Information Endpoint
5.10.1.1. Verifying an Access Token
5.10.1.2. Protecting the Authorization Information Endpoint
5.10.2. Client Requests to the RS
5.10.3. Token Expiration
5.10.4. Key Expiration
6. Security Considerations
6.1. Protecting Tokens
6.2. Communication Security
6.3. Long-Term Credentials
6.4. Unprotected AS Request Creation Hints
6.5. Minimal Security Requirements for Communication
6.6. Token Freshness and Expiration
6.7. Combining Profiles
6.8. Unprotected Information
6.9. Identifying Audiences
6.10. Denial of Service Against or with Introspection
7. Privacy Considerations
8. IANA Considerations
8.1. ACE Authorization Server Request Creation Hints
8.2. CoRE Resource Types
8.3. OAuth Extensions Errors
8.4. OAuth Error Code CBOR Mappings
8.5. OAuth Grant Type CBOR Mappings
8.6. OAuth Access Token Types
8.7. OAuth Access Token Type CBOR Mappings
8.7.1. Initial Registry Contents
8.8. ACE Profiles
8.9. OAuth Parameters
8.10. OAuth Parameters CBOR Mappings
8.11. OAuth Introspection Response Parameters
8.12. OAuth Token Introspection Response CBOR Mappings
8.13. JSON Web Token Claims
8.14. CBOR Web Token Claims
8.15. Media Type Registration
8.16. CoAP Content-Formats
8.17. Expert Review Instructions
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Design Justification
Appendix B. Roles and Responsibilities
Appendix C. Requirements on Profiles
Appendix D. Assumptions on AS Knowledge about the C and RS
Appendix E. Differences to OAuth 2.0
Appendix F. Deployment Examples
F.1. Local Token Validation
F.2. Introspection Aided Token Validation
Acknowledgments
Authors' Addresses
Authorization is the process for granting approval to an entity to access a generic resource [RFC4949]. The authorization task itself can best be described as granting access to a requesting client for a resource hosted on a device, i.e., the resource server (RS). This exchange is mediated by one or multiple authorization servers (ASes). Managing authorization for a large number of devices and users can be a complex task.
認可は、一般的なリソースにアクセスするためのエンティティに承認を付与するプロセスです[RFC4949]。承認タスク自体は、デバイスでホストされているリソース、つまりリソースサーバー（RS）のリクエストクライアントへのアクセスを許可するものとして最もよく説明できます。この交換は、1つまたは複数の承認サーバー（ASE）によって媒介されます。多数のデバイスとユーザーの許可を管理することは、複雑なタスクになる可能性があります。
While prior work on authorization solutions for the Web and for the mobile environment also applies to the Internet of Things (IoT) environment, many IoT devices are constrained, for example, in terms of processing capabilities, available memory, etc. For such devices, the Constrained Application Protocol (CoAP) [RFC7252] can alleviate some resource concerns when used instead of HTTP to implement the communication flows of this specification.
Webおよびモバイル環境向けの認可ソリューションに関する事前の作業は、モノのインターネット（IoT）環境にも適用されますが、たとえば、処理機能、利用可能なメモリなどの点で多くのIoTデバイスが制約されています。制約付きアプリケーションプロトコル（COAP）[RFC7252]は、HTTPの代わりに使用する場合、この仕様の通信フローを実装する場合、いくつかのリソースの懸念を軽減できます。
Appendix A gives an overview of the constraints considered in this design, and a more detailed treatment of constraints can be found in [RFC7228]. This design aims to accommodate different IoT deployments as well as a continuous range of device and network capabilities. Taking energy consumption as an example, at one end, there are energy-harvesting or battery-powered devices that have a tight power budget; on the other end, there are mains-powered devices; and all levels exist in between.
付録Aでは、この設計で考慮された制約の概要を示し、[RFC7228]には、より詳細な制約の処理があります。この設計は、さまざまなIoT展開と、継続的な範囲のデバイスとネットワーク機能に対応することを目的としています。エネルギー消費量を例にとると、一方では、電力予算が厳しいエネルギー収穫またはバッテリー駆動のデバイスがあります。一方、主電源装置のデバイスがあります。そして、すべてのレベルがその間に存在します。
Hence, IoT devices may be very different in terms of available processing and message exchange capabilities, and there is a need to support many different authorization use cases [RFC7744].
したがって、IoTデバイスは、利用可能な処理とメッセージ交換機能の点で非常に異なる場合があり、多くの異なる認証ユースケースをサポートする必要があります[RFC7744]。
This specification describes a framework for Authentication and Authorization for Constrained Environments (ACE) built on reuse of OAuth 2.0 [RFC6749], thereby extending authorization to Internet of Things devices. This specification contains the necessary building blocks for adjusting OAuth 2.0 to IoT environments.
この仕様は、OAUTH 2.0 [RFC6749]の再利用に基づいて構築された制約環境（ACE）の認証と承認のフレームワークを説明し、それにより、モノのインターネットデバイスに承認を拡張します。この仕様には、OAUTH 2.0をIoT環境に調整するために必要なビルディングブロックが含まれています。
Profiles of this framework are available in separate specifications, such as [RFC9202] or [RFC9203]. Such profiles may specify the use of the framework for a specific security protocol and the underlying transports for use in a specific deployment environment to improve interoperability. Implementations may claim conformance with a specific profile, whereby implementations utilizing the same profile interoperate, while implementations of different profiles are not expected to be interoperable. More powerful devices, such as mobile phones and tablets, may implement multiple profiles and will therefore be able to interact with a wider range of constrained devices. Requirements on profiles are described at contextually appropriate places throughout this specification and also summarized in Appendix C.
このフレームワークのプロファイルは、[RFC9202]や[RFC9203]などの別々の仕様で入手できます。このようなプロファイルは、特定のセキュリティプロトコルと、特定の展開環境で使用するための基礎となるトランスポートのフレームワークの使用を指定して、相互運用性を向上させることができます。実装は、特定のプロファイルに適合していると主張する場合があります。これにより、同じプロファイルを使用して実装が相互操作されますが、異なるプロファイルの実装は相互運用可能ではありません。携帯電話やタブレットなどのより強力なデバイスは、複数のプロファイルを実装する可能性があるため、より幅広い制約付きデバイスと対話できます。プロファイルの要件は、この仕様全体で文脈的に適切な場所で説明されており、付録Cにも要約されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Certain security-related terms, such as "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify", are taken from [RFC4949].
「認証」、「承認」、「機密性」、「データ）整合性」、「メッセージ認証コード」、「検証」などの特定のセキュリティ関連の用語は、[RFC4949]から取得されます。
Since exchanges in this specification are described as RESTful protocol interactions, HTTP [RFC9110] offers useful terminology. (Note that "RESTful" refers to the Representational State Transfer (REST) architecture.)
この仕様の交換はRestfulプロトコル相互作用として説明されているため、HTTP [RFC9110]は有用な用語を提供します。（「Restful」とは、表現状態転送（REST）アーキテクチャを指します。）
Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749], such as client (C), resource server (RS), and authorization server (AS).
アーキテクチャ内のエンティティの用語は、クライアント（c）、リソースサーバー（RS）、認証サーバー（AS）などのOAUTH 2.0 [RFC6749]で定義されています。
Note that the term "endpoint" is used here following its OAuth definition, which is to denote resources, such as token and introspection at the AS and authz-info at the RS (see Section 5.10.1 for a definition of the authz-info endpoint). The CoAP definition, which is "[a]n entity participating in the CoAP protocol" [RFC7252], is not used in this specification.
「エンドポイント」という用語は、OAuthの定義に従って使用されていることに注意してください。これは、ASでのトークンや内省などのリソースを示しています。終点）。「COAPプロトコルに参加している[A] nエンティティ」[RFC7252]であるCOAP定義は、この仕様では使用されていません。
The specification in this document is called the "framework" or "ACE framework". When referring to "profiles of this framework", it refers to additional specifications that define the use of this specification with concrete transport and communication security protocols (e.g., CoAP over DTLS).
このドキュメントの仕様は、「フレームワーク」または「ACEフレームワーク」と呼ばれます。「このフレームワークのプロファイル」を参照する場合、この仕様の使用を具体的な輸送および通信セキュリティプロトコル（例：DTLSのコップ）で定義する追加の仕様を指します。
The term "Access Information" is used for parameters, other than the access token, provided to the client by the AS to enable it to access the RS (e.g., public key of the RS or profile supported by RS).
「アクセス情報」という用語は、RS（たとえば、RSの公開キーまたはRSでサポートされているプロファイル）にアクセスできるように、クライアントに提供されるアクセストークン以外のパラメーターに使用されます。
The term "authorization information" is used to denote all information, including the claims of relevant access tokens, that an RS uses to determine whether an access request should be granted.
「承認情報」という用語は、関連するアクセストークンの主張を含むすべての情報を示すために使用されます。RSは、アクセス要求を許可するかどうかを判断するために使用します。
Throughout this document, examples for CBOR data items are expressed in CBOR extended diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610] ("diagnostic notation"), unless noted otherwise. We often use diagnostic notation comments to provide a textual representation of the numeric parameter names and values.
このドキュメント全体で、CBORデータ項目の例は、[RFC8949]のセクション8および[RFC8610]の付録G（「診断表記」）の付録Gで定義されているように、CBOR拡張診断表記で表されます。診断表記コメントを使用して、数値パラメーター名と値のテキスト表現を提供します。
This specification defines the ACE framework for authorization in the Internet of Things environment. It consists of a set of building blocks.
この仕様は、モノのインターネット環境での認可のためのACEフレームワークを定義しています。ビルディングブロックのセットで構成されています。
The basic block is the OAuth 2.0 [RFC6749] framework, which enjoys widespread deployment. Many IoT devices can support OAuth 2.0 without any additional extensions, but for certain constrained settings, additional profiling is needed.
基本ブロックは、OAUTH 2.0 [RFC6749]フレームワークで、広範囲にわたる展開を楽しんでいます。多くのIoTデバイスは、追加の拡張機能なしでOAUTH 2.0をサポートできますが、特定の制約された設定では、追加のプロファイリングが必要です。
Another building block is the lightweight web transfer protocol CoAP [RFC7252], for those communication environments where HTTP is not appropriate. CoAP typically runs on top of UDP, which further reduces overhead and message exchanges. While this specification defines extensions for the use of OAuth over CoAP, other underlying protocols are not prohibited from being supported in the future, such as HTTP/2 [RFC9113], Message Queuing Telemetry Transport (MQTT) [MQTT5.0], Bluetooth Low Energy (BLE) [BLE], and QUIC [RFC9000]. Note that this document specifies protocol exchanges in terms of RESTful verbs, such as GET and POST. Future profiles using protocols that do not support these verbs MUST specify how the corresponding protocol messages are transmitted instead.
別のビルディングブロックは、HTTPが適切でない通信環境のための軽量Web転送プロトコルCoAP [RFC7252]です。COAPは通常、UDPの上で実行され、オーバーヘッドとメッセージ交換がさらに減少します。この仕様では、COAPよりもOAuthを使用するための拡張機能を定義していますが、他の基礎となるプロトコルは、HTTP/2 [RFC9113]など、将来サポートされることを禁止されていません。エネルギー（BLE）[BLE]、およびQUIC [RFC9000]。このドキュメントは、GetやPostなどの安らかな動詞の観点からプロトコル交換を指定していることに注意してください。これらの動詞をサポートしないプロトコルを使用して将来のプロファイルは、代わりに対応するプロトコルメッセージの送信方法を指定する必要があります。
A third building block is the Concise Binary Object Representation (CBOR) [RFC8949], for encodings where JSON [RFC8259] is not sufficiently compact. CBOR is a binary encoding designed for small code and message size. Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used. When CoAP is not used, the use of CBOR remains RECOMMENDED.
3番目のビルディングブロックは、JSON [RFC8259]が十分にコンパクトではないエンコーディング用の簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]です。CBORは、小さなコードとメッセージサイズ用に設計されたバイナリエンコードです。COAPが使用されると、自己完結型トークンとプロトコルメッセージペイロードがCBORでエンコードされます。COAPが使用されない場合、CBORの使用は引き続き推奨されます。
A fourth building block is CBOR Object Signing and Encryption (COSE) [RFC8152], which enables object-level layer security as an alternative or complement to transport layer security (DTLS [RFC6347] [RFC9147] or TLS [RFC8446]). COSE is used to secure self-contained tokens, such as proof-of-possession (PoP) tokens, which are an extension to the OAuth bearer tokens. The default token format is defined in CBOR Web Token (CWT) [RFC8392]. Application-layer security for CoAP using COSE can be provided with Object Security for Constrained RESTful Environments (OSCORE) [RFC8613].
4番目のビルディングブロックは、CBORオブジェクトの署名と暗号化（COSE）[RFC8152]であり、これにより、層のセキュリティを輸送する代替または補完としてオブジェクトレベルのレイヤーセキュリティが可能になります（DTLS [RFC6347] [RFC9147]またはTLS [RFC8446]）。COSEは、Oauth Bearer Tokensの拡張であるProof-of-Possession（POP）トークンなど、自己完結型トークンを確保するために使用されます。デフォルトのトークン形式は、CBOR Webトークン（CWT）[RFC8392]で定義されています。COSを使用したCOAPのアプリケーションレイヤーセキュリティには、制約されたRESTFUL環境（OSCORE）[RFC8613]のオブジェクトセキュリティを提供できます。
With the building blocks listed above, solutions satisfying various IoT device and network constraints are possible. A list of constraints is described in detail in [RFC7228], and a description of how the building blocks mentioned above relate to the various constraints can be found in Appendix A.
上記のビルディングブロックを使用すると、さまざまなIoTデバイスとネットワークの制約を満たすソリューションが可能です。制約のリストは[RFC7228]で詳細に説明されており、上記のビルディングブロックがさまざまな制約にどのように関連しているかの説明は、付録Aにあります。
Luckily, not every IoT device suffers from all constraints. Nevertheless, the ACE framework takes all these aspects into account and allows several different deployment variants to coexist, rather than mandating a one-size-fits-all solution. It is important to cover the wide range of possible interworking use cases and the different requirements from a security point of view. Once IoT deployments mature, popular deployment variants will be documented in the form of ACE profiles.
幸いなことに、すべてのIoTデバイスがすべての制約に苦しんでいるわけではありません。それにもかかわらず、ACEフレームワークでは、これらすべての側面を考慮し、1つのサイズのすべてのソリューションを義務付けるのではなく、いくつかの異なる展開バリアントが共存できるようにします。可能な可能性のある幅広いインターワーキングユースケースと、セキュリティの観点からの異なる要件をカバーすることが重要です。IoTの展開が成熟すると、人気のある展開バリエーションがACEプロファイルの形で文書化されます。
The OAuth 2.0 authorization framework enables a client to obtain scoped access to a resource with the permission of a resource owner. Authorization information, or references to it, is passed between the nodes using access tokens. These access tokens are issued to clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
OAUTH 2.0認証フレームワークにより、クライアントはリソース所有者の許可を得てリソースへのスコープアクセスを取得できます。許可情報、またはそれへの参照は、アクセストークンを使用してノード間で渡されます。これらのアクセストークンは、リソース所有者の承認を得て、承認サーバーによってクライアントに発行されます。クライアントは、アクセストークンを使用して、リソースサーバーがホストする保護されたリソースにアクセスします。
A number of OAuth 2.0 terms are used within this specification:
この仕様内では、多くのOAUTH 2.0用語が使用されています。
Access Tokens: Access tokens are credentials needed to access protected resources. An access token is a data structure representing authorization permissions issued by the AS to the client. Access tokens are generated by the AS and consumed by the RS. The access token content is opaque to the client.
アクセストークン：アクセストークンは、保護されたリソースにアクセスするために必要な資格情報です。アクセストークンは、クライアントに関して発行された承認許可を表すデータ構造です。アクセストークンは、ASによって生成され、Rsによって消費されます。アクセストークンコンテンツは、クライアントにとって不透明です。
Access tokens can have different formats and various methods of utilization (e.g., cryptographic properties) based on the security requirements of the given deployment.
アクセストークンには、指定された展開のセキュリティ要件に基づいて、さまざまな形式とさまざまな使用方法（例えば、暗号化プロパティ）を持つことができます。
Introspection: Introspection is a method for a resource server, or potentially a client, to query the authorization server for the active state and content of a received access token. This is particularly useful in those cases where the authorization decisions are very dynamic and/or where the received access token itself is an opaque reference, rather than a self-contained token. More information about introspection in OAuth 2.0 can be found in [RFC7662].
内省：内省は、リソースサーバー、または潜在的にクライアントの方法であり、受信したアクセストークンのアクティブ状態とコンテンツの認証サーバーを照会する方法です。これは、承認の決定が非常に動的である場合、および/または受信アクセストークン自体が自己完結型トークンではなく不透明な参照である場合に特に役立ちます。OAUTH 2.0の内省の詳細については、[RFC7662]をご覧ください。
Refresh Tokens: Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token expires or to obtain additional access tokens with identical or narrower scope (such access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (B) in Figure 1).
更新トークン：リフレッシュトークンは、アクセストークンを取得するために使用される資格情報です。更新トークンは認証サーバーによってクライアントに発行され、現在のアクセストークンの有効期限が切れたときに新しいアクセストークンを取得するか、同一または狭いスコープで追加のアクセストークンを取得するために使用されます（そのようなアクセストークンは、寿命が短く、許可が少ない場合があります。リソース所有者によって許可されています）。更新トークンの発行は、認証サーバーの裁量でオプションです。Authorization Serverが更新トークンを発行する場合、アクセストークンを発行するときに含まれています（つまり、図1のステップ（b））。
A refresh token in OAuth 2.0 is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers. In this framework, refresh tokens are encoded in binary instead of strings, if used.
OAUTH 2.0の更新トークンは、リソース所有者によってクライアントに付与された承認を表す文字列です。文字列は通常、クライアントにとって不透明です。トークンは、承認情報を取得するために使用される識別子を示します。アクセストークンとは異なり、更新トークンは承認サーバーでのみ使用することを目的としており、リソースサーバーに送信されることはありません。このフレームワークでは、リフレッシュトークンは、使用する場合、文字列の代わりにバイナリでエンコードされます。
Proof-of-Possession Tokens: A token may be bound to a cryptographic key, which is then used to bind the token to a request authorized by the token. Such tokens are called proof-of-possession tokens (or PoP tokens).
Proof-of-Possession Tokens：トークンは暗号化キーにバインドされる場合があります。これは、トークンがトークンによって承認された要求にバインドするために使用されます。このようなトークンは、Proof-of-Possessionトークン（またはポップトークン）と呼ばれます。
The proof-of-possession security concept used here assumes that the AS acts as a trusted third party that binds keys to tokens. In the case of access tokens, these so-called PoP keys are then used by the client to demonstrate the possession of the secret to the RS when accessing the resource. The RS, when receiving an access token, needs to verify that the key used by the client matches the one bound to the access token. When this specification uses the term "access token", it is assumed to be a PoP access token unless specifically stated otherwise.
ここで使用されるプルーフオブポッセッションセキュリティの概念は、ASがキーをトークンに結びつける信頼できるサードパーティとして機能することを前提としています。アクセストークンの場合、これらのいわゆるポップキーを使用して、クライアントがリソースにアクセスするときにRSの秘密の所有を実証します。RSは、アクセストークンを受信するときに、クライアントが使用するキーがアクセストークンにバインドされたものと一致することを確認する必要があります。この仕様が「アクセストークン」という用語を使用する場合、特に明記されていない限り、ポップアクセストークンであると想定されます。
The key bound to the token (the PoP key) may use either symmetric or asymmetric cryptography. The appropriate choice of the kind of cryptography depends on the constraints of the IoT devices as well as on the security requirements of the use case.
トークン（ポップキー）に結合したキーは、対称または非対称の暗号化のいずれかを使用できます。暗号化の種類の適切な選択は、IoTデバイスの制約と、ユースケースのセキュリティ要件に依存します。
Symmetric PoP key: The AS generates a random, symmetric PoP key. The key is either stored to be returned on introspection calls or included in the token. Either the whole token or only the key MUST be encrypted in the latter case. The PoP key is also returned to client together with the token, protected by the secure channel.
対称ポップキー：ランダムな対称ポップキーを生成します。キーは、内省コールで返されるか、トークンに含まれるように保存されます。トークン全体またはキーのみを後者の場合に暗号化する必要があります。POPキーは、セキュアチャネルで保護されたトークンとともにクライアントに返されます。
Asymmetric PoP key: An asymmetric key pair is generated by the client and the public key is sent to the AS (if it does not already have knowledge of the client's public key). Information about the public key, which is the PoP key in this case, is either stored to be returned on introspection calls or included inside the token and sent back to the client. The resource server consuming the token can identify the public key from the information in the token, which allows the client to use the corresponding private key for the proof of possession.
非対称POPキー：非対称キーペアがクライアントによって生成され、公開キーがASに送信されます（クライアントの公開キーの知識がまだない場合）。この場合のポップキーである公開鍵に関する情報は、内省コールで返されるように保存されるか、トークン内に含まれてクライアントに送り返されます。トークンを消費するリソースサーバーは、トークン内の情報から公開キーを識別することができ、クライアントは対応する秘密鍵を使用して所有の証明に使用できます。
The token is either a simple reference or a structured information object (e.g., CWT [RFC8392]) protected by a cryptographic wrapper (e.g., COSE [RFC8152]). The choice of PoP key does not necessarily imply a specific credential type for the integrity protection of the token.
トークンは、単純な参照または構造化された情報オブジェクト（例：CWT [RFC8392]）であり、暗号化ラッパー（COSE [RFC8152]など）によって保護されています。POPキーの選択は、トークンの整合性保護のための特定の資格情報を必ずしも意味するものではありません。
Scopes and Permissions: In OAuth 2.0, the client specifies the type of permissions it is seeking to obtain (via the scope parameter) in the access token request. In turn, the AS may use the scope response parameter to inform the client of the scope of the access token issued. As the client could be a constrained device as well, this specification defines the use of CBOR encoding (see Section 5) for such requests and responses.
スコープと権限：OAUTH 2.0では、クライアントはアクセストークン要求で（スコープパラメーターを介して）取得しようとする権限のタイプを指定します。次に、ASはスコープ応答パラメーターを使用して、発行されたアクセストークンの範囲をクライアントに通知します。クライアントも制約されたデバイスになる可能性があるため、この仕様では、そのようなリクエストと応答に対してCBORエンコード（セクション5を参照）の使用を定義します。
The values of the scope parameter in OAuth 2.0 are expressed as a list of space-delimited, case-sensitive strings with a semantic that is well known to the AS and the RS. More details about the concept of scopes are found under Section 3.3 of [RFC6749].
OAUTH 2.0のスコープパラメーターの値は、ASおよびRSによく知られているセマンティックを備えたスペース削除、ケースに敏感な文字列のリストとして表されます。スコープの概念の詳細については、[RFC6749]のセクション3.3に記載されています。
Claims: Information carried in the access token or returned from introspection, called claims, is in the form of name-value pairs. An access token may, for example, include a claim identifying the AS that issued the token (via the iss claim) and what audience the access token is intended for (via the aud claim). The audience of an access token can be a specific resource, one resource, or many resource servers. The resource owner policies influence what claims are put into the access token by the authorization server.
クレーム：アクセストークンに掲載される情報、または主張と呼ばれる内省から返される情報は、名前と呼ばれるペアの形式です。たとえば、アクセストークンには、トークンを発行したAS（ISSクレームを介して）を特定するクレームと、アクセストークンが意図している視聴者（AUDクレームを介して）を識別するクレームが含まれる場合があります。アクセストークンの視聴者は、特定のリソース、1つのリソース、または多くのリソースサーバーになることができます。リソース所有者のポリシーは、承認サーバーによってアクセストークンに請求される請求に影響を与えます。
While the structure and encoding of the access token varies throughout deployments, a standardized format has been defined with the JSON Web Token (JWT) [RFC7519], where claims are encoded as a JSON object. In [RFC8392], the CBOR Web Token (CWT) has been defined as an equivalent format using CBOR encoding.
アクセストークンの構造とエンコードは展開中に異なりますが、標準化された形式はJSON Webトークン（JWT）[RFC7519]で定義されており、クレームはJSONオブジェクトとしてエンコードされています。[RFC8392]では、CBOR Webトークン（CWT）は、CBORエンコーディングを使用した同等の形式として定義されています。
Token and Introspection Endpoints: The AS hosts the token endpoint that allows a client to request access tokens. The client makes a POST request to the token endpoint on the AS and receives the access token in the response (if the request was successful).
トークンと内省のエンドポイント：ASは、クライアントがアクセストークンを要求できるトークンエンドポイントをホストします。クライアントは、ASのトークンエンドポイントにPOSTリクエストを行い、応答でアクセストークンを受信します（リクエストが成功した場合）。
In some deployments, a token introspection endpoint is provided by the AS, which can be used by the RS and potentially the client, if they need to request additional information regarding a received access token. The requesting entity makes a POST request to the introspection endpoint on the AS and receives information about the access token in the response. (See "Introspection" above.)
一部の展開では、受信アクセストークンに関する追加情報をリクエストする必要がある場合は、RSおよび潜在的にクライアントが使用できるASによってトークン内省エンドポイントが提供されます。リクエストエンティティは、ASの内省エンドポイントへの投稿要求を行い、応答のアクセストークンに関する情報を受け取ります。（上記の「内省」を参照してください。）
CoAP is an application-layer protocol similar to HTTP but specifically designed for constrained environments. CoAP typically uses datagram-oriented transport, such as UDP, where reordering and loss of packets can occur. A security solution needs to take the latter aspects into account.
COAPは、HTTPと同様のアプリケーション層プロトコルですが、制約された環境向けに特別に設計されています。COAPは通常、UDPなどのデータグラム指向のトランスポートを使用します。ここでは、パケットの並べ替えと損失が発生する可能性があります。セキュリティソリューションは、後者の側面を考慮する必要があります。
While HTTP uses headers and query strings to convey additional information about a request, CoAP encodes such information into header parameters called 'options'.
HTTPはヘッダーとクエリ文字列を使用してリクエストに関する追加情報を伝えますが、COAPはそのような情報を「オプション」と呼ばれるヘッダーパラメーターにエンコードします。
CoAP supports application-layer fragmentation of the CoAP payloads through block-wise transfers [RFC7959]. However, block-wise transfer does not increase the size limits of CoAP options; therefore, data encoded in options has to be kept small.
COAPは、ブロックごとの転送[RFC7959]を通じて、COAPペイロードのアプリケーション層の断片化をサポートしています。ただし、ブロックごとの転送は、COAPオプションのサイズ制限を増加させません。したがって、オプションでエンコードされたデータは小さくする必要があります。
Transport layer security for CoAP can be provided by DTLS or TLS [RFC6347] [RFC8446] [RFC9147]. CoAP defines a number of proxy operations that require transport layer security to be terminated at the proxy. One approach for protecting CoAP communication end-to-end through proxies, and also to support security for CoAP over a different transport in a uniform way, is to provide security at the application layer using an object-based security mechanism, such as COSE [RFC8152].
COAPの輸送層セキュリティは、DTLSまたはTLS [RFC6347] [RFC8446] [RFC9147]によって提供できます。COAPは、プロキシで輸送層のセキュリティを終了する必要がある多くのプロキシ操作を定義します。プロキシを通じてCOAP通信エンドツーエンドを保護するための1つのアプローチ、および均一な方法で異なるトランスポートを介してCOAPのセキュリティのセキュリティをサポートすることは、COSEなどのオブジェクトベースのセキュリティメカニズムを使用してアプリケーションレイヤーにセキュリティを提供することです[RFC8152]。
One application of COSE is OSCORE [RFC8613], which provides end-to-end confidentiality, integrity and replay protection, and a secure binding between CoAP request and response messages. In OSCORE, the CoAP messages are wrapped in COSE objects and sent using CoAP.
COSEの1つのアプリケーションはOSCORE [RFC8613]です。これは、エンドツーエンドの機密性、完全性とリプレイ保護を提供し、COAPリクエストと応答メッセージの間の安全な拘束力を提供します。OSCOREでは、COAPメッセージはCOSEオブジェクトに包まれ、COAPを使用して送信されます。
In this framework, the use of CoAP as replacement for HTTP is RECOMMENDED for use in constrained environments. For communication security, this framework does not make an explicit protocol recommendation, since the choice depends on the requirements of the specific application. DTLS [RFC6347] [RFC9147] and OSCORE [RFC8613] are mentioned as examples; other protocols fulfilling the requirements from Section 6.5 are also applicable.
このフレームワークでは、制約付き環境での使用には、HTTPの代替としてCOAPを使用することが推奨されます。コミュニケーションセキュリティの場合、選択は特定のアプリケーションの要件に依存するため、このフレームワークは明示的なプロトコルの推奨を行いません。DTLS [RFC6347] [RFC9147]およびOSCORE [RFC8613]が例として言及されています。セクション6.5の要件を満たす他のプロトコルも適用されます。
The ACE framework is based on the OAuth 2.0 protocol interactions using the token endpoint and optionally the introspection endpoint. A client obtains an access token, and optionally a refresh token, from an AS using the token endpoint and subsequently presents the access token to an RS to gain access to a protected resource. In most deployments, the RS can process the access token locally; however, in some cases, the RS may present it to the AS via the introspection endpoint to get fresh information. These interactions are shown in Figure 1. An overview of various OAuth concepts is provided in Section 3.1.
ACEフレームワークは、トークンエンドポイント、およびオプションで内省エンドポイントを使用したOAUTH 2.0プロトコルの相互作用に基づいています。クライアントがアクセストークンを取得し、オプションではトークンエンドポイントを使用してAsからリフレッシュトークンを取得し、その後、アクセストークンをRSに提示して、保護されたリソースへのアクセスを取得します。ほとんどの展開では、RSはアクセストークンをローカルで処理できます。ただし、場合によっては、RSは、新鮮な情報を取得するために内省エンドポイントを介してASに提示する場合があります。これらの相互作用を図1に示します。さまざまなOAUTH概念の概要をセクション3.1に示します。
+--------+ +---------------+
| |---(A)-- Token Request ------->| |
| | | Authorization |
| |<--(B)-- Access Token ---------| Server |
| | + Access Information | |
| | + Refresh Token (optional) +---------------+
| | ^ |
| | Introspection Request (D)| |
| Client | Response | |(E)
| | (optional exchange) | |
| | | v
| | +--------------+
| |---(C)-- Token + Request ----->| |
| | | Resource |
| |<--(F)-- Protected Resource ---| Server |
| | | |
+--------+ +--------------+
Figure 1: Basic Protocol Flow
図1：基本的なプロトコルフロー
Requesting an Access Token (A): The client makes an access token request to the token endpoint at the AS. This framework assumes the use of PoP access tokens (see Section 3.1 for a short description) wherein the AS binds a key to an access token. The client may include permissions it seeks to obtain and information about the credentials it wants to use for proof of possession (e.g., symmetric/asymmetric cryptography or a reference to a specific key) of the access token.
アクセストークンの要求（a）：クライアントは、ASのトークンエンドポイントにアクセストークン要求を行います。このフレームワークでは、ASがアクセストークンにキーを結合するのは、ポップアクセストークン（簡単な説明についてはセクション3.1を参照）を想定しています。クライアントには、アクセストークンの所有証明（対称/非対称の暗号化または特定のキーへの参照）の証明のために使用したい資格情報に関する情報と情報を取得しようとする権限を含めることができます。
Access Token Response (B): If the request from the client has been successfully verified, authenticated, and authorized, the AS returns an access token and optionally a refresh token. Note that only certain grant types support refresh tokens. The AS can also return additional parameters, referred to as "Access Information". In addition to the response parameters defined by OAuth 2.0 and the PoP access token extension, this framework defines parameters that can be used to inform the client about capabilities of the RS, e.g., the profile the RS supports. More information about these parameters can be found in Section 5.8.4.
アクセストークン応答（b）：クライアントからのリクエストが正常に検証、認証、および承認されている場合、ASはアクセストークンとオプションで更新トークンを返します。特定のグラントタイプのみがトークンの更新をサポートすることに注意してください。ASは、「アクセス情報」と呼ばれる追加のパラメーターを返すこともできます。OAUTH 2.0およびPOP Access Token拡張機能によって定義された応答パラメーターに加えて、このフレームワークは、RSの機能、たとえばRSがサポートするプロファイルについてクライアントに通知するために使用できるパラメーターを定義します。これらのパラメーターの詳細については、セクション5.8.4をご覧ください。
Resource Request (C): The client interacts with the RS to request access to the protected resource and provides the access token. The protocol to use between the client and the RS is not restricted to CoAP. HTTP, HTTP/2 [RFC9113], QUIC [RFC9000], MQTT [MQTT5.0], Bluetooth Low Energy [BLE], etc., are also viable candidates.
リソースリクエスト（c）：クライアントはRSと対話して、保護されたリソースへのアクセスを要求し、アクセストークンを提供します。クライアントとRSの間で使用するプロトコルは、COAPに制限されていません。HTTP、HTTP/2 [RFC9113]、QUIC [RFC9000]、MQTT [MQTT5.0]、Bluetooth Low Energy [BLE]なども実行可能な候補です。
Depending on the device limitations and the selected protocol, this exchange may be split up into two parts:
デバイスの制限と選択したプロトコルに応じて、この交換は2つの部分に分割される場合があります。
(1) the client sends the access token containing, or referencing, the authorization information to the RS that will be used for subsequent resource requests by the client, and
(1) クライアントは、クライアントによる後続のリソース要求に使用されるRSに許可情報を含むアクセストークンを送信するか、参照します。
(2) the client makes the resource access request using the communication security protocol and other Access Information obtained from the AS.
(2) クライアントは、ASから取得した通信セキュリティプロトコルとその他のアクセス情報を使用して、リソースアクセス要求を行います。
The client and the RS mutually authenticate using the security protocol specified in the profile (see step (B)) and the keys obtained in the access token or the Access Information. The RS verifies that the token is integrity protected and originated by the AS. It then compares the claims contained in the access token with the resource request. If the RS is online, validation can be handed over to the AS using token introspection (see messages (D) and (E)) over HTTP or CoAP.
クライアントとRSは、プロファイルで指定されたセキュリティプロトコル（ステップ（b）を参照）とアクセストークンまたはアクセス情報で取得したキーを使用して相互に認証します。RSは、トークンがASによって保護され、発生することを確認します。次に、アクセストークンに含まれるクレームをリソース要求と比較します。RSがオンラインの場合、検証は、HTTPまたはCOAPを介してトークン内省（メッセージ（d）および（e）を参照）を使用してASに引き渡すことができます。
Token Introspection Request (D): A resource server may be configured to introspect the access token by including it in a request to the introspection endpoint at that AS. Token introspection over CoAP is defined in Section 5.9 and for HTTP in [RFC7662].
トークン内注文要求（d）：リソースサーバーは、ASの内省エンドポイントへのリクエストに含めることにより、アクセストークンを内省するように構成されている場合があります。COAPを介したトークンの内省は、セクション5.9および[RFC7662]のHTTPで定義されています。
Note that token introspection is an optional step and can be omitted if the token is self-contained and the resource server is prepared to perform the token validation on its own.
トークン内省はオプションのステップであり、トークンが自己完結型であり、リソースサーバーがトークン検証を独自に実行する準備ができている場合は省略できます。
Token Introspection Response (E): The AS validates the token and returns the most recent parameters, such as scope, audience, validity, etc., associated with it back to the RS. The RS then uses the received parameters to process the request to either accept or to deny it.
トークン内省応答（e）：ASはトークンを検証し、範囲、視聴者、妥当性などの最新のパラメーターをRSに戻します。次に、RSは受信したパラメーターを使用して、要求を処理して、それを受け入れるか拒否します。
Protected Resource (F): If the request from the client is authorized, the RS fulfills the request and returns a response with the appropriate response code. The RS uses the dynamically established keys to protect the response according to the communication security protocol used.
保護されたリソース（f）：クライアントからのリクエストが承認されている場合、RSはリクエストを満たし、適切な応答コードで応答を返します。RSは、動的に確立されたキーを使用して、使用される通信セキュリティプロトコルに従って応答を保護します。
The OAuth 2.0 framework defines a number of "protocol flows" via grant types, which have been extended further with extensions to OAuth 2.0 (such as [RFC7521] and [RFC8628]). What grant type works best depends on the usage scenario; [RFC7744] describes many different IoT use cases, but there are two grant types that cover a majority of these scenarios, namely the authorization code grant (described in Section 4.1 of [RFC6749]) and the client credentials grant (described in Section 4.4 of [RFC6749]). The authorization code grant is a good fit for use with apps running on smartphones and tablets that request access to IoT devices, a common scenario in the smart home environment, where users need to go through an authentication and authorization phase (at least during the initial setup phase). The native apps guidelines described in [RFC8252] are applicable to this use case. The client credentials grant is a good fit for use with IoT devices where the OAuth client itself is constrained. In such a case, the resource owner has prearranged access rights for the client with the authorization server, which is often accomplished using a commissioning tool.
OAUTH 2.0フレームワークは、OAUTH 2.0（[RFC7521]や[RFC8628]など）の拡張を使用してさらに拡張されたグラントタイプを介して多くの「プロトコルフロー」を定義します。グラントタイプが最適に機能するものは、使用シナリオに依存します。 [RFC7744]は多くの異なるIoTユースケースを記述していますが、これらのシナリオの大部分をカバーする2つの助成金タイプがあります。つまり、認証コード助成金（[RFC6749]のセクション4.1で説明）とクライアント資格認定助成金（セクション4.4で説明されています） [RFC6749]）。 Authorization Code Grantは、IoTデバイスへのアクセスを要求するスマートフォンやタブレットで実行されているアプリで使用するのに適しています。これは、ユーザーが認証と承認フェーズを実行する必要があるスマートホーム環境の共通シナリオです（少なくとも最初の段階でセットアップフェーズ）。 [RFC8252]で説明されているネイティブアプリガイドラインは、このユースケースに適用できます。クライアント資格情報の助成金は、OAUTHクライアント自体が制約されているIoTデバイスでの使用に適しています。そのような場合、リソースの所有者は、承認サーバーを使用してクライアントのアクセス権を事前に表現しています。
The consent of the resource owner, for giving a client access to a protected resource, can be provided dynamically as in the classical OAuth flows, or it could be preconfigured by the resource owner as authorization policies at the AS, which the AS evaluates when a token request arrives. The resource owner and the requesting party (i.e., client owner) are not shown in Figure 1.
クライアントが保護されたリソースにアクセスできるようにするためのリソース所有者の同意は、古典的なOAuthフローのように動的に提供することができます。また、ASの認可ポリシーとしてリソース所有者によって事前に設定される可能性があります。トークンリクエストが届きます。リソースの所有者と要求者（つまり、クライアントの所有者）は図1には示されていません。
This framework supports a wide variety of communication security mechanisms between the ACE entities, such as the client, AS, and RS. It is assumed that the client has been registered (also called enrolled or onboarded) to an AS using a mechanism defined outside the scope of this document. In practice, various techniques for onboarding have been used, such as factory-based provisioning or the use of commissioning tools. Regardless of the onboarding technique, this provisioning procedure implies that the client and the AS exchange credentials and configuration parameters. These credentials are used to mutually authenticate each other and to protect messages exchanged between the client and the AS.
このフレームワークは、クライアント、As、RsなどのACEエンティティ間のさまざまな通信セキュリティメカニズムをサポートしています。クライアントは、このドキュメントの範囲外で定義されたメカニズムを使用してASに登録されている（登録またはオンボーディングとも呼ばれます）と想定されています。実際には、工場ベースのプロビジョニングや試運転ツールの使用など、オンボーディング用のさまざまな手法が使用されています。オンボーディング手法に関係なく、このプロビジョニング手順は、クライアントとAS AS Exchange資格と構成パラメーターが示すことを意味します。これらの資格情報は、相互に認証し、クライアントとASの間で交換されるメッセージを保護するために使用されます。
It is also assumed that the RS has been registered with the AS, potentially in a similar way as the client has been registered with the AS. Established keying material between the AS and the RS allows the AS to apply cryptographic protection to the access token to ensure that its content cannot be modified and, if needed, that the content is confidentiality protected. Confidentiality protection of the access token content would be provided on top of confidentiality protection via a communication security protocol.
また、クライアントがASに登録されているのと同様の方法で、RSがASに登録されていると想定されています。ASとRSの間に確立されたキーイング材料により、アクセストークンに暗号化保護を適用して、コンテンツを変更できず、必要に応じてコンテンツが保護されていることを確認できます。アクセストークンコンテンツの機密保護は、通信セキュリティプロトコルを介して機密性保護に加えて提供されます。
The keying material necessary for establishing communication security between the C and RS is dynamically established as part of the protocol described in this document.
CとRS間の通信セキュリティを確立するために必要なキーイング材料は、このドキュメントで説明されているプロトコルの一部として動的に確立されています。
At the start of the protocol, there is an optional discovery step where the client discovers the resource server and the resources this server hosts. In this step, the client might also determine what permissions are needed to access the protected resource. A generic procedure is described in Section 5.1; profiles MAY define other procedures for discovery.
プロトコルの開始時に、クライアントがこのサーバーがホストするリソースサーバーとリソースを発見するオプションの発見ステップがあります。このステップでは、クライアントは、保護されたリソースにアクセスするために必要な許可を決定する場合があります。一般的な手順については、セクション5.1で説明します。プロファイルは、発見のための他の手順を定義する場合があります。
In Bluetooth Low Energy, for example, advertisements are broadcast by a peripheral, including information about the primary services. In CoAP, as a second example, a client can make a request to "/.well-known/core" to obtain information about available resources, which are returned in a standardized format, as described in [RFC6690].
たとえば、Bluetooth Low Energyでは、広告は、一次サービスに関する情報を含む周辺機器によって放送されます。COAPでは、2番目の例として、クライアントは[/.well-known/core]にリクエストを行い、[RFC6690]で説明されているように、標準化された形式で返される利用可能なリソースに関する情報を取得できます。
The following sections detail the profiling and extensions of OAuth 2.0 for constrained environments, which constitutes the ACE framework.
次のセクションでは、ACEフレームワークを構成する制約された環境のOAUTH 2.0のプロファイリングと拡張について詳しく説明しています。
Credential Provisioning In constrained environments, it cannot be assumed that the client and the RS are part of a common key infrastructure. Therefore, the AS provisions credentials and associated information to allow mutual authentication between the client and the RS. The resulting security association between the client and the RS may then also be used to bind these credentials to the access tokens the client uses.
制約された環境での資格プロビジョニングは、クライアントとRSが共通のキーインフラストラクチャの一部であると想定することはできません。したがって、クライアントとRSの間の相互認証を可能にするために、AS ASの提供資格と関連情報。クライアントとRSの間の結果のセキュリティ関連は、クライアントが使用するアクセストークンにこれらの資格情報をバインドするために使用できます。
Proof of Possession The ACE framework, by default, implements proof of possession for access tokens, i.e., that the token holder can prove being a holder of the key bound to the token. The binding is provided by the cnf (confirmation) claim [RFC8747], indicating what key is used for proof of possession. If a client needs to submit a new access token, e.g., to obtain additional access rights, they can request that the AS binds this token to the same key as the previous one.
エースフレームワークの所有証明は、デフォルトでは、アクセストークンの所有権の証明を実装しています。つまり、トークンホルダーがトークンに縛られたキーの所有者であることを証明できることを実装します。この結合は、CNF（確認）クレーム[RFC8747]によって提供され、所有の証明にどのキーが使用されるかを示します。クライアントが追加のアクセス権を取得するために新しいアクセストークンを送信する必要がある場合、ASはこのトークンを前のキーと同じキーに結合するように要求できます。
ACE Profiles The client or RS may be limited in the encodings or protocols it supports. To support a variety of different deployment settings, specific interactions between the client and RS are defined in an ACE profile. In the ACE framework, the AS is expected to manage the matching of compatible profile choices between a client and an RS. The AS informs the client of the selected profile using the ace_profile parameter in the token response.
ACEプロファイルクライアントまたはRSは、サポートするエンコーディングまたはプロトコルで制限される場合があります。さまざまな展開設定をサポートするために、クライアントとRSの間の特定の相互作用がACEプロファイルで定義されます。ACEフレームワークでは、クライアントとRSの間の互換性のあるプロファイルの選択のマッチングを管理することが期待されています。ASは、トークン応答のACE_Profileパラメーターを使用して、選択したプロファイルをクライアントに通知します。
OAuth 2.0 requires the use of TLS to protect the communication between the AS and client when requesting an access token between the client and RS when accessing a resource and between the AS and RS if introspection is used. In constrained settings, TLS is not always feasible or desirable. Nevertheless, it is REQUIRED that the communications named above are encrypted, integrity protected, and protected against message replay. It is also REQUIRED that the communicating endpoints perform mutual authentication. Furthermore, it MUST be assured that responses are bound to the requests in the sense that the receiver of a response can be certain that the response actually belongs to a certain request. Note that setting up such a secure communication may require some unprotected messages to be exchanged first (e.g., sending the token from the client to the RS).
OAUTH 2.0では、クライアントとRSの間のアクセストークンを要求するときにASとクライアントの間の通信を保護するためにTLSを使用する必要があります。制約された設定では、TLSは常に実行可能または望ましいとは限りません。それにもかかわらず、上記の通信が暗号化され、整合性が保護され、メッセージのリプレイから保護されることが必要です。また、通信エンドポイントが相互認証を実行することも必要です。さらに、応答の受信者が実際に特定のリクエストに属していることを確信できるという意味で、応答は要求に拘束されることを保証する必要があります。このような安全な通信を設定するには、最初に保護されていないメッセージを交換する必要がある場合があります（たとえば、クライアントからRSにトークンを送信するなど）。
Profiles MUST specify a communication security protocol between the client and RS that provides the features required above. Profiles MUST specify a communication security protocol RECOMMENDED to be used between the client and AS that provides the features required above. Profiles MUST specify, for introspection, a communication security protocol RECOMMENDED to be used between the RS and AS that provides the features required above. These recommendations enable interoperability between different implementations without the need to define a new profile if the communication between the C and AS, or between the RS and AS, is protected with a different security protocol complying with the security requirements above.
プロファイルは、上記の機能を提供するクライアントとRSの間の通信セキュリティプロトコルを指定する必要があります。プロファイルは、クライアント間で使用することを推奨する通信セキュリティプロトコルと、上記の機能を提供する必要があります。プロファイルは、内省のために、RSの間で使用することを推奨する通信セキュリティプロトコルと、上記の機能を提供することを指定する必要があります。これらの推奨事項により、cとasとasまたはrsの間の通信が、上記のセキュリティ要件に準拠した異なるセキュリティプロトコルで保護されている場合、新しいプロファイルを定義する必要なく、異なる実装間の相互運用性が可能になります。
In OAuth 2.0, the communication with the Token and the Introspection endpoints at the AS is assumed to be via HTTP and may use Uri-query parameters. When profiles of this framework use CoAP instead, it is REQUIRED to use of the following alternative instead of Uri-query parameters: The sender (client or RS) encodes the parameters of its request as a CBOR map and submits that map as the payload of the POST request. The CBOR encoding for a number of OAuth 2.0 parameters is specified in this document; if a profile needs to use other OAuth 2.0 parameters with CoAP, it MUST specify their CBOR encoding.
OAUTH 2.0では、トークンとの通信とASの内省エンドポイントは、HTTPを介して想定されており、URI-Queryパラメーターを使用する場合があります。このフレームワークのプロファイルが代わりにCOAPを使用する場合、URI-Queryパラメーターの代わりに次の代替案を使用する必要があります。Sender（クライアントまたはRS）は、その要求のパラメーターをCBORマップとしてエンコードし、そのマップを提出します。POSTリクエスト。このドキュメントでは、多数のOAUTH 2.0パラメーターのCBORエンコードが指定されています。プロファイルがCOAPを使用して他のOAUTH 2.0パラメーターを使用する必要がある場合、CBORエンコードを指定する必要があります。
Profiles that use CBOR encoding of protocol message parameters at the outermost encoding layer MUST use the Content-Format "application/ ace+cbor". If CoAP is used for communication, the Content-Format MUST be abbreviated with the ID: 19 (see Section 8.16).
最も外側のエンコードレイヤーでプロトコルメッセージパラメーターのCBORエンコードを使用するプロファイルは、コンテンツフォーマット「アプリケーション/ ACE CBOR」を使用する必要があります。COAPが通信に使用される場合、コンテンツフォーマットはID：19で略されなければなりません（セクション8.16を参照）。
The OAuth 2.0 AS uses a JSON structure in the payload of its responses both to the client and RS. If CoAP is used, it is REQUIRED to use CBOR [RFC8949] instead of JSON. Depending on the profile, the CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper.
OAUTH 2.0は、クライアントとRSの両方に応答のペイロードでJSON構造を使用します。COAPを使用する場合、JSONの代わりにCBOR [RFC8949]を使用する必要があります。プロファイルに応じて、CBORペイロードは非CBOR暗号化ラッパーに囲まれている場合があります。
The C must discover the AS in charge of the RS to determine where to request the access token. To do so, the C 1) must find out the AS URI to which the token request message must be sent and 2) MUST validate that the AS with this URI is authorized to provide access tokens for this RS.
Cは、アクセストークンを要求する場所を決定するために、RSを担当するASを発見する必要があります。そのためには、c 1）トークン要求メッセージを送信する必要があり、2）このRsのアクセストークンを提供することが許可されていることを検証する必要があります。
In order to determine the AS URI, the C MAY send an initial Unauthorized Resource Request message to the RS. The RS then denies the request and sends the address of its AS back to the C (see Section 5.2). How the C validates the AS authorization is not in scope for this document. The C may, for example, ask its owner if this AS is authorized for this RS. The C may also use a mechanism that addresses both problems at once (e.g., by querying a dedicated secure service provided by the client owner) .
AS URIを決定するために、Cは最初の不正なリソース要求メッセージをRSに送信する場合があります。次に、RSはリクエストを拒否し、そのアドレスをCに戻すことを送信します（セクション5.2を参照）。CがAS認可を検証する方法は、このドキュメントの範囲ではありません。たとえば、Cは、このRsに対してこれが許可されているかどうかを所有者に尋ねることができます。Cは、両方の問題に一度に対処するメカニズムを使用する場合があります（たとえば、クライアントの所有者が提供する専用の安全なサービスを照会することにより）。
An Unauthorized Resource Request message is a request for any resource hosted by the RS for which the client does not have authorization granted. The RSs MUST treat any request for a protected resource as an Unauthorized Resource Request message when any of the following hold:
許可されていないリソース要求メッセージは、クライアントが認可されていないRSがホストするリソースのリクエストです。RSSは、保護されたリソースのリクエストを、次の保有の場合、不正なリソース要求メッセージとして扱う必要があります。
* The request has been received on an unsecured channel.
* リクエストは無担保チャネルで受信されました。
* The RS has no valid access token for the sender of the request regarding the requested action on that resource.
* RSには、そのリソースに関する要求されたアクションに関するリクエストの送信者の有効なアクセストークンがありません。
* The RS has a valid access token for the sender of the request, but that token does not authorize the requested action on the requested resource.
* RSには、リクエストの送信者に有効なアクセストークンがありますが、そのトークンは要求されたリソースで要求されたアクションを許可していません。
Note: These conditions ensure that the RS can handle requests autonomously once access was granted and a secure channel has been established between the C and RS. The authz-info endpoint, as part of the process for authorizing to protected resources, is not itself a protected resource and MUST NOT be protected as specified above (cf. Section 5.10.1).
注：これらの条件により、RSはアクセスが許可され、CとRSの間に安全なチャネルが確立されると、RSが自律的にリクエストを処理できるようにします。AuthZ-INFOエンドポイントは、保護されたリソースを許可するプロセスの一部として、それ自体が保護されたリソースではなく、上記のように保護されてはなりません（セクション5.10.1を参照）。
Unauthorized Resource Request messages MUST be denied with an "unauthorized_client" error response. In this response, the resource server SHOULD provide proper AS Request Creation Hints to enable the client to request an access token from the RS's AS, as described in Section 5.3.
不正なリソース要求メッセージは、「Unauthorized_Client」エラー応答で拒否される必要があります。この応答では、セクション5.3で説明されているように、クライアントがRSのASからアクセストークンを要求できるようにするために、リクエスト作成のヒントを適切に提供する必要があります。
The handling of all client requests (including unauthorized ones) by the RS is described in Section 5.10.2.
RSによるすべてのクライアント要求（不正なクライアントリクエストを含む）の処理については、セクション5.10.2で説明しています。
The AS Request Creation Hints are sent by an RS as a response to an Unauthorized Resource Request message (see Section 5.2) to help the sender of the Unauthorized Resource Request message acquire a valid access token. The AS Request Creation Hints are a CBOR or JSON map, with an OPTIONAL element AS specifying an absolute URI (see Section 4.3 of [RFC3986]) that identifies the appropriate AS for the RS.
ASリクエスト作成ヒントは、不正なリソース要求メッセージ（セクション5.2を参照）への応答としてRSによって送信され、不正なリソース要求メッセージの送信者が有効なアクセストークンを取得するのに役立ちます。ASリクエスト作成ヒントはCBORまたはJSONマップであり、オプションの要素は、RSに適切なものを識別する絶対URI（[RFC3986]のセクション4.3を参照）を指定します。
The message can also contain the following OPTIONAL parameters:
メッセージには、次のオプションパラメーターも含めることができます。
* An audience element contains an identifier the client should request at the AS, as suggested by the RS. With this parameter, when included in the access token request to the AS, the AS is able to restrict the use of the access token to specific RSs. See Section 6.9 for a discussion of this parameter.
* オーディエンス要素には、RSが示唆するように、クライアントがASで要求する識別子が含まれています。このパラメーターを使用すると、ASへのアクセストークン要求に含まれる場合、ASは特定のRSSへのアクセストークンの使用を制限できます。このパラメーターの説明については、セクション6.9を参照してください。
* A kid (key identifier) element contains the key identifier of a key used in an existing security association between the client and the RS. The RS expects the client to request an access token bound to this key in order to avoid having to reestablish the security association.
* KID（キー識別子）要素には、クライアントとRSの間の既存のセキュリティアソシエーションで使用されるキーのキー識別子が含まれています。RSは、セキュリティ協会の再確立を避けるために、クライアントがこのキーにバインドされたアクセストークンを要求することを期待しています。
* A cnonce element contains a client-nonce. See Section 5.3.1.
* CNONCE要素には、クライアントノンスが含まれています。セクション5.3.1を参照してください。
* A scope element contains the suggested scope that the client should request towards the AS.
* スコープ要素には、クライアントがASに対して要求する必要がある提案されたスコープが含まれています。
Table 1 summarizes the parameters that may be part of the AS Request Creation Hints.
表1は、ASリクエスト作成のヒントの一部である可能性のあるパラメーターをまとめたものです。
+==========+==========+=====================+
| Name | CBOR Key | Value Type |
+==========+==========+=====================+
| AS | 1 | text string |
+----------+----------+---------------------+
| kid | 2 | byte string |
+----------+----------+---------------------+
| audience | 5 | text string |
+----------+----------+---------------------+
| scope | 9 | text or byte string |
+----------+----------+---------------------+
| cnonce | 39 | byte string |
+----------+----------+---------------------+
Table 1: AS Request Creation Hints
表1：リクエスト作成のヒントとして
Note that the schema part of the AS parameter may need to be adapted to the security protocol that is used between the client and the AS. Thus, the example AS value "coap://as.example.com/token" might need to be transformed to "coaps://as.example.com/token". It is assumed that the client can determine the correct schema part on its own depending on the way it communicates with the AS.
ASパラメーターのスキーマ部分は、クライアントとASの間で使用されるセキュリティプロトコルに適応する必要がある場合があることに注意してください。したがって、「coap：//as.example.com/token」値としての例は、「coaps：//as.example.com/token」に変換する必要がある場合があります。クライアントは、ASと通信する方法に応じて、それ自体で正しいスキーマ部分を決定できると想定されています。
Figure 2 shows an example for an AS Request Creation Hints payload using diagnostic notation.
図2は、診断表記を使用して、AS ASリクエスト作成ヒントの例を示しています。
4.01 Unauthorized
Content-Format: application/ace+cbor
Payload :
{
/ AS / 1 : "coaps://as.example.com/token",
/ audience / 5 : "coaps://rs.example.com",
/ scope / 9 : "rTempC",
/ cnonce / 39 : h'e0a156bb3f'
}
Figure 2: AS Request Creation Hints Payload Example
図2：リクエストの作成として、ペイロードの例をヒントします
In the example above, the response parameter AS points the receiver of this message to the URI "coaps://as.example.com/token" to request access tokens. The RS sending this response uses an internal clock that is not synchronized with the clock of the AS. Therefore, it cannot reliably verify the expiration time of access tokens it receives. Nevertheless, to ensure a certain level of access token freshness, the RS has included a cnonce parameter (see Section 5.3.1) in the response. (The hex sequence of the cnonce parameter is encoded in CBOR-based notation in this example.)
上記の例では、応答パラメーターは、URIメッセージの受信者を「Coaps：//as.example.com/token」に指しています。この応答を送信するRSは、ASのクロックと同期されていない内部クロックを使用します。したがって、受信するアクセストークンの有効期限を確実に検証することはできません。それにもかかわらず、特定のレベルのアクセストークンの新鮮さを確保するために、RSには応答にCNONCEパラメーター（セクション5.3.1を参照）が含まれています。（CNONCEパラメーターのHEX配列は、この例ではCBORベースの表記でエンコードされています。）
Figure 3 illustrates the mandatory use of binary encoding of the message payload shown in Figure 2.
図3は、図2に示すメッセージペイロードのバイナリエンコードの必須使用を示しています。
a4 # map(4)
01 # unsigned(1) (=AS)
78 1c # text(28)
636f6170733a2f2f61732e657861
6d706c652e636f6d2f746f6b656e # "coaps://as.example.com/token"
05 # unsigned(5) (=audience)
76 # text(22)
636f6170733a2f2f72732e657861
6d706c652e636f6d # "coaps://rs.example.com"
09 # unsigned(9) (=scope)
66 # text(6)
7254656d7043 # "rTempC"
18 27 # unsigned(39) (=cnonce)
45 # bytes(5)
e0a156bb3f #
Figure 3: AS Request Creation Hints Example Encoded in CBOR
図3：リクエストの作成ヒントの例Cborでエンコードされた例
If the RS does not synchronize its clock with the AS, it could be tricked into accepting old access tokens that are either expired or have been compromised. In order to ensure some level of token freshness in that case, the RS can use the cnonce (client-nonce) parameter. The processing requirements for this parameter are as follows:
RSが時計をASと同期しない場合、有効期限が切れているか妥協されている古いアクセストークンを受け入れるようにだまされる可能性があります。その場合、ある程度のトークンの新鮮さを確保するために、RSはCNONCE（Client-Nonce）パラメーターを使用できます。このパラメーターの処理要件は次のとおりです。
* An RS sending a cnonce parameter in an AS Request Creation Hints message MUST store information to validate that a given cnonce is fresh. How this is implemented internally is out of scope for this specification. Expiration of client-nonces should be based roughly on the time it would take a client to obtain an access token after receiving the AS Request Creation Hints, with some allowance for unexpected delays.
* ASリクエスト作成ヒントメッセージにCNONCEパラメーターを送信するRSは、特定のCNONCEが新鮮であることを検証するために情報を保存する必要があります。これが内部でどのように実装されるかは、この仕様の範囲外です。クライアントノンセの有効期限は、クライアントがリクエスト作成のヒントを受け取った後にクライアントがアクセストークンを取得するのにかかる時間に基づいている必要があります。
* A client receiving a cnonce parameter in an AS Request Creation Hints message MUST include this in the parameters when requesting an access token at the AS, using the cnonce parameter from Section 5.8.4.4.
* AS ASリクエスト作成ヒントでCNONCEパラメーターを受信するクライアントは、セクション5.8.4.4のCNONCEパラメーターを使用して、ASでアクセストークンを要求するときにパラメーターにこれを含める必要があります。
* If an AS grants an access token request containing a cnonce parameter, it MUST include this value in the access token, using the cnonce claim specified in Section 5.10.
* ASがCNONCEパラメーターを含むアクセストークン要求を付与する場合、セクション5.10で指定されたCNONCEクレームを使用して、アクセストークンにこの値を含める必要があります。
* An RS that is using the client-nonce mechanism and that receives an access token MUST verify that this token contains a cnonce claim, with a client-nonce value that is fresh according to the information stored at the first step above. If the cnonce claim is not present or if the cnonce claim value is not fresh, the RS MUST discard the access token. If this was an interaction with the authz-info endpoint, the RS MUST also respond with an error message using a response code equivalent to the CoAP code 4.01 (Unauthorized).
* クライアントノンセメカニズムを使用しており、アクセストークンを受信しているRSは、上記の最初のステップに保存されている情報に応じて新鮮なクライアントノンス値を持つ、このトークンにcnonceクレームが含まれていることを確認する必要があります。CNONCEクレームが存在しない場合、またはCNONCE請求値が新鮮でない場合、RSはアクセストークンを破棄する必要があります。これがauthz-infoエンドポイントとの相互作用である場合、RSは、COAPコード4.01（不正）に相当する応答コードを使用してエラーメッセージで応答する必要があります。
To request an access token, the client obtains authorization from the resource owner or uses its client credentials as a grant. The authorization is expressed in the form of an authorization grant.
アクセストークンを要求するために、クライアントはリソース所有者から承認を取得するか、クライアントの資格情報を助成金として使用します。承認は、承認助成金の形で表明されます。
The OAuth framework [RFC6749] defines four grant types. The grant types can be split up into two groups: those granted on behalf of the resource owner (password, authorization code, implicit) and those for the client (client credentials). Further grant types have been added later, such as an assertion-based authorization grant defined in [RFC7521].
OAuthフレームワーク[RFC6749]は、4つの助成金タイプを定義します。助成金の種類は、リソース所有者（パスワード、承認コード、暗黙的コード）とクライアント（クライアント資格情報）に代わって付与されたグループの2つのグループに分割できます。[RFC7521]で定義されているアサーションベースの承認助成金など、さらに助成金の種類が後で追加されました。
The grant type is selected depending on the use case. In cases where the client acts on behalf of the resource owner, the authorization code grant is recommended. If the client acts on behalf of the resource owner but does not have any display or has very limited interaction possibilities, it is recommended to use the device code grant defined in [RFC8628]. In cases where the client acts autonomously, the client credentials grant is recommended.
助成金の種類は、ユースケースに応じて選択されます。クライアントがリソース所有者に代わって行動する場合、承認コード助成金が推奨されます。クライアントがリソース所有者に代わって行動するが、表示がないか、相互作用の可能性が非常に限られている場合は、[RFC8628]で定義されたデバイスコード助成金を使用することをお勧めします。クライアントが自律的に行動する場合、クライアント資格認定の助成金が推奨されます。
For details on the different grant types, see Section 1.3 of [RFC6749]. The OAuth 2.0 framework provides an extension mechanism for defining additional grant types, so profiles of this framework MAY define additional grant types, if needed.
さまざまな助成金タイプの詳細については、[RFC6749]のセクション1.3を参照してください。OAUTH 2.0フレームワークは、追加の助成金タイプを定義するための拡張メカニズムを提供するため、このフレームワークのプロファイルは、必要に応じて追加の助成金タイプを定義する場合があります。
Authentication of the client is mandatory independent of the grant type when requesting an access token from the token endpoint. In the case of the client credentials grant type, the authentication and grant coincide.
クライアントの認証は、トークンエンドポイントからアクセストークンを要求する場合、助成金タイプとは無関係です。クライアント資格情報の付与タイプの場合、認証と付与は一致します。
Client registration and provisioning of client credentials to the client is out of scope for this specification.
クライアントの登録とクライアント資格情報のクライアントへのプロビジョニングは、この仕様の範囲外です。
The OAuth framework defines one client credential type in Section 2.3.1 of [RFC6749] that comprises the client_id and client_secret values. [OAUTH-RPCC] adds raw public key and pre-shared key to the client credentials type. Profiles of this framework MAY extend it with an additional client credentials type using client certificates.
OAUTHフレームワークは、client_idおよびclient_secret値を含む[RFC6749]のセクション2.3.1の1つのクライアント資格タイプを定義します。[OAUTH-RPCC]は、生の公開キーと事前共有キーをクライアントの資格情報タイプに追加します。このフレームワークのプロファイルは、クライアント証明書を使用して追加のクライアント資格情報タイプで拡張する場合があります。
The client credentials grant does not, by default, authenticate the AS that the client connects to. In classic OAuth, the AS is authenticated with a TLS server certificate.
クライアント資格情報の付与は、クライアントが接続するように、デフォルトでは認証されません。クラシックOAuthでは、TLSサーバー証明書で認証されています。
Profiles of this framework MUST specify how clients authenticate the AS and how communication security is implemented. By default, server side TLS certificates, as defined by OAuth 2.0, are required.
このフレームワークのプロファイルは、クライアントがASを認証する方法とコミュニケーションセキュリティの実装方法を指定する必要があります。デフォルトでは、OAUTH 2.0で定義されているサーバー側のTLS証明書が必要です。
The OAuth 2.0 authorization endpoint is used to interact with the resource owner and obtain an authorization grant in certain grant flows. The primary use case for the ACE-OAuth framework is for machine-to-machine interactions that do not involve the resource owner in the authorization flow; therefore, this endpoint is out of scope here. Future profiles may define constrained adaptation mechanisms for this endpoint as well. Nonconstrained clients interacting with constrained resource servers can use the specification in Section 3.1 of [RFC6749] and the attack countermeasures suggested in Section 4.2 of [RFC6819].
OAUTH 2.0認証エンドポイントは、リソース所有者と対話し、特定の助成金フローで承認助成金を取得するために使用されます。ACE-OAuthフレームワークの主要なユースケースは、認証フローにリソース所有者を巻き込まないマシン間の相互作用です。したがって、このエンドポイントはここで範囲外です。将来のプロファイルは、このエンドポイントの制約された適応メカニズムも定義する場合があります。制約されたリソースサーバーと対話する制約のないクライアントは、[RFC6749]のセクション3.1の仕様と、[RFC6819]のセクション4.2で提案されている攻撃対策を使用できます。
In standard OAuth 2.0, the AS provides the token endpoint for submitting access token requests. This framework extends the functionality of the token endpoint, giving the AS the possibility to help the client and RS establish shared keys or exchange their public keys. Furthermore, this framework defines encodings using CBOR as a substitute for JSON.
標準のOAUTH 2.0では、ASはアクセストークンリクエストを送信するためのトークンエンドポイントを提供します。このフレームワークは、トークンエンドポイントの機能を拡張し、クライアントとRSが共有キーを確立したり、パブリックキーを交換できるようにすることができるようにします。さらに、このフレームワークは、CBORを使用してJSONの代替としてエンコーディングを定義します。
The endpoint may also be exposed over HTTPS, as in classical OAuth or even other transports. A profile MUST define the details of the mapping between the fields described below and these transports. If HTTPS with JSON is used, the semantics of Sections 4.1.3 and 4.1.4 of the OAuth 2.0 specification [RFC6749] MUST be followed (with additions as described below). If CBOR is used as the payload format, the semantics described in this section MUST be followed.
エンドポイントは、古典的なOAuthや他の輸送機関のように、HTTPSを介して露出することもあります。プロファイルは、以下に説明するフィールド間のマッピングの詳細とこれらのトランスポートを定義する必要があります。JSONを使用したHTTPSが使用されている場合、OAUTH 2.0仕様[RFC6749]のセクション4.1.3および4.1.4のセマンティクスに従う必要があります（以下に説明するように追加）。CBORがペイロード形式として使用されている場合、このセクションで説明するセマンティクスに従う必要があります。
For the AS to be able to issue a token, the client MUST be authenticated and present a valid grant for the scopes requested. Profiles of this framework MUST specify how the AS authenticates the client and how the communication between the client and AS is protected, fulfilling the requirements specified in Section 5.
トークンを発行できるようにするために、クライアントは認証され、要求されたスコープに対して有効な助成金を提示する必要があります。このフレームワークのプロファイルは、クライアントがクライアントを認証する方法と、クライアントとAsの保護された方法をどのように認証するかを指定する必要があり、セクション5で指定された要件を満たす必要があります。
The default name of this endpoint in a url-path SHOULD be '/token'. However, implementations are not required to use this name and can define their own instead.
URLパスのこのエンドポイントのデフォルト名は「/トークン」でなければなりません。ただし、実装はこの名前を使用する必要はなく、代わりに独自の名前を定義できます。
The client sends a POST request to the token endpoint at the AS. The profile MUST specify how the communication is protected. The content of the request consists of the parameters specified in the relevant subsection of Section 4 of the OAuth 2.0 specification [RFC6749], depending on the grant type, with the following exceptions and additions:
クライアントは、ASのトークンエンドポイントにPOSTリクエストを送信します。プロファイルは、通信の保護方法を指定する必要があります。リクエストの内容は、OAUTH 2.0仕様[RFC6749]のセクション4の関連するサブセクションで指定されたパラメーターで構成されています。グラントタイプに応じて、次の例外と追加を除きます。
* The grant_type parameter is OPTIONAL in the context of this framework (as opposed to REQUIRED in [RFC6749]). If that parameter is missing, the default value "client_credentials" is implied.
* grant_typeパラメーターは、このフレームワークのコンテキストではオプションです（[rfc6749]で要求されるのではなく）。そのパラメーターが欠落している場合、デフォルト値「client_credentials」が暗示されています。
* The audience parameter from [RFC8693] is OPTIONAL to request an access token bound to a specific audience.
* [RFC8693]のオーディエンスパラメーターは、特定のオーディエンスにバインドされたアクセストークンを要求するためにオプションです。
* The cnonce parameter defined in Section 5.8.4.4 is REQUIRED if the RS provided a client-nonce in the AS Request Creation Hints message (Section 5.3).
* RSがASリクエスト作成ヒントメッセージ（セクション5.3）でクライアントノンスを提供した場合、セクション5.8.4.4で定義されたCNONCEパラメーターが必要です。
* The scope parameter MAY be encoded as a byte string instead of the string encoding specified in Section 3.3 of [RFC6749] or in order to allow compact encoding of complex scopes. The syntax of such a binary encoding is explicitly not specified here and left to profiles or applications. Note specifically that a binary encoded scope does not necessarily use the space character '0x20' to delimit scope-tokens.
* スコープパラメーターは、[RFC6749]のセクション3.3で指定された文字列エンコードの代わりに、または複雑なスコープのコンパクトなエンコードを許可するために、バイト文字列としてエンコードされる場合があります。このようなバイナリエンコーディングの構文は、ここで明示的に指定されておらず、プロファイルまたはアプリケーションに残されています。具体的には、バイナリエンコードされたスコープでは、スペース文字「0x20」を使用してスコープトケンを区切るわけではないことに注意してください。
* The client can send an empty (null value) ace_profile parameter to indicate that it wants the AS to include the ace_profile parameter in the response. See Section 5.8.4.3.
* クライアントは、空の（null値）ace_profileパラメーターを送信して、応答にace_profileパラメーターを含めることを望んでいることを示すことができます。セクション5.8.4.3を参照してください。
* A client MUST be able to use the parameters from [RFC9201] in an access token request to the token endpoint, and the AS MUST be able to process these additional parameters.
* クライアントは、[RFC9201]のパラメーターをトークンエンドポイントへのアクセストークン要求で使用できる必要があり、ASはこれらの追加パラメーターを処理できる必要があります。
The default behavior is that the AS generates a symmetric proof-of-possession key for the client. In order to use an asymmetric key pair or to reuse a key previously established with the RS, the client is supposed to use the req_cnf parameter from [RFC9201].
デフォルトの動作は、Asがクライアントの対称的なプルーフオブポッセッションキーを生成することです。非対称キーペアを使用したり、以前にRSで確立されたキーを再利用するために、クライアントは[RFC9201]のREQ_CNFパラメーターを使用することになっています。
If CoAP is used, then these parameters MUST be provided in a CBOR map (see Table 5).
COAPを使用する場合、これらのパラメーターはCBORマップで提供する必要があります（表5を参照）。
When HTTP is used as a transport, then the client makes a request to the token endpoint; the parameters MUST be encoded as defined in Appendix B of [RFC6749].
HTTPがトランスポートとして使用されると、クライアントはトークンエンドポイントにリクエストを行います。パラメーターは、[RFC6749]の付録Bで定義されているようにエンコードする必要があります。
The following examples illustrate different types of requests for proof-of-possession tokens.
次の例は、所有証明のトークンに対するさまざまなタイプのリクエストを示しています。
Figure 4 shows a request for a token with a symmetric proof-of-possession key, using diagnostic notation.
図4は、診断表記を使用して、対称的なプルーフオブポッセッションキーを持つトークンのリクエストを示しています。
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
/ client_id / 24 : "myclient",
/ audience / 5 : "tempSensor4711"
}
Figure 4: Example Request for an Access Token Bound to a Symmetric Key
図4：対称キーにバインドされたアクセストークンの例の例
Figure 5 shows a request for a token with an asymmetric proof-of-possession key. Note that, in this example, OSCORE [RFC8613] is used to provide object-security; therefore, the Content-Format is "application/oscore" wrapping the "application/ace+cbor" type content. The OSCORE option has a decoded interpretation appended in parentheses for the reader's convenience. Also note that, in this example, the audience is implicitly known by both the client and AS. Furthermore, note that this example uses the req_cnf parameter from [RFC9201].
図5は、非対称のプルーフオブポッセッションキーを備えたトークンのリクエストを示しています。この例では、OSCORE [RFC8613]を使用してオブジェクトセキュリティを提供することに注意してください。したがって、コンテンツフォーマットは「アプリケーション/オスコア」であり、「アプリケーション/ACE CBOR」タイプのコンテンツをラッピングします。OSCOREオプションには、読者の利便性のために括弧内に追加された解釈の解釈がデコードされています。また、この例では、聴衆はクライアントとASの両方によって暗黙的に知られていることに注意してください。さらに、この例では[RFC9201]のREQ_CNFパラメーターを使用していることに注意してください。
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
OSCORE: 0x09, 0x05, 0x44, 0x6C
(h=0, k=1, n=001, partialIV= 0x05, kid=[0x44, 0x6C])
Content-Format: application/oscore
Payload:
0x44025d1/ ... (full payload omitted for brevity) ... /68b3825e
Decrypted payload:
{
/ client_id / 24 : "myclient",
/ req_cnf / 4 : {
/ COSE_Key / 1 : {
/ kty / 1 : 2 / EC2 /,
/ kid / 2 : h'11',
/ crv / -1 : 1 / P-256 /,
/ x / -2 : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8',
/ y / -3 : b64'IBOL+C3BttVivg+lSreASjpkttcsz+1rb7btKLv8EX4'
}
}
}
Figure 5: Example Token Request Bound to an Asymmetric Key
図5：非対称キーにバインドされたトークン要求の例
Figure 6 shows a request for a token where a previously communicated proof-of-possession key is only referenced using the req_cnf parameter from [RFC9201].
図6は、[RFC9201]のREQ_CNFパラメーターを使用してのみ参照される、以前に通信されたProof-ossessionキーが参照されるトークンの要求を示しています。
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
/ client_id / 24 : "myclient",
/ audience / 5 : "valve424",
/ scope / 9 : "read",
/ req_cnf / 4 : {
/ kid / 3 : b64'6kg0dXJM13U'
}
}
Figure 6: Example Request for an Access Token Bound to a Key Reference
図6：キーリファレンスにバインドされたアクセストークンの例の例
Refresh tokens are typically not stored as securely as proof-of-possession keys in requesting clients. Proof-of-possession-based refresh token requests MUST NOT request different proof-of-possession keys or different audiences in token requests. Refresh token requests can only be used to request access tokens bound to the same proof-of-possession key and the same audience as access tokens issued in the initial token request.
リフレッシュトークンは、通常、クライアントにリクエストする際に、プルーフオブポッセッションキーとして安全に保存されません。Proof-of-Possessionベースの更新トークンリクエストは、トークンリクエストで別のプルーフポッセッションキーまたは異なる視聴者を要求してはなりません。リフレッシュトークンリクエストは、最初のトークンリクエストで発行されたアクセストークンと同じプルーフオブポッセッションキーと同じオーディエンスにバインドされたアクセストークンを要求するためにのみ使用できます。
If the access token request has been successfully verified by the AS and the client is authorized to obtain an access token corresponding to its access token request, the AS sends a response with the response code equivalent to the CoAP response code 2.01 (Created). If the client request was invalid, or not authorized, the AS returns an error response, as described in Section 5.8.3.
アクセストークン要求がASによって正常に検証されている場合、クライアントがアクセストークンリクエストに対応するアクセストークンを取得することを許可されている場合、ASはCOAP応答コード2.01（作成）に相当する応答コードを使用して応答を送信します。セクション5.8.3で説明されているように、クライアント要求が無効であるか、許可されていない場合、ASはエラー応答を返します。
Note that the AS decides which token type and profile to use when issuing a successful response. It is assumed that the AS has prior knowledge of the capabilities of the client and the RS (see Appendix D). This prior knowledge may, for example, be set by the use of a dynamic client registration protocol exchange [RFC7591]. If the client has requested a specific proof-of-possession key using the req_cnf parameter from [RFC9201], this may also influence which profile the AS selects, as it needs to support the use of the key type requested by the client.
ASは、成功した応答を発行するときに使用するトークンタイプとプロファイルを決定することに注意してください。ASには、クライアントとRSの機能に関する事前知識があると想定されています（付録Dを参照）。この事前知識は、たとえば、動的なクライアント登録プロトコル交換[RFC7591]を使用することにより設定される場合があります。クライアントが[RFC9201]のREQ_CNFパラメーターを使用して特定のプルーフオブポッセッションキーを要求した場合、これはクライアントが要求するキータイプの使用をサポートする必要があるため、ASを選択するプロファイルに影響する可能性があります。
The content of the successful reply is the Access Information. When using CoAP, the payload MUST be encoded as a CBOR map; when using HTTP, the encoding is a JSON map, as specified in Section 5.1 of [RFC6749]. In both cases, the parameters specified in Section 5.1 of [RFC6749] are used, with the following additions and changes:
成功した返信の内容はアクセス情報です。COAPを使用する場合、ペイロードはCBORマップとしてエンコードする必要があります。HTTPを使用する場合、エンコードは[RFC6749]のセクション5.1で指定されているように、JSONマップです。どちらの場合も、[RFC6749]のセクション5.1で指定されたパラメーターが使用され、次の追加と変更があります。
ace_profile: This parameter is OPTIONAL unless the request included an empty ace_profile parameter, in which case it is MANDATORY. This indicates the profile that the client MUST use towards the RS. See Section 5.8.4.3 for the formatting of this parameter. If this parameter is absent, the AS assumes that the client implicitly knows which profile to use towards the RS.
ACE_Profile：このパラメーターは、要求に空のACE_Profileパラメーターが含まれていない限りオプションです。この場合は必須です。これは、クライアントがRSに向かって使用する必要があるプロファイルを示します。このパラメーターのフォーマットについては、セクション5.8.4.3を参照してください。このパラメーターが存在しない場合、ASは、クライアントがRSに使用するプロファイルを暗黙的に知っていると想定しています。
token_type: This parameter is OPTIONAL, as opposed to REQUIRED in [RFC6749]. By default, implementations of this framework SHOULD assume that the token_type is "PoP". If a specific use case requires another token_type (e.g., "Bearer") to be used, then this parameter is REQUIRED.
token_type：[RFC6749]では要求されるのではなく、このパラメーターはオプションです。デフォルトでは、このフレームワークの実装は、token_typeが「POP」であると想定する必要があります。特定のユースケースで別のtoken_type（例えば、「ベアラー」）を使用する必要がある場合、このパラメーターが必要です。
Furthermore, [RFC9201] defines additional parameters that the AS MUST be able to use when responding to a request to the token endpoint.
さらに、[RFC9201]は、トークンエンドポイントへのリクエストに応答するときにASが使用できる追加のパラメーターを定義します。
Table 2 summarizes the parameters that can currently be part of the Access Information. Future extensions may define additional parameters.
表2は、現在アクセス情報の一部になる可能性のあるパラメーターをまとめたものです。将来の拡張機能は、追加のパラメーターを定義する場合があります。
+===================+==============+
| Parameter name | Specified in |
+===================+==============+
| access_token | [RFC6749] |
+-------------------+--------------+
| token_type | [RFC6749] |
+-------------------+--------------+
| expires_in | [RFC6749] |
+-------------------+--------------+
| refresh_token | [RFC6749] |
+-------------------+--------------+
| scope | [RFC6749] |
+-------------------+--------------+
| state | [RFC6749] |
+-------------------+--------------+
| error | [RFC6749] |
+-------------------+--------------+
| error_description | [RFC6749] |
+-------------------+--------------+
| error_uri | [RFC6749] |
+-------------------+--------------+
| ace_profile | RFC 9200 |
+-------------------+--------------+
| cnf | [RFC9201] |
+-------------------+--------------+
| rs_cnf | [RFC9201] |
+-------------------+--------------+
Table 2: Access Information Parameters
表2：アクセス情報パラメーター
Figure 7 shows a response containing a token and a cnf parameter with a symmetric proof-of-possession key, which is defined in [RFC9201]. Note that the key identifier kid is only used to simplify indexing and retrieving the key, and no assumptions should be made that it is unique in the domains of either the client or the RS.
図7は、トークンを含む応答と、[RFC9201]で定義されている対称的なプルーフオブポッセッションキーを備えたCNFパラメーターを示しています。キー識別子のKIDは、インデックス作成とキーの取得を簡素化するためにのみ使用されることに注意してください。また、クライアントまたはRSのドメインで一意であるという仮定は行われないでください。
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
/ access_token / 1 : b64'SlAV32hk'/ ...
(remainder of CWT omitted for brevity;
CWT contains COSE_Key in the cnf claim)/,
/ ace_profile / 38 : "coap_dtls",
/ expires_in / 2 : 3600,
/ cnf / 8 : {
/ COSE_Key / 1 : {
/ kty / 1 : 4 / Symmetric /,
/ kid / 2 : b64'39Gqlw',
/ k / -1 : b64'hJtXhkV8FJG+Onbc6mxC'
}
}
}
Figure 7: Example AS Response with an Access Token Bound to a Symmetric Key
図7：対称キーにバインドされたアクセストークンを使用した応答としての例
The error responses for interactions with the AS are generally equivalent to the ones defined in Section 5.2 of [RFC6749], with the following exceptions:
ASとの相互作用のエラー応答は、一般に[RFC6749]のセクション5.2で定義されているものと同等です。
* When using CoAP, the payload MUST be encoded as a CBOR map, with the Content-Format "application/ace+cbor". When using HTTP, the payload is encoded in JSON, as specified in Section 5.2 of [RFC6749].
* COAPを使用する場合、コンテンツ形式の「アプリケーション/ACE CBOR」を使用して、ペイロードをCBORマップとしてエンコードする必要があります。HTTPを使用する場合、[RFC6749]のセクション5.2で指定されているように、ペイロードはJSONでエンコードされます。
* A response code equivalent to the CoAP code 4.00 (Bad Request) MUST be used for all error responses, except for invalid_client, where a response code equivalent to the CoAP code 4.01 (Unauthorized) MAY be used under the same conditions as specified in Section 5.2 of [RFC6749].
* COAPコード4.00（悪い要求）に相当する応答コードは、すべてのエラー応答に使用する必要があります。ただし、COAPコード4.01に相当する応答コード（不正）に相当する応答コードは、セクション5.2で指定されたものと同じ条件で使用できます。[RFC6749]。
* The parameters error, error_description, and error_uri MUST be abbreviated using the codes specified in Table 5, when a CBOR encoding is used.
* CBORエンコードが使用される場合、表5で指定されたコードを使用して、パラメーターエラー、ERROR_Description、およびERROR_URIを省略する必要があります。
* The error code (i.e., value of the error parameter) MUST be abbreviated, as specified in Table 3, when a CBOR encoding is used.
* エラーコード（つまり、エラーパラメーターの値）は、CBORエンコードが使用されるときに表3に指定されているように、省略する必要があります。
+===========================+=============+========================+
| Name | CBOR Values | Original Specification |
+===========================+=============+========================+
| invalid_request | 1 | Section 5.2 of |
| | | [RFC6749] |
+---------------------------+-------------+------------------------+
| invalid_client | 2 | Section 5.2 of |
| | | [RFC6749] |
+---------------------------+-------------+------------------------+
| invalid_grant | 3 | Section 5.2 of |
| | | [RFC6749] |
+---------------------------+-------------+------------------------+
| unauthorized_client | 4 | Section 5.2 of |
| | | [RFC6749] |
+---------------------------+-------------+------------------------+
| unsupported_grant_type | 5 | Section 5.2 of |
| | | [RFC6749] |
+---------------------------+-------------+------------------------+
| invalid_scope | 6 | Section 5.2 of |
| | | [RFC6749] |
+---------------------------+-------------+------------------------+
| unsupported_pop_key | 7 | RFC 9200 |
+---------------------------+-------------+------------------------+
| incompatible_ace_profiles | 8 | RFC 9200 |
+---------------------------+-------------+------------------------+
Table 3: CBOR Abbreviations for Common Error Codes
表3：一般的なエラーコードのCBORの略語
In addition to the error responses defined in OAuth 2.0, the following behavior MUST be implemented by the AS:
OAUTH 2.0で定義されているエラー応答に加えて、次のような動作は次のように実装する必要があります。
* If the client submits an asymmetric key in the token request that the RS cannot process, the AS MUST reject that request with a response code equivalent to the CoAP code 4.00 (Bad Request), including the error code "unsupported_pop_key" specified in Table 3.
* クライアントがトークンのリクエストの非対称キーを提出した場合、RSが処理できないことを要求する場合、ASは、表3に指定されたエラーコード「unsupported_pop_key」を含む、COAPコード4.00（悪い要求）に相当する応答コードでその要求を拒否する必要があります。
* If the client and the RS it has requested an access token for do not share a common profile, the AS MUST reject that request with a response code equivalent to the CoAP code 4.00 (Bad Request), including the error code "incompatible_ace_profiles" specified in Table 3.
* クライアントとRSがアクセストークンを要求した場合、共通のプロファイルを共有しない場合、ASは、COAPコード4.00（悪い要求）に相当する応答コードでその要求を拒否する必要があります。表3。
This section provides more detail about the new parameters that can be used in access token requests and responses, as well as abbreviations for more compact encoding of existing parameters and common parameter values.
このセクションでは、アクセストークンの要求と応答で使用できる新しいパラメーターの詳細と、既存のパラメーターと共通パラメーター値のよりコンパクトなエンコードのための略語について説明します。
The abbreviations specified in the registry defined in Section 8.5 MUST be used in CBOR encodings instead of the string values defined in [RFC6749] if CBOR payloads are used.
セクション8.5で定義されているレジストリで指定された略語は、CBORペイロードを使用する場合は[RFC6749]で定義された文字列値の代わりに、CBORエンコーディングで使用する必要があります。
+====================+============+============================+
| Name | CBOR Value | Original Specification |
+====================+============+============================+
| password | 0 | Section 4.3.2 of [RFC6749] |
+--------------------+------------+----------------------------+
| authorization_code | 1 | Section 4.1.3 of [RFC6749] |
+--------------------+------------+----------------------------+
| client_credentials | 2 | Section 4.4.2 of [RFC6749] |
+--------------------+------------+----------------------------+
| refresh_token | 3 | Section 6 of [RFC6749] |
+--------------------+------------+----------------------------+
Table 4: CBOR Abbreviations for Common Grant Types
表4：一般的な助成金タイプのCBORの略語
The token_type parameter, defined in Section 5.1 of [RFC6749], allows the AS to indicate to the client which type of access token it is receiving (e.g., a bearer token).
[RFC6749]のセクション5.1で定義されているtoken_typeパラメーターは、受信しているアクセストークンのタイプ（ベアラートークンなど）をクライアントに示すことができます。
This document registers the new value "PoP" for the "OAuth Access Token Types" registry, specifying a proof-of-possession token. How the proof of possession by the client to the RS is performed MUST be specified by the profiles.
このドキュメントは、「OAuthアクセストークンタイプ」レジストリの新しい値「POP」を登録し、所有証明のトークンを指定します。クライアントによるRSへの所有の証明の実行方法は、プロファイルによって指定されなければなりません。
The values in the token_type parameter MUST use the CBOR abbreviations defined in the registry specified by Section 8.7 if a CBOR encoding is used.
token_Typeパラメーターの値は、CBORエンコードが使用されている場合、セクション8.7で指定されたレジストリで定義されたCBOR省略図を使用する必要があります。
In this framework, the "pop" value for the token_type parameter is the default. The AS may, however, provide a different value from those registered in [IANA.OAuthAccessTokenTypes].
このフレームワークでは、token_typeパラメーターの「POP」値がデフォルトです。ただし、ASは、[iana.oauthaccestokentypes]に登録されている値とは異なる値を提供します。
Profiles of this framework MUST define the communication protocol and the communication security protocol between the client and the RS. The security protocol MUST provide encryption, integrity, and replay protection. It MUST also provide a binding between requests and responses. Furthermore, profiles MUST define a list of allowed proof-of-possession methods if they support proof-of-possession tokens.
このフレームワークのプロファイルは、クライアントとRSの間の通信プロトコルと通信セキュリティプロトコルを定義する必要があります。セキュリティプロトコルは、暗号化、整合性、およびリプレイ保護を提供する必要があります。また、リクエストと応答の間に拘束力を提供する必要があります。さらに、プロファイルが、所有証明のトークンをサポートする場合、許可されたプルーフオブポッセッション方法のリストを定義する必要があります。
A profile MUST specify an identifier that MUST be used to uniquely identify itself in the ace_profile parameter. The textual representation of the profile identifier is intended for human readability and for JSON-based interactions; it MUST NOT be used for CBOR-based interactions. Profiles MUST register their identifier in the registry defined in Section 8.8.
プロファイルは、ACE_Profileパラメーターで一意に識別するために使用する必要がある識別子を指定する必要があります。プロファイル識別子のテキスト表現は、人間の読みやすさとJSONベースの相互作用を目的としています。CBORベースの相互作用に使用してはなりません。プロファイルは、セクション8.8で定義されているレジストリに識別子を登録する必要があります。
Profiles MAY define additional parameters for both the token request and the Access Information in the access token response in order to support negotiation or signaling of profile-specific parameters.
プロファイルは、プロファイル固有のパラメーターの交渉または信号をサポートするために、トークン要求とアクセストークン応答のアクセス情報の両方の追加のパラメーターを定義できます。
Clients that want the AS to provide them with the ace_profile parameter in the access token response can indicate that by sending an ace_profile parameter with a null value for CBOR-based interactions, or an empty string if CBOR is not used, in the access token request.
アクセストークン応答にACE_Profileパラメーターを提供したいクライアントは、CBORベースのインタラクションにnull値を持つACE_Profileパラメーターを送信することにより、またはCBORが使用されていない場合は空の文字列を送信することにより、アクセストークンリクエストで示すことができます。。
This parameter MUST be sent from the client to the AS if it previously received a cnonce parameter in the AS Request Creation Hints (Section 5.3). The parameter is encoded as a byte string for CBOR-based interactions and as a string (base64url without padding encoded binary [RFC4648]) if CBOR is not used. It MUST copy the value from the cnonce parameter in the AS Request Creation Hints.
このパラメーターは、ASリクエスト作成ヒント（セクション5.3）で以前にCNONCEパラメーターを受信したかのように、クライアントからクライアントに送信する必要があります。パラメーターは、CBORベースの相互作用のバイト文字列としてエンコードされ、CBORが使用されていない場合は、エンコードされたバイナリ[RFC4648]をパディングしないbase64url）としてエンコードされます。ASリクエスト作成ヒントのCNONCEパラメーターから値をコピーする必要があります。
If CBOR encoding is used, all OAuth parameters in access token requests and responses MUST be mapped to CBOR types, as specified in the registry defined by Section 8.10, using the given integer abbreviation for the map keys.
CBORエンコーディングを使用する場合、アクセストークンリクエストと応答のすべてのOAUTHパラメーターは、マップキーの指定された整数の略語を使用して、セクション8.10で定義されたレジストリで指定されているように、CBORタイプにマッピングする必要があります。
Note that we have aligned the abbreviations corresponding to claims with the abbreviations defined in [RFC8392].
[RFC8392]で定義されている略語とのクレームに対応する略語を整列させたことに注意してください。
Note also that abbreviations from -24 to 23 have a 1-byte encoding size in CBOR. We have thus chosen to assign abbreviations in that range to parameters we expect to be used most frequently in constrained scenarios.
また、-24から23までの略語は、CBORに1バイトのエンコードサイズがあることに注意してください。したがって、その範囲内の略語を、制約付きシナリオで最も頻繁に使用すると予想されるパラメーターに割り当てることを選択しました。
+===================+==========+=============+===============+
| Name | CBOR Key | Value Type | Original |
| | | | Specification |
+===================+==========+=============+===============+
| access_token | 1 | byte string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| expires_in | 2 | unsigned | [RFC6749] |
| | | integer | |
+-------------------+----------+-------------+---------------+
| audience | 5 | text string | [RFC8693] |
+-------------------+----------+-------------+---------------+
| scope | 9 | text or | [RFC6749] |
| | | byte string | |
+-------------------+----------+-------------+---------------+
| client_id | 24 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| client_secret | 25 | byte string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| response_type | 26 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| redirect_uri | 27 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| state | 28 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| code | 29 | byte string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| error | 30 | integer | [RFC6749] |
+-------------------+----------+-------------+---------------+
| error_description | 31 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| error_uri | 32 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| grant_type | 33 | unsigned | [RFC6749] |
| | | integer | |
+-------------------+----------+-------------+---------------+
| token_type | 34 | integer | [RFC6749] |
+-------------------+----------+-------------+---------------+
| username | 35 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| password | 36 | text string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| refresh_token | 37 | byte string | [RFC6749] |
+-------------------+----------+-------------+---------------+
| ace_profile | 38 | integer | RFC 9200 |
+-------------------+----------+-------------+---------------+
| cnonce | 39 | byte string | RFC 9200 |
+-------------------+----------+-------------+---------------+
Table 5: CBOR Mappings Used in Token Requests and Responses
表5：トークンのリクエストと応答で使用されるCBORマッピング
Token introspection [RFC7662] MAY be implemented by the AS and the RS. When implemented, it MAY be used by the RS and to query the AS for metadata about a given token, e.g., validity or scope. Analogous to the protocol defined in [RFC7662] for HTTP and JSON, this section defines adaptations to more constrained environments using CBOR and leaving the choice of the application protocol to the profile. The client MAY also implement and use introspection analogously to the RS to obtain information about a given token.
トークン内省[RFC7662]は、ASおよびRSによって実装される場合があります。実装された場合、RSによって使用され、特定のトークン、たとえば有効性や範囲についてメタデータを照会することができます。HTTPおよびJSONの[RFC7662]で定義されているプロトコルと同様に、このセクションでは、CBORを使用してより制約された環境への適応を定義し、アプリケーションプロトコルの選択をプロファイルに任せます。また、クライアントは、RSと同様に内省を実装および使用して、特定のトークンに関する情報を取得することもできます。
Communication between the requesting entity and the introspection endpoint at the AS MUST be integrity protected and encrypted. The communication security protocol MUST also provide a binding between requests and responses. Furthermore, the two interacting parties MUST perform mutual authentication. Finally, the AS SHOULD verify that the requesting entity has the right to access introspection information about the provided token. Profiles of this framework that support introspection MUST specify how authentication and communication security between the requesting entity and the AS is implemented.
ASの要求エンティティと内省エンドポイントとの間のコミュニケーションは、整合性保護および暗号化されている必要があります。通信セキュリティプロトコルは、リクエストと応答の間の拘束力も提供する必要があります。さらに、2つの相互作用者は相互認証を実行する必要があります。最後に、ASは、要求エンティティが提供されたトークンに関する内省情報にアクセスする権利を持っていることを確認する必要があります。内省をサポートするこのフレームワークのプロファイルは、要求エンティティと実装されているASの間の認証と通信セキュリティをどのように指定する必要があります。
The default name of this endpoint in a url-path SHOULD be '/introspect'. However, implementations are not required to use this name and can define their own instead.
URLパスのこのエンドポイントのデフォルト名は「/内省」である必要があります。ただし、実装はこの名前を使用する必要はなく、代わりに独自の名前を定義できます。
The requesting entity sends a POST request to the introspection endpoint at the AS. The profile MUST specify how the communication is protected. If CoAP is used, the payload MUST be encoded as a CBOR map with a token entry containing the access token. Further optional parameters representing additional context that is known by the requesting entity to aid the AS in its response MAY be included.
要求エンティティは、ASの内省エンドポイントにPOST要求を送信します。プロファイルは、通信の保護方法を指定する必要があります。COAPを使用する場合、ペイロードは、アクセストークンを含むトークンエントリを備えたCBORマップとしてエンコードする必要があります。要求のエンティティによって知られている追加のコンテキストを表すさらにオプションのパラメーターは、その応答にASを支援することができます。
For CoAP-based interaction, all messages MUST use the content type "application/ace+cbor". For HTTP, the encoding defined in Section 2.1 of [RFC7662] is used.
COAPベースのインタラクションの場合、すべてのメッセージはコンテンツタイプ「アプリケーション/ACE CBOR」を使用する必要があります。HTTPの場合、[RFC7662]のセクション2.1で定義されているエンコーディングが使用されます。
The same parameters are required and optional as in Section 2.1 of [RFC7662].
[RFC7662]のセクション2.1のように、同じパラメーターが必要であり、オプションです。
For example, Figure 8 shows an RS calling the token introspection endpoint at the AS to query about an OAuth 2.0 proof-of-possession token. Note that object security based on OSCORE [RFC8613] is assumed in this example; therefore, the Content-Format is "application/oscore". Figure 9 shows the decoded payload.
たとえば、図8は、OAuth 2.0 Proof-of-Possessionトークンに関するクエリに関して、トークン内省エンドポイントを呼び出すRSを示しています。この例では、OSCORE [RFC8613]に基づくオブジェクトセキュリティが想定されていることに注意してください。したがって、コンテンツフォーマットは「アプリケーション/オスコア」です。図9は、デコードされたペイロードを示しています。
Header: POST (Code=0.02) Uri-Host: "as.example.com" Uri-Path: "introspect" OSCORE: 0x09, 0x05, 0x25 Content-Format: application/oscore Payload: ... COSE content ...
ヘッダー：投稿（コード= 0.02）uri-host： "as.example.com" uri-path： "introspect" oscore：0x09、0x05、0x25コンテンツフォーマット：アプリケーション/オスコアペイロード：...
Figure 8: Example Introspection Request
図8：イントロスペクティションリクエストの例
{
/ token / 11 : b64'7gj0dXJQ43U',
/ token_type_hint / 33 : 2 / PoP /
}
Figure 9: Decoded Payload
図9：デコードされたペイロード
If the introspection request is authorized and successfully processed, the AS sends a response with the response code equivalent to the CoAP code 2.01 (Created). If the introspection request was invalid, not authorized, or couldn't be processed, the AS returns an error response, as described in Section 5.9.3.
内省要求が承認され、処理された場合、ASはCOAPコード2.01（作成）に相当する応答コードを使用して応答を送信します。内省要求が無効で、許可されていない、または処理できなかった場合、ASはセクション5.9.3で説明されているようにエラー応答を返します。
In a successful response, the AS encodes the response parameters in a map. If CoAP is used, this MUST be encoded as a CBOR map; if HTTP is used, the JSON encoding specified in Section 2.2 of [RFC7662] is used. The map containing the response payload includes the same required and optional parameters as in Section 2.2 of [RFC7662], with the following additions:
成功した応答では、ASはマップ内の応答パラメーターをエンコードします。COAPを使用する場合、これはCBORマップとしてエンコードする必要があります。HTTPを使用すると、[RFC7662]のセクション2.2で指定されたJSONエンコードが使用されます。応答ペイロードを含むマップには、[RFC7662]のセクション2.2と同じ必要なパラメーターとオプションのパラメーターが含まれ、次の追加が含まれています。
ace_profile This parameter is OPTIONAL. This indicates the profile that the RS MUST use with the client. See Section 5.8.4.3 for more details on the formatting of this parameter. If this parameter is absent, the AS assumes that the RS implicitly knows which profile to use towards the client.
ACE_Profileこのパラメーターはオプションです。これは、RSがクライアントで使用する必要があるプロファイルを示します。このパラメーターのフォーマットの詳細については、セクション5.8.4.3を参照してください。このパラメーターが存在しない場合、RSがクライアントに使用するプロファイルを暗黙的に知っていると想定しています。
cnonce This parameter is OPTIONAL. This is a client-nonce provided to the AS by the client. The RS MUST verify that this corresponds to the client-nonce previously provided to the client in the AS Request Creation Hints. See Sections 5.3 and 5.8.4.4. Its value is a byte string when encoded in CBOR and is the base64url encoding of this byte string without padding when encoded in JSON [RFC4648].
このパラメーターはオプションです。これは、クライアントがASに提供するクライアントノンセです。RSは、これがASリクエスト作成のヒントで以前に提供されたクライアントに対応することを確認する必要があります。セクション5.3および5.8.4.4を参照してください。その値は、CBORでエンコードされているときにバイト文字列であり、JSON [RFC4648]でエンコードされた場合、パディングなしでこのバイト文字列のbase64urlエンコードです。
cti This parameter is OPTIONAL. This is the cti claim associated to this access token. This parameter has the same meaning and processing rules as the jti parameter defined in Section 3.1.2 of [RFC7662] except that its value is a byte string when encoded in CBOR and is the base64url encoding of this byte string without padding when encoded in JSON [RFC4648].
CTIこのパラメーターはオプションです。これは、このアクセストークンに関連付けられたCTIクレームです。このパラメーターには、[RFC7662]のセクション3.1.2で定義されているJTIパラメーターと同じ意味と処理ルールがあります。[RFC4648]。
exi This parameter is OPTIONAL. This is the expires_in claim associated to this access token. See Section 5.10.3.
exiこのパラメーターはオプションです。これは、このアクセストークンに関連付けられている有効期限切れの請求です。セクション5.10.3を参照してください。
Furthermore, [RFC9201] defines more parameters that the AS MUST be able to use when responding to a request to the introspection endpoint.
さらに、[RFC9201]は、内省エンドポイントへのリクエストに応答するときにASが使用できる必要があるパラメーターを定義します。
For example, Figure 10 shows an AS response to the introspection request in Figure 8. Note that this example contains the cnf parameter defined in [RFC9201].
たとえば、図10は、図8の内省要求に対するAS応答を示しています。この例には、[RFC9201]で定義されたCNFパラメーターが含まれていることに注意してください。
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
/ active / 10 : true,
/ scope / 9 : "read",
/ ace_profile / 38 : 1 / coap_dtls /,
/ cnf / 8 : {
/ COSE_Key / 1 : {
/ kty / 1 : 4 / Symmetric /,
/ kid / 2 : b64'39Gqlw',
/ k / -1 : b64'hJtXhkV8FJG+Onbc6mxC'
}
}
}
Figure 10: Example Introspection Response
図10：イントロスペクティション応答の例
The error responses for CoAP-based interactions with the AS are equivalent to the ones for HTTP-based interactions, as defined in Section 2.3 of [RFC7662], with the following differences:
ASとのCOAPベースの相互作用のエラー応答は、[RFC7662]のセクション2.3で定義されているように、HTTPベースの相互作用のものと同等であり、次の違いがあります。
* If content is sent and CoAP is used, the payload MUST be encoded as a CBOR map and the Content-Format "application/ace+cbor" MUST be used. For HTTP, the encoding defined in Section 2.3 of [RFC6749] is used.
* コンテンツが送信され、COAPが使用される場合、ペイロードはCBORマップとしてエンコードする必要があり、コンテンツフォーマット「アプリケーション/ACE CBOR」を使用する必要があります。HTTPの場合、[RFC6749]のセクション2.3で定義されているエンコーディングが使用されます。
* If the credentials used by the requesting entity (usually the RS) are invalid, the AS MUST respond with the response code equivalent to the CoAP code 4.01 (Unauthorized) and use the required and optional parameters from Section 2.3 of [RFC7662].
* 要求エンティティ（通常はRS）が使用する資格情報が無効である場合、ASはCOAPコード4.01（不正）に相当する応答コードで応答する必要があり、[RFC7662]のセクション2.3から必要なパラメーターとオプションのパラメーターを使用します。
* If the requesting entity does not have the right to perform this introspection request, the AS MUST respond with a response code equivalent to the CoAP code 4.03 (Forbidden). In this case, no payload is returned.
* 要求エンティティにこの内省要求を実行する権利がない場合、ASはCOAPコード4.03（禁止）に相当する応答コードで応答する必要があります。この場合、ペイロードは返されません。
* The parameters error, error_description, and error_uri MUST be abbreviated using the codes specified in Table 5.
* 表5に指定されたコードを使用して、パラメーターエラー、error_description、およびerror_uriを省略する必要があります。
* The error codes MUST be abbreviated using the codes specified in the registry defined by Section 8.4.
* エラーコードは、セクション8.4で定義されたレジストリで指定されたコードを使用して省略する必要があります。
Note that a properly formed and authorized query for an inactive or otherwise invalid token does not warrant an error response by this specification. In these cases, the authorization server MUST instead respond with an introspection response with the active field set to "false".
非アクティブまたはその他の無効なトークンのために適切に形成および承認されたクエリは、この仕様によるエラー応答を保証しないことに注意してください。これらの場合、Authorization Serverは、「False」に設定されたアクティブフィールドを使用して、内省的応答で応答する必要があります。
If CBOR is used, the introspection request and response parameters MUST be mapped to CBOR types, as specified in the registry defined by Section 8.12, using the given integer abbreviation for the map key.
CBORを使用する場合、MAPキーの指定された整数の略語を使用して、セクション8.12で定義されているレジストリで指定されているように、内省要求と応答パラメーターをCBORタイプにマッピングする必要があります。
Note that we have aligned abbreviations that correspond to a claim with the abbreviations defined in [RFC8392] and the abbreviations of parameters with the same name from Section 5.8.5.
[RFC8392]で定義されている略語との主張に対応する略語と、セクション5.8.5の同じ名前のパラメーターの略語を調整したことに注意してください。
+===================+======+======================+===============+
| Parameter name | CBOR | Value Type | Original |
| | Key | | Specification |
+===================+======+======================+===============+
| iss | 1 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| sub | 2 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| aud | 3 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| exp | 4 | integer or floating- | [RFC7662] |
| | | point number | |
+-------------------+------+----------------------+---------------+
| nbf | 5 | integer or floating- | [RFC7662] |
| | | point number | |
+-------------------+------+----------------------+---------------+
| iat | 6 | integer or floating- | [RFC7662] |
| | | point number | |
+-------------------+------+----------------------+---------------+
| cti | 7 | byte string | RFC 9200 |
+-------------------+------+----------------------+---------------+
| scope | 9 | text or byte string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| active | 10 | True or False | [RFC7662] |
+-------------------+------+----------------------+---------------+
| token | 11 | byte string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| client_id | 24 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| error | 30 | integer | [RFC7662] |
+-------------------+------+----------------------+---------------+
| error_description | 31 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| error_uri | 32 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| token_type_hint | 33 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| token_type | 34 | integer | [RFC7662] |
+-------------------+------+----------------------+---------------+
| username | 35 | text string | [RFC7662] |
+-------------------+------+----------------------+---------------+
| ace_profile | 38 | integer | RFC 9200 |
+-------------------+------+----------------------+---------------+
| cnonce | 39 | byte string | RFC 9200 |
+-------------------+------+----------------------+---------------+
| exi | 40 | unsigned integer | RFC 9200 |
+-------------------+------+----------------------+---------------+
Table 6: CBOR Mappings for Token Introspection Parameters
表6：トークン内省パラメーターのCBORマッピング
In this framework, the use of CBOR Web Token (CWT) as specified in [RFC8392] is RECOMMENDED.
このフレームワークでは、[RFC8392]で指定されているCbor Webトークン（CWT）の使用が推奨されます。
In order to facilitate offline processing of access tokens, this document uses the cnf claim from [RFC8747] and the scope claim from [RFC8693] for JWT- and CWT-encoded tokens. In addition to string encoding specified for the scope claim, a binary encoding MAY be used. The syntax of such an encoding is explicitly not specified here and left to profiles or applications, specifically note that a binary encoded scope does not necessarily use the space character '0x20' to delimit scope-tokens.
アクセストークンのオフライン処理を容易にするために、このドキュメントでは、JWTおよびCWTエンコードトークンの[RFC8747]からのCNFクレームと[RFC8693]からのスコープクレームを使用します。スコープクレームに指定された文字列エンコードに加えて、バイナリエンコードを使用することができます。このようなエンコーディングの構文は、ここで明示的に指定されておらず、プロファイルまたはアプリケーションに任されています。特に、バイナリエンコードされたスコープでは、スペース文字「0x20」を使用してスコープトークンを区切るとは限らないことに注意してください。
If the AS needs to convey a hint to the RS about which profile it should use to communicate with the client, the AS MAY include an ace_profile claim in the access token, with the same syntax and semantics as defined in Section 5.8.4.3.
必要な場合、クライアントと通信するために使用するプロファイルについてのヒントをRSに伝える必要がある場合、ASには、セクション5.8.4.3で定義されている同じ構文とセマンティクスを使用して、アクセストークンにACE_Profileクレームが含まれる場合があります。
If the client submitted a cnonce parameter in the access token request (Section 5.8.4.4), the AS MUST include the value of this parameter in the cnonce claim specified here. The cnonce claim uses binary encoding.
クライアントがアクセストークン要求（セクション5.8.4.4）にcnonceパラメーターを提出した場合、ASには、ここで指定されたcnonceクレームにこのパラメーターの値を含める必要があります。CNONCEクレームはバイナリエンコーディングを使用します。
The access token, containing authorization information and information about the proof-of-possession method used by the client, needs to be transported to the RS so that the RS can authenticate and authorize the client request.
クライアントが使用する承認情報と所有権の証明方法に関する情報を含むアクセストークンは、RSがクライアントリクエストを認証および承認できるように、RSに輸送する必要があります。
This section defines a method for transporting the access token to the RS using a RESTful protocol, such as CoAP. Profiles of this framework MAY define other methods for token transport.
このセクションでは、COAPなどのRESTFULプロトコルを使用して、アクセストークンをRSに輸送する方法を定義します。このフレームワークのプロファイルは、トークン輸送の他の方法を定義する場合があります。
The method consists of an authz-info endpoint, implemented by the RS. A client using this method MUST make a POST request to the authz-info endpoint at the RS with the access token in the payload. The CoAP Content-Format or HTTP media type MUST reflect the format of the token, e.g., "application/cwt", for CBOR Web Tokens; if no Content-Format or media type is defined for the token format, "application/ octet-stream" MUST be used.
この方法は、Rsによって実装されたAuthZ-INFOエンドポイントで構成されています。この方法を使用するクライアントは、ペイロードにアクセストークンを使用して、RSのAuthZ-INFOエンドポイントにPOSTリクエストを行う必要があります。COAPコンテンツフォーマットまたはHTTPメディアタイプは、CBOR Webトークンのトークン、たとえば「アプリケーション/CWT」の形式を反映する必要があります。トークン形式でコンテンツフォーマットまたはメディアタイプが定義されていない場合、「アプリケーション/オクテットストリーム」を使用する必要があります。
The RS receiving the token MUST verify the validity of the token. If the token is valid, the RS MUST respond to the POST request with a response code equivalent to CoAP code 2.01 (Created). Section 5.10.1.1 outlines how an RS MUST proceed to verify the validity of an access token.
トークンを受け取るRSは、トークンの有効性を検証する必要があります。トークンが有効な場合、RSはCOAPコード2.01（作成）に相当する応答コードでPOSTリクエストに応答する必要があります。セクション5.10.1.1は、RSがアクセストークンの有効性を検証するためにどのように進む必要があるかを概説しています。
The RS MUST be prepared to store at least one access token for future use. This is a difference as to how access tokens are handled in OAuth 2.0, where the access token is typically sent along with each request and therefore not stored at the RS.
RSは、将来の使用のために少なくとも1つのアクセストークンを保存するために準備する必要があります。これは、アクセストークンがOAUTH 2.0で処理される方法の違いです。ここでは、アクセストークンは通常、各リクエストとともに送信されるため、RSに保存されません。
When using this framework, it is RECOMMENDED that an RS stores only one token per proof-of-possession key. This means that an additional token linked to the same key will supersede any existing token at the RS by replacing the corresponding authorization information. The reason is that this greatly simplifies (constrained) implementations, with respect to required storage and resolving a request to the applicable token. The use of multiple access tokens for a single client increases the strain on the resource server, as it must consider every access token and calculate the actual permissions of the client. Also, tokens may contradict each other, which may lead the server to enforce wrong permissions. If one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection.
このフレームワークを使用する場合、RSは、プルーフオブポッセッションキーごとに1つのトークンのみを保存することをお勧めします。これは、同じキーにリンクされた追加のトークンが、対応する承認情報を置き換えることにより、RSの既存のトークンに取って代わることを意味します。その理由は、これにより、必要なストレージと該当するトークンへの要求の解決に関して、実装が大幅に簡素化されるためです。単一のクライアントに複数のアクセストークンを使用すると、すべてのアクセストークンを考慮し、クライアントの実際のアクセス許可を計算する必要があるため、リソースサーバーのひずみが増加します。また、トークンは互いに矛盾する可能性があり、サーバーが間違った許可を実施するように導く可能性があります。アクセストークンの1つが他のものよりも早く期限切れになった場合、結果として生じる権限は保護が不十分である可能性があります。
If the payload sent to the authz-info endpoint does not parse to a token, the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request).
authz-infoエンドポイントに送信されたペイロードがトークンに解析されない場合、RSはCOAPコード4.00に相当する応答コード（悪い要求）で応答する必要があります。
The RS MAY make an introspection request to validate the token before responding to the POST request to the authz-info endpoint, e.g., if the token is an opaque reference. Some transport protocols may provide a way to indicate that the RS is busy and the client should retry after an interval; this type of status update would be appropriate while the RS is waiting for an introspection response.
RSは、トークンが不透明な参照である場合、authz-infoエンドポイントへのPOSTリクエストに応答する前に、トークンを検証するために内省要求を行う場合があります。一部の輸送プロトコルは、RSが忙しく、クライアントが間隔後に再試行することを示す方法を提供する場合があります。RSが内省的応答を待っている間、このタイプのステータスの更新が適切です。
Profiles MUST specify whether the authz-info endpoint is protected, including whether error responses from this endpoint are protected. Note that since the token contains information that allows the client and the RS to establish a security context in the first place, mutual authentication may not be possible at this point.
プロファイルは、このエンドポイントからのエラー応答が保護されているかどうかなど、AUTHZ-INFOエンドポイントが保護されているかどうかを指定する必要があります。トークンには、クライアントとRSがそもそもセキュリティコンテキストを確立できるようにする情報が含まれているため、この時点で相互認証は不可能かもしれないことに注意してください。
The default name of this endpoint in a url-path is '/authz-info'; however, implementations are not required to use this name and can define their own instead.
URLパスのこのエンドポイントのデフォルト名は「/authz-info」です。ただし、実装はこの名前を使用する必要はなく、代わりに独自の名前を定義できます。
When an RS receives an access token, it MUST verify it before storing it. The details of token verification depends on various aspects, including the token encoding, the type of token, the security protection applied to the token, and the claims. The token encoding matters since the security protection differs between the token encodings. For example, a CWT token uses COSE, while a JWT token uses JSON Object Signing and Encryption (JOSE). The type of token also has an influence on the verification procedure since tokens may be self-contained, whereby token verification may happen locally at the RS, while a reference token requires further interaction with the authorization server, for example, using token introspection, to obtain the claims associated with the token reference. Self-contained tokens MUST at least be integrity protected, but they MAY also be encrypted.
RSがアクセストークンを受け取ったら、保存する前に確認する必要があります。トークン検証の詳細は、トークンエンコード、トークンの種類、トークンに適用されるセキュリティ保護、クレームなど、さまざまな側面に依存します。セキュリティ保護はトークンエンコーディング間で異なるため、トークンエンコードが重要です。たとえば、CWTトークンはCOSEを使用しますが、JWTトークンはJSONオブジェクトの署名と暗号化（Jose）を使用します。トークンのタイプは、トークンが自己完結型である可能性があるため、検証手順にも影響を及ぼします。トークンリファレンスに関連するクレームを取得します。自己完結型トークンは、少なくとも整合性保護されている必要がありますが、暗号化される場合もあります。
For self-contained tokens, the RS MUST process the security protection of the token first, as specified by the respective token format. For CWT, the description can be found in [RFC8392]; for JWT, the relevant specification is [RFC7519]. This MUST include a verification that security protection (and thus the token) was generated by an AS that has the right to issue access tokens for this RS.
自己完結型トークンの場合、RSは、それぞれのトークン形式で指定されているように、最初にトークンのセキュリティ保護を処理する必要があります。CWTの場合、説明は[RFC8392]に記載されています。JWTの場合、関連する仕様は[RFC7519]です。これには、セキュリティ保護（したがってトークン）が、このRsのアクセストークンを発行する権利を有するASによって生成されたという検証を含める必要があります。
In case the token is communicated by reference, the RS needs to obtain the claims first. When the RS uses token introspection, the relevant specification is [RFC7662] with CoAP transport specified in Section 5.9.
トークンが参照によって通信された場合、RSは最初にクレームを取得する必要があります。RSがトークン内省を使用する場合、関連する仕様は[RFC7662]で、セクション5.9で指定されたCOAP輸送があります。
Errors may happen during this initial processing stage:
この初期処理段階でエラーが発生する可能性があります。
* If the verification of the security wrapper fails, or the token was issued by an AS that does not have the right to issue tokens for the receiving RS, the RS MUST discard the token and, if this was an interaction with authz-info, return an error message with a response code equivalent to the CoAP code 4.01 (Unauthorized).
* セキュリティラッパーの検証が失敗した場合、またはトークンが受信RSのトークンを発行する権利を持たないASによってトークンが発行された場合、RSはトークンを破棄しなければなりません。COAPコード4.01（不正）に相当する応答コードを持つエラーメッセージ。
* If the claims cannot be obtained, the RS MUST discard the token and, in case of an interaction via the authz-info endpoint, return an error message with a response code equivalent to the CoAP code 4.00 (Bad Request).
* クレームを取得できない場合、RSはトークンを破棄し、authz-infoエンドポイントを介した相互作用の場合、COAPコード4.00（悪い要求）に相当する応答コードを持つエラーメッセージを返します。
Next, the RS MUST verify claims, if present, contained in the access token. Errors are returned when claim checks fail, in the order of priority of this list:
次に、RSは、存在する場合、アクセストークンに含まれるクレームを検証する必要があります。このリストの優先順位で、クレームチェックが失敗したときにエラーが返されます。
iss The iss claim (if present) must identify the AS that has produced the security protection for the access token. If that is not the case, the RS MUST discard the token. If this was an interaction with authz-info, the RS MUST also respond with a response code equivalent to the CoAP code 4.01 (Unauthorized).
ISS請求（存在する場合）は、アクセストークンのセキュリティ保護を生み出したASを特定する必要があります。そうでない場合、RSはトークンを破棄する必要があります。これがauthz-infoとの相互作用である場合、RSはまた、COAPコード4.01（不正）に相当する応答コードで応答する必要があります。
exp The expiration date must be in the future. If that is not the case, the RS MUST discard the token. If this was an interaction with authz-info, the RS MUST also respond with a response code equivalent to the CoAP code 4.01 (Unauthorized). Note that the RS has to terminate access rights to the protected resources at the time when the tokens expire.
Exp有効期限は将来的になければなりません。そうでない場合、RSはトークンを破棄する必要があります。これがauthz-infoとの相互作用である場合、RSはまた、COAPコード4.01（不正）に相当する応答コードで応答する必要があります。RSは、トークンが期限切れになったときに保護されたリソースへのアクセス権を終了する必要があることに注意してください。
aud The aud claim must refer to an audience that the RS identifies with. If that is not the case, the RS MUST discard the token. If this was an interaction with authz-info, the RS MUST also respond with a response code equivalent to the CoAP code 4.03 (Forbidden).
AUDは、RSが識別する聴衆を指す必要があります。そうでない場合、RSはトークンを破棄する必要があります。これがauthz-infoとの相互作用である場合、RSはCOAPコード4.03（禁止）に相当する応答コードでも応答する必要があります。
scope The RS must recognize value of the scope claim. If that is not the case, the RS MUST discard the token. If this was an interaction with authz-info, the RS MUST also respond with a response code equivalent to the CoAP code 4.00 (Bad Request). The RS MAY provide additional information in the error response to clarify what went wrong.
スコープRSは、スコープクレームの価値を認識する必要があります。そうでない場合、RSはトークンを破棄する必要があります。これがauthz-infoとの相互作用である場合、RSはまた、COAPコード4.00（悪い要求）に相当する応答コードで応答する必要があります。RSは、エラー応答の追加情報を提供して、何がうまくいかなかったかを明確にすることができます。
Additional processing may be needed for other claims in a way specific to a profile or the underlying application.
プロファイルまたは基礎となるアプリケーションに固有の方法で、他のクレームには追加の処理が必要になる場合があります。
Note that the sub (Subject) claim cannot always be verified when the token is submitted to the RS since the client may not have authenticated yet. Also note that a counter for the exi (expires in) claim MUST be initialized when the RS first verifies this token.
クライアントがまだ認証されていない可能性があるため、トークンがRSに提出された場合、サブ（サブジェクト）クレームを常に確認することはできないことに注意してください。また、RSが最初にこのトークンを検証したときに、EXI（有効期限が切れる）クレームのカウンター（有効期限が切れる）は初期化する必要があることに注意してください。
Also note that profiles of this framework may define access token transport mechanisms that do not allow for error responses. Therefore, the error messages specified here only apply if the token was sent to the authz-info endpoint.
また、このフレームワークのプロファイルは、エラー応答を許可しないアクセストークン輸送メカニズムを定義する場合があることに注意してください。したがって、ここで指定されたエラーメッセージは、トークンがAuthz-INFOエンドポイントに送信された場合にのみ適用されます。
When sending error responses, the RS MAY use the error codes from Section 3.1 of [RFC6750] to provide additional details to the client.
エラー応答を送信する場合、RSは[RFC6750]のセクション3.1のエラーコードを使用して、クライアントに追加の詳細を提供する場合があります。
As this framework can be used in RESTful environments, it is important to make sure that attackers cannot perform unauthorized requests on the authz-info endpoints, other than submitting access tokens.
このフレームワークは、Restful環境で使用できるため、アクセストークンを送信する以外に、AuthZ-INFOエンドポイントで攻撃者が不正なリクエストを実行できないことを確認することが重要です。
Specifically, it SHOULD NOT be possible to perform GET, DELETE, or PUT on the authz-info endpoint.
具体的には、authz-infoエンドポイントをGET、削除、または配置することはできないはずです。
The RS SHOULD implement rate-limiting measures to mitigate attacks aiming to overload the processing capacity of the RS by repeatedly submitting tokens. For CoAP-based communication, the RS could use the mechanisms from [RFC8516] to indicate that it is overloaded.
RSは、トークンを繰り返し提出することにより、RSの処理能力を過負荷にすることを目的とした攻撃を緩和するためのレート制限措置を実装する必要があります。COAPベースの通信の場合、RSは[RFC8516]のメカニズムを使用して、それが過負荷であることを示します。
Before sending a request to an RS, the client MUST verify that the keys used to protect this communication are still valid. See Section 5.10.4 for details on how the client determines the validity of the keys used.
RSにリクエストを送信する前に、クライアントは、この通信を保護するために使用されるキーがまだ有効であることを確認する必要があります。クライアントが使用するキーの有効性をどのように決定するかの詳細については、セクション5.10.4を参照してください。
If an RS receives a request from a client and the target resource requires authorization, the RS MUST first verify that it has an access token that authorizes this request and that the client has performed the proof-of-possession binding for that token to the request.
RSがクライアントからリクエストを受信し、ターゲットリソースが許可を必要とする場合、RSはまず、このリクエストを承認するアクセストークンがあること、およびクライアントがそのトークンに対してリクエストへの入金の証明バインディングを実行したことを確認する必要があります。。
The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof of possession or if the RS has no valid access token for the client. If the RS has an access token for the client but the token does not authorize access for the resource that was requested, the RS MUST reject the request with a 4.03 (Forbidden). If the RS has an access token for the client but it does not cover the action that was requested on the resource, the RS MUST reject the request with a 4.05 (Method Not Allowed).
クライアントが所有証明を実行していない場合、またはRSにクライアントの有効なアクセストークンがない場合、応答コードは4.01（不正）でなければなりません。RSにクライアントにアクセストークンがあるが、トークンが要求されたリソースのアクセスを許可しない場合、RSは4.03（禁止）でリクエストを拒否する必要があります。RSにクライアントにアクセストークンがあるが、リソースで要求されたアクションをカバーしていない場合、RSは4.05（許可されていない方法）でリクエストを拒否する必要があります。
Note: The use of the response codes 4.03 and 4.05 is intended to prevent infinite loops where a client optimistically tries to access a requested resource with any access token received from AS. As malicious clients could pretend to be the C to determine the C's privileges, these detailed response codes must be used only when a certain level of security is already available, which can be achieved only when the client is authenticated.
注：応答コード4.03および4.05の使用は、クライアントがASから受け取ったアクセストークンを備えた要求されたリソースに楽観的にアクセスしようとする無限ループを防ぐことを目的としています。悪意のあるクライアントはCの特権を決定するためにCのふりをすることができるため、これらの詳細な応答コードは、特定のレベルのセキュリティがすでに利用可能である場合にのみ使用する必要があります。
Note: The RS MAY use introspection for timely validation of an access token at the time when a request is presented.
注：RSは、リクエストが提示されたときにアクセストークンのタイムリーな検証に内省を使用する場合があります。
Note: Matching the claims of the access token (e.g., scope) to a specific request is application specific.
注：アクセストークン（例：スコープ）のクレームを特定のリクエストに一致させることは、アプリケーション固有です。
If the request matches a valid token and the client has performed the proof of possession for that token, the RS continues to process the request as specified by the underlying application.
リクエストが有効なトークンと一致し、クライアントがそのトークンの所有証明を実行した場合、RSは基礎となるアプリケーションで指定されたようにリクエストを処理し続けます。
Depending on the capabilities of the RS, there are various ways in which it can verify the expiration of a received access token. The following is a list of the possibilities including what functionality they require of the RS.
RSの機能に応じて、受信したアクセストークンの有効期限を検証できるさまざまな方法があります。以下は、Rsに必要な機能を含む可能性のリストです。
* The token is a CWT and includes an exp claim and possibly the nbf claim. The RS verifies these by comparing them to values from its internal clock, as defined in [RFC7519]. In this case, the RS's internal clock must reflect the current date and time or at least be synchronized with the AS's clock. How this clock synchronization would be performed is out of scope for this specification.
* トークンはCWTであり、EXP請求と場合によってはNBFクレームが含まれています。RSは、[RFC7519]で定義されているように、内部クロックからの値と比較することにより、これらを検証します。この場合、RSの内部時計は現在の日付と時刻を反映するか、少なくともASの時計と同期する必要があります。この仕様のこのクロック同期がどのように実行されるかは、範囲外です。
* The RS verifies the validity of the token by performing an introspection request, as specified in Section 5.9. This requires the RS to have a reliable network connection to the AS and to be able to handle two secure sessions in parallel (C to RS and RS to AS).
* RSは、セクション5.9で指定されているように、内省要求を実行することにより、トークンの妥当性を検証します。これには、RSがASへの信頼性の高いネットワーク接続を持ち、2つの安全なセッションを並行して（CからRSおよびRSからAS）処理できる必要があります。
* In order to support token expiration for devices that have no reliable way of synchronizing their internal clocks, this specification defines the following approach: The claim exi (expires in) can be used to provide the RS with the lifetime of the token in seconds from the time the RS first receives the token. This mechanism only works for self-contained tokens, i.e., CWTs and JWTs. For CWTs, this parameter is encoded as an unsigned integer, while JWTs encode this as JSON number.
* 内部クロックを同期する信頼できる方法のないデバイスのトークンの有効期限をサポートするために、この仕様は次のアプローチを定義します。RSが最初にトークンを受信する時間。このメカニズムは、自己完結型のトークン、つまりCWTSおよびJWTSでのみ機能します。CWTSの場合、このパラメーターは符号なし整数としてエンコードされ、JWTSはこれをJSON番号としてエンコードします。
* Processing this claim requires that the RS does the following:
* このクレームの処理には、RSが次のことを行う必要があります。
- For each token the RS receives that contains an exi claim, keep track of the time it received that token and revisit that list regularly to expunge expired tokens.
- トークンごとに、EXIクレームを含むRS受信を受信し、そのトークンを受け取った時間を追跡し、そのリストを定期的に再検討して、期限切れのトークンを抹消します。
- Keep track of the identifiers of tokens containing the exi claim that have expired (in order to avoid accepting them again). In order to avoid an unbounded memory usage growth, this MUST be implemented in the following way when the exi claim is used:
- 有効期限が切れているEXIクレームを含むトークンの識別子を追跡してください（再度受け入れないように）。固定されていないメモリの使用の成長を回避するには、EXIクレームが使用される場合、これは次の方法で実装する必要があります。
o When creating the token, the AS MUST add a cti claim (or jti for JWTs) to the access token. The value of this claim MUST be created as the binary representation of the concatenation of the identifier of the RS with a sequence number counting the tokens containing an exi claim, issued by this AS for the RS.
o トークンを作成するとき、ASはアクセストークンにCTIクレーム（またはJWTのJTI）を追加する必要があります。このクレームの値は、RSに関して発行されたEXI請求を含むトークンをカウントするシーケンス番号を使用したRSの識別子の連結のバイナリ表現として作成する必要があります。
o The RS MUST store the highest sequence number of an expired token containing the exi claim that it has seen and treat tokens with lower sequence numbers as expired. Note that this could lead to discarding valid tokens with lower sequence numbers if the AS where to issue tokens of different validity time for the same RS. The assumption is that typically tokens in such a scenario would all have the same validity time.
o RSは、EXIを含む有効期限が切れたトークンの最高のシーケンス数を、期限切れに応じて低いシーケンス数でトークンを見て処理したという主張を保存する必要があります。これにより、同じRsの異なる妥当性時間のトークンを発行する場所として、シーケンス数が低い有効なトークンを破棄する可能性があることに注意してください。仮定は、通常、このようなシナリオのトークンにはすべて同じ妥当性時間があるということです。
If a token that authorizes a long-running request, such as a CoAP Observe [RFC7641], expires, the RS MUST send an error response with the response code equivalent to the CoAP code 4.01 (Unauthorized) to the client and then terminate processing the long-running request.
COAP Observe [RFC7641]などの長期にわたるリクエストを承認するトークンは、COAPコード4.01（不正）に相当する応答コードでエラー応答をクライアントに送信し、処理を終了する必要があります。長期にわたるリクエスト。
The AS provides the client with key material that the RS uses. This can either be a common symmetric PoP key or an asymmetric key used by the RS to authenticate towards the client. Since there is currently no expiration metadata associated to those keys, the client has no way of knowing if these keys are still valid. This may lead to situations where the client sends requests containing sensitive information to the RS using a key that is expired and possibly in the hands of an attacker or where the client accepts responses from the RS that are not properly protected and could possibly have been forged by an attacker.
ASは、RSが使用する重要な資料をクライアントに提供します。これは、一般的な対称ポップキーまたはRSがクライアントに認証するために使用する非対称キーのいずれかです。現在、これらのキーに関連付けられた有効期限メタデータはないため、クライアントはこれらのキーがまだ有効かどうかを知る方法がありません。これにより、クライアントが有効期限が切れ、場合によっては攻撃者の手にあるキーを使用して、機密情報を含むリクエストをRSに送信する状況につながる可能性があります。攻撃者によって。
In order to prevent this, the client must assume that those keys are only valid as long as the related access token is. Since the access token is opaque to the client, one of the following methods MUST be used to inform the client about the validity of an access token:
これを防ぐために、クライアントは、関連するアクセストークンがある限り、これらのキーが有効であると想定する必要があります。アクセストークンはクライアントにとって不透明であるため、次の方法の1つを使用して、アクセストークンの有効性についてクライアントに通知する必要があります。
* The client knows a default validity time for all tokens it is using (i.e., how long a token is valid after being issued). This information could be provisioned to the client when it is registered at the AS or published by the AS in a way that the client can query.
* クライアントは、使用しているすべてのトークンのデフォルトの妥当性時間を知っています（つまり、発行後にトークンが有効になる時間）。この情報は、クライアントがASに登録されている場合、またはクライアントがクライアントがクエリできる方法で公開されたときにクライアントにプロビジョニングすることができます。
* The AS informs the client about the token validity using the expires_in parameter in the Access Information.
* ASは、アクセス情報のexpires_inパラメーターを使用したトークンの妥当性についてクライアントに通知します。
A client that is not able to obtain information about the expiration of a token MUST NOT use this token.
トークンの有効期限に関する情報を取得できないクライアントは、このトークンを使用してはなりません。
Security considerations applicable to authentication and authorization in RESTful environments provided in OAuth 2.0 [RFC6749] apply to this work. Furthermore, [RFC6819] provides additional security considerations for OAuth, which apply to IoT deployments as well. If the introspection endpoint is used, the security considerations from [RFC7662] also apply.
OAUTH 2.0 [RFC6749]で提供される安らかな環境での認証と認証に適用されるセキュリティ上の考慮事項この作業には適用されます。さらに、[RFC6819]は、IoTの展開にも適用されるOAUTHに追加のセキュリティ上の考慮事項を提供します。内省エンドポイントを使用する場合、[RFC7662]からのセキュリティに関する考慮事項も適用されます。
The following subsections address issues specific to this document and its use in constrained environments.
次のサブセクションは、このドキュメントに固有の問題と制約付き環境での使用に対処します。
A large range of threats can be mitigated by protecting the contents of the access token by using a digital signature or a keyed message digest, e.g., a Message Authentication Code (MAC) or an Authenticated Encryption with Associated Data (AEAD) algorithm. Consequently, the token integrity protection MUST be applied to prevent the token from being modified, particularly since it contains a reference to the symmetric key or the asymmetric key used for proof of possession. If the access token contains the symmetric key, this symmetric key MUST be encrypted by the authorization server so that only the resource server can decrypt it. Note that using an AEAD algorithm is preferable over using a MAC unless the token needs to be publicly readable.
デジタル署名またはキー付きメッセージダイジェスト、例えばメッセージ認証コード（MAC）または関連データ（AEAD）アルゴリズムを使用した認証された暗号化を使用して、アクセストークンの内容を保護することにより、さまざまな脅威を軽減できます。その結果、トークンが修正されないようにするために、トークンの整合性保護を適用する必要があります。これは、特に対称キーまたは所持の証明に使用される非対称キーへの参照が含まれているためです。アクセストークンに対称キーが含まれている場合、この対称キーは、リソースサーバーのみがそれを解読できるように、承認サーバーによって暗号化される必要があります。トークンが公開されている必要がない限り、AEADアルゴリズムを使用することはMacの使用よりも好ましいことに注意してください。
If the token is intended for multiple recipients (i.e., an audience that is a group), integrity protection of the token with a symmetric key, shared between the AS and the recipients, is not sufficient, since any of the recipients could modify the token undetected by the other recipients. Therefore, a token with a multirecipient audience MUST be protected with an asymmetric signature.
トークンが複数の受信者（つまり、グループであるオーディエンス）を対象としている場合、ASと受信者の間で共有される対称キーを持つトークンの整合性保護は十分ではありません。他の受信者によって検出されない。したがって、マルチリサイパントオーディエンスを備えたトークンは、非対称の署名で保護する必要があります。
It is important for the authorization server to include the identity of the intended recipient (the audience), typically a single resource server (or a list of resource servers), in the token. The same shared secret MUST NOT be used as a proof-of-possession key with multiple resource servers, since the benefit from using the proof-of-possession concept is then significantly reduced.
承認サーバーが、トークンに、通常、単一のリソースサーバー（またはリソースサーバーのリスト）の意図した受信者（聴衆）のIDを含めることが重要です。Proof-ossessionコンセプトを使用することによる利点が大幅に削減されるため、複数のリソースサーバーを使用して、同じ共有の秘密を、複数のリソースサーバーを使用したプルーフオブポッセッションキーとして使用してはなりません。
If clients are capable of doing so, they should frequently request fresh access tokens, as this allows the AS to keep the lifetime of the tokens short. This allows the AS to use shorter proof-of-possession key sizes, which translate to a performance benefit for the client and for the resource server. Shorter keys also lead to shorter messages (particularly with asymmetric keying material).
クライアントがそうすることができる場合、彼らは頻繁に新鮮なアクセストークンを要求する必要があります。これにより、トークンの寿命を短く保つことができます。これにより、より短いProof-of-Possessionキーサイズを使用できます。これは、クライアントとリソースサーバーのパフォーマンスメリットに変換されます。短いキーは、より短いメッセージにもつながります（特に非対称キーイング材料を使用）。
When authorization servers bind symmetric keys to access tokens, they SHOULD scope these access tokens to a specific permission.
承認サーバーが対称キーをバインドしてトークンにアクセスする場合、これらのアクセストークンを特定の許可にスコープする必要があります。
In certain situations, it may be necessary to revoke an access token that is still valid. Client-initiated revocation is specified in [RFC7009] for OAuth 2.0. Other revocation mechanisms are currently not specified, as the underlying assumption in OAuth is that access tokens are issued with a relatively short lifetime. This may not hold true for disconnected constrained devices needing access tokens with relatively long lifetimes and would therefore necessitate further standardization work that is out of scope for this document.
特定の状況では、まだ有効なアクセストークンを取り消す必要がある場合があります。クライアントが開始する取り消しは、OAUTH 2.0の[RFC7009]で指定されています。OAuthの根本的な仮定は、アクセストークンが比較的短い寿命で発行されることであるため、他の取り消しメカニズムは現在指定されていません。これは、比較的長い寿命でアクセストークンを必要とする切断された制約付きデバイスには当てはまらない場合があり、したがって、このドキュメントの範囲外のさらなる標準化作業が必要になります。
Communication with the authorization server MUST use confidentiality protection. This step is extremely important since the client or the RS may obtain the proof-of-possession key from the authorization server for use with a specific access token. Not using confidentiality protection exposes this secret (and the access token) to an eavesdropper, thereby completely negating proof-of-possession security. The requirements for communication security of profiles are specified in Section 5.
Authorization Serverとの通信は、機密保護を使用する必要があります。クライアントまたはRSは、特定のアクセストークンで使用するために承認サーバーからプルーフポッセッションキーを取得する可能性があるため、このステップは非常に重要です。機密保護を使用しないことで、この秘密（およびアクセストークン）が盗聴者にさらされ、それにより、所有の証明のセキュリティを完全に否定します。プロファイルの通信セキュリティの要件は、セクション5で指定されています。
Additional protection for the access token can be applied by encrypting it, for example, encryption of CWTs is specified in Section 7.1 of [RFC8392]. Such additional protection can be necessary if the token is later transferred over an insecure connection (e.g., when it is sent to the authz-info endpoint).
アクセストークンの追加保護は、それを暗号化することで適用できます。たとえば、CWTSの暗号化は[RFC8392]のセクション7.1で指定されています。トークンが後で安全でない接続（たとえば、authz-infoエンドポイントに送信された場合）にトークンが転送される場合、このような追加の保護が必要になる場合があります。
Care must be taken by developers to prevent leakage of the PoP credentials (i.e., the private key or the symmetric key). An adversary in possession of the PoP credentials bound to the access token will be able to impersonate the client. Be aware that this is a real risk with many constrained environments, since adversaries may get physical access to the devices and can therefore use physical extraction techniques to gain access to memory contents. This risk can be mitigated to some extent by making sure that keys are refreshed frequently, by using software isolation techniques, and by using hardware security.
POP資格情報（つまり、秘密鍵または対称キー）の漏れを防ぐために、開発者が注意する必要があります。アクセストークンに縛られたポップ資格を所有する敵は、クライアントになりすまします。敵はデバイスに物理的にアクセスできるため、物理的な抽出技術を使用してメモリコンテンツにアクセスできるため、これは多くの制約された環境での実際のリスクであることに注意してください。このリスクは、キーが頻繁に更新されることを確認し、ソフトウェア分離技術を使用し、ハードウェアセキュリティを使用することにより、ある程度緩和できます。
Both the clients and RSs have long-term credentials that are used to secure communications and authenticate to the AS. These credentials need to be protected against unauthorized access. In constrained devices deployed in publicly accessible places, such protection can be difficult to achieve without specialized hardware (e.g., secure key storage memory).
クライアントとRSSの両方が、通信を確保し、ASに認証するために使用される長期的な資格情報を持っています。これらの資格情報は、不正アクセスから保護する必要があります。公的にアクセス可能な場所に展開された制約付きデバイスでは、そのような保護は、特殊なハードウェア（たとえば、セキュアなキーストレージメモリなど）なしで達成するのが難しい場合があります。
If credentials are lost or compromised, the operator of the affected devices needs to have procedures to invalidate any access these credentials give and needs to revoke tokens linked to such credentials. The loss of a credential linked to a specific device MUST NOT lead to a compromise of other credentials not linked to that device; therefore, secret keys used for authentication MUST NOT be shared between more than two parties.
資格情報が紛失または侵害されている場合、影響を受けるデバイスのオペレーターは、これらの資格情報が提供するアクセスを無効にする手順を持つ必要があり、そのような資格情報にリンクされたトークンを取り消す必要があります。特定のデバイスにリンクされた資格情報の損失は、そのデバイスにリンクされていない他の資格情報の妥協につながってはなりません。したがって、認証に使用されるシークレットキーは、2つ以上の当事者間で共有してはなりません。
Operators of the clients or RSs SHOULD have procedures in place to replace credentials that are suspected to have been compromised or that have been lost.
クライアントまたはRSSのオペレーターは、侵害されたと疑われる資格情報を置き換えるための手順を導入する必要があります。
Operators also SHOULD have procedures for decommissioning devices that include securely erasing credentials and other security-critical material in the devices being decommissioned.
また、オペレーターは、廃止されているデバイス内の資格情報やその他のセキュリティ批判的な資料を安全に消去することを含む廃止措置デバイスの手順を持つ必要があります。
Initially, no secure channel exists to protect the communication between the C and RS. Thus, the C cannot determine if the AS Request Creation Hints contained in an unprotected response from the RS to an unauthorized request (see Section 5.3) are authentic. Therefore, the C MUST determine if an AS is authorized to provide access tokens for a certain RS. How this determination is implemented is out of scope for this document and left to the applications.
当初、CとRsの間の通信を保護するための安全なチャネルは存在しません。したがって、Cは、RSから不正リクエスト（セクション5.3を参照）への保護されていない応答に含まれるASリクエスト作成ヒントが本物であるかどうかを判断できません。したがって、Cは、特定のRsにアクセストークンを提供することが許可されているASが許可されているかどうかを判断する必要があります。この決定の実装方法は、このドキュメントの範囲外であり、アプリケーションに任されています。
This section summarizes the minimal requirements for the communication security of the different protocol interactions.
このセクションでは、さまざまなプロトコル相互作用の通信セキュリティに関する最小限の要件をまとめたものです。
C-AS All communication between the client and the authorization server MUST be encrypted and integrity and replay protected. Furthermore, responses from the AS to the client MUST be bound to the client's request to avoid attacks where the attacker swaps the intended response for an older one valid for a previous request. This requires that the client and the authorization server have previously exchanged either a shared secret or their public keys in order to negotiate a secure communication. Furthermore, the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS. This can, for example, be done through preconfigured lists or through an online lookup mechanism that in turn also must be secured.
C-クライアントと承認サーバー間のすべての通信は、暗号化され、整合性とリプレイ保護されている必要があります。さらに、攻撃者が以前のリクエストに有効な古い応答に意図した応答を交換する攻撃を避けるために、クライアントに対するASからの応答は、クライアントの要求に拘束されなければなりません。これには、安全な通信を交渉するために、クライアントと承認サーバーが以前に共有秘密またはパブリックキーのいずれかを交換する必要があります。さらに、クライアントは、特定のRsにアクセストークンを発行する権限があるかどうかを判断できる必要があります。これは、たとえば、事前に設定されたリストを介して、またはオンラインルックアップメカニズムを介して実行することもできます。
RS-AS The communication between the resource server and the authorization server via the introspection endpoint MUST be encrypted and integrity and replay protected. Furthermore, responses from the AS to the RS MUST be bound to the RS's request. This requires that the RS and the authorization server have previously exchanged either a shared secret or their public keys in order to negotiate a secure communication. Furthermore, the RS MUST be able to determine whether an AS has the authority to issue access tokens itself. This is usually configured out of band but could also be performed through an online lookup mechanism, provided that it is also secured in the same way.
RS-内省エンドポイントを介したリソースサーバーと承認サーバー間の通信は、暗号化され、整合性とリプレイが保護されている必要があります。さらに、RSに対するASからの応答は、RSの要求に拘束される必要があります。これには、安全な通信を交渉するために、RSと承認サーバーが以前に共有秘密またはパブリックキーを交換したことが必要です。さらに、RSは、アクセストークン自体を発行する権限があるかどうかを判断できる必要があります。これは通常、バンドから構成されますが、同じ方法で保護されている場合、オンラインルックアップメカニズムを介して実行することもできます。
C-RS The initial communication between the client and the resource server cannot be secured in general, since the RS is not in possession of on access token for that client, which would carry the necessary parameters. If both parties support DTLS without client authentication, it is RECOMMENDED to use this mechanism for protecting the initial communication. After the client has successfully transmitted the access token to the RS, a secure communication protocol MUST be established between the client and RS for the actual resource request. This protocol MUST provide confidentiality, integrity, and replay protection, as well as a binding between requests and responses. This requires that the client learned either the RS's public key or received a symmetric proof-of-possession key bound to the access token from the AS. The RS must have learned either the client's public key, a shared symmetric key from the claims in the token, or an introspection request. Since ACE does not provide profile negotiation between the C and RS, the client MUST have learned what profile the RS supports (e.g., from the AS or preconfigured) and initiated the communication accordingly.
C-RSクライアントとリソースサーバー間の最初の通信は一般的に保護できません。RSは、必要なパラメーターを運ぶクライアントのアクセストークンを所有していないためです。両方の当事者がクライアント認証なしでDTLをサポートする場合、初期通信を保護するためにこのメカニズムを使用することをお勧めします。クライアントがアクセストークンをRSに正常に送信した後、実際のリソース要求のために、クライアントとRSの間に安全な通信プロトコルを確立する必要があります。このプロトコルは、機密性、整合性、およびリプレイ保護を提供するだけでなく、リクエストと応答の間の拘束力を提供する必要があります。これには、クライアントがRSの公開キーを学習するか、ASからのアクセストークンにバインドされた対称Proof-of-Possessionキーを受け取ったことが必要です。 RSは、クライアントの公開キー、トークンのクレームからの共有対称キー、または内省リクエストのいずれかを学習している必要があります。 ACEはCとRSの間のプロファイル交渉を提供していないため、クライアントはRSがサポートするプロファイル（ASまたは事前に設定されたものから）を学習し、それに応じて通信を開始する必要があります。
An RS that is offline faces the problem of clock drift. Since it cannot synchronize its clock with the AS, it may be tricked into accepting old access tokens that are no longer valid or have been compromised. In order to prevent this, an RS may use the nonce-based mechanism (cnonce) defined in Section 5.3 to ensure freshness of an Access Token subsequently presented to this RS.
オフラインであるRSは、クロックドリフトの問題に直面しています。時計をASと同期させることはできないため、もはや有効ではない、または妥協されている古いアクセストークンを受け入れるようにだまされる可能性があります。これを防ぐために、RSはセクション5.3で定義されているNonCEベースのメカニズム（CNONCE）を使用して、このRSにその後提示されたアクセストークンの新鮮さを確保することができます。
Another problem with clock drift is that evaluating the standard token expiration claim exp can give unpredictable results.
クロックドリフトのもう1つの問題は、標準のトークン有効期限の請求Expを評価すると予測不可能な結果が得られる可能性があることです。
Acceptable ranges of clock drift are highly dependent on the concrete application. Important factors are how long access tokens are valid and how critical timely expiration of the access token is.
許容可能なクロックドリフトの範囲は、具体的なアプリケーションに大きく依存しています。重要な要素は、アクセストークンがどれだけ有効であるか、アクセストークンのタイムリーな有効期限がどれほど重要であるかです。
The expiration mechanism implemented by the exi claim, based on the first time the RS sees the token, was defined to provide a more predictable alternative. The exi approach has some drawbacks that need to be considered:
RSがトークンを最初に見た時期に基づいて、EXIクレームによって実装された有効期限メカニズムは、より予測可能な代替品を提供するために定義されました。EXIアプローチには、考慮する必要があるいくつかの欠点があります。
* A malicious client may hold back tokens with the exi claim in order to prolong their lifespan.
* 悪意のあるクライアントは、寿命を延ばすためにEXIの主張でトークンを抑えることができます。
* If an RS loses state (e.g., due to an unscheduled reboot), it may lose the current values of counters tracking the exi claims of tokens it is storing.
* RSが状態を失った場合（例：予定外の再起動により）、保存しているトークンのEXIクレームを追跡するカウンターの現在の値を失う可能性があります。
The first drawback is inherent to the deployment scenario and the exi solution. It can therefore not be mitigated without requiring the RS be online at times. The second drawback can be mitigated by regularly storing the value of exi counters to persistent memory.
最初の欠点は、展開シナリオとEXIソリューションに固有のものです。したがって、RSをオンラインで時々必要とせずに緩和することはできません。2番目の欠点は、EXIカウンターの値を永続的なメモリに定期的に保存することで軽減できます。
There may be use cases where different transport and security protocols are allowed for the different interactions, and, if that is not explicitly covered by an existing profile, it corresponds to combining profiles into a new one. For example, a new profile could specify that a previously defined MQTT-TLS profile is used between the client and the RS in combination with a previously defined CoAP-DTLS profile for interactions between the client and the AS. The new profile that combines existing profiles MUST specify how the existing profiles' security requirements remain satisfied. Therefore, any profile MUST clearly specify its security requirements and MUST document if its security depends on the combination of various protocol interactions.
さまざまな輸送プロトコルが異なる相互作用に許可されている場合、既存のプロファイルで明示的にカバーされていない場合、プロファイルを新しいプロファイルに組み合わせることに対応する場合があります。たとえば、新しいプロファイルでは、クライアントとAS間の相互作用のために以前に定義されたCOAP-DTLSプロファイルと組み合わせて、クライアントとRSの間で以前に定義されたMQTT-TLSプロファイルが使用されることを指定できます。既存のプロファイルを組み合わせた新しいプロファイルは、既存のプロファイルのセキュリティ要件がどのように満たされているかを指定する必要があります。したがって、任意のプロファイルは、セキュリティ要件を明確に指定する必要があり、そのセキュリティがさまざまなプロトコル相互作用の組み合わせに依存しているかどうかを文書化する必要があります。
Communication with the authz-info endpoint, as well as the various error responses defined in this framework, potentially includes sending information over an unprotected channel. These messages may leak information to an adversary or may be manipulated by active attackers to induce incorrect behavior. For example, error responses for requests to the authorization information endpoint can reveal information about an otherwise opaque access token to an adversary who has intercepted this token.
AuthZ-INFOエンドポイントとの通信、およびこのフレームワークで定義されているさまざまなエラー応答には、保護されていないチャネルを介して情報を送信する可能性があります。これらのメッセージは、敵に情報を漏らしたり、アクティブな攻撃者によって操作されて誤った動作を誘発する場合があります。たとえば、承認情報エンドポイントへの要求のエラー応答は、このトークンを傍受した敵への不透明なアクセストークンに関する情報を明らかにすることができます。
As far as error messages are concerned, this framework is written under the assumption that, in general, the benefits of detailed error messages outweigh the risk due to information leakage. For particular use cases where this assessment does not apply, detailed error messages can be replaced by more generic ones.
エラーメッセージに関する限り、このフレームワークは、一般的に、情報の漏れによるリスクを上回る詳細なエラーメッセージの利点がリスクを上回るという仮定の下で書かれています。この評価が適用されない特定のユースケースの場合、詳細なエラーメッセージをより一般的なエラーメッセージに置き換えることができます。
In some scenarios, it may be possible to protect the communication with the authz-info endpoint (e.g., through DTLS with only server-side authentication). In cases where this is not possible, it is RECOMMENDED to use encrypted CWTs or tokens that are opaque references and need to be subjected to introspection by the RS.
一部のシナリオでは、AuthZ-INFOエンドポイントとの通信を保護することが可能かもしれません（たとえば、サーバー側の認証のみを備えたDTLを介して）。これが不可能な場合は、不透明な参照であり、RSによって内省を受ける必要がある暗号化されたCWTまたはトークンを使用することをお勧めします。
If the initial Unauthorized Resource Request message (see Section 5.2) is used, the client MUST make sure that it is not sending sensitive content in this request. While GET and DELETE requests only reveal the target URI of the resource, POST and PUT requests would reveal the whole payload of the intended operation.
最初の許可されていないリソース要求メッセージ（セクション5.2を参照）を使用する場合、クライアントはこのリクエストで機密コンテンツを送信していないことを確認する必要があります。取得および削除要求は、リソースのターゲットURIのみを明らかにしますが、ポストとプットリクエストは、意図した操作のペイロード全体を明らかにします。
Since the client is not authenticated at the point when it is submitting an access token to the authz-info endpoint, attackers may be pretending to be a client and trying to trick an RS to use an obsolete profile that in turn specifies a vulnerable security mechanism via the authz-info endpoint. Such an attack would require a valid access token containing an ace_profile claim requesting the use of said obsolete profile. Resource owners should update the configuration of their RSs to prevent them from using such obsolete profiles.
クライアントはAuthZ-INFOエンドポイントにアクセストークンを送信している時点で認証されていないため、攻撃者はクライアントのふりをし、RSをだまして廃止されたセキュリティメカニズムを指定する廃止されたプロファイルを使用しようとする可能性があります。authz-infoエンドポイントを介して。このような攻撃では、ACE_Profileクレームを含む有効なアクセストークンが必要になり、上記の時代遅れのプロファイルの使用を要求します。リソース所有者は、RSSの構成を更新して、そのような廃止されたプロファイルを使用しないようにする必要があります。
The aud claim, as defined in [RFC7519], and the equivalent audience parameter from [RFC8693] are intentionally vague on how to match the audience value to a specific RS. This is intended to allow application-specific semantics to be used. This section attempts to give some general guidance for the use of audiences in constrained environments.
[RFC7519]で定義されているAUDクレーム、および[RFC8693]の同等のオーディエンスパラメーターは、視聴者の価値を特定のRSに一致させる方法について意図的にあいまいです。これは、アプリケーション固有のセマンティクスを使用できるようにすることを目的としています。このセクションでは、制約された環境で視聴者を使用するための一般的なガイダンスを提供しようとします。
URLs are not a good way of identifying mobile devices that can switch networks and thus be associated with new URLs. If the audience represents a single RS and asymmetric keys are used, the RS can be uniquely identified by a hash of its public key. If this approach is used, it is RECOMMENDED to apply the procedure from Section 3 of [RFC6920].
URLは、ネットワークを切り替えて新しいURLに関連付けることができるモバイルデバイスを識別する良い方法ではありません。視聴者が単一のRSを表し、非対称キーを使用する場合、RSは公開キーのハッシュによって一意に識別できます。このアプローチを使用する場合は、[RFC6920]のセクション3から手順を適用することをお勧めします。
If the audience addresses a group of resource servers, the mapping of a group identifier to an individual RS has to be provisioned to each RS before the group-audience is usable. Managing dynamic groups could be an issue if any RS is not always reachable when the groups' memberships change. Furthermore, issuing access tokens bound to symmetric proof-of-possession keys that apply to a group-audience is problematic, as an RS that is in possession of the access token can impersonate the client towards the other RSs that are part of the group. It is therefore NOT RECOMMENDED to issue access tokens bound to a group-audience and symmetric proof-of possession keys.
視聴者がリソースサーバーのグループにアドレス指定する場合、グループ監査が使用可能になる前に、個々のRSへのグループ識別子のマッピングを各RSにプロビジョニングする必要があります。グループのメンバーシップが変更されたときに、RSが常に到達できるとは限らない場合、動的グループの管理は問題になる可能性があります。さらに、グループの監査に適用される対称的なプルーフオブポッセッションキーに結合したアクセストークンを発行することは問題があります。これは、アクセストークンを所有しているRSがグループの一部である他のRSSにクライアントになりすましているからです。したがって、グループオーディエンスと対称的な所有キーにバインドされたアクセストークンを発行することはお勧めしません。
Even the client must be able to determine the correct values to put into the audience parameter in order to obtain a token for the intended RS. Errors in this process can lead to the client inadvertently obtaining a token for the wrong RS. The correct values for audience can either be provisioned to the client as part of its configuration or dynamically looked up by the client in some directory. In the latter case, the integrity and correctness of the directory data must be assured. Note that the audience hint provided by the RS as part of the AS Request Creation Hints (Section 5.3) is not typically source authenticated and integrity protected and should therefore not be treated a trusted value.
クライアントでさえ、意図したRSのトークンを取得するために、オーディエンスパラメーターに配置する正しい値を決定できる必要があります。このプロセスのエラーは、クライアントが間違ったRSのトークンを誤って取得することにつながる可能性があります。オーディエンスの正しい値は、その構成の一部としてクライアントにプロビジョニングするか、一部のディレクトリでクライアントが動的に調べることができます。後者の場合、ディレクトリデータの完全性と正確性を保証する必要があります。ASリクエスト作成ヒント（セクション5.3）の一部としてRSが提供するオーディエンスのヒントは、通常、ソース認証と整合性の保護されていないため、信頼できる価値を扱うべきではないことに注意してください。
The optional introspection mechanism provided by OAuth and supported in the ACE framework allows for two types of attacks that need to be considered by implementers.
OAUTHによって提供され、ACEフレームワークでサポートされているオプションの内省メカニズムにより、実装者が考慮する必要がある2種類の攻撃が可能になります。
First, an attacker could perform a denial-of-service attack against the introspection endpoint at the AS in order to prevent validation of access tokens. To maintain the security of the system, an RS that is configured to use introspection MUST NOT allow access based on a token for which it couldn't reach the introspection endpoint.
第一に、攻撃者は、アクセストークンの検証を防ぐために、ASの内省エンドポイントに対してサービス拒否攻撃を実行できます。システムのセキュリティを維持するために、内省を使用するように構成されているRSは、内省エンドポイントに到達できなかったトークンに基づいてアクセスを許可してはなりません。
Second, an attacker could use the fact that an RS performs introspection to perform a denial-of-service attack against that RS by repeatedly sending tokens to its authz-info endpoint that require an introspection call. The RS can mitigate such attacks by implementing rate limits on how many introspection requests they perform in a given time interval for a certain client IP address submitting tokens to /authz-info. When that limit has been reached, incoming requests from that address are rejected for a certain amount of time. A general rate limit on the introspection requests should also be considered in order to mitigate distributed attacks.
第二に、攻撃者は、RSが内省を実行して、内省コールを必要とするAuthZ-INFOエンドポイントにトークンを繰り返し送信することにより、そのRSに対してサービス拒否攻撃を実行するという事実を使用できます。RSは、 /authz-infoにトークンを送信する特定のクライアントIPアドレスに対して、特定のクライアントIPアドレスに対して特定の時間間隔で実行される内省要求についてレート制限を実装することにより、そのような攻撃を軽減できます。その制限に達した場合、そのアドレスからの着信要求は一定の時間拒否されます。分散攻撃を緩和するために、内省要求の一般的なレート制限も考慮する必要があります。
Implementers and users should be aware of the privacy implications of the different possible deployments of this framework.
実装者とユーザーは、このフレームワークのさまざまな展開のプライバシーへの影響を認識する必要があります。
The AS is in a very central position and can potentially learn sensitive information about the clients requesting access tokens. If the client credentials grant is used, the AS can track what kind of access the client intends to perform. With other grants, this can be prevented by the resource owner. To do so, the resource owner needs to bind the grants it issues to anonymous, ephemeral credentials that do not allow the AS to link different grants and thus different access token requests by the same client.
Asは非常に中心的な位置にあり、アクセストークンを要求するクライアントに関する機密情報を潜在的に学習できます。クライアント資格情報の付与が使用されている場合、ASはクライアントが実行する予定のアクセスを追跡できます。他の助成金により、これはリソース所有者によって防止できます。そのためには、リソースの所有者は、ASが異なる助成金をリンクし、したがって異なるアクセストークンリクエストを許可しない匿名の一時的な資格情報に補助金をバインドする必要があります。
The claims contained in a token can reveal privacy-sensitive information about the client and the RS to any party having access to them (whether by processing the content of a self-contained token or by introspection). The AS SHOULD be configured to minimize the information about clients and RSs disclosed in the tokens it issues.
トークンに含まれるクレームは、クライアントとRSに関するプライバシーに敏感な情報を、アクセスする任意の当事者に対する情報を明らかにすることができます（自己完結型のトークンのコンテンツを処理するか、内省によって）。ASは、クライアントに関する情報を最小化するように構成され、ITの問題に開示されているRSS。
If tokens are only integrity protected and not encrypted, they may reveal information to attackers listening on the wire or be able to acquire the access tokens in some other way. In the case of CWTs, the token may, e.g., reveal the audience, the scope, and the confirmation method used by the client. The latter may reveal the identity of the device or application running the client. This may be linkable to the identity of the person using the client (if there is a person and not a machine-to-machine interaction).
トークンが整合性の保護されており、暗号化されていない場合、ワイヤーで聞いている攻撃者に情報を明らかにするか、他の方法でアクセストークンを取得できる場合があります。CWTSの場合、トークンは、たとえば、クライアントが使用する視聴者、範囲、および確認方法を明らかにすることがあります。後者は、クライアントを実行しているデバイスまたはアプリケーションのIDを明らかにする場合があります。これは、クライアントを使用している人の身元にリンクできる場合があります（マシン間の相互作用ではなく、人がいる場合）。
Clients using asymmetric keys for proof of possession should be aware of the consequences of using the same key pair for proof of possession towards different RSs. A set of colluding RSs or an attacker able to obtain the access tokens will be able to link the requests or even to determine the client's identity.
所有の証明のために非対称キーを使用しているクライアントは、同じキーペアを使用して、異なるRSSに対する所持の証明のために使用する結果を認識する必要があります。首尾一連のRSSまたはアクセストークンを取得できる攻撃者は、リクエストをリンクしたり、クライアントのIDを決定したりすることさえできます。
An unprotected response to an unauthorized request (see Section 5.3) may disclose information about the RS and/or its existing relationship with the C. It is advisable to include as little information as possible in an unencrypted response. Even the absolute URI of the AS may reveal sensitive information about the service that the RS provides. Developers must ensure that the RS does not disclose information that has an impact on the privacy of the stakeholders in the AS Request Creation Hints. They may choose to use a different mechanism for the discovery of the AS if necessary. If means of encrypting communication between the C and RS already exist, more detailed information may be included with an error response to provide the C with sufficient information to react on that particular error.
許可されていない要求に対する保護されていない応答（セクション5.3を参照）は、RSおよび/またはCとの既存の関係に関する情報を開示する場合があります。ASの絶対的なURIでさえ、RSが提供するサービスに関する機密情報を明らかにする可能性があります。開発者は、RSがASリクエスト作成のヒントにおける利害関係者のプライバシーに影響を与える情報を開示しないようにする必要があります。彼らは、必要に応じて発見するために別のメカニズムを使用することを選択する場合があります。CとRS間の通信を暗号化する手段がすでに存在する場合、その特定のエラーに反応するのに十分な情報をCに提供するために、より詳細な情報がエラー応答に含まれる場合があります。
This document creates several registries with a registration policy of Expert Review; guidelines to the experts are given in Section 8.17.
このドキュメントでは、専門家のレビューの登録ポリシーを備えたいくつかのレジストリを作成します。専門家へのガイドラインは、セクション8.17に記載されています。
This specification establishes the IANA "ACE Authorization Server Request Creation Hints" registry.
この仕様により、IANA「ACE Authorization Server Request Creations Hints」レジストリが確立されます。
The columns of the registry are:
レジストリの列は次のとおりです。
Name: The name of the parameter.
名前：パラメーターの名前。
CBOR Key: CBOR map key for the parameter. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use.
CBORキー：パラメーターのCBORマップキー。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256〜255の整数値は、標準アクションとして指定されています。-65536から-257から256から65535までの整数値は、必要な仕様として指定されています。65535を超える整数値は、専門家のレビューとして指定されています。-65536未満の整数値は、私的使用としてマークされています。
Value Type: The CBOR data types allowable for the values of this parameter.
値タイプ：このパラメーターの値に許容できるCBORデータ型。
Reference: This contains a pointer to the public specification of the Request Creation Hint abbreviation, if one exists.
参照：これには、存在する場合、リクエスト作成ヒントの略語の公開仕様へのポインターが含まれています。
This registry has been initially populated by the values in Table 1. The Reference column for all of these entries is this document.
このレジストリには、最初に表1の値が入力されています。これらのすべてのエントリの参照列には、このドキュメントです。
IANA has registered a new Resource Type (rt=) Link Target Attribute in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" [IANA.CoreParameters] registry:
IANAは、「制約されたRESTFUL環境（CORE）パラメーター」[IANA.CoreParameters]レジストリの下で、「リソースタイプ（rt =）リンクターゲット属性値」のサブレジストリに新しいリソースタイプ（rt =）リンクターゲット属性を登録しています。
Value: ace.ai Description: ACE-OAuth authz-info endpoint resource. Reference: RFC 9200
値：ACE.AI説明：ACE-OAUTH AUTHZ-INFOエンドポイントリソース。参照：RFC 9200
Specific ACE-OAuth profiles can use this common resource type for defining their profile-specific discovery processes.
特定のACE-OAUTHプロファイルは、この共通のリソースタイプを使用して、プロファイル固有の発見プロセスを定義できます。
This specification registers the following error values in the "OAuth Extensions Error Registry" [IANA.OAuthExtensionsErrorRegistry].
この仕様は、「OAuth拡張エラーレジストリ」[iana.oauthextensionserrorregistry]で次のエラー値を登録します。
Name: unsupported_pop_key Usage Location: token error response Protocol Extension: RFC 9200 Change Controller: IETF Reference: Section 5.8.3 of RFC 9200
名前：unsupported_pop_keyの使用場所：トークンエラー応答プロトコル拡張：RFC 9200変更コントローラー：IETFリファレンス：RFC 9200のセクション5.8.3
Name: incompatible_ace_profiles Usage Location: token error response Protocol Extension: RFC 9200 Change Controller: IETF Reference: Section 5.8.3 of RFC 9200
名前：互換性のない型dease_profilesの使用場所：トークンエラー応答プロトコル拡張：RFC 9200変更コントローラー：IETFリファレンス：RFC 9200のセクション5.8.3
This specification establishes the IANA "OAuth Error Code CBOR Mappings" registry.
この仕様により、IANA「OAuthエラーコードCBORマッピング」レジストリが確立されます。
The columns of the registry are:
レジストリの列は次のとおりです。
Name: The OAuth Error Code name, refers to the name in Section 5.2 of [RFC6749], e.g., "invalid_request".
名前：OAuthエラーコード名は、[RFC6749]のセクション5.2の名前を指します。
CBOR Value: CBOR abbreviation for this error code. Integer values less than -65536 are marked as Private Use; all other values use the registration policy Expert Review [RFC8126].
CBOR値：このエラーコードのCBOR略語。-65536未満の整数値は、私的使用としてマークされています。他のすべての値は、登録ポリシーの専門家レビュー[RFC8126]を使用しています。
Reference: This contains a pointer to the public specification of the error code abbreviation, if one exists.
参照：これには、存在する場合、エラーコードの略語の公開仕様へのポインタが含まれます。
Original Specification: This contains a pointer to the public specification of the error code, if one exists.
元の仕様：これには、存在する場合、エラーコードの公開仕様へのポインターが含まれています。
This registry has been initially populated by the values in Table 3. The Reference column for all of these entries is this document.
このレジストリには、最初に表3の値が入力されています。これらのすべてのエントリの参照列には、このドキュメントがあります。
This specification establishes the IANA "OAuth Grant Type CBOR Mappings" registry.
この仕様により、IANA「OAuth Grant Type Cborマッピング」レジストリが確立されます。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name: The name of the grant type, as specified in Section 1.3 of [RFC6749].
名前：[RFC6749]のセクション1.3で指定されている助成金タイプの名前。
CBOR Value: CBOR abbreviation for this grant type. Integer values less than -65536 are marked as Private Use; all other values use the registration policy Expert Review [RFC8126].
CBOR値：この助成金タイプのCBORの略語。-65536未満の整数値は、私的使用としてマークされています。他のすべての値は、登録ポリシーの専門家レビュー[RFC8126]を使用しています。
Reference: This contains a pointer to the public specification of the grant type abbreviation, if one exists.
参照：これには、存在する場合、助成金タイプの略語の公開仕様へのポインターが含まれています。
Original Specification: This contains a pointer to the public specification of the grant type, if one exists.
元の仕様：これには、存在する場合、助成金タイプの公開仕様へのポインターが含まれています。
This registry has been initially populated by the values in Table 4. The Reference column for all of these entries is this document.
このレジストリには、最初に表4の値が入力されています。これらのすべてのエントリの参照列は、このドキュメントです。
This section registers the following new token type in the "OAuth Access Token Types" registry [IANA.OAuthAccessTokenTypes].
このセクションでは、次の新しいトークンタイプを「OAuthアクセストークンタイプ」レジストリ[IANA.OAUTHACCESSTOKENTYPES]に登録します。
Name: PoP Additional Token Endpoint Response Parameters: cnf, rs_cnf (see Section 3.1 of [RFC8747] and Section 3.2 of [RFC9201]). HTTP Authentication Scheme(s): N/A Change Controller: IETF Reference: RFC 9200
名前：POP追加トークンエンドポイント応答パラメーター：CNF、RS_CNF（[RFC8747]のセクション3.1および[RFC9201]のセクション3.2を参照）。HTTP認証スキーム：N/A変更コントローラー：IETFリファレンス：RFC 9200
This specification establishes the IANA "OAuth Access Token Type CBOR Mappings" registry.
この仕様により、IANA「OAuth Access Token Type Cborマッピング」レジストリが確立されます。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name: The name of the token type, as registered in the "OAuth Access Token Types" registry, e.g., "Bearer".
名前：「OAuthアクセストークンタイプ」レジストリに登録されているトークンタイプの名前。
CBOR Value: CBOR abbreviation for this token type. Integer values less than -65536 are marked as Private Use; all other values use the registration policy Expert Review [RFC8126].
CBOR値：このトークンタイプのCBORの略語。-65536未満の整数値は、私的使用としてマークされています。他のすべての値は、登録ポリシーの専門家レビュー[RFC8126]を使用しています。
Reference: This contains a pointer to the public specification of the OAuth token type abbreviation, if one exists.
参照：これには、OAuthトークンタイプの略語の公開仕様へのポインターが含まれています。
Original Specification: This contains a pointer to the public specification of the OAuth token type, if one exists.
元の仕様：これには、OAuthトークンタイプの公開仕様へのポインターが含まれています。
Name: Bearer CBOR Value: 1 Reference: RFC 9200 Original Specification: [RFC6749]
名前：ベアラーCBOR値：1リファレンス：RFC 9200オリジナル仕様：[RFC6749]
Name: PoP CBOR Value: 2 Reference: RFC 9200 Original Specification: RFC 9200
名前：POP CBOR値：2リファレンス：RFC 9200オリジナル仕様：RFC 9200
This specification establishes the IANA "ACE Profile" registry.
この仕様により、IANAの「ACEプロファイル」レジストリが確立されます。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name: The name of the profile to be used as the value of the profile attribute.
名前：プロファイル属性の値として使用されるプロファイルの名前。
Description: Text giving an overview of the profile and the context it is developed for.
説明：プロファイルとコンテキストの概要を示すテキスト。
CBOR Value: CBOR abbreviation for this profile name. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 are designated as Specification Required. Integer values greater than 65535 are designated as Expert Review. Integer values less than -65536 are marked as Private Use.
CBOR値：このプロファイル名のCBORの略語。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256〜255の整数値は、標準アクションとして指定されています。-65536から-257から256から65535までの整数値は、必要な仕様として指定されています。65535を超える整数値は、専門家のレビューとして指定されています。-65536未満の整数値は、私的使用としてマークされています。
Reference: This contains a pointer to the public specification of the profile abbreviation, if one exists.
参照：これには、存在する場合、プロファイルの略語の公開仕様へのポインターが含まれています。
This specification registers the following parameter in the "OAuth Parameters" registry [IANA.OAuthParameters]:
この仕様は、「OAuthパラメーター」レジストリ[iana.oauthparameters]の次のパラメーターを登録します。
Name: ace_profile Parameter Usage Location: token response Change Controller: IETF Reference: Sections 5.8.2 and 5.8.4.3 of RFC 9200
名前：ACE_Profileパラメーターの使用場所
This specification establishes the IANA "OAuth Parameters CBOR Mappings" registry.
この仕様により、IANA「OAuthパラメーターCBORマッピング」レジストリが確立されます。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name: The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., client_id.
名前：OAUTHパラメーター名は、OAUTHパラメーターレジストリの名前を指します。たとえば、client_id。
CBOR Key: CBOR map key for this parameter. Integer values less than -65536 are marked as Private Use; all other values use the registration policy Expert Review [RFC8126].
CBORキー：このパラメーターのCBORマップキー。-65536未満の整数値は、私的使用としてマークされています。他のすべての値は、登録ポリシーの専門家レビュー[RFC8126]を使用しています。
Value Type: The allowable CBOR data types for values of this parameter.
値タイプ：このパラメーターの値の許容CBORデータ型。
Reference: This contains a pointer to the public specification of the OAuth parameter abbreviation, if one exists.
参照：これには、OAuthパラメーターの略語の公開仕様へのポインターが含まれています。
Original Specification This contains a pointer to the public specification of the OAuth parameter, if one exists.
元の仕様これには、OAuthパラメーターの公開仕様へのポインターが含まれています。
This registry has been initially populated by the values in Table 5. The Reference column for all of these entries is this document.
このレジストリには、最初に表5の値が入力されています。これらすべてのエントリの参照列には、このドキュメントがあります。
This specification registers the following parameters in the "OAuth Token Introspection Response" registry [IANA.TokenIntrospectionResponse].
この仕様は、「OAuthトークン内省応答」レジストリ[iana.tokenintrospectionResponse]の次のパラメーターを登録します。
Name: ace_profile Description: The ACE profile used between the client and RS. Change Controller: IETF Reference: Section 5.9.2 of RFC 9200
名前：ACE_Profile説明：クライアントとRsの間で使用されるACEプロファイル。Change Controller：IETFリファレンス：RFC 9200のセクション5.9.2
Name: cnonce Description: "client-nonce". A nonce previously provided to the AS by the RS via the client. Used to verify token freshness when the RS cannot synchronize its clock with the AS. Change Controller: IETF Reference: Section 5.9.2 of RFC 9200
名前：CNONCE説明： "Client-Nonce"。以前にRSによってASに提供されたNonCE。RSがクロックをASと同期できない場合、トークンの新鮮さを検証するために使用されます。Change Controller：IETFリファレンス：RFC 9200のセクション5.9.2
Name cti Description "CWT ID". The identifier of a CWT as defined in [RFC8392]. Change Controller IETF Reference Section 5.9.2 of RFC 9200
名前CTI説明「CWT ID」。[RFC8392]で定義されているCWTの識別子。RFC 9200のコントローラーIETF参照セクション5.9.2を変更します
Name: exi Description: "Expires in". Lifetime of the token in seconds from the time the RS first sees it. Used to implement a weaker form of token expiration for devices that cannot synchronize their internal clocks. Change Controller: IETF Reference: Section 5.9.2 of RFC 9200
名前：exi説明：「有効期限が切れます」。RSが最初に見た時から数秒でトークンの寿命。内部クロックを同期できないデバイスに、より弱い形式のトークン有効期限を実装するために使用されます。Change Controller：IETFリファレンス：RFC 9200のセクション5.9.2
This specification establishes the IANA "OAuth Token Introspection Response CBOR Mappings" registry.
この仕様により、IANA「OAuthトークン内注文応答CBORマッピング」レジストリが確立されます。
The columns of this registry are:
このレジストリの列は次のとおりです。
Name: The OAuth Parameter name, refers to the name in the OAuth parameter registry, e.g., client_id.
名前：OAUTHパラメーター名は、OAUTHパラメーターレジストリの名前を指します。たとえば、client_id。
CBOR Key: CBOR map key for this parameter. Integer values less than -65536 are marked as Private Use; all other values use the registration policy Expert Review [RFC8126].
CBORキー：このパラメーターのCBORマップキー。-65536未満の整数値は、私的使用としてマークされています。他のすべての値は、登録ポリシーの専門家レビュー[RFC8126]を使用しています。
Value Type: The allowable CBOR data types for values of this parameter.
値タイプ：このパラメーターの値の許容CBORデータ型。
Reference: This contains a pointer to the public specification of the introspection response parameter abbreviation, if one exists.
参照：これには、存在する場合、内省応答パラメーターの略語の公開仕様へのポインターが含まれています。
Original Specification This contains a pointer to the public specification of the OAuth Token Introspection parameter, if one exists.
元の仕様これには、OAuthトークン内省パラメーターの公開仕様へのポインターが含まれています。
This registry has been initially populated by the values in Table 6. The Reference column for all of these entries is this document.
このレジストリには、最初に表6の値が入力されています。これらのすべてのエントリの参照列は、このドキュメントです。
Note that the mappings of parameters corresponding to claim names intentionally coincide with the CWT claim name mappings from [RFC8392].
[RFC8392]のCWTクレーム名マッピングと意図的に一致するクレーム名に対応するパラメーターのマッピングは
This specification registers the following new claims in the "JSON Web Token Claims" subregistry under the "JSON Web Token (JWT)" registry [IANA.JsonWebTokenClaims]:
この仕様は、「JSON Web Token（JWT）」レジストリ[IANA.JSONWEBTOKENCALINS]の下で「JSON Webトークンクレーム」サブレジストリで次の新しいクレームを登録します。
Claim Name: ace_profile Claim Description: The ACE profile a token is supposed to be used with. Change Controller: IETF Reference: Section 5.10 of RFC 9200
クレーム名：ace_profileクレーム説明：トークンが使用されることになっているACEプロファイル。Change Controller：IETFリファレンス：RFC 9200のセクション5.10
Claim Name: cnonce Claim Description: "client-nonce". A nonce previously provided to the AS by the RS via the client. Used to verify token freshness when the RS cannot synchronize its clock with the AS. Change Controller: IETF Reference: Section 5.10 of RFC 9200
クレーム名：CNONCEクレーム説明：「クライアントノンス」。以前にRSによってASに提供されたNonCE。RSがクロックをASと同期できない場合、トークンの新鮮さを検証するために使用されます。Change Controller：IETFリファレンス：RFC 9200のセクション5.10
Claim Name: exi Claim Description: "Expires in". Lifetime of the token in seconds from the time the RS first sees it. Used to implement a weaker form of token expiration for devices that cannot synchronize their internal clocks. Change Controller: IETF Reference: Section 5.10.3 of RFC 9200
クレーム名：exiクレーム説明：「有効期限」。RSが最初に見た時から数秒でトークンの寿命。内部クロックを同期できないデバイスに、より弱い形式のトークン有効期限を実装するために使用されます。Change Controller：IETFリファレンス：RFC 9200のセクション5.10.3
This specification registers the following new claims in the "CBOR Web Token (CWT) Claims" registry [IANA.CborWebTokenClaims].
この仕様は、「CBOR Web Token（CWT）クレーム」レジストリ[IANA.CBORWEBTOKENCALIMS]で次の新しいクレームを登録します。
Claim Name: ace_profile Claim Description: The ACE profile a token is supposed to be used with. JWT Claim Name: ace_profile Claim Key: 38 Claim Value Type: integer Change Controller: IETF Reference: Section 5.10 of RFC 9200
クレーム名：ace_profileクレーム説明：トークンが使用されることになっているACEプロファイル。JWTクレーム名：ACE_Profileクレームキー：38クレーム値タイプ：整数変更コントローラー：IETFリファレンス：RFC 9200のセクション5.10
Claim Name: cnonce Claim Description: The client-nonce sent to the AS by the RS via the client. JWT Claim Name: cnonce Claim Key: 39 Claim Value Type: byte string Change Controller: IETF Reference: Section 5.10 of RFC 9200
クレーム名：CNONCEクレーム説明：クライアントを介してRSによってASに送信されたクライアントノンス。JWTクレーム名：CNONCEクレームキー：39クレーム値タイプ：バイト文字列変更コントローラー：IETFリファレンス：RFC 9200のセクション5.10
Claim Name: exi Claim Description: The expiration time of a token measured from when it was received at the RS in seconds. JWT Claim Name: exi Claim Key: 40 Claim Value Type: unsigned integer Change Controller: IETF Reference: Section 5.10.3 of RFC 9200
クレーム名：exiクレーム説明：rsで受信したときから測定されたトークンの有効期限時間。JWTクレーム名：EXIクレームキー：40クレーム値タイプ：署名されていない整数変更コントローラー：IETFリファレンス：RFC 9200のセクション5.10.3
Claim Name: scope Claim Description: The scope of an access token, as defined in [RFC6749]. JWT Claim Name: scope Claim Key: 9 Claim Value Type: byte string or text string Change Controller: IETF Reference: Section 4.2 of [RFC8693]
クレーム名：スコープクレーム説明：[RFC6749]で定義されているアクセストークンの範囲。JWTクレーム名：スコープクレームキー：9クレーム値タイプ：バイト文字列またはテキスト文字列変更コントローラー：IETFリファレンス：[RFC8693]のセクション4.2
This specification registers the "application/ace+cbor" media type for messages of the protocols defined in this document carrying parameters encoded in CBOR. This registration follows the procedures specified in [RFC6838].
この仕様は、CBORでエンコードされたパラメーターを運ぶこのドキュメントで定義されているプロトコルのメッセージの「アプリケーション/ACE CBOR」メディアタイプを登録します。この登録は、[RFC6838]で指定された手順に従います。
Type name: application
タイプ名：アプリケーション
Subtype name: ace+cbor
サブタイプ名：Ace Cbor
Required parameters: N/A
必要なパラメーター：n/a
Optional parameters: N/A
オプションのパラメーター：n/a
Encoding considerations: Must be encoded as a CBOR map containing the protocol parameters defined in RFC 9200.
考慮事項のエンコード：RFC 9200で定義されたプロトコルパラメーターを含むCBORマップとしてエンコードする必要があります。
Security considerations: See Section 6 of RFC 9200
セキュリティ上の考慮事項：RFC 9200のセクション6を参照してください
Interoperability considerations: N/A
相互運用性の考慮事項：n/a
Published specification: RFC 9200
公開された仕様：RFC 9200
Applications that use this media type: The type is used by authorization servers, clients, and resource servers that support the ACE framework with CBOR encoding, as specified in RFC 9200.
このメディアタイプを使用するアプリケーション：タイプは、RFC 9200で指定されているように、CBORエンコードでACEフレームワークをサポートする認証サーバー、クライアント、およびリソースサーバーによって使用されます。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：n/a
Additional information: N/A
追加情報：n/a
Person & email address to contact for further information:
IESG <iesg@ietf.org>
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: none
使用に関する制限：なし
Author: Ludwig Seitz <ludwig.seitz@combitech.se>
Change controller: IETF
Change Controller：IETF
The following entry has been registered in the "CoAP Content-Formats" registry:
次のエントリは、「Coapコンテンツフォーマット」レジストリに登録されています。
Media Type: application/ace+cbor
Encoding: -
ID: 19
Reference: RFC 9200
All of the IANA registries established in this document are defined to use a registration policy of Expert Review. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.
このドキュメントで確立されたすべてのIANAレジストリは、専門家のレビューの登録ポリシーを使用するために定義されています。このセクションでは、専門家が探しているものについてのいくつかの一般的なガイドラインを示していますが、それらは理由で専門家として指定されているため、実質的な緯度を与えられるべきです。
Expert Reviewers should take into consideration the following points:
専門家のレビュアーは、次のポイントを考慮する必要があります。
* Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as Private Use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.
* ポイントスクワットは落胆する必要があります。レビューアは、登録要求のための十分な情報を取得して、使用が既に登録されているものを複製しないようにし、ポイントが展開で使用される可能性が高いことを確認することをお勧めします。私的使用としてタグ付けされたゾーンは、テスト目的と閉鎖環境を目的としています。他の範囲のコードポイントは、テスト用に割り当てられないでください。
* Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
* 閉じた環境の外側で使用可能な方法で使用されることが期待される場合、最初のCOMEのファーストサービス範囲には仕様が必要です。仕様が提供されていない場合、提供された説明には、ポイントが使用されているものを特定するのに十分な情報が必要です。
* Experts should take into account the expected usage of fields when approving point assignment. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, i.e., the size of device it will be used on.
* 専門家は、ポイント割り当てを承認する際に、フィールドの予想される使用を考慮する必要があります。標準の追跡ドキュメントの範囲があるという事実は、標準の追跡ドキュメントがその範囲外に割り当てられたポイントを持つことができないことを意味するものではありません。エンコードされた値の長さは、その長さのコードポイントの数、つまり使用されるデバイスのサイズと比較検討する必要があります。
* Since a high degree of overlap is expected between these registries and the contents of the OAuth parameters [IANA.OAuthParameters] registries, experts should require new registrations to maintain alignment with parameters from OAuth that have comparable functionality. Deviation from this alignment should only be allowed if there are functional differences that are motivated by the use case and that cannot be easily or efficiently addressed by comparable OAuth parameters.
* これらのレジストリとOAuthパラメーター[IANA.OAUTHPARAMETERS]レジストリの内容との間に高度なオーバーラップが予想されるため、専門家は、同等の機能を持つOAUTHからのパラメーターとのアライメントを維持するために新しい登録を必要とする必要があります。このアライメントからの偏差は、ユースケースによって動機付けられ、同等のOAuthパラメーターで簡単にまたは効率的に対処できない機能的な違いがある場合にのみ許可する必要があります。
[IANA.CborWebTokenClaims] IANA, "CBOR Web Token (CWT) Claims", <https://www.iana.org/assignments/cwt>.
[iana.cborwebtokenclaids] iana、 "cbor webトークン（cwt）クレーム"、<https://www.iana.org/assignments/cwt>。
[IANA.CoreParameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
[IANA.COREPARAMETERS] IANA、「制約された安らかな環境（コア）パラメーター」、<https://www.iana.org/assignments/core-parameters>。
[IANA.JsonWebTokenClaims] IANA, "JSON Web Token Claims", <https://www.iana.org/assignments/jwt>.
[iana.jsonwebtokenclaids] iana、 "json webトークンクレーム"、<https://www.iana.org/assignments/jwt>。
[IANA.OAuthAccessTokenTypes] IANA, "OAuth Access Token Types", <https://www.iana.org/assignments/oauth-parameters>.
[iana.oauthaccestokentypes] iana、 "oauth access token型"、<https://www.iana.org/assignments/oauth-parameters>。
[IANA.OAuthExtensionsErrorRegistry] IANA, "OAuth Extensions Error Registry", <https://www.iana.org/assignments/oauth-parameters>.
[iana.oauthextensionserrorregistry] iana、 "oauth extensionsエラーレジストリ"、<https://www.iana.org/assignments/oauth-parameters>。
[IANA.OAuthParameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[iana.oauthparameters] iana、 "oauth parameters"、<https://www.iana.org/assignments/oauth-parameters>。
[IANA.TokenIntrospectionResponse] IANA, "OAuth Token Introspection Response", <https://www.iana.org/assignments/oauth-parameters>.
[IANA.TOKENINTROSPECTIONSPONSE] IANA、 "Oauth Token Introspection Response"、<https://www.iana.org/assignments/oauth-parameters>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[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>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「データグラムトランスポートレイヤーセキュリティバージョン1.2」、RFC 6347、DOI 10.17487/RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D.、ed。、「The Oauth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487/RFC6749、2012年10月、<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>.
[RFC6750]ジョーンズ、M。およびD.ハード、「OAUTH 2.0認証フレームワーク：ベアラートークンの使用」、RFC 6750、DOI 10.17487/RFC6750、2012年10月、<https://www.rfc-editor.org/info/RFC6750>。
[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>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487/RFC6838、2013年1月、<https：//www.rfc-editor.org/info/rfc6838>。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Hashesで物を命名」、RFC 6920、DOI 10.17487/RFC6920、2013年4月、<https://www.rfc-editor.org/info/rfc6920>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「制約付きアプリケーションプロトコル（COAP）」、RFC 7252、DOI 10.17487/RFC7252、2014年6月、<https：//www.rfc-editor。org/info/rfc7252>。
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[RFC7519] Jones、M.、Bradley、J。、およびN. Sakimura、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487/RFC7519、2015年5月、<https：//www.rfc-editor.org/info/rfc7519>。
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.
[RFC7662] Richer、J.、ed。、「Oauth 2.0トークン内省」、RFC 7662、DOI 10.17487/RFC7662、2015年10月、<https://www.rfc-editor.org/info/rfc762>
[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>.
[RFC8126] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8126>。
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.
[RFC8152] Schaad、J。、「Cborオブジェクトの署名と暗号化（COSE）」、RFC 8152、DOI 10.17487/RFC8152、2017年7月、<https://www.rfc-editor.org/info/rfc8152>
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8392] Jones、M.、Wahlstroem、E.、Erdtman、S.、およびH. Tschofenig、「Cbor Web Token（CWT）」、RFC 8392、DOI 10.17487/RFC8392、2018年5月、<https：// www。rfc-editor.org/info/rfc8392>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C。、およびC. Bormann、「Scise Data Definition Language（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）およびJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/info/rfc8693>.
[RFC8693] Jones、M.、Nadalin、A.、Campbell、B.、Ed。、Bradley、J.、およびC. Mortimore、「Oauth 2.0トークン交換」、RFC 8693、DOI 10.17487/RFC8693、1月2020年、<https://www.rfc-editor.org/info/rfc8693>。
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC8747] Jones、M.、Seitz、L.、Selander、G.、Erdtman、S。、およびH. Tschofenig、「Cbor Web Tokens（CWTS）のプルーフオブポッセッションキーセマンティクス」、RFC 8747、DOI 10.17487/RFC8747、2020年3月、<https://www.rfc-editor.org/info/rfc8747>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C。and P. Hoffman、「Concise binary Object Lepressation（CBOR）」、STD 94、RFC 8949、DOI 10.17487/RFC8949、2020年12月、<https://www.rfc-editor.org/info/RFC8949>。
[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication and Authorization in Constrained Environments (ACE)", RFC 9201, DOI 10.17487/RFC9201, August 2022, <https://www.rfc-editor.org/info/rfc9201>.
[RFC9201] Seitz、L。、「制約付き環境での認証と認証のための追加のOAuthパラメーター（ACE）」、RFC 9201、DOI 10.17487/RFC9201、2022年<https://www.rfc-editor.org/info/RFC9201>。
[BLE] Bluetooth Special Interest Group, "Core Specification 5.3", Section 4.4, July 2021, <https://www.bluetooth.com/specifications/bluetooth-core-specification/>.
[BLE] Bluetooth Special Interest Group、「Core Specification 5.3」、セクション4.4、2021年7月、<https://www.bluetooth.com/spifications/bluetooth-core-pecification/>。
[DCAF] Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP Authentication and Authorization Framework (DCAF)", Work in Progress, Internet-Draft, draft-gerdes-ace-dcaf-authorize-04, 19 October 2015, <https://datatracker.ietf.org/doc/html/draft-gerdes-ace-dcaf-authorize-04>.
[DCAF] Gerdes、S.、Bergmann、O.、およびC. Bormann、「委任Coap認証と認証フレームワーク（DCAF）」、進行中の作業、インターネットドラフト、ドラフト-Gerdes-acaf-authorize-04、2015年10月19日、<https://datatracker.ietf.org/doc/html/draft-gerdes-ase-dcaf-authorize-04>。
[Margi10impact] Margi, C., de Oliveira, B., de Sousa, G., Simplicio Jr, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, "Impact of Operating Systems on Wireless Sensor Networks (Security) Applications and Testbeds", Proceedings of the 19th International Conference on Computer Communications and Networks, DOI 10.1109/ICCCN.2010.5560028, August 2010, <https://doi.org/10.1109/ICCCN.2010.5560028>.
[Margi10impact] Margi、C.、De Oliveira、B.、De Sousa、G.、Simplicio Jr、M.、Barreto、P.、Carvalho、T.、Naeslund、M。、およびR. Gold、 "操作の影響ワイヤレスセンサーネットワークのシステム（セキュリティ）アプリケーションとテストベッド」、コンピューター通信およびネットワークに関する第19回国際会議の議事録、DOI 10.1109/ICCCN.2010.5560028、2010年8月<https://doi.org/10.1109/ICCCN.2010.5560028>。
[MQTT5.0] Banks, A., Briggs, E., Borgendale, K., and R. Gupta, "MQTT Version 5.0", OASIS Standard, March 2019, <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html>.
[MQTT5.0] Banks、A.、Briggs、E.、Borgendale、K。、およびR. Gupta、 "MQTTバージョン5.0"、Oasis Standard、2019年3月、<https://docs.oasis-open.org/MQTT/MQTT/V5.0/MQTT-V5.0.HTML>。
[OAUTH-RPCC] Seitz, L., Erdtman, S., and M. Tiloca, "Raw-Public-Key and Pre-Shared-Key as OAuth client credentials", Work in Progress, Internet-Draft, draft-erdtman-oauth-rpcc-00, 21 November 2017, <https://datatracker.ietf.org/doc/html/ draft-erdtman-oauth-rpcc-00>.
[Oauth-RPCC] Seitz、L.、Erdtman、S。、およびM. Tiloca、「Raw-Public-Key and Pre-Shared-KeyはOAuth Client Credentials」、進行中の作業、インターネットドラフト、Draft-Erdtman-OAUTH-RPCC-00、2017年11月21日、<https://datatracker.ietf.org/doc/html/ draft-erdtman-oauth-rpcc-00>。
[POP-KEY-DIST] Bradley, J., Hunt, P., Jones, M., Tschofenig, H., and M. Meszaros, "OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution", Work in Progress, Internet-Draft, draft-ietf-oauth-pop-key-distribution-07, 27 March 2019, <https://datatracker.ietf.org/doc/html/ draft-ietf-oauth-pop-key-distribution-07>.
[Pop-Key-Dist] Bradley、J.、Hunt、P.、Jones、M.、Tschofenig、H。、およびM. Meszaros、「Oauth 2.0 Proof-of-Possession：承認サーバーからクライアントキーディストリビューション」、作業進行中、インターネットドラフト、ドラフト-IITF-OAUTH-POP-KEY-Distribution-07、2019年3月27日、<https://datatracker.ietf.org/doc/html/ draft-ietf-oauth-pop-key-分布-07>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487/RFC4949、2007年8月、<https://www.rfc-editor.org/info/rfc4949>
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>.
[RFC6690]シェルビー、Z。、「制約付き安静環境（コア）リンク形式」、RFC 6690、DOI 10.17487/RFC6690、2012年8月、<https://www.rfc-editor.org/info/rfc690>
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <https://www.rfc-editor.org/info/rfc6819>.
[RFC6819] LodderStedt、T.、Ed。、McGloin、M.、およびP. Hunt、「OAuth 2.0脅威モデルとセキュリティの考慮事項」、RFC 6819、DOI 10.17487/RFC6819、2013年1月、<https：//www.rfc-editor.org/info/rfc6819>。
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7009] LodderStedt、T.、Ed。、Dronia、S。、およびM. Scurtescu、「Oauth 2.0 Token Regocation」、RFC 7009、DOI 10.17487/RFC7009、2013年8月、<https：//www.rfc-editor。org/info/rfc7009>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M。、およびA. Keranen、「制約ノードネットワークの用語」、RFC 7228、DOI 10.17487/RFC7228、2014年5月、<https://www.rfc-editor.org/info/rfc7228>。
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <https://www.rfc-editor.org/info/rfc7521>.
[RFC7521] Campbell、B.、Mortimore、C.、Jones、M。、およびY. Goland、「OAUTH 2.0クライアント認証と認証助成金のアサーションフレームワーク」、RFC 7521、DOI 10.17487/RFC7521、2015年5月、<HTTPS：//www.rfc-editor.org/info/rfc7521>。
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/info/rfc7591>.
[RFC7591] Richer、J.、ed。、ed。、Jones、M.、Bradley、J.、Machulak、M.、およびP. Hunt、「OAuth 2.0 Dynamic Client Registration Protocol」、RFC 7591、DOI 10.17487/RFC7591、2015年7月、<https://www.rfc-editor.org/info/rfc7591>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「制約付きアプリケーションプロトコル（COAP）のリソースの観察」、RFC 7641、DOI 10.17487/RFC7641、2015年9月、<https://www.rfc-editor.org/info/rfc7641>。
[RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., and S. Kumar, "Use Cases for Authentication and Authorization in Constrained Environments", RFC 7744, DOI 10.17487/RFC7744, January 2016, <https://www.rfc-editor.org/info/rfc7744>.
[RFC7744] Seitz、L.、Ed。、Gerdes、S.、Ed。、Selander、G.、Mani、M。、およびS. Kumar、「制約された環境での認証と認証のためのユースケース」、RFC 7744、doi10.17487/rfc7744、2016年1月、<https://www.rfc-editor.org/info/rfc7744>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、C。およびZ. Shelby、ed。、「制約付きアプリケーションプロトコル（COAP）のブロックごとの転送」、RFC 7959、DOI 10.17487/RFC7959、2016年8月、<https：//www.rfc-editor.org/info/rfc7959>。
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, <https://www.rfc-editor.org/info/rfc8252>.
[RFC8252] Denniss、W。and J. Bradley、「ネイティブアプリのOAuth 2.0」、BCP 212、RFC 8252、DOI 10.17487/RFC8252、2017年10月、<https://www.rfc-editor.org/info/rfc82522>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ed。、「JavaScriptオブジェクト表記（JSON）データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<https：//www.rfc-editor.org/info/rfc8259>。
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/info/rfc8414>.
[RFC8414] Jones、M.、Sakimura、N。、およびJ. Bradley、「Oauth 2.0 Authorization Server Metadata」、RFC 8414、DOI 10.17487/RFC8414、2018年6月、<https：//www.rfc-editor.org/情報/RFC8414>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[RFC8516] Keranen, A., ""Too Many Requests" Response Code for the Constrained Application Protocol", RFC 8516, DOI 10.17487/RFC8516, January 2019, <https://www.rfc-editor.org/info/rfc8516>.
[RFC8516] Keranen、A。、 ""制約付きアプリケーションプロトコルの「リクエストが多すぎる」応答コード、RFC 8516、DOI 10.17487/RFC8516、2019年1月、<https://www.rfc-editor.org/info/RFC85166666666666>。
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.
[RFC8613] Selander、G.、Mattsson、J.、Palombini、F.、およびL. Seitz、「制約された安らかな環境のオブジェクトセキュリティ（OSCORE）」、RFC 8613、DOI 10.17487/RFC8613、2019年7月、<HTTPS：//www.rfc-editor.org/info/rfc8613>。
[RFC8628] Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/info/rfc8628>.
[RFC8628] Denniss、W.、Bradley、J.、Jones、M。、およびH. Tschofenig、「Oauth 2.0 Device Authorization Grant」、RFC 8628、DOI 10.17487/RFC8628、2019年8月、<https：//ww.rfc-editor.org/info/rfc8628>。
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[RFC9110] 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>.
[RFC9110] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[RFC9113] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and L. Seitz, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", RFC 9202, DOI 10.17487/RFC9202, August 2022, <https://www.rfc-editor.org/info/rfc9202>.
[RFC9202] Gerdes、S.、Bergmann、O.、Bormann、C.、Selander、G。、およびL. Seitz、「データグラム輸送層セキュリティ（DTLS）制約環境の認証と認可のためのプロファイル（ACE）」、RFC9202、doi 10.17487/rfc9202、2022年8月、<https://www.rfc-editor.org/info/rfc9202>。
[RFC9203] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework", RFC 9203, DOI 10.17487/RFC9203, August 2022, <https://www.rfc-editor.org/info/rfc9203>.
[RFC9203] Palombini、F.、Seitz、L.、Selander、G。、およびM. Gunnarsson、「制約されたRESTFUL環境のオブジェクトセキュリティ（OSCORE）制約環境の認証と承認（ACE）フレームワークのプロファイル」、RFC9203、doi 10.17487/rfc9203、2022年8月、<https://www.rfc-editor.org/info/rfc9203>。
This section provides further insight into the design decisions of the solution documented in this document. Section 3 lists several building blocks and briefly summarizes their importance. The justification for offering some of those building blocks, as opposed to using OAuth 2.0 as is, is given below.
このセクションでは、このドキュメントに記載されているソリューションの設計上の決定に関するさらなる洞察を提供します。セクション3には、いくつかのビルディングブロックをリストし、それらの重要性を簡単に要約しています。OAUTH 2.0を使用するのではなく、これらのビルディングブロックの一部を提供する正当化を以下に示します。
Common IoT constraints are:
一般的なIoTの制約は次のとおりです。
Low Power Radio: Many IoT devices are equipped with a small battery that needs to last for a long time. For many constrained wireless devices, the highest energy cost is associated to transmitting or receiving messages (roughly by a factor of 10 compared to AES) [Margi10impact]. It is therefore important to keep the total communication overhead low, including minimizing the number and size of messages sent and received, which has an impact of choice on the message format and protocol. By using CoAP over UDP and CBOR-encoded messages, some of these aspects are addressed. Security protocols contribute to the communication overhead and can, in some cases, be optimized. For example, authentication and key establishment may, in certain cases where security requirements allow, be replaced by the provisioning of security context by a trusted third party, using transport or application-layer security.
低電力ラジオ：多くのIoTデバイスには、長期間持続する必要がある小さなバッテリーが装備されています。多くの制約されたワイヤレスデバイスの場合、最高のエネルギーコストはメッセージの送信または受信に関連付けられています（AEと比較して約10倍）[Margi10Impact]。したがって、送信および受信したメッセージの数とサイズを最小限に抑えるなど、総通信オーバーヘッドを低く抑えることが重要です。UDPおよびCBORエンコードメッセージを介してCOAPを使用することにより、これらの側面のいくつかに対処されます。セキュリティプロトコルは、通信オーバーヘッドに貢献し、場合によっては最適化できます。たとえば、認証と主要な施設は、セキュリティ要件が許可されている特定の場合、トランスポートまたはアプリケーションレイヤーセキュリティを使用して、信頼できるサードパーティによるセキュリティコンテキストのプロビジョニングに置き換えることができます。
Low CPU Speed: Some IoT devices are equipped with processors that are significantly slower than those found in most current devices on the Internet. This typically has implications on what timely cryptographic operations a device is capable of performing, which in turn impacts, e.g., protocol latency. Symmetric key cryptography may be used instead of the computationally more expensive public key cryptography where the security requirements so allow, but this may also require support for trusted, third-party-assisted secret key establishment using transport- or application-layer security.
CPU速度が低い：一部のIoTデバイスには、インターネット上のほとんどの現在のデバイスで見られるものよりも大幅に遅いプロセッサが装備されています。これは通常、デバイスが実行できるタイムリーな暗号操作に影響を及ぼします。対称的なキー暗号化は、セキュリティ要件が許可されているため、計算的により高価な公開キーの暗号化を許可する代わりに使用できますが、これには、輸送またはアプリケーションレイヤーセキュリティを使用した信頼できるサードパーティ支援の秘密キー設立のサポートも必要になる場合があります。
Small Amount of Memory: Microcontrollers embedded in IoT devices are often equipped with only a small amount of RAM and flash memory, which places limitations on what kind of processing can be performed and how much code can be put on those devices. To reduce code size, fewer and smaller protocol implementations can be put on the firmware of such a device. In this case, CoAP may be used instead of HTTP, symmetric-key cryptography may be used instead of public-key cryptography, and CBOR may be used instead of JSON. An authentication and key establishment protocol, e.g., the DTLS handshake, in comparison with assisted key establishment, also has an impact on memory and code footprints.
少量のメモリ：IoTデバイスに埋め込まれたマイクロコントローラーには、多くの場合、少量のRAMとフラッシュメモリのみが装備されているため、どのような処理を実行でき、それらのデバイスにどれだけのコードを置くことができるかに制限があります。コードサイズを削減するために、このようなデバイスのファームウェアには、より少ないプロトコルの実装を配置できます。この場合、HTTPの代わりにCOAPを使用でき、対称キー暗号化はパブリックキー暗号化の代わりに使用でき、JSONの代わりにCBORを使用できます。認証と主要な確立プロトコル、たとえば、DTLSの握手が支援された主要な設立と比較して、メモリとコードのフットプリントにも影響を与えます。
User Interface Limitations: Protecting access to resources is both an important security as well as privacy feature. End users and enterprise customers may not want to give access to the data collected by their IoT device or to functions it may offer to third parties. Since the classical approach of requesting permissions from end users via a rich user interface does not work in many IoT deployment scenarios, these functions need to be delegated to user-controlled devices that are better suitable for such tasks, such as smartphones and tablets.
ユーザーインターフェイスの制限：リソースへのアクセスを保護することは、重要なセキュリティとプライバシー機能の両方です。エンドユーザーとエンタープライズの顧客は、IoTデバイスによって収集されたデータや、第三者に提供される機能にアクセスしたくない場合があります。リッチなユーザーインターフェイスを介してエンドユーザーにアクセス許可を要求する古典的なアプローチは、多くのIoT展開シナリオで機能しないため、これらの機能は、スマートフォンやタブレットなどのこのようなタスクに適したユーザー制御デバイスに委任する必要があります。
Communication Constraints: In certain constrained settings, an IoT device may not be able to communicate with a given device at all times. Devices may be sleeping or just disconnected from the Internet because of general lack of connectivity in the area, cost reasons, or security reasons, e.g., to avoid an entry point for denial-of-service attacks.
通信制約：特定の制約された設定では、IoTデバイスが常に特定のデバイスと通信できない場合があります。サービス拒否攻撃のエントリポイントを回避するために、エリアの接続性、コストの理由、またはセキュリティ上の理由など、デバイスが睡眠をとっているか、単にインターネットから切断されている可能性があります。
The communication interactions this framework builds upon (as shown graphically in Figure 1) may be accomplished using a variety of different protocols, and not all parts of the message flow are used in all applications due to the communication constraints. Deployments making use of CoAP are expected, but this framework is not limited to them. Other protocols, such as HTTP or Bluetooth Smart communication, that do not necessarily use IP could also be used. The latter raises the need for application-layer security over the various interfaces.
このフレームワークが構築する通信の相互作用（図1にグラフィカルに示されているように）は、さまざまなプロトコルを使用して達成できます。また、通信の制約により、すべてのアプリケーションでメッセージフローのすべての部分が使用されるわけではありません。COAPを使用する展開が予想されますが、このフレームワークはそれらに限定されません。HTTPやBluetoothスマート通信などの他のプロトコルも、必ずしもIPを使用するとは限りません。後者は、さまざまなインターフェイスでアプリケーション層セキュリティの必要性を高めます。
In the light of these constraints, we have made the following design decisions:
これらの制約に照らして、次の設計上の決定を下しました。
CBOR, COSE, CWT: When using this framework, it is RECOMMENDED to use CBOR [RFC8949] as the data format. Where CBOR data needs to be protected, the use of COSE [RFC8152] is RECOMMENDED. Furthermore, where self-contained tokens are needed, it is RECOMMENDED to use CWT [RFC8392]. These measures aim at reducing the size of messages sent over the wire, the RAM size of data objects that need to be kept in memory, and the size of libraries that devices need to support.
CBOR、COSE、CWT：このフレームワークを使用する場合、CBOR [RFC8949]をデータ形式として使用することをお勧めします。CBORデータを保護する必要がある場合、COSE [RFC8152]の使用が推奨されます。さらに、自己完結型のトークンが必要な場合は、CWT [RFC8392]を使用することをお勧めします。これらの測定は、ワイヤー上で送信されるメッセージのサイズ、メモリに保持する必要があるデータオブジェクトのRAMサイズ、およびデバイスがサポートする必要があるライブラリのサイズを縮小することを目的としています。
CoAP: When using this framework, it is RECOMMENDED to use CoAP [RFC7252] instead of HTTP. This does not preclude the use of other protocols specifically aimed at constrained devices, e.g., Bluetooth Low Energy (see Section 3.2). This aims again at reducing the size of messages sent over the wire, the RAM size of data objects that need to be kept in memory, and the size of libraries that devices need to support.
COAP：このフレームワークを使用する場合、HTTPの代わりにCOAP [RFC7252]を使用することをお勧めします。これは、制約されたデバイス、たとえばBluetooth低エネルギーを目的とした他のプロトコルの使用を排除するものではありません（セクション3.2を参照）。これは、ワイヤー上で送信されるメッセージのサイズ、メモリに保持する必要があるデータオブジェクトのRAMサイズ、およびデバイスがサポートする必要があるライブラリのサイズを減らすことを目的としています。
Access Information: This framework defines the name "Access Information" for data concerning the RS that the AS returns to the client in an access token response (see Section 5.8.2). This aims at enabling scenarios where a powerful client supporting multiple profiles needs to interact with an RS for which it does not know the supported profiles and the raw public key.
アクセス情報：このフレームワークは、ASがアクセストークン応答でクライアントに戻るRSに関するデータの「アクセス情報」という名前を定義します（セクション5.8.2を参照）。これは、複数のプロファイルをサポートする強力なクライアントが、サポートされているプロファイルと生の公開キーを知らないRSと対話する必要があるシナリオを可能にすることを目的としています。
Proof of Possession: This framework makes use of proof-of-possession tokens, using the cnf claim [RFC8747]. A request parameter cnf and a Response parameter cnf, both having a value space semantically and syntactically identical to the cnf claim, are defined for the token endpoint to allow requesting and stating confirmation keys. This aims at making token theft harder. Token theft is specifically relevant in constrained use cases, as communication often passes through middleboxes, which could be able to steal bearer tokens and use them to gain unauthorized access.
所有証明：このフレームワークは、CNFクレーム[RFC8747]を使用して、プルーフオブポッセッショントークンを使用しています。リクエストパラメーターCNFと応答パラメーターCNFは、両方ともCNFクレームとセマンティックおよび構文的に同一の値スペースを持つ、トークンエンドポイントに対して定義され、確認キーの要求と記載を許可します。これは、トークンの盗難を難しくすることを目指しています。トークンの盗難は、制約されたユースケースに特に関連しています。これは、通信がミドルボックスを通過することが多いため、ベアラートークンを盗み、不正アクセスを得るためにそれらを使用できる可能性があるためです。
Authz-Info endpoint: This framework introduces a new way of providing access tokens to an RS by exposing an authz-info endpoint to which access tokens can be POSTed. This aims at reducing the size of the request message and the code complexity at the RS. The size of the request message is problematic, since many constrained protocols have severe message size limitations at the physical layer (e.g., in the order of 100 bytes). This means that larger packets get fragmented, which in turn combines badly with the high rate of packet loss and the need to retransmit the whole message if one packet gets lost. Thus, separating sending of the request and sending of the access tokens helps to reduce fragmentation.
authz-infoエンドポイント：このフレームワークでは、アクセストークンを投稿できるAuthz-infoエンドポイントを公開することにより、アクセストークンをRSに提供する新しい方法を紹介します。これは、Rsのリクエストメッセージのサイズとコードの複雑さを削減することを目的としています。多くの制約付きプロトコルには、物理層（例えば、100バイト程度）で深刻なメッセージサイズの制限があるため、要求メッセージのサイズには問題があります。これは、より大きなパケットが断片化されることを意味します。これは、1つのパケットが失われた場合に、高いパケット損失率とメッセージ全体を再送信する必要性とひどく組み合わされます。したがって、リクエストの送信とアクセストークンの送信を分離すると、断片化を減らすことができます。
Client Credentials Grant: In this framework, the use of the client credentials grant is RECOMMENDED for machine-to-machine communication use cases, where manual intervention of the resource owner to produce a grant token is not feasible. The intention is that the resource owner would instead prearrange authorization with the AS based on the client's own credentials. The client can then (without manual intervention) obtain access tokens from the AS.
クライアント資格認定助成金：このフレームワークでは、クライアントクレデンシャルの助成金の使用が、マシン間通信のユースケースに推奨されます。この場合、リソース所有者が助成金トークンを作成するための手動介入は実現不可能です。意図は、リソースの所有者が代わりに、クライアント自身の資格情報に基づいてASで承認を条件として事前に条件として事前に課すことです。クライアントは（手動介入なしで）ASからアクセストークンを取得できます。
Introspection: In this framework, the use of access token introspection is RECOMMENDED in cases where the client is constrained in a way that it cannot easily obtain new access tokens (i.e., it has connectivity issues that prevent it from communicating with the AS). In that case, it is RECOMMENDED to use a long-term token that could be a simple reference. The RS is assumed to be able to communicate with the AS and can therefore perform introspection in order to learn the claims associated with the token reference. The advantage of such an approach is that the resource owner can change the claims associated to the token reference without having to be in contact with the client, thus granting or revoking access rights.
内省：このフレームワークでは、クライアントが新しいアクセストークンを簡単に取得できないように制約されている場合にアクセストークン内省の使用が推奨されます（つまり、ASと通信するのを防ぐ接続の問題があります）。その場合、単純な参照になる可能性のある長期トークンを使用することをお勧めします。RSは、ASと通信できると想定されているため、トークン参照に関連するクレームを学習するために内省を実行できます。このようなアプローチの利点は、リソース所有者がクライアントと連絡を取ることなくトークンリファレンスに関連するクレームを変更し、アクセス権を付与または取り消すことができることです。
Resource Owner * Make sure that the RS is registered at the AS. This includes making known to the AS which profiles, token_type, scopes, and key types (symmetric/asymmetric) the RS supports. Also making it known to the AS which audience(s) the RS identifies itself with.
リソース所有者 * RSがASに登録されていることを確認してください。これには、RSがサポートするプロファイル、token_type、scopes、およびキータイプ（対称/非対称）としてどのようなプロファイルを作成するかが含まれます。また、RSがどの視聴者を識別しているかを知っています。
* Make sure that clients can discover the AS that is in charge of the RS.
* クライアントがRsを担当しているAsを発見できることを確認してください。
* If the client-credentials grant is used, make sure that the AS has the necessary, up-to-date access control policies for the RS.
* Client-Credentials Grantが使用されている場合は、ASがRSの必要な最新のアクセス制御ポリシーを持っていることを確認してください。
Requesting Party * Make sure that the client is provisioned the necessary credentials to authenticate to the AS.
要求パーティ * ASに認証するために必要な資格情報をクライアントがプロビジョニングしていることを確認します。
* Make sure that the client is configured to follow the security requirements of the requesting party when issuing requests (e.g., minimum communication security requirements or trust anchors).
* クライアントが、リクエストを発行する際に要求者のセキュリティ要件に従うように構成されていることを確認してください（たとえば、最小通信セキュリティ要件や信頼のアンカー）。
* Register the client at the AS. This includes making known to the AS which profiles, token_types, and key types (symmetric/ asymmetric) for the client.
* ASでクライアントを登録します。これには、クライアントのどのプロファイル、token_types、およびキータイプ（対称/非対称）として知られるようにすることが含まれます。
Authorization Server * Register the RS and manage corresponding security contexts.
Authorization Server * RSを登録し、対応するセキュリティコンテキストを管理します。
* Register clients and authentication credentials.
* クライアントと認証資格情報を登録します。
* Allow resource owners to configure and update access control policies related to their registered RSs.
* リソース所有者が登録されているRSSに関連するアクセス制御ポリシーを構成および更新できるようにします。
* Expose the token endpoint to allow clients to request tokens.
* トークンのエンドポイントを公開して、クライアントがトークンを要求できるようにします。
* Authenticate clients that wish to request a token.
* トークンを要求したいクライアントを認証します。
* Process a token request using the authorization policies configured for the RS.
* Rs用に構成された承認ポリシーを使用して、トークン要求を処理します。
* Optionally, expose the introspection endpoint that allows RSs to submit token introspection requests.
* オプションでは、RSSがトークン内省要求を提出できるようにする内省エンドポイントを公開します。
* If providing an introspection endpoint, authenticate RSs that wish to get an introspection response.
* 内省エンドポイントを提供する場合、内省応答を取得したいRSSを認証します。
* If providing an introspection endpoint, process token introspection requests.
* 内省のエンドポイントを提供する場合、トークン内省要求を処理します。
* Optionally, handle token revocation.
* オプションで、トークンの取り消しを処理します。
* Optionally, provide discovery metadata. See [RFC8414].
* オプションで、発見メタデータを提供します。[RFC8414]を参照してください。
* Optionally, handle refresh tokens.
* オプションで、トークンの更新を処理します。
Client * Discover the AS in charge of the RS that is to be targeted with a request.
クライアント *リクエストでターゲットにされるRSを担当するASを発見します。
* Submit the token request (see step (A) of Figure 1).
* トークンリクエストを送信します（図1のステップ（a）を参照）。
- Authenticate to the AS.
- ASに認証します。
- Optionally (if not preconfigured), specify which RS, which resource(s), and which action(s) the request(s) will target.
- オプションで（事前に設定されていない場合）、どのRS、リソース、およびどのアクションがリクエストをターゲットにするかを指定します。
- If raw public keys (RPKs) or certificates are used, make sure the AS has the right RPK or certificate for this client.
- 生のパブリックキー（RPK）または証明書が使用されている場合は、このクライアントに適切なRPKまたは証明書があることを確認してください。
* Process the access token and Access Information (see step (B) of Figure 1).
* アクセストークンとアクセス情報を処理します（図1のステップ（b）を参照）。
- Check that the Access Information provides the necessary security parameters (e.g., PoP key or information on communication security protocols supported by the RS).
- アクセス情報が必要なセキュリティパラメーターを提供していることを確認します（例：RSでサポートされている通信セキュリティプロトコルに関するPOPキーまたは情報）。
- Safely store the proof-of-possession key.
- Proof-of-Possessionキーを安全に保存します。
- If provided by the AS, safely store the refresh token.
- ASによって提供される場合は、更新トークンを安全に保存します。
* Send the token and request to the RS (see step (C) of Figure 1).
* トークンを送信し、Rsにリクエストを要求します（図1のステップ（c）を参照）。
- Authenticate towards the RS (this could coincide with the proof-of-possession process).
- RSに向けて認証します（これは、所有の証明プロセスと一致する可能性があります）。
- Transmit the token as specified by the AS (default is to the authz-info endpoint; alternative options are specified by profiles).
- ASで指定されているトークンを送信します（デフォルトはauthz-infoエンドポイントにあります。代替オプションはプロファイルで指定されています）。
- Perform the proof-of-possession procedure as specified by the profile in use (this may already have been taken care of through the authentication procedure).
- 使用中のプロファイルで指定されているプルーフオブポッセッション手順を実行します（これは、認証手順を通じてすでに処理されている可能性があります）。
* Process the RS response (see step (F) of Figure 1) of the RS.
* RsのRS応答（図1のステップ（f）を参照）を処理します。
Resource Server * Expose a way to submit access tokens. By default, this is the authz-info endpoint.
リソースサーバー *アクセストークンを送信する方法を公開します。デフォルトでは、これはauthz-infoエンドポイントです。
* Process an access token.
* アクセストークンを処理します。
- Verify the token is from a recognized AS.
- トークンが認識されていることを確認します。
- Check the token's integrity.
- トークンの完全性を確認してください。
- Verify that the token applies to this RS.
- トークンがこのRsに適用されることを確認します。
- Check that the token has not expired (if the token provides expiration information).
- トークンが期限切れになっていないことを確認します（トークンが有効期限情報を提供している場合）。
- Store the token so that it can be retrieved in the context of a matching request.
- トークンを保存して、一致するリクエストのコンテキストで取得できるようにします。
Note: The order proposed here is not normative; any process that arrives at an equivalent result can be used. A noteworthy consideration is whether one can use cheap operations early on to quickly discard nonapplicable or invalid tokens before performing expensive cryptographic operations (e.g., doing an expiration check before verifying a signature).
注：ここで提案されている順序は規範的ではありません。同等の結果に到達するプロセスを使用できます。注目に値する考慮事項は、高価な暗号操作を実行する前に、早期に安価な操作を使用して適用できないトークンまたは無効なトークンをすばやく破棄できるかどうかです（たとえば、署名を確認する前に有効期限チェックを行う）。
* Process a request.
* リクエストを処理します。
- Set up communication security with the client.
- クライアントとの通信セキュリティを設定します。
- Authenticate the client.
- クライアントを認証します。
- Match the client against existing tokens.
- クライアントを既存のトークンと一致させます。
- Check that tokens belonging to the client actually authorize the requested action.
- クライアントに属するトークンが実際に要求されたアクションを承認することを確認してください。
- Optionally, check that the matching tokens are still valid, using introspection (if this is possible.)
- オプションで、一致するトークンが内省を使用してまだ有効であることを確認してください（これが可能な場合）。
* Send a response following the agreed upon communication security mechanism(s).
* 合意された通信セキュリティメカニズムに続いて応答を送信します。
* Safely store credentials, such as raw public keys, for authentication or proof-of-possession keys linked to access tokens.
* 生のパブリックキーなどの資格情報を安全に保存して、アクセストークンにリンクされた認証または入力証明キーを保存します。
This section lists the requirements on profiles of this framework for the convenience of profile designers.
このセクションには、プロファイルデザイナーの利便性のためのこのフレームワークのプロファイルに関する要件をリストします。
* Optionally, define new methods for the client to discover the necessary permissions and AS for accessing a resource different from the one proposed in Sections 5.1 and 4
* オプションでは、クライアントが必要なアクセス許可を発見し、セクション5.1および4で提案されているリソースとは異なるリソースにアクセスするための新しい方法を定義します。
* Optionally, specify new grant types (Section 5.4).
* オプションで、新しい助成金タイプを指定します（セクション5.4）。
* Optionally, define the use of client certificates as client credential type (Section 5.5).
* オプションで、クライアント証明書の使用をクライアント資格情報のタイプとして定義します（セクション5.5）。
* Specify the communication protocol the client and RS must use (e.g., CoAP) (Sections 5 and 5.8.4.3).
* クライアントが使用する必要がある通信プロトコル（COAPなど）を指定します（セクション5および5.8.4.3）。
* Specify the security protocol the client and RS must use to protect their communication (e.g., OSCORE or DTLS). This must provide encryption and integrity and replay protection (Section 5.8.4.3).
* クライアントとRSが通信を保護するために使用する必要があるセキュリティプロトコルを指定します（OSCOREまたはDTLSなど）。これは、暗号化と完全性とリプレイの保護を提供する必要があります（セクション5.8.4.3）。
* Specify how the client and the RS mutually authenticate (Section 4).
* クライアントとRSが相互に認証する方法を指定します（セクション4）。
* Specify the proof-of-possession protocol(s) and how to select one if several are available. Also specify which key types (e.g., symmetric/asymmetric) are supported by a specific proof-of-possession protocol (Section 5.8.4.2).
* Proof-of-Possessionプロトコルを指定し、いくつかが利用可能な場合は1つを選択する方法を指定します。また、特定のプルーフオブポッセッションプロトコル（セクション5.8.4.2）によってサポートされるキータイプ（対称/非対称など）も指定します。
* Specify a unique ace_profile identifier (Section 5.8.4.3).
* 一意のace_profile識別子を指定します（セクション5.8.4.3）。
* If introspection is supported, specify the communication and security protocol for introspection (Section 5.9).
* 内省がサポートされている場合は、内省のための通信およびセキュリティプロトコルを指定します（セクション5.9）。
* Specify the communication and security protocol for interactions between the client and AS. This must provide encryption, integrity protection, replay protection, and a binding between requests and responses (Sections 5 and 5.8).
* クライアントとAS間の相互作用のための通信およびセキュリティプロトコルを指定します。これは、暗号化、整合性保護、リプレイ保護、およびリクエストと応答の間の拘束力を提供する必要があります（セクション5および5.8）。
* Specify how/if the authz-info endpoint is protected, including how error responses are protected (Section 5.10.1).
* エラー応答の保護方法など、AuthZ-INFOエンドポイントが保護されている方法/かどうかを指定します（セクション5.10.1）。
* Optionally, define other methods of token transport than the authz-info endpoint (Section 5.10.1).
* オプションでは、Authz-INFOエンドポイント（セクション5.10.1）よりも、他のトークン輸送方法を定義します。
This section lists the assumptions on what an AS should know about a client and an RS in order to be able to respond to requests to the token and introspection endpoints. How this information is established is out of scope for this document.
このセクションでは、トークンと内省のエンドポイントへのリクエストに応答できるようにするために、クライアントとRSについて知っておくべきことに関する仮定をリストします。この情報の確立方法は、このドキュメントの範囲外です。
* The identifier of the client or RS.
* クライアントまたはRsの識別子。
* The profiles that the client or RS supports.
* クライアントまたはRSがサポートするプロファイル。
* The scopes that the RS supports.
* RSがサポートするスコープ。
* The audiences that the RS identifies with.
* RSが識別する視聴者。
* The key types (e.g., pre-shared symmetric key, raw public key, key length, and other key parameters) that the client or RS supports.
* クライアントまたはRSがサポートするキータイプ（たとえば、以前の共有対称キー、生の公開キー、キー長、およびその他のキーパラメーター）。
* The types of access tokens the RS supports (e.g., CWT).
* RSがサポートするアクセスの種類（例：CWT）。
* If the RS supports CWTs, the COSE parameters for the crypto wrapper (e.g., algorithm, key-wrap algorithm, and key-length) that the RS supports.
* RSがCWTSをサポートしている場合、RSがサポートするCryptoラッパー（例：アルゴリズム、キーWRAPアルゴリズム、キーレングス）のCOSEパラメーター。
* The expiration time for access tokens issued to this RS (unless the RS accepts a default time chosen by the AS).
* このRSに発行されたアクセストークンの有効期限は（RSがASによって選択されたデフォルトの時間を受け入れない限り）。
* The symmetric key shared between the client and AS (if any).
* 対称キーは、クライアントとAS（ある場合）の間で共有されます。
* The symmetric key shared between the RS and AS (if any).
* 対称キーは、RSとAS（ある場合）の間で共有されます。
* The raw public key of the client or RS (if any).
* クライアントまたはRSの生の公開鍵（ある場合）。
* Whether the RS has synchronized time (and thus is able to use the exp claim) or not.
* RSが同期した時間を持っているかどうか（したがって、Expクレームを使用できるかどうか）かどうか。
This document adapts OAuth 2.0 to be suitable for constrained environments. This section lists the main differences from the normative requirements of OAuth 2.0.
このドキュメントは、制約された環境に適しているようにOAUTH 2.0を適応させます。このセクションには、OAUTH 2.0の規範的要件との主な違いをリストします。
Use of TLS OAuth 2.0 requires the use of TLS to protect the communication between the AS and client when requesting an access token, between the client and RS when accessing a resource, and between the AS and RS if introspection is used. This framework requires similar security properties but does not require that they be realized with TLS. See Section 5.
TLS OAUTH 2.0の使用には、ASとクライアントの間の通信を保護するためにTLSを使用する必要があります。アクセストークンを要求するとき、クライアントとRSの間、リソースにアクセスするとき、および内省が使用される場合はASとRSの間です。このフレームワークには、同様のセキュリティプロパティが必要ですが、TLSで実現する必要はありません。セクション5を参照してください。
Cardinality of grant_type parameter In client-to-AS requests using OAuth 2.0, the grant_type parameter is required (per [RFC6749]). In this framework, this parameter is optional. See Section 5.8.1.
OAUTH 2.0を使用してクライアントからASのリクエストにおけるgrant_typeパラメーターのカーディナリティが必要です（[RFC6749]ごとに）。このフレームワークでは、このパラメーターはオプションです。セクション5.8.1を参照してください。
Encoding of scope parameter In client-to-AS requests using OAuth 2.0, the scope parameter is string encoded (per [RFC6749]). In this framework, this parameter may also be encoded as a byte string. See Section 5.8.1.
OAUTH 2.0を使用してクライアントからクライアントへのリクエストにおけるスコープパラメーターのエンコード、スコープパラメーターは文字列エンコード（[RFC6749]ごと）です。このフレームワークでは、このパラメーターはバイト文字列としてエンコードされる場合があります。セクション5.8.1を参照してください。
Cardinality of token_type parameter In AS-to-client responses using OAuth 2.0, the token_type parameter is required (per [RFC6749]). In this framework, this parameter is optional. See Section 5.8.2.
OAUTH 2.0を使用したASクライアント応答におけるtoken_typeパラメーターのカーディナリティ、token_typeパラメーターが必要です（[RFC6749]ごと）。このフレームワークでは、このパラメーターはオプションです。セクション5.8.2を参照してください。
Access token retention In OAuth 2.0, the access token may be sent with every request to the RS. The exact use of access tokens depends on the semantics of the application and the session management concept it uses. In this framework, the RS must be able to store these tokens for later use. See Section 5.10.1.
アクセストークン保持OAUTH 2.0では、アクセストークンは、Rsにリクエストするたびに送信できます。アクセストークンの正確な使用は、アプリケーションのセマンティクスと使用するセッション管理の概念によって異なります。このフレームワークでは、RSは後で使用するためにこれらのトークンを保存できる必要があります。セクション5.10.1を参照してください。
There is a large variety of IoT deployments, as is indicated in Appendix A, and this section highlights a few common variants. This section is not normative but illustrates how the framework can be applied.
付録Aに示されているように、さまざまなIoT展開があり、このセクションではいくつかの一般的なバリアントを強調しています。このセクションは規範ではありませんが、フレームワークを適用する方法を示しています。
For each of the deployment variants, there are a number of possible security setups between clients, resource servers, and authorization servers. The main focus in the following subsections is on how authorization of a client request for a resource hosted by an RS is performed. This requires the security of the requests and responses between the clients and the RS to be considered.
展開バリエーションのそれぞれについて、クライアント、リソースサーバー、および認証サーバーの間に多くの可能なセキュリティセットアップがあります。次のサブセクションの主な焦点は、RSがホストするリソースのクライアント要求の承認がどのように実行されるかです。これには、クライアントとRSの間のリクエストと応答のセキュリティが考慮される必要があります。
Note: CBOR diagnostic notation is used for examples of requests and responses.
注：CBOR診断表記は、リクエストと応答の例に使用されます。
In this scenario, the case where the resource server is offline is considered, i.e., it is not connected to the AS at the time of the access request. This access procedure involves steps (A), (B), (C), and (F) of Figure 1.
このシナリオでは、リソースサーバーがオフラインである場合、つまり、アクセスリクエストの時点でASに接続されていません。このアクセス手順には、図1の手順（a）、（b）、（c）、および（f）が含まれます。
Since the resource server must be able to verify the access token locally, self-contained access tokens must be used.
リソースサーバーはアクセストークンをローカルで確認できる必要があるため、自己完結型アクセストークンを使用する必要があります。
This example shows the interactions between a client, the authorization server, and a temperature sensor acting as a resource server. Message exchanges A and B are shown in Figure 11.
この例は、クライアント、認証サーバー、およびリソースサーバーとして機能する温度センサー間の相互作用を示しています。メッセージ交換AとBを図11に示します。
A: The client first generates a public-private key pair used for communication security with the RS.
A：クライアントは、最初にRSとの通信セキュリティに使用される官民キーペアを生成します。
The client sends a CoAP POST request to the token endpoint at the AS. The security of this request can be transport or application layer. It is up the communication security profile to define. In the example, it is assumed that both the client and AS have performed mutual authentication, e.g., via DTLS. The request contains the public key of the client and the audience parameter set to "tempSensorInLivingRoom", a value that the temperature sensor identifies itself with. The AS evaluates the request and authorizes the client to access the resource.
クライアントは、ASのトークンエンドポイントにCOAP POSTリクエストを送信します。このリクエストのセキュリティは、トランスポートまたはアプリケーションレイヤーです。定義するのは通信セキュリティプロファイルです。この例では、クライアントとASの両方が、たとえばDTLSを介して相互認証を実行したと想定されています。リクエストには、クライアントの公開鍵と、「Tempsensorinlivivesroom」に設定されたオーディエンスパラメーターが含まれています。これは、温度センサーが識別する値です。ASはリクエストを評価し、クライアントにリソースにアクセスすることを許可します。
B: The AS responds with a 2.05 (Content) response containing the Access Information, including the access token. The PoP access token contains the public key of the client, and the Access Information contains the public key of the RS. For communication security, this example uses DTLS RawPublicKey between the client and the RS. The issued token will have a short validity time, i.e., exp close to iat, in order to mitigate attacks using stolen client credentials. The token includes claims, such as scope, with the authorized access that an owner of the temperature device can enjoy. In this example, the scope claim issued by the AS informs the RS that the owner of the token that can prove the possession of a key is authorized to make a GET request against the /temperature resource and a POST request on the /firmware resource. Note that the syntax and semantics of the scope claim are application specific.
B：ASは、アクセストークンを含むアクセス情報を含む2.05（コンテンツ）応答で応答します。ポップアクセストークンにはクライアントの公開鍵が含まれており、アクセス情報にはRSの公開鍵が含まれています。通信セキュリティのために、この例では、クライアントとRSの間でDTLS RawPublickeyを使用しています。発行されたトークンは、盗まれたクライアントの資格情報を使用して攻撃を軽減するために、IATに近いExpの妥当性時間が短いです。トークンには、温度デバイスの所有者が享受できる許可されたアクセスを含む範囲などのクレームが含まれています。この例では、ASが発行したスコープ請求は、キーの所有を証明できるトークンの所有者が /温度リソースに対するGETリクエストと /ファームウェアリソースのPOSTリクエストを行うことを許可されていることをRSに通知します。スコープクレームの構文とセマンティクスはアプリケーション固有であることに注意してください。
Note: In this example, it is assumed that the client knows what resource it wants to access and is therefore able to request specific audience and scope claims for the access token.
注：この例では、クライアントがアクセスしたいリソースを知っているため、アクセストークンの特定のオーディエンスと範囲のクレームを要求できると想定されています。
Authorization
Client Server
| |
|<=======>| DTLS Connection Establishment
| | and mutual authentication
| |
A: +-------->| Header: POST (Code=0.02)
| POST | Uri-Path:"token"
| | Content-Format: application/ace+cbor
| | Payload: <Request-Payload>
| |
B: |<--------+ Header: 2.05 Content
| 2.05 | Content-Format: application/ace+cbor
| | Payload: <Response-Payload>
| |
Figure 11: Token Request and Response Using Client Credentials
図11：クライアント資格情報を使用したトークンの要求と応答
The information contained in the Request-Payload and the Response-Payload is shown in Figure 12. Note that the parameter rs_cnf from [RFC9201] is used to inform the client about the resource server's public key.
リクエストペイロードと応答ペイロードに含まれる情報を図12に示します。[RFC9201]のパラメーターrs_cnfは、リソースサーバーの公開キーについてクライアントに通知するために使用されることに注意してください。
Request-Payload :
{
/ audience / 5 : "tempSensorInLivingRoom",
/ client_id / 24 : "myclient",
/ req_cnf / 4 : {
/ COSE_Key / 1 : {
/ kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
/ kty / 1 : 2 / EC2 /,
/ crv / -1 : 1 / P-256 /,
/ x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
/ y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
}
}
}
Response-Payload :
{
/ access_token / 1 : b64'0INDoQEKoQVNKkXfb7xaWqMT'/ .../,
/ rs_cnf / 41 : {
/ COSE_Key / 1 : {
/ kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
/ kty / 1 : 2 / EC2 /,
/ crv / -1 : 1 / P-256 /,
/ x / -2 : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4',
/ y / -3 : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM'
}
}
}
Figure 12: Request and Response Payload Details
図12：リクエストと応答ペイロードの詳細
The content of the access token is shown in Figure 13.
アクセストークンの内容を図13に示します。
{
/ aud / 3 : "tempSensorInLivingRoom",
/ iat / 6 : 1563451500,
/ exp / 4 : 1563453000,
/ scope / 9 : "temperature_g firmware_p",
/ cnf / 8 : {
/ COSE_Key / 1 : {
/ kid / 2 : b64'1Bg8vub9tLe1gHMzV76e',
/ kty / 1 : 2 / EC2 /,
/ crv / -1 : 1 / P-256 /,
/ x / -2 : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU',
/ y / -3 : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0'
}
}
}
Figure 13: Access Token Including Public Key of the Client
図13：クライアントの公開鍵を含むアクセストークン
Messages C and F are shown in Figures 14 and 15.
メッセージCとFを図14および15に示します。
C: The client then sends the PoP access token to the authz-info endpoint at the RS. This is a plain CoAP POST request, i.e., no transport or application-layer security is used between the client and RS since the token is integrity protected between the AS and RS. The RS verifies that the PoP access token was created by a known and trusted AS, which it applies to this RS, and that it is valid. The RS caches the security context together with authorization information about this client contained in the PoP access token.
C：次に、クライアントはRSのPOPアクセストークンをAUTHZ-INFOエンドポイントに送信します。これはプレーンコップポストリクエストです。つまり、トークンはASとRSの間で整合性保護されているため、クライアントとRSの間で輸送またはアプリケーションレイヤーのセキュリティは使用されません。RSは、ポップアクセストークンが既知の信頼と信頼できるものによって作成されたことを確認します。これは、このRSに適用され、有効であることを確認します。RSは、ポップアクセストークンに含まれるこのクライアントに関する認証情報とともに、セキュリティコンテキストをキャッシュします。
Resource
Client Server
| |
C: +-------->| Header: POST (Code=0.02)
| POST | Uri-Path:"authz-info"
| | Payload: 0INDoQEKoQVN ...
| |
|<--------+ Header: 2.04 Changed
| 2.04 |
| |
Figure 14: Access Token Provisioning to the RS
図14：Rsへのトークンプロビジョニングにアクセスします
The client and the RS runs the DTLS handshake using the raw public keys established in steps B and C.
クライアントとRSは、手順BとCに確立された生の公開キーを使用してDTLSハンドシェイクを実行します。
The client sends a CoAP GET request to /temperature on the RS over DTLS. The RS verifies that the request is authorized based on previously established security context.
クライアントは、DTLSを介してRSのCOAP GETリクエスト /温度を送信します。RSは、以前に確立されたセキュリティコンテキストに基づいて、リクエストが承認されていることを確認します。
F: The RS responds over the same DTLS channel with a CoAP 2.05 Content response containing a resource representation as payload.
F：RSは、ペイロードとしてリソース表現を含むCOAP 2.05コンテンツ応答で同じDTLSチャネルで応答します。
Resource
Client Server
| |
|<=======>| DTLS Connection Establishment
| | using Raw Public Keys
| |
+-------->| Header: GET (Code=0.01)
| GET | Uri-Path: "temperature"
| |
| |
| |
F: |<--------+ Header: 2.05 Content
| 2.05 | Payload: <sensor value>
| |
Figure 15: Resource Request and Response Protected by DTLS
図15：DTLによって保護されているリソース要求と応答
In this deployment scenario, it is assumed that a client is not able to access the AS at the time of the access request, whereas the RS is assumed to be connected to the back-end infrastructure. Thus, the RS can make use of token introspection. This access procedure involves steps (A)-(F) of Figure 1 but assumes steps (A) and (B) have been carried out during a phase when the client had connectivity to the AS.
この展開シナリオでは、クライアントはアクセス要求の時点でASにアクセスできないと想定されていますが、RSはバックエンドインフラストラクチャに接続されていると想定されています。したがって、RSはトークン内省を利用できます。このアクセス手順には、図1の手順（a） - （f）が含まれますが、クライアントがASに接続したフェーズ中に手順（a）と（b）が実行されたと想定しています。
Since the client is assumed to be offline, at least for a certain period of time, a preprovisioned access token has to be long lived. Since the client is constrained, the token will not be self-contained (i.e., not a CWT) but instead just a reference. The resource server uses its connectivity to learn about the claims associated to the access token by using introspection, which is shown in the example below.
クライアントは、少なくとも一定の期間、オフラインであると想定されるため、既存のアクセストークンを長期にわたって生きなければなりません。クライアントは制約されているため、トークンは自己完結型（つまり、CWTではなく）ではなく、単なる参照です。リソースサーバーは、その接続性を使用して、以下の例に示す内省を使用して、アクセストークンに関連するクレームについて学習します。
In the example, interactions between an offline client (key fob), an RS (online lock), and an AS is shown. It is assumed that there is a provisioning step where the client has access to the AS. This corresponds to message exchanges A and B, which are shown in Figure 16.
この例では、オフラインクライアント（キーFOB）、RS（オンラインロック）、および示されているように相互作用します。クライアントがASにアクセスできるプロビジョニングステップがあると想定されています。これは、図16に示すメッセージ交換AとBに対応します。
Authorization consent from the resource owner can be preconfigured, but it can also be provided via an interactive flow with the resource owner. An example of this for the key fob case could be that the resource owner has a connected car and buys a generic key to use with the car. To authorize the key fob, the owner connects it to a computer that then provides the UI for the device. After that, OAuth 2.0 implicit flow can be used to authorize the key for the car at the car manufacturer's AS.
リソース所有者からの承認の同意は、事前に設定できますが、リソース所有者とのインタラクティブなフローを介して提供することもできます。キーFOBケースのこの例は、リソースの所有者が接続された車を持ち、車で使用する一般的なキーを購入していることです。キーFOBを承認するために、所有者はそれをコンピューターに接続し、デバイスにUIを提供します。その後、OAUTH 2.0の暗黙的なフローを使用して、自動車メーカーASの車のキーを承認できます。
Note: In this example, the client does not know the exact door it will be used to access since the token request is not sent at the time of access. So the scope and audience parameters are set quite wide to start with, while tailored values narrowing down the claims to the specific RS being accessed can be provided to that RS during an introspection step.
注：この例では、クライアントは、アクセス時にトークンリクエストが送信されないため、アクセスに使用される正確なドアを知りません。したがって、スコープとオーディエンスのパラメーターは最初から非常に広く設定されていますが、調整された値がイントロスペクティションステップ中にアクセスされる特定のRSの主張を絞り込むことができます。
A: The client sends a CoAP POST request to the token endpoint at the AS. The request contains the audience parameter set to "PACS1337" (Physical Access System (PACS)), a value that identifies the physical access control system to which the individual doors are connected. The AS generates an access token as an opaque string, which it can match to the specific client and the targeted audience. It furthermore generates a symmetric proof-of-possession key. The communication security and authentication between the client and AS is assumed to have been provided at the transport layer (e.g., via DTLS) using a pre-shared security context (pre-shared key (PSK), RPK, or certificate).
A：クライアントは、ASのトークンエンドポイントにCOAP POSTリクエストを送信します。この要求には、「PACS1337」（物理アクセスシステム（PACS））に設定されたオーディエンスパラメーターが含まれています。これは、個々のドアが接続されている物理アクセス制御システムを識別する値です。ASは、特定のクライアントとターゲットオーディエンスに一致させることができる不透明な文字列としてアクセストークンを生成します。さらに、対称的なプルーフオブポッセッションキーを生成します。クライアント間の通信セキュリティと認証は、事前共有セキュリティコンテキスト（Pre-Sharedキー（PSK）、RPK、または証明書）を使用して、輸送層（例：DTLを介して）で提供されていると想定されています。
B: The AS responds with a CoAP 2.05 Content response, containing as payload the Access Information, including the access token and the symmetric proof-of-possession key. Communication security between the C and RS will be DTLS and PreSharedKey. The PoP key is used as the PreSharedKey.
B：ASは、Accessトークンや対称的なプルーフオブポッセッションキーを含むアクセス情報をペイロードとして含むCOAP 2.05コンテンツ応答で応答します。CとRSの間のコミュニケーションセキュリティは、DTLとPresharedKeyです。POPキーはPresharedKeyとして使用されます。
Note: In this example, we are using a symmetric key for a multi-RS audience, which is not recommended normally (see Section 6.9). However, in this case, the risk is deemed to be acceptable, since all the doors are part of the same physical access control system; therefore, the risk of a malicious RS impersonating the client towards another RS is low.
注：この例では、マルチRSオーディエンスに対称キーを使用していますが、これは正常に推奨されていません（セクション6.9を参照）。ただし、この場合、すべてのドアは同じ物理アクセス制御システムの一部であるため、リスクは受け入れられるとみなされます。したがって、悪意のあるRSがクライアントに別のRSになりすましているリスクは低いです。
Authorization
Client Server
| |
|<=======>| DTLS Connection Establishment
| | and mutual authentication
| |
A: +-------->| Header: POST (Code=0.02)
| POST | Uri-Path:"token"
| | Content-Format: application/ace+cbor
| | Payload: <Request-Payload>
| |
B: |<--------+ Header: 2.05 Content
| | Content-Format: application/ace+cbor
| 2.05 | Payload: <Response-Payload>
| |
Figure 16: Token Request and Response Using Client Credentials
図16：クライアント資格情報を使用したトークンの要求と応答
The information contained in the Request-Payload and the Response-Payload is shown in Figure 17.
リクエストペイロードと応答ペイロードに含まれる情報を図17に示します。
Request-Payload:
{
/ client_id / 24 : "keyfob",
/ audience / 5 : "PACS1337"
}
Response-Payload:
{
/ access_token / 1 : b64'VGVzdCB0b2tlbg',
/ cnf / 8 : {
/ COSE_Key / 1 : {
/ kid / 2 : b64'c29tZSBwdWJsaWMga2V5IGlk',
/ kty / 1 : 4 / Symmetric /,
/ k / -1 : b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE'
}
}
}
Figure 17: Request and Response Payload for the C Offline
図17：オフラインのCのリクエストと応答ペイロード
In this case, the access token is just an opaque byte string referencing the authorization information at the AS.
この場合、アクセストークンは、ASの承認情報を参照する不透明なバイト文字列です。
C: Next, the client POSTs the access token to the authz-info endpoint in the RS. This is a plain CoAP request, i.e., no DTLS between the client and RS. Since the token is an opaque string, the RS cannot verify it on its own, and thus defers to respond to the client with a status code until after step E.
C：次に、クライアントはRSのAUTHZ-INFOエンドポイントにアクセストークンを投稿します。これは単純なCOAP要求です。つまり、クライアントとRsの間にDTLはありません。トークンは不透明な文字列であるため、RSはそれ自体でそれを確認することができないため、ステップEの後までステータスコードでクライアントに応答するようにdeferします。
D: The RS sends the token to the introspection endpoint on the AS using a CoAP POST request. In this example, the RS and AS are assumed to have performed mutual authentication using a pre-shared security context (PSK, RPK, or certificate) with the RS acting as the DTLS client.
D：RSは、COAP POSTリクエストを使用してASの内省エンドポイントにトークンを送信します。この例では、RSおよびASは、DTLSクライアントとして機能するRSを使用して、事前共有セキュリティコンテキスト（PSK、RPK、または証明書）を使用して相互認証を実行したと想定されています。
E: The AS provides the introspection response (2.05 Content) containing parameters about the token. This includes the confirmation key (cnf) parameter that allows the RS to verify the client's proof of possession in step F. Note that our example in Figure 19 assumes a preestablished key (e.g., one used by the client and the RS for a previous token) that is now only referenced by its key identifier kid.
E：ASは、トークンに関するパラメーターを含む内省応答（2.05コンテンツ）を提供します。これには、RSがステップFでクライアントの所有の証明を検証できる確認キー（CNF）パラメーターが含まれます。図19の例は、事前に確立されたキーを想定していることに注意してください（例えば、クライアントが以前のトークンで使用しているものとRSが使用しています。）それは現在、そのキー識別子KIDによってのみ参照されています。
After receiving message E, the RS responds to the client's POST in step C with the CoAP response code 2.01 (Created).
メッセージEを受信した後、RSはCOAP応答コード2.01（作成）でステップCのクライアントの投稿に応答します。
Resource
Client Server
| |
C: +-------->| Header: POST (T=CON, Code=0.02)
| POST | Uri-Path:"authz-info"
| | Payload: b64'VGVzdCB0b2tlbg'
| |
| | Authorization
| | Server
| | |
| D: +--------->| Header: POST (Code=0.02)
| | POST | Uri-Path: "introspect"
| | | Content-Format: application/ace+cbor
| | | Payload: <Request-Payload>
| | |
| E: |<---------+ Header: 2.05 Content
| | 2.05 | Content-Format: application/ace+cbor
| | | Payload: <Response-Payload>
| | |
| |
|<--------+ Header: 2.01 Created
| 2.01 |
| |
Figure 18: Token Introspection for the C Offline
図18：Cオフラインのトークン内省
The information contained in the Request-Payload and the Response-Payload is shown in Figure 19.
リクエストペイロードと応答ペイロードに含まれる情報を図19に示します。
Request-Payload:
{
/ token / 11 : b64'VGVzdCB0b2tlbg',
/ client_id / 24 : "FrontDoor"
}
Response-Payload:
{
/ active / 10 : true,
/ aud / 3 : "lockOfDoor4711",
/ scope / 9 : "open close",
/ iat / 6 : 1563454000,
/ cnf / 8 : {
/ kid / 3 : b64'c29tZSBwdWJsaWMga2V5IGlk'
}
}
Figure 19: Request and Response Payload for Introspection
図19：内省のためのリクエストと応答のペイロード
The client uses the symmetric PoP key to establish a DTLS PreSharedKey secure connection to the RS. The CoAP request PUT is sent to the uri-path /state on the RS, changing the state of the door to locked.
クライアントは、対称POPキーを使用して、RSへのDTLS PresharedKeyセキュアな接続を確立します。COAPリクエストプットはRSのURI-Path /Stateに送信され、ドアの状態をロックします。
F: The RS responds with an appropriate response over the secure DTLS channel.
F：RSは、安全なDTLSチャネルを介した適切な応答で応答します。
Resource
Client Server
| |
|<=======>| DTLS Connection Establishment
| | using Pre Shared Key
| |
+-------->| Header: PUT (Code=0.03)
| PUT | Uri-Path: "state"
| | Payload: <new state for the lock>
| |
F: |<--------+ Header: 2.04 Changed
| 2.04 | Payload: <new state for the lock>
| |
Figure 20: Resource Request and Response Protected by OSCORE
図20：オスコアによって保護されているリソース要求と応答
Acknowledgments
謝辞
This document is a product of the ACE Working Group of the IETF.
このドキュメントは、IETFのACEワーキンググループの製品です。
Thanks to Eve Maler for her contributions to the use of OAuth 2.0 and Unlicensed Mobile Access (UMA) in IoT scenarios, Robert Taylor for his discussion input, and Mališa Vučinić for his input on the predecessors of this proposal.
Eve Malerは、IoTシナリオでのOAUTH 2.0と免許付きモバイルアクセス（UMA）、ロバートテイラーのディスカッションインプット、およびこの提案の前任者に関する入力についてのMališaVučinićに貢献してくれたことに感謝します。
Thanks to the authors of "[POP-KEY-DIST]OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution" [POP-KEY-DIST], from where parts of the security considerations where copied.
「[Pop-Key-Dist] Oauth 2.0 Proof-of-Possession：承認サーバーへのクライアントキーディストリビューション」[Pop-Key-Dist]の著者に感謝します。
Thanks to Stefanie Gerdes, Olaf Bergmann, and Carsten Bormann for contributing their work on AS discovery from "Delegated CoAP Authentication and Authorization Framework (DCAF)" [DCAF] (see Section 5.1) and the considerations on multiple access tokens.
Stefanie Gerdes、Olaf Bergmann、およびCarsten Bormannに、「委任されたCoap認証と承認フレームワーク（DCAF）」[DCAF]（DCAF]（セクション5.1を参照）と複数のアクセストケンに関する考慮事項からの発見としての研究を貢献してくれたことに感謝します。
Thanks to Jim Schaad and Mike Jones for their comprehensive reviews.
包括的なレビューをしてくれたジム・シャードとマイク・ジョーンズに感謝します。
Thanks to Benjamin Kaduk for his input on various questions related to this work.
この作業に関連するさまざまな質問に関する彼の意見について、ベンジャミン・カドゥクに感謝します。
Thanks to Cigdem Sengul for some very useful review comments.
非常に有用なレビューコメントをしてくれたCigdem Sengulに感謝します。
Thanks to Carsten Bormann for contributing the text for the CoRE Resource Type registry.
Carsten Bormannに、コアリソースタイプレジストリのテキストを提供してくれたことに感謝します。
Thanks to Roman Danyliw for suggesting Appendix E (including its contents).
付録E（その内容を含む）を提案してくれたRoman Danyliwに感謝します。
Ludwig Seitz and Göran Selander worked on this document as part of the CelticPlus project CyberWI, with funding from Vinnova. Ludwig Seitz has also received further funding for this work by Vinnova in the context of the CelticNext project CRITISEC.
Ludwig SeitzとGöranSelanderは、Vinnovaからの資金を提供して、Celticplus Project Cyberwiの一部としてこの文書に取り組みました。Ludwig Seitzは、Celticnext Project Critisecの文脈でVinnovaによるこの作業のためにさらに資金を受け取っています。
Authors' Addresses
著者のアドレス
Ludwig Seitz Combitech Djäknegatan 31 SE-211 35 Malmö Sweden Email: ludwig.seitz@combitech.com
Ludwig Seitz CombitechDjäknegatan31 SE-211 35MalmöSwedenメール：ludwig.seitz@combitech.com
Göran Selander Ericsson SE-164 80 Kista Sweden Email: goran.selander@ericsson.com
GöranSelanderEricssonSE-164 80 Kista Swedenメール：goran.selander@ericsson.com
Erik Wahlstroem Sweden Email: erik@wahlstromstekniska.se
Erik Wahlstroem Swedenメール：erik@wahlstromstekniska.se
Samuel Erdtman Spotify AB Birger Jarlsgatan 61, 4tr SE-113 56 Stockholm Sweden Email: erdtman@spotify.com
Samuel Erdtman Spotify AB Birger Jarlsgatan 61、4TR SE-113 56 Stockholm Swedenメール：erdtman@spotify.com
Hannes Tschofenig Arm Ltd. 6067 Absam Austria Email: Hannes.Tschofenig@arm.com
Hannes Tschofenig Arm Ltd. 6067 Absam Austriaメール：hannes.tschofenig@arm.com