[要約] RFC 9201 は、ACEフレームワークで使用されるOAuth 2.0トークンおよびintrospectionエンドポイントのための新しいパラメータとエンコーディングを定義しています。これらは、PoPキーの表現に使用され、クライアントが使用するPoPキー、認可サーバーが選択したPoPキー、リソースサーバーがクライアントに認証するために使用するPoPキーを示します。
Internet Engineering Task Force (IETF) L. Seitz
Request for Comments: 9201 Combitech
Category: Standards Track August 2022
ISSN: 2070-1721
Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE)
制約された環境の認証と承認のための追加のOAuthパラメーター（ACE）
Abstract
概要
This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client.
この仕様では、制約された環境（ACE）の認証と承認のためのフレームワークで使用された場合、OAUTH 2.0トークンおよび内省エンドポイントの新しいパラメーターとエンコーディングを定義します（ACE）。これらは、クライアントが使用したいと考えているProof-of-Possession（POP）キー、Authorization Serverが選択したPOPキー、およびリソースサーバーがクライアントに認証するために使用するPOPキーを表現するために使用されます。
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/rfc9201.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9201で取得できます。
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. Parameters for the Token Endpoint
3.1. Client-to-AS Request
3.2. AS-to-Client Response
4. Parameters for the Introspection Endpoint
5. Confirmation Method Parameters
6. CBOR Mappings
7. Requirements When Using Asymmetric Keys
8. Security Considerations
9. Privacy Considerations
10. IANA Considerations
10.1. OAuth Parameter Registration
10.2. OAuth Parameters CBOR Mappings Registration
10.3. OAuth Token Introspection Response CBOR Mappings
Registration
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Author's Address
The Authentication and Authorization for Constrained Environments (ACE) specification [RFC9200] requires some new parameters for interactions with the OAuth 2.0 [RFC6749] token and introspection endpoints, as well as some new claims to be used in access tokens. These parameters and claims can also be used in other contexts and have therefore been put into a dedicated document to facilitate their use in a manner independent of [RFC9200].
制約された環境（ACE）仕様[RFC9200]の認証と承認には、OAUTH 2.0 [RFC6749]トークンおよび内省エンドポイントとの相互作用のためのいくつかの新しいパラメーター、およびアクセストケンで使用されるいくつかの新しい主張が必要です。これらのパラメーターとクレームは、他のコンテキストでも使用できるため、[RFC9200]に依存しない方法で使用を促進するために専用のドキュメントに入れられました。
Note that although all examples are shown in Concise Binary Object Representation (CBOR) [RFC8949], JSON [RFC8259] MAY be used as an alternative for HTTP-based communications, as specified in [RFC9200].
すべての例は簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]に示されていますが、[RFC9200]で指定されているように、JSON [RFC8259]はHTTPベースの通信の代替品として使用できることに注意してください。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Readers are assumed to be familiar with the terminology from [RFC9200], especially the terminology for entities in the architecture such as client (C), resource server (RS), and authorization server (AS).
読者は、[RFC9200]の用語、特にクライアント（C）、リソースサーバー（RS）、認証サーバー（AS）などのアーキテクチャのエンティティの用語の用語に精通していると想定されています。
Terminology from [RFC8152] is used in the examples, especially COSE_Key, which is defined in Section 7 of [RFC8152].
[RFC8152]の用語は、例、特に[RFC8152]のセクション7で定義されているCOSE_KEYの例で使用されています。
Note that the term "endpoint" is used here following its OAuth 2.0 [RFC6749] definition, which is to denote resources such as token and introspection at the AS and authz-info at the RS. The Constrained Application Protocol (CoAP) [RFC7252] definition, which is "[a]n entity participating in the CoAP protocol", is not used in this specification.
「エンドポイント」という用語は、OAUTH 2.0 [RFC6749]定義に従ってここで使用されていることに注意してください。これは、ASでのトークンや内省などのリソースとRSのAuthz-INFOを示すことに注意してください。制約されたアプリケーションプロトコル（COAP）[RFC7252]定義は、「[A] nエンティティがCOAPプロトコルに参加している」というものであり、この仕様では使用されていません。
This section defines additional parameters for the interactions with the token endpoint in the ACE framework [RFC9200].
このセクションでは、ACEフレームワーク[RFC9200]のトークンエンドポイントとの相互作用の追加パラメーターを定義します。
This section defines the req_cnf parameter allowing clients to request a specific PoP key in an access token from a token endpoint in the ACE framework [RFC9200]:
このセクションでは、REQ_CNFパラメーターを定義して、クライアントがACEフレームワークのトークンエンドポイントからアクセストークンの特定のPOPキーを要求できる[RFC9200]：
req_cnf OPTIONAL. This field contains information about the key the client would like to bind to the access token for proof of possession. It is RECOMMENDED that an AS rejects a request containing a symmetric key value in the req_cnf field (kty=Symmetric), since the AS is expected to be able to generate better symmetric keys than a constrained client. (Note: this does not apply to key identifiers referencing a symmetric key.) The AS MUST verify that the client really is in possession of the corresponding key. Profiles of [RFC9200] using this specification MUST define the PoP method used by the AS if they allow clients to use this request parameter. Values of this parameter follow the syntax and semantics of the cnf claim either from Section 3.1 of [RFC8747] for CBOR-based interactions or from Section 3.1 of [RFC7800] for JSON-based interactions.
req_cnfオプション。このフィールドには、クライアントが所有証明のためにアクセストークンにバインドしたいキーに関する情報が含まれています。ASは、REQ_CNFフィールド（kty = symmetric）に対称キー値を含むリクエストを拒否することをお勧めします。（注：これは、対称キーを参照するキー識別子には適用されません。）ASは、クライアントが実際に対応するキーを所有していることを確認する必要があります。[RFC9200]のプロファイルこの仕様を使用すると、クライアントがこのリクエストパラメーターを使用できるように使用するPOPメソッドを定義する必要があります。このパラメーターの値は、CBORベースの相互作用の[RFC8747]のセクション3.1から、またはJSONベースの相互作用の[RFC7800]のセクション3.1からCNFクレームの構文とセマンティクスに従います。
Figure 1 shows a request for an access token using the req_cnf parameter to request a specific public key as a PoP key. The content is displayed in CBOR diagnostic notation with line breaks for better readability.
図1は、REQ_CNFパラメーターを使用したアクセストークンのリクエストを示しており、特定の公開キーをポップキーとして要求します。コンテンツは、読みやすくするためにラインブレークでCBOR診断表記で表示されます。
Header: POST (Code=0.02)
Uri-Host: "as.example.com"
Uri-Path: "token"
Content-Format: application/ace+cbor
Payload:
{
/ req_cnf / 4 : {
/ COSE_Key / 1 : {
/ kty / 1 : 2 /EC2/,
/ kid / 2 : h'11',
/ crv / -1 : 1 /P-256/,
/ x / -2 : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24
4DC189F745228255A219A86D6A09EFF',
/ y / -3 : h'20138BF82DC1B6D562BE0FA54AB7804A3
A64B6D72CCFED6B6FB6ED28BBFC117E'
}
}
}
Figure 1: Example Request for an Access Token Bound to an Asymmetric Key
図1：非対称キーにバインドされたアクセストークンの例の例
This section defines the following additional parameters for an AS response to a request to the token endpoint:
このセクションでは、トークンエンドポイントへのリクエストに対するAS AS応答の次の追加パラメーターを定義します。
cnf REQUIRED if the token type is "pop" and a symmetric key is used. MAY be present for asymmetric PoP keys. This field contains the PoP key that the AS selected for the token. Values of this parameter follow the syntax and semantics of the cnf claim either from Section 3.1 of [RFC8747] for CBOR-based interactions or from Section 3.1 of [RFC7800] for JSON-based interactions. See Section 5 for additional discussion of the usage of this parameter.
トークンタイプが「ポップ」であり、対称キーが使用されている場合は、CNFが必要です。非対称ポップキーには存在する場合があります。このフィールドには、トークン用に選択されたポップキーが含まれています。このパラメーターの値は、CBORベースの相互作用の[RFC8747]のセクション3.1から、またはJSONベースの相互作用の[RFC7800]のセクション3.1からCNFクレームの構文とセマンティクスに従います。このパラメーターの使用に関する追加の議論については、セクション5を参照してください。
rs_cnf OPTIONAL if the token type is "pop" and asymmetric keys are used. MUST NOT be present otherwise. This field contains information about the public key used by the RS to authenticate. If this parameter is absent, either the RS does not use a public key or the AS knows that the RS can authenticate itself to the client without additional information. Values of this parameter follow the syntax and semantics of the cnf claim either from Section 3.1 of [RFC8747] for CBOR-based interactions or from Section 3.1 of [RFC7800] for JSON-based interactions. See Section 5 for additional discussion of the usage of this parameter.
RS_CNFオプショントークンタイプが「ポップ」で、非対称キーが使用されている場合。そうでなければ存在してはいけません。このフィールドには、RSが認証するために使用する公開キーに関する情報が含まれています。このパラメーターが存在しない場合、RSは公開キーを使用しないか、RSが追加情報なしでクライアントに認証できることを知っています。このパラメーターの値は、CBORベースの相互作用の[RFC8747]のセクション3.1から、またはJSONベースの相互作用の[RFC7800]のセクション3.1からCNFクレームの構文とセマンティクスに従います。このパラメーターの使用に関する追加の議論については、セクション5を参照してください。
Figure 2 shows an AS response containing a token and a cnf parameter with a symmetric PoP key.
図2は、トークンを含むAS応答と対称POPキーを備えたCNFパラメーターを示しています。
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
/ access_token / 1 : h'4A5015DF686428/...
(remainder of CWT omitted for brevity;
CWT contains COSE_Key in the "cnf" claim)/',
/ cnf / 8 : {
/ COSE_Key / 1 : {
/ kty / 1 : 4 / Symmetric /,
/ kid / 2 : h'DFD1AA97',
/ k / -1 : h'849B5786457C1491BE3A76DCEA6C427108'
}
}
}
Figure 2: Example AS Response with an Access Token Bound to a Symmetric Key
図2：対称キーにバインドされたアクセストークンを使用した応答としての例
Figure 3 shows an AS response containing a token bound to a previously requested asymmetric PoP key (not shown) and an rs_cnf parameter containing the public key of the RS.
図3は、以前に要求された非対称POPキー（図示せず）に結合したトークンを含むAS応答と、RSの公開キーを含むRS_CNFパラメーターを示しています。
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
/ access_token / 1 : h'D08343A1010AA1054D2A45DF6FBC5A5A/...
(remainder of CWT omitted for brevity)/',
/ rs_cnf / 41 : {
/ COSE_Key / 1 : {
/ kty / 1 : 2 /EC2/,
/ kid / 2 : h'12',
/ crv / -1 : 1 /P-256/,
/ x / -2 : h'BCEE7EAAC162F91E6F330F5771211E220
B8B546C96589B0AC4AD0FD24C77E1F1',
/ y / -3 : h'C647B38C55EFBBC4E62E651720F002D5D
75B2E0C02CD1326E662BCA222B90416'
}
}
}
Figure 3: Example AS Response Including the RS's Public Key
図3：RSの公開キーを含む応答としての例
This section defines the use of CBOR instead of JSON for the cnf introspection response parameter specified in Section 9.4 of [RFC8705].
このセクションでは、[RFC8705]のセクション9.4で指定されたCNF内省応答パラメーターに対するJSONの代わりにCBORの使用を定義します。
If CBOR is used instead of JSON in an interaction with the introspection endpoint, the AS MUST use the parameter mapping specified in Table 1 and the value must follow the syntax of cnf claim values from Section 3.1 of [RFC8747].
内省エンドポイントとの相互作用でJSONの代わりにCBORを使用する場合、ASは表1で指定されたパラメーターマッピングを使用する必要があり、値は[RFC8747]のセクション3.1のCNFクレーム値の構文に従う必要があります。
Figure 4 shows an AS response to an introspection request including the cnf parameter to indicate the PoP key bound to the token.
図4は、トークンに結合したPOPキーを示すCNFパラメーターを含む内省要求に対するAS応答を示しています。
Header: Created (Code=2.01)
Content-Format: application/ace+cbor
Payload:
{
/ active / 10 : true,
/ scope / 9 : "read",
/ aud / 3 : "tempSensor4711",
/ cnf / 8 : {
/ COSE_Key / 1 : {
/ kty / 1 : 2 /EC2/,
/ kid / 2 : h'11',
/ crv / -1 : 1 /P-256/,
/ x / -2 : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24
4DC189F745228255A219A86D6A09EFF',
/ y / -3 : h'20138BF82DC1B6D562BE0FA54AB7804A3
A64B6D72CCFED6B6FB6ED28BBFC117E'
}
}
}
Figure 4: Example Introspection Response
図4：イントロスペクティション応答の例
The confirmation method parameters are used in [RFC9200] as follows:
確認方法パラメーターは、[RFC9200]で次のように使用されます。
* req_cnf in the access token request C -> AS, OPTIONAL to indicate the client's raw public key or the key identifier of a previously established key between the C and RS that the client wishes to use for proof of possession of the access token.
* アクセストークンのreq_cnf要求c - > asは、クライアントの生の公開キーまたはクライアントがアクセストークンの所有証明のために使用したいCとrsの間に以前に確立されたキーのキー識別子を示すためにオプションです。
* cnf in the token response AS -> C, OPTIONAL if using an asymmetric key or a key that the client requested via a key identifier in the request. REQUIRED if the client didn't specify a req_cnf and symmetric keys are used. Used to indicate the symmetric key generated by the AS for proof of possession of the access token.
* トークン応答のCNF - > c、非対称キーまたはクライアントがリクエストのキー識別子を介して要求したキーを使用する場合はオプション。クライアントがREQ_CNFを指定しなかった場合に必要です。対称キーが使用されます。アクセストークンの所持の証明のために生成される対称キーを示すために使用されます。
* cnf in the introspection response AS -> RS, REQUIRED if the access token that was subject to introspection is a PoP token, absent otherwise. Indicates the PoP key bound to the access token.
* 内省応答のCNF - > rs、内省の対象となったアクセストークンがポップトークンである場合、そうでない場合はポップトークンである場合。アクセストークンにバインドされたポップキーを示します。
* rs_cnf in the token response AS -> C, OPTIONAL to indicate the public key of the RS if it uses one to authenticate itself to the client and the binding between the key and RS identity is not established through other means.
* トークン応答のrs_cnfは - > cとして、rsの公開鍵を使用してクライアントに認証する場合、rsの公開鍵を示すためにオプションであり、キーとRSのアイデンティティの間のバインディングは他の手段を通じて確立されません。
Note that the COSE_Key structure in a confirmation claim or parameter may contain an alg or key_ops parameter. If such parameters are present, a client MUST NOT use a key that is incompatible with the profile or PoP algorithm according to those parameters. An RS MUST reject a proof of possession using such a key with a response code equivalent to the CoAP code 4.00 (Bad Request).
確認請求またはパラメーターのCOSE_KEY構造には、ALGまたはKEY_OPSパラメーターが含まれている場合があることに注意してください。そのようなパラメーターが存在する場合、クライアントは、それらのパラメーターに従ってプロファイルまたはポップアルゴリズムと互換性のないキーを使用してはなりません。RSは、COAPコード4.00（悪い要求）に相当する応答コードを使用して、そのようなキーを使用して所有証明を拒否する必要があります。
If an access token is issued for an audience that includes several RSs, the rs_cnf parameter MUST NOT be used, since the client cannot determine for which RS the key applies. This document recommends to specify a different endpoint that the client can use to acquire RS authentication keys in such cases. The specification of such an endpoint is out of scope for this document.
複数のRSSを含むオーディエンスに対してアクセストークンが発行される場合、クライアントがどのRSが適用されるかをクライアントが決定できないため、RS_CNFパラメーターを使用してはなりません。このドキュメントでは、クライアントがそのような場合にRS認証キーを取得するために使用できる別のエンドポイントを指定することを推奨しています。このようなエンドポイントの仕様は、このドキュメントの範囲外です。
If CBOR is used, the new parameters and claims defined in this document MUST be mapped to CBOR types, as specified in Table 1, using the given integer abbreviation for the map key.
CBORを使用する場合、このドキュメントで定義されている新しいパラメーターとクレームは、MAPキーの指定された整数の略語を使用して、表1で指定されているようにCBORタイプにマッピングする必要があります。
+=========+==========+============+========================+
| Name | CBOR Key | Value Type | Usage |
+=========+==========+============+========================+
| req_cnf | 4 | map | token request |
+---------+----------+------------+------------------------+
| cnf | 8 | map | token response |
+---------+----------+------------+------------------------+
| cnf | 8 | map | introspection response |
+---------+----------+------------+------------------------+
| rs_cnf | 41 | map | token response |
+---------+----------+------------+------------------------+
Table 1: CBOR Mappings for New Parameters and Claims
表1：新しいパラメーターとクレーム用のCBORマッピング
An RS using asymmetric keys to authenticate to the client MUST NOT hold several different asymmetric key pairs applicable to the same authentication algorithm. For example, when using DTLS, the RS MUST NOT hold several asymmetric key pairs applicable to the same cipher suite. The reason for this restriction is that the RS has no way of determining which key to use before the client's identity is established. Therefore, authentication attempts by the RS could randomly fail based on which key the RS selects, unless the algorithm negotiation produces a unique choice of key pair for the RS.
非対称キーを使用してクライアントに認証するRSは、同じ認証アルゴリズムに適用されるいくつかの異なる非対称キーペアを保持してはなりません。たとえば、DTLを使用する場合、RSは同じ暗号スイートに適用されるいくつかの非対称キーペアを保持してはなりません。この制限の理由は、RSがクライアントのIDが確立される前に使用する鍵を決定する方法がないためです。したがって、アルゴリズムのネゴシエーションがRSのキーペアのユニークな選択を生成しない限り、RSによる認証試行は、RSが選択するキーに基づいてランダムに失敗する可能性があります。
This document is an extension to [RFC9200]. All security considerations from that document apply here as well.
このドキュメントは[RFC9200]の拡張機能です。このドキュメントからのすべてのセキュリティ上の考慮事項もここにも適用されます。
This document is an extension to [RFC9200]. All privacy considerations from that document apply here as well.
このドキュメントは[RFC9200]の拡張機能です。このドキュメントからのすべてのプライバシーに関する考慮事項もここにも適用されます。
This section registers the following parameters in the "OAuth Parameters" registry [IANA.OAuthParameters]:
このセクションでは、「OAuthパラメーター」レジストリ[iana.oauthparameters]の次のパラメーターを登録します。
Name: req_cnf Parameter Usage Location: token request Change Controller: IETF Reference: Section 5 of RFC 9201
名前：REQ_CNFパラメーターの使用場所
Name: rs_cnf Parameter Usage Location: token response Change Controller: IETF Reference: Section 5 of RFC 9201
名前：RS_CNFパラメーターの使用場所
Name: cnf Parameter Usage Location: token response Change Controller: IETF Reference: Section 5 of RFC 9201
名前：CNFパラメーターの使用場所：トークン応答変更コントローラー：IETFリファレンス：RFC 9201のセクション5
This section registers the following parameter mappings in the "OAuth Parameters CBOR Mappings" registry established in Section 8.10 of [RFC9200].
このセクションでは、[RFC9200]のセクション8.10で確立された「OAuthパラメーターCBORマッピング」レジストリの次のパラメーターマッピングを登録します。
Name: req_cnf CBOR Key: 4 Value Type: map Reference: Section 3.1 of RFC 9201 Original Specification: RFC 9201
名前：REQ_CNF CBORキー：4値タイプ：マップリファレンス：RFC 9201のセクション3.1オリジナル仕様：RFC 9201
Name: cnf CBOR Key: 8 Value Type: map Reference: Section 3.2 of RFC 9201 Original Specification: RFC 9201
名前：CNF CBORキー：8値タイプ：マップリファレンス：RFC 9201のセクション3.2オリジナル仕様：RFC 9201
Name: rs_cnf CBOR Key: 41 Value Type: map Reference: Section 3.2 of RFC 9201 Original Specification: RFC 9201
名前：RS_CNF CBORキー：41値タイプ：マップリファレンス：RFC 9201のセクション3.2オリジナル仕様：RFC 9201
This section registers the following parameter mapping in the "OAuth Token Introspection Response CBOR Mappings" registry established in Section 8.12 of [RFC9200].
このセクションでは、[RFC9200]のセクション8.12で確立された「OAuthトークン内注文応答CBORマッピング」レジストリで次のパラメーターマッピングを登録します。
Name: cnf CBOR Key: 8 Value Type: map Reference: Section 4 of RFC 9201 Original Specification: [RFC8705]
名前：CNF CBORキー：8値タイプ：マップリファレンス：RFC 9201のセクション4オリジナル仕様：[RFC8705]
[IANA.OAuthParameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[iana.oauthparameters] iana、 "oauth parameters"、<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>。
[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>
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/info/rfc7800>.
[RFC7800] Jones、M.、Bradley、J。、およびH. Tschofenig、「JSON Web Tokens（JWTS）のプルーフポッセッションキーセマンティクス」、RFC 7800、DOI 10.17487/RFC7800、2016年4月、<https：/<https：//www.rfc-editor.org/info/rfc7800>。
[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>。
[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>。
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/info/rfc8705>.
[RFC8705] Campbell、B.、Bradley、J.、Sakimura、N.、およびT. Lodderstedt、「OAUTH 2.0 Mutual-TLSクライアント認証と証明書バウンドアクセストークン」、RFC 8705、DOI 10.17487/RFC8705、February 2020、<https://www.rfc-editor.org/info/rfc8705>。
[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>。
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/info/rfc9200>.
[RFC9200] Seitz、L.、Selander、G.、Wahlstroem、E.、Erdtman、S.、およびH. Tschofenig、「OAUTH 2.0フレームワーク（ACE-OAuth）を使用した制約環境（ACE）の認証と認証（ACE-OAuth）」RFC 9200、DOI 10.17487/RFC9200、2022年8月、<https://www.rfc-editor.org/info/rfc9200>。
[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>。
Acknowledgments
謝辞
This document is a product of the ACE Working Group of the IETF. Special thanks to Brian Campbell for his thorough review of this document.
このドキュメントは、IETFのACEワーキンググループの製品です。この文書を徹底的にレビューしてくれたブライアンキャンベルに感謝します。
Ludwig Seitz worked on this document as part of the CelticNext projects CyberWI and CRITISEC with funding from Vinnova.
Ludwig Seitzは、CelticNext Projectの一部として、CyberwiとCritisecのヴィノバからの資金提供でこの文書に取り組みました。
Author's Address
著者の連絡先
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