Internet Engineering Task Force (IETF) M. Tiloca
Request for Comments: 9770 RISE AB
Category: Standards Track F. Palombini
ISSN: 2070-1721 Ericsson AB
S. Echeverria
G. Lewis
CMU SEI
June 2025
This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an authorization server to notify clients and resource servers (i.e., registered devices) about revoked access tokens. As specified in this document, the method allows clients and resource servers (RSs) to access a Token Revocation List (TRL) on the authorization server by using the Constrained Application Protocol (CoAP), with the possible additional use of resource observation. Resulting (unsolicited) notifications of revoked access tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on clients and RSs.
このドキュメントは、制約された環境（ACE）フレームワークの認証と承認の方法を指定します。これにより、承認サーバーは、取り消されたアクセストークンに関するクライアントとリソースサーバー（つまり、登録されたデバイス）に通知できます。このドキュメントで指定されているように、この方法により、クライアントとリソースサーバー（RSS）は、制約されたアプリケーションプロトコル（COAP）を使用して、認証サーバーのトークン取り消しリスト（TRL）にアクセスでき、リソース観測の追加の使用が可能になります。結果として、取り消されたアクセストークンの結果の（未承諾）通知は、クライアントやRSSに追加のエンドポイントを必要としませんが、トークン内省などの代替アプローチを補完します。
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/rfc9770.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9770で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. Protocol Overview
3. Issuing of Access Tokens at the AS
4. Token Hash
4.1. Motivation for the Used Construction
4.1.1. Issuing of the Access Token to the Client
4.1.2. Provisioning of Access Tokens to the RS
4.1.3. Design Rationale
4.2. Hash Input on the Client and the AS
4.2.1. AS-to-Client Response Encoded in CBOR
4.2.2. AS-to-Client Response Encoded in JSON
4.3. HASH_INPUT on the RS
4.3.1. Access Tokens as CWTs
4.3.2. Access Tokens as JWTs
4.4. Computing the Token Hash
5. Token Revocation List (TRL)
5.1. Update of the TRL
6. The TRL Endpoint
6.1. Error Responses with Problem Details
6.2. Supporting Diff Queries
6.2.1. Supporting the "Cursor" Extension
6.3. Query Parameters
7. Full Query of the TRL
8. Diff Query of the TRL
9. Response Messages when Using the "Cursor" Extension
9.1. Response to Full Query
9.2. Response to Diff Query
9.2.1. Empty Update Collection
9.2.2. Cursor Not Included in the Diff Query Request
9.2.3. Cursor Included in the Diff Query Request
10. Registration at the Authorization Server
11. Notification of Revoked Access Tokens
11.1. Handling of Revoked Access Tokens and Token Hashes
12. ACE Token Revocation List Parameters
13. ACE Token Revocation List Error Identifiers
14. Security Considerations
14.1. Content Retrieval from the TRL
14.2. Size of the TRL
14.3. Communication Patterns
14.4. Request of New Access Tokens
14.5. Vulnerable Time Window at the RS
14.6. Preventing Unnoticed Manipulation of Access Tokens
14.7. Two Token Hashes at the RS Using JWTs
14.8. Additional Security Measures
15. IANA Considerations
15.1. Media Type Registrations
15.2. CoAP Content-Formats Registry
15.3. Custom Problem Detail Keys Registry
15.4. ACE Token Revocation List Parameters Registry
15.5. ACE Token Revocation List Errors
15.6. Expert Review Instructions
16. References
16.1. Normative References
16.2. Informative References
Appendix A. On Using the Series Transfer Pattern
Appendix B. Local Supportive Parameters of the TRL Endpoint
Appendix C. Interaction Examples
C.1. Full Query with Observe
C.2. Diff Query with Observe
C.3. Full Query with Observe and Diff Query
C.4. Diff Query with Observe and "Cursor" Extension
C.5. Full Query with Observe and Diff Query with "Cursor"
Extension
Acknowledgments
Authors' Addresses
Authentication and Authorization for Constrained Environments (ACE) [RFC9200] is a framework that enforces access control on Internet of Things (IoT) devices acting as resource servers (RSs). In order to use ACE, both clients and RSs have to register with an authorization server (AS) and become registered devices. Once registered, a client can send a request to the AS to obtain an access token for an RS. For a client to access the RS, the client must present the issued access token at the RS, which then validates it before storing it (see Section 5.10.1.1 of [RFC9200]).
制約付き環境の認証と承認（ACE）[RFC9200]は、リソースサーバー（RSS）として機能するモノのインターネット（IoT）デバイスのアクセス制御を強制するフレームワークです。ACEを使用するには、クライアントとRSSの両方が認証サーバーに登録し（AS）、登録デバイスになる必要があります。登録されると、クライアントはRsのアクセストークンを取得するためにリクエストを送信できます。クライアントがRSにアクセスするには、クライアントがRSで発行されたアクセストークンを提示する必要があります。これは、保存する前に検証する必要があります（[RFC9200]のセクション5.10.1.1を参照）。
Even though access tokens have expiration times, there are circumstances by which an access token may need to be revoked before its expiration time, such as when:
アクセストークンには有効期限がありますが、次の場合など、アクセストークンを有効期限の前に取り消す必要がある状況があります。
1. a registered device has been compromised or is suspected of being compromised;
1. 登録されたデバイスは侵害されているか、侵害されていると疑われています。
2. a registered device is decommissioned;
2. 登録されたデバイスが廃止されます。
3. there has been a change in the ACE profile for a registered device;
3. 登録されたデバイスのACEプロファイルに変更がありました。
4. there has been a change in access policies for a registered device; or
4. 登録されたデバイスのアクセスポリシーが変更されました。または
5. there has been a change in the outcome of policy evaluation for a registered device (e.g., if policy assessment depends on dynamic conditions in the execution environment, the user context, or the resource utilization).
5. 登録されたデバイスのポリシー評価の結果に変化がありました（たとえば、ポリシー評価が実行環境、ユーザーコンテキスト、またはリソース利用の動的条件に依存する場合）。
As discussed in Section 6.1 of [RFC9200], only client-initiated revocation is currently specified [RFC7009] for OAuth 2.0 [RFC6749], based on the assumption that access tokens in OAuth are issued with a relatively short lifetime. However, this is not expected to be the case for constrained, intermittently connected devices that need access tokens with relatively long lifetimes.
[RFC9200]のセクション6.1で説明したように、OAUTHのアクセストークンが比較的短い寿命で発行されるという仮定に基づいて、OAUTH 2.0 [RFC6749]のクライアントが開始する取り消しのみが現在指定されています[RFC7009]。ただし、これは、比較的長い寿命のあるアクセストークンを必要とする制約された断続的に接続されたデバイスの場合には当てはまりません。
This document specifies a method for allowing registered devices to access and possibly subscribe to a Token Revocation List (TRL) on the AS in order to obtain updated information about pertaining access tokens that were revoked prior to their expiration. As specified in this document, the registered devices use the Constrained Application Protocol (CoAP) [RFC7252] to communicate with the AS and with one another and can subscribe to the TRL on the AS by using resource observation for CoAP [RFC7641]. Underlying protocols other than CoAP are not prohibited from being supported in the future, if they are defined to be used in the ACE framework.
このドキュメントは、登録されたデバイスがアクセスできるようにし、可能性のあるASのトークン取り消しリスト（TRL）にサブスクライブする方法を指定して、有効期限の前に取り消されたアクセストークンに関する更新された情報を取得します。このドキュメントで指定されているように、登録されたデバイスは制約付きアプリケーションプロトコル（COAP）[RFC7252]を使用してASと互いに通信し、COAP [RFC7641]のリソース観測を使用してASのTRLを購読できます。COAP以外の基礎となるプロトコルは、ACEフレームワークで使用されると定義されている場合、将来サポートされることを禁止されていません。
Unlike in the case of token introspection (see Section 5.9 of [RFC9200]), a registered device does not provide an owned access token to the AS for inquiring about its current state. Instead, registered devices simply obtain updated information about pertaining access tokens that were revoked prior to their expiration as efficiently identified by corresponding hash values.
トークン内省の場合（[RFC9200]のセクション5.9を参照）の場合とは異なり、登録されたデバイスは、現在の状態について問い合わせるASへの所有アクセストークンを提供しません。代わりに、登録されたデバイスは、対応するハッシュ値によって効率的に識別されるように、有効期限の前に取り消されたアクセストークンの関係に関する更新された情報を取得するだけです。
The benefits of this method are that it complements token introspection and does not require the registered devices to support any additional endpoints (see Section 1.1). The only additional requirements for registered devices are a request/response interaction with the AS to access and possibly subscribe to the TRL (see Section 2) and the lightweight computation of hash values to use as access token identifiers (see Section 4).
この方法の利点は、トークンの内省を補完し、登録されたデバイスが追加のエンドポイントをサポートする必要がないことです（セクション1.1を参照）。登録されたデバイスの追加要件は、TRL（セクション2を参照）にアクセスし、場合によってはサブスクライブ（セクション2を参照）と、アクセストークン識別子として使用するハッシュ値の軽量計算（セクション4を参照）との要求/応答の相互作用です。
The process by which access tokens are declared revoked is out of the scope of this document. The method by which the AS determines or is notified of revoked access tokens, according to which the AS consequently updates the TRL as specified in this document, is also out of scope.
アクセストークンが取り消されたと宣言されるプロセスは、このドキュメントの範囲外です。ASが取り消されたアクセストークンを決定または通知する方法は、このドキュメントで指定されたTRLを結果として更新すると、範囲外です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Readers are expected to be familiar with the terms and concepts described in the ACE framework [RFC9200], as well as with terms and concepts related to CBOR Web Tokens (CWTs) [RFC8392] and JSON Web Tokens (JWTs) [RFC7519].
読者は、ACEフレームワーク[RFC9200]に記載されている用語と概念、およびCBOR Webトークン（CWTS）[RFC8392]およびJSON Webトークン（JWTS）[RFC7519]に関連する用語と概念に精通していることが期待されています。
The terminology for entities in the considered architecture is defined in OAuth 2.0 [RFC6749]. In particular, this includes client, RS, and authorization server (AS).
考慮されたアーキテクチャのエンティティの用語は、OAUTH 2.0 [RFC6749]で定義されています。特に、これにはクライアント、RS、および承認サーバー（AS）が含まれます。
Readers are also expected to be familiar with the terms and concepts related to the Concise Data Definition Language (CDDL) [RFC8610], Concise Binary Object Representation (CBOR) [RFC8949], JSON [RFC8259], CBOR Object Signing and Encryption (COSE) [RFC9052], CoAP [RFC7252], CoAP Observe [RFC7641], and the use of hash functions to name objects as defined in [RFC6920].
読者は、簡潔なデータ定義言語（CDDL）[RFC8610]、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]、JSON [RFC8259]、CBORオブジェクトの署名と暗号化（COSE）[RFC9052]、COAP [RFC7252]、COAP [RFC7252]、COBRのオブジェクトの署名と暗号化に関連する用語と概念に精通していることも期待されています。[RFC6920]で定義されているようにオブジェクトを名前を付けるためのハッシュ関数の使用。
Note that the term "endpoint" is used here following its OAuth definition [RFC6749], aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" [RFC7252], is not used in this document.
「エンドポイント」という用語は、ASなどの /トークンなどのリソースを示すことを目的としたOAUTH定義[RFC6749]に従って、ここで使用されていることに注意してください。「COAPプロトコルに参加している[a] nエンティティ」[RFC7252]であるCOAP定義は、このドキュメントでは使用されていません。
This specification also uses the following terminology:
この仕様では、次の用語も使用します。
Token hash:
トークンハッシュ：
identifier of an access token, in binary format encoding. The token hash has no relation to other access token identifiers possibly used, such as the 'cti' (CWT ID) claim of CBOR Web Tokens (CWTs) [RFC8392].
アクセストークンの識別子、バイナリ形式のエンコード。トークンハッシュは、CBOR Webトークン（CWTS）の「CTI」（CWT ID）クレームなど、使用される可能性のある他のアクセストークン識別子とは関係ありません[RFC8392]。
Token Revocation List (TRL):
トークンの取り消しリスト（TRL）：
a collection of token hashes such that the corresponding access tokens have been revoked but are not expired yet.
対応するアクセストークンが取り消されているが、まだ期限切れになっていないトークンハッシュのコレクション。
TRL endpoint:
TRLエンドポイント：
an endpoint at the AS with a TRL as its representation. The default name of the TRL endpoint in a url-path is '/revoke/trl'. Implementations are not required to use this name and can define their own instead.
表現としてTRLを使用したASのエンドポイント。URLパスのTRLエンドポイントのデフォルト名は「/revoke/TRL」です。実装はこの名前を使用する必要はなく、代わりに独自の名前を定義できます。
Registered device:
登録デバイス：
a device registered at the AS, i.e., as a client, an RS, or both. A registered device acts as a requester towards the TRL endpoint.
AS、つまりクライアント、RS、またはその両方で登録されているデバイス。登録されたデバイスは、TRLエンドポイントに向けて要求者として機能します。
Administrator:
管理者：
an entity that is authorized to get full access to the TRL at the AS and that acts as a requester towards the TRL endpoint. An administrator is not necessarily a registered device as defined above, i.e., a client requesting access tokens or an RS consuming access tokens.
ASでTRLへの完全なアクセスを取得することが許可されているエンティティ、およびTRLエンドポイントに向けて要求者として機能します。管理者は、必ずしも上記のように登録されたデバイスではありません。つまり、アクセストークンまたはRS消費アクセストークンを要求するクライアントです。
An administrator might also be authorized to perform further administrative operations at the AS, e.g., through a dedicated admin interface that is out of the scope of this document. By considering the token hashes retrieved from the TRL together with other information obtained from the AS, the administrator becomes able to derive additional information, e.g., the fact that accesses have been revoked for specific registered devices.
また、管理者は、このドキュメントの範囲外である専用の管理インターフェイスなど、ASでさらに管理操作を実行することを許可される場合があります。TRLから取得されたトークンハッシュをASから取得した他の情報とともに検討することにより、管理者は追加情報を導き出すことができるようになります。たとえば、特定の登録デバイスのアクセスが取り消されたという事実。
Pertaining access token:
アクセストークンの関係：
* With reference to an administrator, an access token issued by the AS.
* 管理者を参照して、ASによって発行されたアクセストークン。
* With reference to a registered device, an access token intended to be owned by that device. An access token pertains to a client if the AS has issued the access token for that client following its request. An access token pertains to an RS if the AS has issued the access token to be consumed by that RS.
* 登録されたデバイスを参照して、そのデバイスが所有することを目的としたアクセストークン。ASがその要求に従ってそのクライアントのアクセストークンを発行した場合、アクセストークンはクライアントに関係します。ASがそのRsによって消費されるようにASが発行された場合、アクセストークンがRSに関係します。
Token hash pertaining to a requester:
リクエスターに関連するトークンハッシュ：
a token hash corresponding to an access token pertaining to that requester, i.e., an administrator or a registered device.
その要求者に関連するアクセストークン、つまり管理者または登録デバイスに対応するトークンハッシュ。
TRL update pertaining to a requester:
リクエスターに関連するTRLアップデート：
an update to the TRL through which token hashes pertaining to that requester have been added to or removed from the TRL.
TRLの更新では、その要求者に関連するトークンハッシュがTRLに追加または削除されました。
Full query:
フルクエリ：
a type of query to the TRL where the AS returns the token hashes of the revoked access tokens currently in the TRL and pertaining to the requester. Further details are specified in Sections 6 and 7.
TRLへのクエリの種類。詳細については、セクション6および7に指定されています。
Diff query:
diff query：
a type of query to the TRL where the AS returns a list of diff entries, each related to one update that occurred to the TRL and containing a set of token hashes pertaining to the requester. Further details are specified in Sections 6 and 8.
TRLへのクエリの種類。ASがDiffエントリのリストを返します。それぞれがTRLに発生し、リクエスターに関連するトークンハッシュのセットを含む1つの更新に関連しています。詳細については、セクション6および8に指定されています。
See Section 4 for further terminology used throughout that section.
そのセクション全体で使用されるさらなる用語については、セクション4を参照してください。
Examples throughout this document are expressed in CBOR diagnostic notation as defined in Section 8 of [RFC8949] and Appendix G of [RFC8610]. Diagnostic notation comments are often used to provide a textual representation of the numeric parameter names and values.
このドキュメント全体の例は、[RFC8949]のセクション8および[RFC8610]の付録Gで定義されているように、CBOR診断表記で表現されています。診断表記コメントは、多くの場合、数値パラメーター名と値のテキスト表現を提供するために使用されます。
This protocol defines how a CoAP-based AS informs clients and RSs, i.e., registered devices, about pertaining revoked access tokens. How the relationship between a registered device and the AS is established is out of the scope of this specification.
このプロトコルは、COAPベースがクライアントとRSS、つまり登録されたデバイスを、取り消されたアクセストークンの関係についてどのように通知するかを定義します。登録されたデバイスと確立されているASとの関係が、この仕様の範囲外である方法。
At a high level, the steps of this protocol are as follows:
高いレベルでは、このプロトコルのステップは次のとおりです。
1. Upon startup, the AS creates a single TRL accessible through the TRL endpoint. At any point in time, the TRL represents the list of all revoked access tokens issued by the AS that are not expired yet.
1. 起動時に、ASはTRLエンドポイントを介してアクセス可能な単一のTRLを作成します。いつでも、TRLは、ASによって発行されたすべての取り消されたアクセストークンのリストを、まだ期限切れにしていないことを表します。
2. When a device registers at the AS, it also receives the url-path to the TRL endpoint.
2. デバイスがASで登録すると、TRLエンドポイントへのURLパスも受信します。
At any time after the registration procedure is finished, the registered device can send a GET request to the TRL endpoint at the AS. When doing so, it can request the following: the current list of pertaining revoked access tokens (see Section 7) or the most recent updates that occurred over the list of pertaining revoked access tokens (see Section 8).
登録手順が終了した後でも、登録されたデバイスはASのTRLエンドポイントにGETリクエストを送信できます。その場合、次のことを要求できます。取り消されたアクセストークン（セクション7を参照）の現在のリストまたは、取り消されたアクセストークン（セクション8を参照）のリストで発生した最新の更新。
In particular, the registered device can rely on Observation for CoAP [RFC7641]. In such a case, the GET request sent to the TRL endpoint includes the CoAP Observe Option set to 0 (register), i.e., it is an Observation Request. By doing so, the registered device effectively subscribes to the TRL, as the device is interested in receiving notifications about the TRL's update. Upon receiving the Observation Request, the AS adds the registered device to the list of observers of the TRL endpoint.
特に、登録されたデバイスは、COAP [RFC7641]の観察に依存することができます。そのような場合、TRLエンドポイントに送信されたGETリクエストには、0（レジスタ）に設定されたCOAP Observeオプションが含まれます。つまり、これは観測リクエストです。そうすることで、登録されたデバイスは、TRLの更新に関する通知の受信に関心があるため、TRLを効果的にサブスクライブします。観察要求を受信すると、asは登録されたデバイスをTRLエンドポイントのオブザーバーのリストに追加します。
3. When an access token is revoked, the AS adds the corresponding token hash to the TRL. Also, when a revoked access token eventually expires, the AS removes the corresponding token hash from the TRL.
3. アクセストークンが取り消されると、ASは対応するトークンハッシュをTRLに追加します。また、取り消されたアクセストークンが最終的に期限切れになると、TRLから対応するトークンハッシュを削除します。
In either case, after updating the TRL, the AS sends Observe notifications as per [RFC7641]. That is, an Observe notification is sent to each registered device that is subscribed to the TRL and to which the access token pertains.
どちらの場合でも、TRLを更新した後、[RFC7641]に従って通知をsendsに送信します。つまり、観察通知は、TRLにサブスクライブされ、アクセストークンが関係する各登録デバイスに送信されます。
Depending on the specific subscription established through the Observation Request, the notification provides either the current updated list of revoked access tokens in the subset of the TRL pertaining to that device (see Section 7) or the most recent TRL updates that occurred over that list of pertaining revoked access tokens (see Section 8).
観察要求を通じて確立された特定のサブスクリプションに応じて、通知は、そのデバイスに関連するTRLのサブセットの取り消されたアクセストークンの現在の更新リスト（セクション7を参照）のいずれか、または関連しているREMACEEDアクセストケンのリストで発生した最新のTRL更新（セクション8を参照）のいずれかを提供します。
Further Observe notifications may be sent, consistent with ongoing additional observations of the TRL endpoint.
TRLエンドポイントの進行中の追加の観測と一致して、さらに観察する通知を送信できます。
4. An administrator can access and subscribe to the TRL like a registered device while getting the content of the whole TRL (see Section 7) or the most recent updates that occurred to the whole TRL (see Section 8).
4. 管理者は、TRL全体（セクション7を参照）またはTRL全体に発生した最新の更新（セクション8を参照）を取得しながら、登録デバイスのようにTRLにアクセスして購読できます。
Figure 1 shows a high-level overview of the service provided by this protocol. For the sake of simplicity, the example shown in the figure considers the simultaneous revocation of the three access tokens t1, t2, and t3 whose corresponding token hashes are th1, th2, and th3, respectively. Consequently, the AS adds the three token hashes to the TRL at once and sends Observe notifications to one administrator and four registered devices. Each dotted line associated with a pair of registered devices indicates the access token that they both own.
図1は、このプロトコルが提供するサービスの高レベルの概要を示しています。簡単にするために、図に示されている例は、それぞれ対応するトークンのハッシュがそれぞれTh1、Th2、およびTh3である3つのアクセストークンT1、T2、およびT3の同時取り消しを考慮しています。その結果、ASは3つのトークンをTRLに追加し、1つの管理者と4つの登録されたデバイスに通知を観察する通知を送信します。登録されたデバイスのペアに関連付けられている各点線は、両方とも所有するアクセストークンを示します。
+----------------------+
| Authorization server |
+-----------o----------+
/revoke/trl | TRL: (th1,th2,th3)
|
+-----------------+------------+------------+------------+
| | | | |
| th1,th2,th3 | th1,th2 | th1 | th3 | th2,th3
v v v v v
+---------------+ +----------+ +----------+ +----------+ +----------+
| Administrator | | Client 1 | | Resource | | Client 2 | | Resource |
| | | | | server 1 | | | | server 2 |
+---------------+ +----------+ +----------+ +----------+ +----------+
: : : : : :
: : t1 : : t3 : :
: :........: :............: :
: t2 :
:...........................................:
Figure 1: Protocol Overview
図1：プロトコルの概要
Appendix C provides examples of the protocol flow and message exchanges between the AS and a registered device.
付録Cは、ASと登録されたデバイスの間のプロトコルの流れとメッセージ交換の例を示しています。
An AS that supports the method defined in this document MUST adhere to the following rules when issuing an access token:
このドキュメントで定義されているメソッドをサポートすると、アクセストークンを発行する際には、次のルールを順守する必要があります。
* All the intended header parameters in the access token MUST be specified within integrity-protected fields.
* アクセストークン内のすべての目的のヘッダーパラメーターは、整合性保護フィールド内で指定する必要があります。
* If the access token is a CWT, the following applies:
* アクセストークンがCWTの場合、次のものが適用されます。
- Any "unprotected" field MUST be empty, i.e., its value MUST be encoded as the empty CBOR map (0xa0). This applies to the top-level "unprotected" field of the COSE object used for the CWT, the "unprotected" field of each element of the "signatures" array, and the "unprotected" field of each element of any "recipients" array (see Sections 2, 3, 4, 5, and 6 of [RFC9052]).
- 「保護されていない」フィールドは空でなければなりません。つまり、その値は空のCborマップ（0xa0）としてエンコードする必要があります。これは、CWTに使用されるCOSEオブジェクトのトップレベルの「保護されていない」フィールド、「署名」アレイの各要素の「保護されていない」フィールド、および[RFC9052]のセクション2、3、4、5、および6を参照）。
- Consistent with the specific COSE object used for the CWT, the corresponding tagged structure in the set COSE_Tagged_Message MUST be used (see Section 2 of [RFC9052]). That is, the CBOR array that encodes the CWT MUST be tagged by using the COSE CBOR tag corresponding to the used COSE object. Table 1 in Section 2 of [RFC9052] specifies the tag numbers in question.
- CWTに使用される特定のCOSEオブジェクトと一致して、セットCOSE_TAGGED_MESSAGEの対応するタグ付き構造を使用する必要があります（[RFC9052]のセクション2を参照）。つまり、CWTをコードするCBORアレイは、使用されているCOSEオブジェクトに対応するCOSE CBORタグを使用してタグ付けする必要があります。[RFC9052]のセクション2の表1に、問題のタグ番号を指定します。
In turn, the resulting tagged data item MUST be tagged by using the CWT CBOR tag with tag number 61 (see Section 6 of [RFC8392]). After that, the resulting data item MUST NOT be further tagged.
次に、結果のタグ付けされたデータ項目は、タグ番号61のCWT CBORタグを使用してタグ付けする必要があります（[RFC8392]のセクション6を参照）。その後、結果のデータ項目にさらにタグ付けする必要はありません。
Encoding of the tag numbers MUST be done using definite lengths, and the length of the encoded tag numbers MUST be the minimum possible length. This means that tag number 16 is encoded as 0xd0 and not as 0xd810.
タグ番号のエンコードは、明確な長さを使用して行う必要があり、エンコードされたタグ番号の長さは最小可能な長さでなければなりません。これは、タグ番号16が0xD810ではなく0xD0としてエンコードされることを意味します。
The example in Figure 2 shows a CWT that uses the COSE object COSE_Encrypt0 (see Section 5.2 of [RFC9052]).
図2の例は、COSEオブジェクトCOSE_ENCRYPT0を使用するCWTを示しています（[RFC9052]のセクション5.2を参照）。
* If, like for JWTs [RFC7519], the access token relies on a JSON object for encoding its claims, the following applies:
* JWTS [RFC7519]のように、アクセストークンがその主張をエンコードするためにJSONオブジェクトに依存している場合、次のものが適用されます。
Consistent with the ACE framework [RFC9200], this document specifically considers JWTs, which are always represented using the JSON Web Signature (JWS) Compact Serialization from [RFC7515] or the JSON Web Encryption (JWE) Compact Serialization from [RFC7516]. Consequently, all the header parameters are specified within integrity-protected fields.
ACEフレームワーク[RFC9200]と一致して、このドキュメントは、[RFC7515]または[RFC7516]からのJSON Web暗号化（JWE）コンパクトシリアル化からのJSON Web署名（JWS）コンパクトシリアル化を使用して常に表現されるJWTSを明確に考慮します。その結果、すべてのヘッダーパラメーターは、整合性保護フィールド内で指定されます。
In case alternative access tokens were used, the following applies:
代替アクセストークンが使用された場合、次のものが適用されます。
- If the access token uses the JWS JSON Serialization from [RFC7515], it MUST NOT include the JWS Unprotected Header.
- アクセストークンが[RFC7515]のJWS JSONシリアル化を使用している場合、JWSの保護されていないヘッダーを含めてはなりません。
- If the access token uses the JWE JSON Serialization from [RFC7516], it MUST NOT include the JWE Shared Unprotected Header and it MUST NOT include the "header" member in any of the elements of the "recipients" array.
- アクセストークンが[RFC7516]からのJWE JSONシリアル化を使用している場合、JWE共有されていないヘッダーを共有してはならず、「受信者」アレイのいずれかの要素に「ヘッダー」メンバーを含めてはなりません。
/ CWT CBOR tag / 61(
/ COSE_Encrypt0 CBOR tag / 16(
/ COSE_Encrypt0 object / [
/ protected / h'a3010a044c53796d6d65747269633132
38054d99a0d7846e762c49ffe8a63e0b',
/ unprotected / {},
/ ciphertext / h'b918a11fd81e438b7f973d9e2e119bcb
22424ba0f38a80f27562f400ee1d0d6c
0fdb559c02421fd384fc2ebe22d70713
78b0ea7428fff157444d45f7e6afcda1
aae5f6495830c58627087fc5b4974f31
9a8707a635dd643b'
]
)
)
Figure 2: Example of CWT Using COSE_Encrypt0
図2：COSE_ENCRYPT0を使用したCWTの例
Section 14.6 discusses how adhering to the rules above neutralizes an attack against the RS where an active adversary can induce the RS to compute a token hash different from the correct one.
セクション14.6では、上記のルールを順守することで、アクティブな敵がRSを誘導して、正しいものとは異なるトークンハッシュを計算することができるRSに対する攻撃をどのように中和するかについて説明します。
This section specifies how token hashes are computed.
このセクションでは、トークンハッシュの計算方法を指定します。
First, Section 4.1 provides the motivation for the used construction.
まず、セクション4.1では、使用済み構造の動機を示します。
Building on that, the value used as input to compute a token hash is defined in Section 4.2 for the client and the AS and in Section 4.3 for the RS. Finally, Section 4.4 defines how such an input is used for computing the token hash.
その上に、トークンハッシュを計算するために入力として使用される値は、クライアントとASのセクション4.2、およびRSのセクション4.3で定義されています。最後に、セクション4.4は、トークンハッシュの計算にこのような入力がどのように使用されるかを定義しています。
The process outlined below refers to the base64url encoding and decoding without padding (see Section 5 of [RFC4648]) and denotes as "binary representation" of a text string the corresponding UTF-8 encoding [RFC3629], which is the implied charset used in JSON (see Section 8.1 of [RFC8259]).
以下に概説するプロセスは、パディングなしでのbase64URLエンコードとデコード（[RFC4648]のセクション5を参照）を指し、JSONで使用されるインプライドされた特性を参照してください（[RFC8259]のセクション8.1を参照）。
Consistent with Section 3.4 of [RFC8949], the term "tag" is used for the entire CBOR data item consisting of both a tag number and the tag content: the tag content is the CBOR data item that is being tagged.
[RFC8949]のセクション3.4と一致して、「タグ」という用語は、タグ番号とタグコンテンツの両方で構成されるCBORデータ項目全体に使用されます。タグコンテンツは、タグ付けされているCBORデータ項目です。
Also, "tagged access token" is used to denote nested CBOR tags (possibly a single one), with the innermost tag content being a CWT.
また、「タグ付きアクセストークン」は、ネストされたCBORタグ（おそらく単一のタグ）を示すために使用され、最も内側のタグコンテンツはCWTです。
An access token can have one among different formats. The most expected formats are CWT [RFC8392] and JWT [RFC7519], with the former being the default format to use in the ACE framework (see Section 3 of [RFC9200]). While access tokens are opaque to clients, an RS is aware of whether access tokens that are issued for it to consume are either CWTs or JWTs.
アクセストークンは、異なる形式の1つを持つことができます。最も期待される形式はCWT [RFC8392]およびJWT [RFC7519]であり、前者はACEフレームワークで使用するデフォルト形式です（[RFC9200]のセクション3を参照）。アクセストークンはクライアントにとって不透明ですが、RSは、消費するために発行されるアクセストークンがCWTSまたはJWTSのいずれかであるかどうかを認識しています。
There are two possible encodings that the AS can use for the AS-to-Client response (see Section 5.8.2 of [RFC9200]) where the issued access token is included and provided to the requester client. The RS may not be aware of which encoding is used for that response to that particular requester client.
発行されたアクセストークンが含まれ、リクエスタークライアントに提供されている場合、ASクライアント応答に使用できる2つのエンコーディングがあります（[RFC9200]のセクション5.8.2を参照）。RSは、その特定のRequesterクライアントへのその応答に使用されるエンコードがどのエンコードが使用されているかを認識していない場合があります。
* One method of encoding relies on CBOR, which is required if CoAP is used (see Section 5 of [RFC9200]) and is recommended otherwise (see Section 3 of [RFC9200]). That is, the AS-to-Client response has media-type "application/ace+cbor".
* エンコーディングの1つの方法はCBORに依存しています。これは、COAPが使用される場合（[RFC9200]セクション5を参照）、別の方法で推奨されます（[RFC9200]のセクション3を参照）。つまり、ascly-to-client応答には、メディアタイプの「アプリケーション/ACE+CBOR」があります。
This implies that, within the CBOR map specified as message payload, the 'access_token' parameter is a CBOR data item of type CBOR byte string and with a value of BYTES. In particular:
これは、メッセージペイロードとして指定されたCBORマップ内で、「Access_Token」パラメーターがタイプCBORバイト文字列とバイトの値を持つCBORデータ項目であることを意味します。特に：
- If the access token is a CWT, then BYTES is the binary representation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token with the CWT as the innermost tag content.
- アクセストークンがCWTの場合、バイトは、CWT（つまり、覆われていないCWTをコードするCBORアレイ）またはタグ付きアクセストークンのCWTを最も内側のタグコンテンツとして表現するバイナリ表現です。
- If the access token is a JWT, then BYTES is the binary representation of the JWT (i.e., of the text string that encodes the JWT).
- アクセストークンがJWTの場合、バイトはJWT（つまり、JWTをコードするテキスト文字列のバイナリ表現です。
* An alternative method of encoding relies on JSON. That is, the AS-to-Client response has media-type "application/ace+json".
* エンコードの代替方法は、JSONに依存しています。つまり、ascly-to-client応答には、メディアタイプの「アプリケーション/ACE+JSON」があります。
This implies that, within the JSON object specified as message payload, the 'access_token' parameter has as a value a text string TEXT. In particular:
これは、メッセージペイロードとして指定されたJSONオブジェクト内で、「Access_Token」パラメーターがテキスト文字列テキストとして値としてあることを意味します。特に：
- If the access token is a JWT, then TEXT is the text string that encodes the JWT.
- アクセストークンがJWTの場合、テキストはJWTをコードするテキスト文字列です。
- If the access token is a CWT, then TEXT is the base64url-encoded text string of BYTES, which is the binary representation of the CWT (i.e., of the CBOR array that encodes the untagged CWT) or of a tagged access token with the CWT as the innermost tag content.
- アクセストークンがCWTの場合、テキストはBase64urlエンコードされたテキストのバイト文字列であり、CWT（つまり、覆われていないCWTをコードするCBORアレイ）または最小限のタグコンテンツとしてCWTを使用したタグ付きアクセストークンのバイナリ表現です。
In accordance with the used transport profile of ACE (e.g., [RFC9202], [RFC9203], [RFC9431]), the RS receives a piece of token-related information hereafter denoted as TOKEN_INFO.
ACEの使用済み輸送プロファイル（例：[RFC9202]、[RFC9203]、[RFC9431]）に従って、RSは、Token_Infoとして示されたトークン関連の情報を受け取ります。
In particular:
特に：
* If the AS-to-Client response was encoded in CBOR, then TOKEN_INFO is the value of the CBOR byte string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the access token.
* as-client応答がCBORでエンコードされている場合、token_infoは、その応答の「Access_Token」パラメーターによって伝達されるCBORバイト文字列の値です。つまり、token_infoはアクセストークンのバイナリ表現です。
* If the AS-to-Client response was encoded in JSON and the access token is a JWT, then TOKEN_INFO is the binary representation of the text string conveyed by the 'access_token' parameter of that response. That is, TOKEN_INFO is the binary representation of the access token.
* as-client応答がJSONでエンコードされ、アクセストークンがJWTである場合、token_infoは、その応答の「アクセス_token」パラメーターによって伝えられるテキスト文字列のバイナリ表現です。つまり、token_infoはアクセストークンのバイナリ表現です。
* If the AS-to-Client response was encoded in JSON and the access token is a CWT, then TOKEN_INFO is the binary representation of the base64url-encoded text string that encodes the binary representation of the access token. That is, TOKEN_INFO is the binary representation of the base64url-encoded text string conveyed by the 'access_token' parameter.
* as-client応答がJSONでエンコードされ、アクセストークンがCWTである場合、token_infoはアクセストークンのバイナリ表現をコードするbase64urlエンコードテキスト文字列のバイナリ表現です。つまり、token_infoは、「access_token」パラメーターによって伝達されるbase64urlエンコードテキスト文字列のバイナリ表現です。
The following overviews how the above specifically applies to the existing transport profiles of ACE:
以下の概要は、上記がACEの既存の輸送プロファイルにどのように適用されるかを示しています。
* The access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint (see Section 5.10.1 of [RFC9200]), using a CoAP Content-Format or HTTP media-type that reflects the format of the access token, if available (e.g., "application/cwt" for CWTs), or "application/octet-stream" otherwise. When doing so (e.g., like in [RFC9202]), TOKEN_INFO is the payload of the POST request.
* アクセストークンは、/authz-infoエンドポイントへのPOSTリクエストによってRSにアップロードできます（[RFC9200]のセクション5.10.1を参照）、COAPコンテンツフォーマットまたはHTTPメディアタイプを使用して、アクセストークンのフォーマットを反映しています。そうする場合（たとえば、[RFC9202]のように）、token_infoはPOSTリクエストのペイロードです。
* The access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint, using the media-type "application/ace+cbor". When doing so (e.g., like in [RFC9203]), TOKEN_INFO is the value of the CBOR byte string conveyed by the 'access_token' parameter, within the CBOR map specified as payload of the POST request.
* アクセストークンは、メディアタイプの「Application /ACE+CBOR」を使用して、 /authz-infoエンドポイントへのPOSTリクエストによってRSにアップロードできます。そうする場合（たとえば、[rfc9203]のように）、token_infoは、POSTリクエストのペイロードとして指定されたCBORマップ内の「Access_Token」パラメーターによって伝達されるCBORバイト文字列の値です。
* The access token can be uploaded to the RS during a DTLS session establishment, e.g., like it is defined in Section 3.3.2 of [RFC9202]. When doing so, TOKEN_INFO is the value of the 'psk_identity' field of the ClientKeyExchange message (when using DTLS 1.2 [RFC6347]) or of the 'identity' field of a PSKIdentity, within the PreSharedKeyExtension of a ClientHello message (when using DTLS 1.3 [RFC9147]).
* アクセストークンは、[RFC9202]のセクション3.3.2で定義されているように、DTLSセッションの確立中にRSにアップロードできます。そうする場合、token_infoは、clienthellohelloメッセージのpresharedkeyextension内のpskidentityの「dtls 1.2 [rfc6347]を使用する場合）の「psk_identity」フィールド（dtls 1.2 [rfc6347]を使用する場合）の値（dtls 1.3 [rfc9147]を使用する場合）の値です。
* The access token can be uploaded to the RS within the MQTT CONNECT packet, e.g., like it is defined in Section 2.2.4.1 of [RFC9431]. When doing so, TOKEN_INFO is specified within the 'Authentication Data' field of the MQTT CONNECT packet, following the property identifier 22 (0x16) and the token length.
* アクセストークンは、[RFC9431]のセクション2.2.4.1で定義されているように、MQTT接続パケット内のRSにアップロードできます。その場合、token_infoは、プロパティ識別子22（0x16）とトークン長に従って、MQTT Connectパケットの「認証データ」フィールド内で指定されます。
Note that, if the access token is a CWT, it is specifically tagged as defined in Section 3.
アクセストークンがCWTである場合、セクション3で定義されているように特異的にタグ付けされていることに注意してください。
Considering the possible variants discussed above, it must always be ensured that the same HASH_INPUT value is used as input for generating the token hash of a given access token, by the AS that has issued the access token and by the registered devices to which the access token pertains (both client and RS).
上記の考えられるバリアントを考慮すると、特定のアクセストークンのトークンハッシュを生成するための入力として同じHash_input値が、アクセストークンを発行し、アクセストークンに関連する登録デバイス（クライアントとRsの両方）によって常に使用されることを常に保証する必要があります。
This is achieved by building HASH_INPUT according to the content of the 'access_token' parameter in the AS-to-Client responses because that is what the AS, the client, and the RS are all able to see.
これは、AS、クライアント、およびRSがすべて表示できるものであるため、クライアントへの応答の「Access_Token」パラメーターのコンテンツに従ってHASH_INPUTを構築することによって達成されます。
The client and the AS consider the content of the 'access_token' parameter in the AS-to-Client response, in which the access token is included and provided to the requester client. Note that, if the access token is a CWT, it is specifically tagged as defined in Section 3.
クライアントとAS AS AS AS AS AS-Client応答の「Access_Token」パラメーターのコンテンツは、アクセストークンが含まれ、リクエスタクライアントに提供されます。アクセストークンがCWTである場合、セクション3で定義されているように特異的にタグ付けされていることに注意してください。
The following defines how the client and the AS determine the HASH_INPUT value to use as input for computing the token hash of the conveyed access token, depending on the AS-to-Client response being encoded in CBOR (see Section 4.2.1) or in JSON (see Section 4.2.2).
以下は、CBOR（セクション4.2.1を参照）またはJSON（セクション4.2.2を参照）でエンコードされているASクライアント応答のトークンハッシュを計算するための入力として使用するHASH_INPUT値をクライアントとASを決定する方法を定義します。
Once HASH_INPUT is determined, the client and the AS use it to compute the token hash of the conveyed access token as defined in Section 4.4.
HASH_INPUTが決定されると、クライアントとAS ASを使用して、セクション4.4で定義されているように、伝達されたアクセストークンのトークンハッシュを計算します。
If the AS-to-Client response is encoded in CBOR, then HASH_INPUT is defined as follows:
as-client応答がCBORでエンコードされている場合、hash_inputは次のように定義されます。
* BYTES denotes the value of the CBOR byte string conveyed in the 'access_token' parameter.
* バイトは、「Access_Token」パラメーターで配信されるCBORバイト文字列の値を示します。
With reference to the example in Figure 3, BYTES is the bytes {0xd8, 0x3d, 0xd0, ..., 0x64, 0x3b}.
図3の例を参照すると、バイトはバイト{0xd8、0x3d、0xd0、...、0x64、0x3b}です。
Note that BYTES is the binary representation of the tagged access token if this is a CWT (as per Section 3) or of the access token if this is a JWT.
バイトは、これがCWT（セクション3に従って）の場合のタグ付きアクセストークンのバイナリ表現であるか、JWTの場合はアクセストークンのバイナリ表現であることに注意してください。
* HASH_INPUT_TEXT is the base64url-encoded text string that encodes BYTES.
* hash_input_textは、バイトをエンコードするbase64urlエンコードテキスト文字列です。
* HASH_INPUT is the binary representation of HASH_INPUT_TEXT.
* HASH_INPUTは、HASH_INPUT_TEXTのバイナリ表現です。
Header: Created (Code=2.01)
Content-Format: 19 (application/ace+cbor)
Max-Age: 85800
Payload:
{
/ access_token / 1 : h'd83dd0835820a3010a044c53796d6d
6574726963313238054d99a0d7846e
762c49ffe8a63e0ba05858b918a11f
d81e438b7f973d9e2e119bcb22424b
a0f38a80f27562f400ee1d0d6c0fdb
559c02421fd384fc2ebe22d7071378
b0ea7428fff157444d45f7e6afcda1
aae5f6495830c58627087fc5b4974f
319a8707a635dd643b',
/ token_type / 34 : 2 / PoP /,
/ expires_in / 2 : 86400,
/ ace_profile / 38 : 1 / coap_dtls /
/ (remainder of the response omitted for brevity) /
}
Figure 3: Example of AS-to-Client CoAP Response Using CBOR
図3：CBORを使用したASクライアントへのCOAP応答の例
If the AS-to-Client response is encoded in JSON, then HASH_INPUT is the binary representation of the text string conveyed by the 'access_token' parameter.
as-client応答がJSONでエンコードされている場合、hash_inputは「access_token」パラメーターによって伝えられるテキスト文字列のバイナリ表現です。
With reference to the example in Figure 4, HASH_INPUT is the binary representation of "eyJh...YFiA". When showing the access token, Figure 4 uses line breaks for display purposes only.
図4の例を参照すると、Hash_inputは「Eyjh ... yfia」のバイナリ表現です。アクセストークンを表示する場合、図4は表示目的でのみ行のブレークを使用します。
Note that:
ご了承ください：
* If the access token is a JWT, then HASH_INPUT is the binary representation of the JWT.
* アクセストークンがJWTの場合、hash_inputはJWTのバイナリ表現です。
* If the access token is a CWT, then HASH_INPUT is the binary representation of a base64url-encoded text string, which encodes the binary representation of a tagged access token with the CWT as the innermost tag content (as per Section 3).
* アクセストークンがCWTの場合、hash_inputはbase64urlエンコードされたテキスト文字列のバイナリ表現であり、CWTを伴うタグ付きアクセストークンのバイナリ表現を最も内側のタグコンテンツとしてエンコードします（セクション3に従って）。
HTTP/1.1 200 OK
Content-Type: application/ace+json
Cache-Control: no-store
Pragma: no-cache
Payload:
{
"access_token" : "eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJB
MTI4Q0JDLUhTMjU2In0.
QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8
qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
oNfABIPJaZm0HaA415sv3aeuBWnD8J-U
i7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvW
n_hXV1BNMHzUjPyYwEsRhDhzjAD26ima
sOTsgruobpYGoQcXUwFDn7moXPRfDE8-
NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
YCitxoQVPzjbl7WBuB7AohdBoZOdZ24W
lN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
1rZgN5TiysnmzTROF869lQ.
AxY8DCtDaGlsbGljb3RoZQ.
MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeW
nDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7
sln1Eu9g3J8.
fiK51VwhsxJ-siBMR-YFiA",
"token_type" : "PoP",
"expires_in" : 86400,
"ace_profile" : "coap_dtls"
}
Figure 4: Example of AS-to-Client HTTP Response Using JSON
図4：JSONを使用したASクライアントHTTP応答の例
The following defines how the RS determines the HASH_INPUT value to use as input for computing the token hash of an access token, depending on the RS using either CWTs (see Section 4.3.1) or JWTs (see Section 4.3.2).
以下は、RSがCWTS（セクション4.3.1を参照）またはJWTS（セクション4.3.2を参照）を使用してRSに応じて、アクセストークンのトークンハッシュを計算するための入力として使用するHASH_INPUT値を決定する方法を定義します。
If the RS expects access tokens to be CWTs, then the RS performs the following steps:
RSがアクセストークンがCWTSになることを期待する場合、RSは次の手順を実行します。
1. The RS receives the token-related information TOKEN_INFO, in accordance with what is specified by the used profile of ACE (see Section 4.1.2).
1. RSは、使用済みのACEプロファイルによって指定されているものに従って、トークン関連情報token_infoを受信します（セクション4.1.2を参照）。
2. The RS assumes that the client received the access token in an AS-to-Client response encoded in CBOR (see Section 4.2.1). Hence, the RS assumes TOKEN_INFO to be the binary representation of the tagged access token with the CWT as the innermost tag content (as per Section 3).
2. RSは、クライアントがCBORでエンコードされたASクライアント応答でアクセストークンを受け取ったと想定しています（セクション4.2.1を参照）。したがって、RSは、Token_InfoがCWTを伴うタグ付きアクセストークンのバイナリ表現であると仮定します（セクション3に従って）。
3. The RS verifies the access token as per Section 5.10.1.1 of [RFC9200]. If the verification fails, then the RS does not discard the access token yet; instead, it moves to Step 4.
3. RSは、[RFC9200]のセクション5.10.1.1に従って、アクセストークンを検証します。検証が失敗した場合、RSはまだアクセストークンを破棄しません。代わりに、ステップ4に移動します。
Otherwise, the RS stores the access token and computes the corresponding token hash as defined in Section 4.4. In particular, the RS considers HASH_INPUT_TEXT as the base64url-encoded text string that encodes TOKEN_INFO. Then, HASH_INPUT is the binary representation of HASH_INPUT_TEXT.
それ以外の場合、RSはアクセストークンを保存し、セクション4.4で定義されているように対応するトークンハッシュを計算します。特に、RSは、hash_input_textをtoken_infoをコードするbase64urlエンコードテキスト文字列と見なします。次に、hash_inputはhash_input_textのバイナリ表現です。
After that, the RS stores the computed token hash as associated with the access token; then, it terminates this algorithm.
その後、RSは、アクセストークンに関連付けられている計算されたトークンハッシュを保存します。次に、このアルゴリズムを終了します。
4. The RS assumes that the client received the access token in an AS-to-Client response encoded in JSON (see Section 4.2.2). Hence, the RS assumes TOKEN_INFO to be the binary representation of HASH_INPUT_TEXT. In turn, HASH_INPUT_TEXT is the base64url-encoded text string that encodes the binary representation of the tagged access token with the CWT as the innermost tag content (as per Section 3).
4. RSは、クライアントがJSONでエンコードされたASクライアント応答でアクセストークンを受け取ったと想定しています（セクション4.2.2を参照）。したがって、RSはdoken_infoがhash_input_textのバイナリ表現であると想定しています。次に、hash_input_textは、CWTを最も内側のタグコンテンツとして（セクション3に従って）にして、タグ付きアクセストークンのバイナリ表現をコードするbase64urlエンコードテキスト文字列です。
5. The RS performs the base64url decoding of HASH_INPUT_TEXT and considers the result to be the binary representation of the tagged access token.
5. RSは、hash_input_textのbase64urlデコードを実行し、結果をタグ付きアクセストークンのバイナリ表現であると考えています。
6. The RS verifies the access token as per Section 5.10.1.1 of [RFC9200]. If the verification fails, then the RS terminates this algorithm.
6. RSは、[RFC9200]のセクション5.10.1.1に従って、アクセストークンを検証します。検証が失敗した場合、RSはこのアルゴリズムを終了します。
Otherwise, the RS stores the access token and computes the corresponding token hash as defined in Section 4.4. In particular, HASH_INPUT is TOKEN_INFO.
それ以外の場合、RSはアクセストークンを保存し、セクション4.4で定義されているように対応するトークンハッシュを計算します。特に、hash_inputはtoken_infoです。
After that, the RS stores the computed token hash as associated with the access token.
その後、RSは、アクセストークンに関連付けられている計算されたトークンハッシュを保存します。
If the RS expects access tokens to be JWTs, then the RS performs the following steps:
RSがアクセストークンがJWTSになることを期待する場合、RSは次の手順を実行します。
1. The RS receives the token-related information TOKEN_INFO, in accordance with what is specified by the used profile of ACE (see Section 4.1.2).
1. RSは、使用済みのACEプロファイルによって指定されているものに従って、トークン関連情報token_infoを受信します（セクション4.1.2を参照）。
2. The RS verifies the access token as per Section 5.10.1.1 of [RFC9200]. If the verification fails, then the RS terminates this algorithm. Otherwise, the RS stores the access token.
2. RSは、[RFC9200]のセクション5.10.1.1に従って、アクセストークンを検証します。検証が失敗した場合、RSはこのアルゴリズムを終了します。それ以外の場合、RSはアクセストークンを保存します。
3. The RS computes a first token hash associated with the access token as defined in Section 4.4.
3. RSは、セクション4.4で定義されているように、アクセストークンに関連付けられた最初のトークンハッシュを計算します。
In particular, the RS assumes that the client received the access token in an AS-to-Client response encoded in JSON (see Section 4.2.2). Hence, HASH_INPUT is TOKEN_INFO.
特に、RSは、クライアントがJSONでエンコードされたASクライアント応答でアクセストークンを受け取ったと想定しています（セクション4.2.2を参照）。したがって、hash_inputはtoken_infoです。
After that, the RS stores the computed token hash as associated with the access token.
その後、RSは、アクセストークンに関連付けられている計算されたトークンハッシュを保存します。
4. The RS computes a second token hash associated with the access token as defined in Section 4.4.
4. RSは、セクション4.4で定義されているように、アクセストークンに関連付けられた2番目のトークンハッシュを計算します。
In particular, the RS assumes that the client received the access token in an AS-to-Client response encoded in CBOR (see Section 4.2.1). Hence, HASH_INPUT is the binary representation of HASH_INPUT_TEXT, which, in turn, is the base64url-encoded text string that encodes TOKEN_INFO.
特に、RSは、クライアントがCBORでエンコードされたASクライアント応答でアクセストークンを受け取ったと想定しています（セクション4.2.1を参照）。したがって、hash_inputはhash_input_textのバイナリ表現であり、これはtoken_infoをコードするbase64urlエンコードテキスト文字列です。
After that, the RS stores the computed token hash as associated with the access token.
その後、RSは、アクセストークンに関連付けられている計算されたトークンハッシュを保存します。
The RS skips Step 3 only if it is certain that all its pertaining access tokens are provided to any client by means of AS-to-Client responses encoded as CBOR messages. Otherwise, the RS MUST perform Step 3.
RSは、CBORメッセージとしてエンコードされたClient-to-client応答を使用して、すべての関連するアクセストークンが任意のクライアントに提供されることが確実な場合にのみ、ステップ3をスキップします。それ以外の場合、RSはステップ3を実行する必要があります。
The RS skips Step 4 only if it is certain that all its pertaining access tokens are provided to any client by means of AS-to-Client responses encoded as JSON messages. Otherwise, the RS MUST perform Step 4.
RSは、JSONメッセージとしてエンコードされたASクライアントからクライアントへの応答によって、すべての関連するアクセストークンが任意のクライアントに提供されることが確実な場合にのみ、ステップ4をスキップします。それ以外の場合、RSはステップ4を実行する必要があります。
If the RS performs both Steps 3 and 4 above, then the RS MUST store, maintain, and rely on both token hashes as associated with the access token, consistent with what is specified in Section 11.1.
RSが上記のステップ3と4の両方を実行する場合、RSは、セクション11.1で指定されているものと一致して、アクセストークンに関連付けられているトークンハッシュの両方を保存、維持、および依存する必要があります。
Section 14.7 discusses how computing and storing both token hashes neutralizes an attack against the RS, where a dishonest client can induce the RS to compute a token hash different from the correct one.
セクション14.7では、両方のトークンハッシュの計算と保存がRSに対する攻撃を中和する方法について説明します。ここでは、不正なクライアントがRSを誘導して、正しいものとは異なるトークンハッシュを計算することができます。
Once HASH_INPUT is determined as defined in Sections 4.2 and 4.3, a hash value of HASH_INPUT is generated as per Section 6 of [RFC6920]. The resulting output in binary format is used as the token hash. Note that the used binary format embeds the identifier of the used hash function in the first byte of the computed token hash.
セクション4.2および4.3で定義されているようにHASH_INPUTが決定されると、[RFC6920]のセクション6に従って、hash_inputのハッシュ値が生成されます。結果のバイナリ形式での出力は、トークンハッシュとして使用されます。使用されたバイナリ形式は、計算されたトークンハッシュの最初のバイトに使用されたハッシュ関数の識別子を埋め込むことに注意してください。
The specific hash function used MUST be collision resistant on byte strings and MUST be selected from the "Named Information Hash Algorithm Registry" [IANA.Hash.Algorithms]. Consistent with the compliance requirements in Section 2 of [RFC6920], the hash function sha-256 as specified in [SHA-256] is mandatory to implement.
使用される特定のハッシュ関数は、バイト文字列に衝突抵抗性でなければならず、「名前付き情報ハッシュアルゴリズムレジストリ」[iana.hash.algorithms]から選択する必要があります。[RFC6920]のセクション2のコンプライアンス要件と一致して、[SHA-256]で指定されているハッシュ関数SHA-256は、実装が必須です。
The AS specifies the used hash function to registered devices during their registration procedure (see Section 10).
ASは、登録手順中に登録デバイスに使用されたハッシュ関数を指定します（セクション10を参照）。
Upon startup, the AS creates a single Token Revocation List (TRL) encoded as a CBOR array.
起動時に、ASはCBORアレイとしてエンコードされた単一のトークン取り消しリスト（TRL）を作成します。
Each element of the array is a CBOR byte string, whose value is the token hash of an access token. The CBOR array MUST be treated as a set, i.e., the order of its elements has no meaning.
配列の各要素はCborバイト文字列で、その値はアクセストークンのトークンハッシュです。CBORアレイはセットとして扱う必要があります。つまり、その要素の順序には意味がありません。
The TRL is initialized as empty, i.e., its initial content MUST be the empty CBOR array. The TRL is accessible through the TRL endpoint at the AS.
TRLは空として初期化されます。つまり、その初期コンテンツは空のCBORアレイでなければなりません。TRLは、ASのTRLエンドポイントからアクセスできます。
The AS updates the TRL in the following two cases:
ASは、次の2つのケースでTRLを更新します。
* When a non-expired access token is revoked, the token hash of the access token is added to the TRL. That is, a CBOR byte string with the token hash as its value is added to the CBOR array encoding the TRL.
* 非エスパイアされたアクセストークンが取り消されると、アクセストークンのトークンハッシュがTRLに追加されます。つまり、TRLをエンコードするCBORアレイに値が追加されると、トークンハッシュを備えたCBORバイト文字列。
* When a revoked access token expires, the token hash of the access token is removed from the TRL. That is, the CBOR byte string with the token hash as its value is removed from the CBOR array encoding the TRL.
* 取り消されたアクセストークンの有効期限が切れると、アクセストークンのトークンハッシュがTRLから削除されます。つまり、TRLをエンコードするCBORアレイから値が削除されると、トークンハッシュが付いたCBORバイト文字列。
The AS MAY perform a single update to the TRL such that one or more token hashes are added or removed at once. For example, this can be the case if multiple access tokens are revoked or expire at the same time or within an acceptably narrow time frame.
ASは、TRLの単一のアップデートを実行する可能性があり、1つ以上のトークンハッシュが一度に追加または削除されます。たとえば、これは、複数のアクセストークンが取り消されたり、同時にまたは容認できる狭い時間枠内で有効になっている場合に当てはまります。
Consistent with Section 6.5 of [RFC9200], all communications between the AS and a requester interacting with the TRL endpoint at the AS MUST be encrypted, as well as integrity and replay protected. Furthermore, responses from the AS to the requester MUST be bound to the corresponding requests.
[RFC9200]のセクション6.5と一致して、ASとASのTRLエンドポイントと相互作用するASとリクエスターとの間のすべての通信を暗号化する必要があり、保護された整合性とリプレイ。さらに、要求者に対するASからの応答は、対応するリクエストに拘束される必要があります。
Following a request to the TRL endpoint, the corresponding success response messages sent by the AS use Content-Format "application/ace-trl+cbor". Their payload is formatted as a CBOR map, and the CBOR values used to abbreviate the parameters included therein are defined in Section 12.
TRLエンドポイントへのリクエストに続いて、ASの使用コンテンツフォーマット「Application/ACE-TRL+CBOR」によって送信される対応する成功応答メッセージ。ペイロードはCBORマップとしてフォーマットされており、そこに含まれるパラメーターを省略するために使用されるCBOR値はセクション12で定義されています。
The AS MUST implement measures to prevent access to the TRL endpoint by entities other than registered devices and authorized administrators (see Section 10).
ASは、登録されたデバイスおよび認定管理者以外のエンティティによるTRLエンドポイントへのアクセスを防ぐための措置を実装する必要があります（セクション10を参照）。
The TRL endpoint supports only the GET method, and allows two types of queries of the TRL:
TRLエンドポイントはGETメソッドのみをサポートし、TRLの2種類のクエリを許可します。
1. Full query: the AS returns the token hashes of the revoked access tokens currently in the TRL and pertaining to the requester.
1. フルクエリ：ASは、現在TRLにあり、リクエスターに関連して、取り消されたアクセストークンのトークンハッシュを返します。
The AS MUST support this type of query. The processing of a full query and the related response format are defined in Section 7.
このタイプのクエリをサポートする必要があります。完全なクエリと関連する応答形式の処理は、セクション7で定義されています。
2. Diff query: the AS returns a list of diff entries. Each diff entry is related to one update that occurred to the TRL, and it contains a set of token hashes pertaining to the requester. In particular, all such token hashes were added to the TRL or removed from the TRL at the update related to the diff entry in question.
2. diff query：asは、diffエントリのリストを返します。各diffエントリは、TRLに発生した1つの更新に関連しており、リクエスターに関連するトークンハッシュのセットが含まれています。特に、このようなトークンハッシュはすべてTRLに追加されるか、問題のDIFFエントリに関連するアップデートでTRLから削除されました。
The AS MAY support this type of query. In such a case, the AS maintains the history of updates to the TRL as defined in Section 6.2. The processing of a diff query and the related response format are defined in Section 8.
このタイプのクエリをサポートする可能性があります。そのような場合、Sはセクション6.2で定義されているように、TRLの更新の履歴を維持します。差分クエリと関連する応答形式の処理は、セクション8で定義されています。
If it supports diff queries, the AS MAY additionally support the related "Cursor" extension, which has two benefits:
DIFFクエリをサポートする場合、ASは、2つの利点がある関連する「カーソル」拡張機能をさらにサポートする場合があります。
1. The AS can avoid excessively long messages when several diff entries have to be transferred by delivering several diff query responses, each containing one adjacent subset of diff entries at a time.
1. ASは、複数のDiffクエリ応答を配信することにより、いくつかのdiffエントリを転送する必要がある場合に、過度に長いメッセージを回避できます。
2. A requester can retrieve diff entries associated with TRL updates that, even if not the most recent ones, occurred after a TRL update associated with a diff entry indicated as a reference point.
2. リクエスターは、TRLアップデートに関連付けられた差異エントリを取得できます。これは、最新のエントリではない場合でも、基準点として示されているDIFFエントリに関連付けられたTRLアップデートの後に発生したことです。
If it supports the "Cursor" extension, the AS stores additional information when maintaining the history of updates to the TRL as defined in Section 6.2.1. Also, the processing of full query requests and diff query requests, as well as the related response format, are further extended as defined in Section 9.
「カーソル」拡張機能をサポートする場合、セクション6.2.1で定義されているTRLの更新履歴を維持するときに、追加情報を保存します。また、関連する応答形式と同様に、完全なクエリ要求とdiffクエリ要求の処理は、セクション9で定義されているようにさらに拡張されます。
Appendix B provides an aggregated overview of the local supportive parameters that the AS internally uses at its TRL endpoint when supporting diff queries and the "Cursor" extension.
付録Bは、DIFFクエリと「カーソル」拡張機能をサポートするときにASがTRLエンドポイントで内部的に使用するローカルサポートパラメーターの集約された概要を提供します。
Some error responses from the TRL endpoint at the AS can convey error-specific information according to the problem-details format defined in [RFC9290]. Such error responses MUST have Content-Format set to "application/concise-problem-details+cbor". The payload of these error responses MUST be a CBOR map specifying a Concise Problem Details data item (see Section 2 of [RFC9290]). The CBOR map is formatted as follows:
ASのTRLエンドポイントからのいくつかのエラー応答は、[RFC9290]で定義されている問題 - セテール形式に従ってエラー固有の情報を伝えることができます。このようなエラー応答には、コンテンツフォーマットが「アプリケーション/簡潔な問題」に設定されている必要があります。これらのエラー応答のペイロードは、簡潔な問題の詳細データ項目を指定するCBORマップでなければなりません（[RFC9290]のセクション2を参照）。CBORマップは次のようにフォーマットされます。
* It MUST include the Custom Problem Detail entry 'ace-trl-error' registered in Section 15.3 of this document. This entry is formatted as a CBOR map, which includes the following fields:
* このドキュメントのセクション15.3に登録されているカスタム問題の詳細エントリ「ACE-TRL-ERROR」を含める必要があります。このエントリは、次のフィールドを含むCBORマップとしてフォーマットされています。
- The 'error-id' field MUST be present. The map key used for this field is the CBOR unsigned integer with a value of 0. The value of this field is a CBOR integer specifying the error that occurred at the AS. This value is taken from the 'Value' column of the "ACE Token Revocation List Errors" registry defined in Section 15.5 of this document.
- 「エラーID」フィールドが存在する必要があります。このフィールドに使用されるマップキーは、0の値を持つCBORの署名整数です。このフィールドの値は、ASで発生したエラーを指定するCBOR整数です。この値は、このドキュメントのセクション15.5で定義されている「エーストークン取り消しリストエラー」レジストリの「値」列から取得されます。
- The 'cursor' field MAY be present. The map key used for this field is the CBOR unsigned integer with a value of 1. The value of this field is a CBOR unsigned integer or the CBOR simple value null (0xf6). The use of this field is defined in Section 6.3.
- 「カーソル」フィールドが存在する場合があります。このフィールドに使用されるマップキーは、1の値を持つCBORの署名整合体です。このフィールドの値は、CBOR signed IntegerまたはCBOR Simple値null（0xf6）です。このフィールドの使用は、セクション6.3で定義されています。
The CDDL notation [RFC8610] of the 'ace-trl-error' entry is given below:
「ACE-TRL-ERROR」エントリのCDDL表記[RFC8610]を以下に示します。
ace-trl-error = {
0: int, ; error-id
? 1: uint / null ; cursor
}
* It MAY include further Standard Problem Detail entries or Custom Problem Detail entries (see [RFC9290]).
* さらに標準の問題の詳細エントリまたはカスタム問題の詳細エントリが含まれる場合があります（[RFC9290]を参照）。
In particular, it can include the Standard Problem Detail entry 'detail' (map key -2), whose value is a CBOR text string that specifies a human-readable diagnostic description of the error that occurred at the AS. The diagnostic text is intended for software engineers as well as for device and network operators in order to aid in debugging and provide context for possible intervention. The diagnostic message SHOULD be logged by the AS. The 'detail' entry is unlikely to be relevant in an unattended setup where human intervention is not expected.
特に、標準の問題の詳細エントリ「詳細」（マップキー-2）を含めることができます。その値は、ASで発生したエラーの人間が読み取る診断説明を指定するCBORテキスト文字列です。診断テキストは、デバッグを支援し、介入の可能性のコンテキストを提供するために、ソフトウェアエンジニアとデバイスおよびネットワークオペレーターを対象としています。診断メッセージはASによって記録する必要があります。「詳細」エントリは、人間の介入が予想されない無人設定に関連する可能性は低いです。
An example of an error response using the problem-details format is shown in Figure 5.
問題からの問題形式を使用したエラー応答の例を図5に示します。
Header: Bad Request (Code=4.00)
Content-Format: 257 (application/concise-problem-details+cbor)
Payload:
{
/ title / -1: "Invalid parameter value",
/ detail / -2: "Invalid value for 'cursor': -53",
/ ace-trl-error / 1: {
/ error-id / 0: 0 / "Invalid parameter value" /,
/ cursor / 1: 42
}
}
Figure 5: Example of Error Response with Problem Details
図5：問題の詳細を含むエラー応答の例
The problem-details format in general and the Custom Problem Detail entry 'ace-trl-error' in particular are OPTIONAL to support for registered devices. A registered device supporting the entry 'ace-trl-error' and that is able to understand the specified error may use that information to determine what actions to take next.
一般的には問題から控えめな形式と、特にカスタム問題の詳細エントリ「Ace-Trl-error」は、登録されたデバイスをサポートするためにオプションです。エントリ「Ace-Trl-error」をサポートする登録デバイスであり、指定されたエラーがその情報を使用して、次に実行するアクションを決定することができます。
If the AS supports diff queries, it is able to transfer a list of diff entries, each of which is related to one update that occurred to the TRL (see Section 6). That is, when replying to a diff query performed for a requester, the AS provides the diff entries related to the most recent TRL updates pertaining to the requester.
ASがDIFFクエリをサポートする場合、DIFFエントリのリストを転送できます。各エントリは、TRLに発生した1つの更新に関連しています（セクション6を参照）。つまり、要求者に対して実行されたDIFFクエリに返信するとき、ASはリクエスターに関連する最新のTRLアップデートに関連する差分エントリを提供します。
The following defines how the AS builds and maintains an ordered list of diff entries, for each registered device and administrator, hereafter referred to as "requesters". In particular, a requester's diff entry associated with a TRL update contains a set of token hashes pertaining to that requester, each of which was added to the TRL or removed from the TRL at that update.
以下は、登録されたデバイスと管理者ごとに、「リクエスター」と呼ばれる各デバイスおよび管理者の順序付けされたリストをどのように構築および維持するかを定義します。特に、TRLアップデートに関連付けられたリクエスターのDIFFエントリには、その要求者に関連するトークンハッシュのセットが含まれており、それぞれがTRLに追加されるか、そのアップデートでTRLから削除されました。
The AS defines the single constant positive integer MAX_N >= 1. For each requester, the AS maintains an update collection of maximum MAX_N series items, each of which is a diff entry. For each requester, the AS MUST keep track of the MAX_N most recent TRL updates pertaining to the requester. If the AS supports diff queries, the AS MUST provide requesters with the value of MAX_N upon their registration (see Section 10).
ASは、単一の一定の正の整数MAX_N> = 1を定義します。各要求者について、ASは最大MAX_Nシリーズアイテムの更新コレクションを維持します。各要求者について、ASは、リクエスターに関連する最新のTRLアップデートをMAX_N更新を追跡する必要があります。ASがDIFFクエリをサポートする場合、ASは登録時にMAX_Nの値を要求者に提供する必要があります（セクション10を参照）。
The series of items in the update collection MUST be strictly chronologically ordered. That is, at any point in time, the first series item is the one least recently added to the update collection and still retained by the AS; the last series item is the one most recently added to the update collection. The particular method used to achieve this is implementation specific.
アップデートコレクションの一連のアイテムは、厳密に時系列に注文する必要があります。つまり、いつでも最初のシリーズアイテムは、更新コレクションに最近追加されたものであり、ASによって保持されています。最後のシリーズアイテムは、最近アップデートコレクションに追加されたものです。これを達成するために使用される特定の方法は、実装固有です。
Each time the TRL changes, the AS performs the following operations for each requester:
TRLが変更されるたびに、ASは各要求者に対して次の操作を実行します。
1. The AS considers the subset of the TRL pertaining to that requester. If the TRL subset is not affected by this TRL update, the AS stops the processing for that requester. Otherwise, the AS moves to Step 2.
1. ASは、その要求者に関連するTRLのサブセットを考慮します。TRLサブセットがこのTRLアップデートの影響を受けない場合、ASはその要求者の処理を停止します。それ以外の場合、ASはステップ2に移動します。
2. The AS creates two trl_patch sets of token hashes, i.e., one 'removed' set and one 'added' set, as related to this TRL update.
2. ASは、このTRLアップデートに関連する2つのTRL_PATCHセットのトークンハッシュ、つまり「削除」セットと1つの「追加」セットを作成します。
3. The AS fills the two sets with the token hashes of the removed and added access tokens, respectively, from/to the TRL subset considered at Step 1.
3. ASは、ステップ1で検討されたTRLサブセットから、それぞれ削除および追加されたアクセストークンのトークンハッシュをそれぞれ埋めます。
4. The AS creates a new series item that includes the two sets from Step 3.
4. ASは、ステップ3の2つのセットを含む新しいシリーズアイテムを作成します。
5. If the update collection associated with the requester currently includes MAX_N series items, the AS MUST delete the oldest series item in the update collection.
5. リクエスターに関連付けられた更新コレクションに現在MAX_Nシリーズアイテムが含まれている場合、ASはアップデートコレクションで最も古いシリーズアイテムを削除する必要があります。
6. The AS adds the series item to the update collection associated with the requester as the last (most recent) series item.
6. ASは、最後の（最新の）シリーズアイテムとしてリクエスターに関連付けられた更新コレクションにシリーズアイテムを追加します。
If it supports the "Cursor" extension for diff queries, the AS also performs the following actions:
DIFFクエリの「カーソル」拡張機能をサポートする場合、ASは次のアクションも実行します。
The AS defines the single constant unsigned integer MAX_INDEX <= ((2^64) - 1). The value of MAX_INDEX is REQUIRED to be at least (MAX_N - 1) and is RECOMMENDED to be at least ((2^32) - 1). MAX_INDEX SHOULD be orders of magnitude greater than MAX_N.
ASは、単一の定数符号なし整数max_index <=（（2^64）-1）を定義します。max_indexの値は少なくとも（max_n -1）が必要であり、少なくとも（（2^32）-1）になることをお勧めします。max_indexは、max_nよりも桁違いに大きくする必要があります。
The following applies separately for each requester's update collection:
以下は、各リクエスターの更新コレクションに個別に適用されます。
* Each series item X in the update collection is also associated with an unsigned integer 'index', whose minimum value is 0 and whose maximum value is MAX_INDEX. The first series item ever added to the update collection MUST have an 'index' with a value of 0.
* アップデートコレクションの各シリーズアイテムXは、最小値が0であり、最大値がmax_indexである未署名の整数「インデックス」にも関連付けられています。更新コレクションに追加された最初のシリーズアイテムには、値が0の「インデックス」が必要です。
If i_X is the value of 'index' associated with a series item X, then the following series item Y will take 'index' with a value of i_Y = (i_X + 1) % (MAX_INDEX + 1). That is, after having added a series item whose associated 'index' has a value of MAX_INDEX, the next added series item will result in a wraparound of the 'index' value; thus, it will take an 'index' with a value of 0.
I_XがシリーズアイテムXに関連付けられた「インデックス」の値である場合、次のシリーズアイテムyは、i_y =（i_x + 1）％（max_index + 1）の値で「インデックス」を取ります。つまり、関連する「インデックス」がmax_indexの値を持っているシリーズアイテムを追加した後、次に追加されたシリーズアイテムは「インデックス」値のラップアラウンドになります。したがって、値は0の「インデックス」が必要です。
For example, assuming MAX_N = 3, the values of 'index' in the update collection chronologically evolve as follows, as new series items are added and old series items are deleted:
たとえば、MAX_N = 3を仮定すると、新しいシリーズアイテムが追加され、古いシリーズアイテムが削除されると、更新コレクションの「インデックス」の値が次のように時系列に進化します。
- ...
- ...
- (i_A = MAX_INDEX - 2, i_B = MAX_INDEX - 1, i_C = MAX_INDEX)
- （i_a = max_index -2、i_b = max_index -1、i_c = max_index）
- (i_B = MAX_INDEX - 1, i_C = MAX_INDEX, i_D = 0)
- （i_b = max_index -1、i_c = max_index、i_d = 0）
- (i_C = MAX_INDEX, i_D = 0, i_E = 1)
- （i_c = max_index、i_d = 0、i_e = 1）
- (i_D = 0, i_E = 1, i_F = 2)
- （i_d = 0、i_e = 1、i_f = 2）
- ...
- ...
* The unsigned integer 'last_index' is also defined, with minimum value 0 and maximum value MAX_INDEX.
* 符号なしの整数「last_index」も定義されており、最小値0と最大値max_indexです。
If the update collection is empty (i.e., no series items have been added yet), the value of 'last_index' is not defined. If the update collection is not empty, 'last_index' has the value of 'index' currently associated with the last series item in the update collection.
更新コレクションが空の場合（つまり、シリーズアイテムはまだ追加されていません）、「last_index」の値は定義されていません。更新コレクションが空でない場合、「last_index」には、更新コレクションの最後のシリーズアイテムに現在関連付けられている「インデックス」の値があります。
That is, after having added V series items to the update collection, the last and most recently added series item has an 'index' with a value of 'last_index' = (V - 1) % (MAX_INDEX + 1).
つまり、更新コレクションにVシリーズアイテムを追加した後、最後の最近で追加されたシリーズアイテムには、「last_index」=（v -1）％（max_index + 1）の値を持つ「インデックス」があります。
As long as a wraparound of the 'index' value has not occurred, the value of 'last_index' is the absolute counter of series items added to that update collection, minus 1.
「インデックス」値のラップアラウンドが発生していない限り、「last_index」の値は、その更新コレクションに追加されたシリーズアイテムの絶対的なカウンターであるマイナス1です。
When processing a diff query using the "Cursor" extension, the values of 'index' are used as cursor information, as defined in Section 9.2.
「カーソル」拡張機能を使用して差分クエリを処理する場合、セクション9.2で定義されているように、「インデックス」の値がカーソル情報として使用されます。
For each requester's update collection, the AS also defines a constant positive integer MAX_DIFF_BATCH <= MAX_N, whose value specifies the maximum number of diff entries to be included in a single diff query response. The specific value MAY depend on the specific registered device or administrator associated with the update collection in question. If supporting the "Cursor" extension, the AS MUST provide registered devices and administrators with the corresponding value of MAX_DIFF_BATCH upon their registration (see Section 10).
各リクエスターの更新コレクションについて、ASは一定の正の整数max_diff_batch <= max_nも定義します。特定の値は、問題の更新コレクションに関連付けられている特定の登録デバイスまたは管理者に依存する場合があります。「カーソル」拡張機能をサポートする場合、ASは登録されたデバイスと管理者に登録時にMAX_DIFF_BATCHの対応する値を提供する必要があります（セクション10を参照）。
A GET request to the TRL endpoint can include the following query parameters. The AS MUST silently ignore unknown query parameters.
TRLエンドポイントへの取得要求には、次のクエリパラメーターを含めることができます。ASは、不明なクエリパラメーターを静かに無視する必要があります。
* 'diff': if included, it asks the AS to perform a diff query of the TRL (see Section 8). Its value MUST be either:
* 「Diff」：含まれている場合、TRLのdiffクエリを実行するように尋ねます（セクション8を参照）。その価値は次のとおりでなければなりません：
- the integer 0, indicating that a (notification) response should include as many diff entries as the AS can provide in the response; or
- 整数0は、（通知）応答が、応答で提供できるように多くの差分エントリを含める必要があることを示しています。または
- a positive integer strictly greater than 0, indicating the maximum number of diff entries that a (notification) response should include.
- 厳密に0より大きい正の整数は、（通知）応答が含める必要がある差分エントリの最大数を示しています。
If the AS does not support diff queries, it ignores the 'diff' query parameter when present in the GET request and proceeds like when performing a full query of the TRL (see Section 7).
ASがDIFFクエリをサポートしていない場合、GETリクエストに存在するときに「DIFF」クエリパラメーターを無視し、TRLの完全なクエリを実行するときのように進行します（セクション7を参照）。
Otherwise, the AS MUST return a 4.00 (Bad Request) response in case the 'diff' query parameter of the GET request has a value that is neither 0 nor a positive integer, irrespective of the presence of the 'cursor' query parameter and its value (see below). The response MUST have Content-Format set to "application/concise-problem-details+cbor", and its payload is formatted as defined in Section 6.1. Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field MUST be set to 0 ("Invalid parameter value"), and the 'cursor' field MUST NOT be present.
それ以外の場合、ASは、「カーソル」クエリパラメーターの存在とその値の存在に関係なく、GETリクエストの「DIFF」クエリパラメーターに0または正の整数でもない値がある場合に、4.00（悪い要求）応答を返す必要があります（以下を参照）。応答には、コンテンツフォーマットが「アプリケーション/簡潔な問題」に設定されている必要があります。そのペイロードは、セクション6.1で定義されているようにフォーマットされています。カスタム問題の詳細エントリ「ACE-TRL-ERROR」内で、「エラーID」フィールドの値を0（「無効なパラメーター値」）に設定する必要があり、「カーソル」フィールドが存在してはなりません。
* 'cursor': if included, it asks the AS to perform a diff query of the TRL together with the "Cursor" extension, as defined in Section 9.2. Its value MUST be either 0 or a positive integer. If the 'cursor' query parameter is included, then the 'diff' query parameter MUST also be included.
* 「カーソル」：含まれている場合、セクション9.2で定義されているように、「カーソル」拡張機能とともにTRLの差分クエリを実行するように求められます。その値は0または正の整数でなければなりません。「カーソル」クエリパラメーターが含まれている場合、「diff」クエリパラメーターも含める必要があります。
If included, the 'cursor' query parameter has an unsigned integer value that was provided by the AS in a previous response from the TRL endpoint (see Sections 9.1, 9.2.2, and 9.2.3).
含まれている場合、「カーソル」クエリパラメーターには、TRLエンドポイントからの以前の応答のように提供された署名されていない整数値があります（セクション9.1、9.2.2、および9.2.3を参照）。
If the AS does not support the "Cursor" extension, it ignores the 'cursor' query parameter when present in the GET request. In such a case, the AS proceeds as specified elsewhere in this document, that is:
ASが「カーソル」拡張機能をサポートしていない場合、GETリクエストに存在するときに「カーソル」クエリパラメーターを無視します。そのような場合、このドキュメントの他の場所で指定されているように進行するもの、つまり：
1. it performs a diff query of the TRL (see Section 8), if it supports diff queries and the 'diff' query parameter is present in the GET request; otherwise,
1. diffクエリをサポートし、「diff」クエリパラメーターがgetリクエストに存在する場合、trlのdiffクエリ（セクション8を参照）を実行します。さもないと、
2. it performs a full query of the TRL (see Section 7).
2. TRLの完全なクエリを実行します（セクション7を参照）。
If the AS supports both diff queries and the "Cursor" extension, and the GET request includes the 'cursor' query parameter, then the AS MUST return a 4.00 (Bad Request) response in case any of the conditions below holds.
ASがDIFFクエリと「カーソル」拡張機能の両方をサポートし、GETリクエストに「カーソル」クエリパラメーターが含まれている場合、ASは以下の条件のいずれかが保持された場合に4.00（悪い要求）応答を返す必要があります。
The 4.00 (Bad Request) response MUST have Content-Format set to "application/concise-problem-details+cbor", and its payload is formatted as defined in Section 6.1.
4.00（悪い要求）応答には、コンテンツフォーマットが「アプリケーション/簡潔な問題」に設定されている必要があります。
- The GET request does not include the 'diff' query parameter, irrespective of the value of the 'cursor' query parameter.
- GETリクエストには、「カーソル」クエリパラメーターの値に関係なく、「diff」クエリパラメーターは含まれません。
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field MUST be set to 1 ("Invalid set of parameters"), and the 'cursor' field MUST NOT be present.
カスタム問題の詳細エントリ「ACE-TRL-ERROR」内で、「エラーID」フィールドの値は1（「無効なパラメーターセット」）に設定する必要があり、「カーソル」フィールドを存在してはなりません。
- The 'cursor' query parameter has a value that is neither 0 nor a positive integer; or it has a value strictly greater than MAX_INDEX (see Section 6.2.1).
- 「カーソル」クエリパラメーターには、0でも正の整数でもない値があります。または、MAX_INDEXよりも厳密に大きい値があります（セクション6.2.1を参照）。
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field MUST be set to 0 ("Invalid parameter value"). The entry 'ace-trl-error' MUST include the 'cursor' field, whose value is either:
カスタム問題の詳細エントリ「ACE-TRL-ERROR」内で、「エラーID」フィールドの値を0（「無効なパラメーター値」）に設定する必要があります。エントリ「Ace-Trl-Error」には、「カーソル」フィールドを含める必要があります。
o the CBOR simple value null (0xf6), if the update collection associated with the requester is empty; or, otherwise
o リクエスターに関連付けられた更新コレクションが空の場合、CBOR Simple Value Null（0xf6）。または、そうでなければ
o the corresponding current value of 'last_index'.
o 「last_index」の対応する電流値。
- All of the following hold: the update collection associated with the requester is not empty; no wraparound of the 'index' value has occurred; and the 'cursor' query parameter has a value strictly greater than the current 'last_index' on the update collection (see Section 6.2.1).
- 次のすべてのホールド：要求者に関連付けられた更新コレクションは空ではありません。「インデックス」値のラップアラウンドは発生していません。また、「カーソル」クエリパラメーターには、更新コレクションの現在の「last_index」よりも厳密に大きい値があります（セクション6.2.1を参照）。
Within the Custom Problem Detail entry 'ace-trl-error', the value of the 'error-id' field MUST be set to 2 ("Out of bound cursor value"), and the 'cursor' field MUST NOT be present.
カスタム問題の詳細エントリ「ACE-TRL-ERROR」内で、「エラーID」フィールドの値は2（「バインドされたカーソル値からの範囲外」）に設定する必要があり、「カーソル」フィールドを存在してはなりません。
In order to produce a (notification) response to a GET request asking for a full query of the TRL, the AS performs the following actions:
TRLの完全なクエリを要求するGETリクエストに対する（通知）応答を作成するために、ASは次のアクションを実行します。
1. From the TRL, the AS builds a HASHES set such that:
1. TRLから、ASは次のようなハッシュセットを構築します。
* If the requester is a registered device, HASHES specifies the token hashes currently in the TRL and associated with the access tokens pertaining to that registered device. The AS can always use the authenticated identity of the registered device to perform the necessary filtering on the TRL content.
* 要求者が登録されたデバイスである場合、ハッシュは現在TRLにあるトークンハッシュを指定し、その登録されたデバイスに関連するアクセストークンに関連付けられています。ASは、登録されたデバイスの認証されたアイデンティティを常に使用して、TRLコンテンツで必要なフィルタリングを実行できます。
* If the requester is an administrator, HASHES specifies all the token hashes currently in the TRL.
* 要求者が管理者である場合、ハッシュは現在TRLにあるすべてのトークンハッシュを指定します。
2. The AS sends a 2.05 (Content) response to the requester. The response MUST have Content-Format set to "application/ace-trl+cbor". The payload of the response is a CBOR map, which MUST be formatted as follows.
2. ASは、リクエスターに2.05（コンテンツ）応答を送信します。応答には、コンテンツフォーマットが「アプリケーション/ACE-TRL+CBOR」に設定されている必要があります。応答のペイロードはCBORマップであり、次のようにフォーマットする必要があります。
* The 'full_set' parameter MUST be included and MUST encode a CBOR array 'full_set_value'. Each element of 'full_set_value' is a CBOR byte string, whose value is one of the token hashes from the HASHES set. If the HASHES set is empty, the 'full_set' parameter specifies the empty CBOR array.
* 「Full_set」パラメーターを含める必要があり、CBORアレイ「FULL_SET_VALUE」をエンコードする必要があります。「Full_set_Value」の各要素はCBORバイト文字列であり、その値はハッシュセットからのトークンハッシュの1つです。ハッシュセットが空の場合、「Full_set」パラメーターは空のCBORアレイを指定します。
The CBOR array MUST be treated as a set, i.e., the order of its elements has no meaning.
CBORアレイはセットとして扱う必要があります。つまり、その要素の順序には意味がありません。
* The 'cursor' parameter MUST be included if the AS supports both diff queries and the related "Cursor" extension (see Sections 6.2 and 6.2.1). Its value is set as specified in Section 9.1 and provides the requester with information for sending a new request that asks the AS to perform a follow-up diff query using the "Cursor" extension (see Section 9.2).
* ASがDIFFクエリと関連する「カーソル」拡張機能の両方をサポートする場合、「カーソル」パラメーターを含める必要があります（セクション6.2および6.2.1を参照）。その値は、セクション9.1で指定されているとおりに設定され、「カーソル」拡張子を使用してフォローアップDIFFクエリを実行するように依頼する新しいリクエストを送信するための情報を要求者に提供します（セクション9.2を参照）。
If the AS does not support both diff queries and the "Cursor" extension, this parameter MUST NOT be included. In case the requester does not support both diff queries and the "Cursor" extension, it MUST silently ignore the 'cursor' parameter if present.
ASがDIFFクエリと「カーソル」拡張機能の両方をサポートしていない場合、このパラメーターを含めてはなりません。要求者がDIFFクエリと「カーソル」拡張機能の両方をサポートしていない場合、存在する場合は「カーソル」パラメーターを静かに無視する必要があります。
Figure 6 provides the CDDL definition [RFC8610] of the CBOR array 'full_set_value' specified in the response from the AS as the value of the 'full_set' parameter.
図6は、「FULL_SET 'パラメーターの値としてAS ASの応答で指定されたCBORアレイ「FULL_SET_VALUE」のCDDL定義[RFC8610]を示しています。
token_hash = bytes
full_set_value = [* token_hash]
Figure 6: CDDL Definition of 'full_set_value'
図6：「full_set_value」のCDDL定義
Figure 7 shows an example of a response from the AS following a full query request to the TRL endpoint. In this example, the AS does not support diff queries nor the "Cursor" extension; hence the 'cursor' parameter is not included in the payload of the response. Also, full token hashes are omitted for brevity.
図7は、TRLエンドポイントへの完全なクエリリクエストに続くASからの応答の例を示しています。この例では、ASはdiffクエリや「カーソル」拡張機能をサポートしていません。したがって、「カーソル」パラメーターは、応答のペイロードに含まれていません。また、簡潔にするために、完全なトークンのハッシュは省略されています。
Header: Content (Code=2.05)
Content-Format: 262 (application/ace-trl+cbor)
Payload:
{
/ full_set / 0: [
h'01fa51cc...4819', / elided for brevity /
h'01748190...223d' / elided for brevity /
]
}
Figure 7: Example of a Response Following a Full Query Request to the TRL Endpoint
図7：TRLエンドポイントへの完全なクエリ要求に続く応答の例
In order to produce a (notification) response to a GET request asking for a diff query of the TRL, the AS performs the following actions:
TRLの差分クエリを要求するGETリクエストに対する（通知）応答を作成するために、ASは次のアクションを実行します。
Note that, if the AS supports both diff queries and the related "Cursor" extension, Steps 3 and 4 defined below are extended as defined in Section 9.2.
ASがDIFFクエリと関連する「カーソル」拡張機能の両方をサポートする場合、以下に定義する手順3と4はセクション9.2で定義されているように拡張されていることに注意してください。
1. The AS defines the positive integer NUM as follows: if the value N specified in the 'diff' query parameter in the GET request is equal to 0 or greater than the predefined positive integer MAX_N (see Section 6.2), then NUM takes the value of MAX_N. Otherwise, NUM takes N.
1. asは、正の整数numを次のように定義します。GETリクエストの「diff」queryパラメーターで指定された値nが事前定義された正の整数max_nよりも0以下に等しい場合（セクション6.2を参照）、numはmax_nの値を取得します。それ以外の場合、numはnを取ります。
2. The AS determines U = min(NUM, SIZE), where SIZE <= MAX_N. In particular, SIZE is the number of diff entries currently stored in the requester's update collection.
2. asはu = min（num、size）を決定します。ここで、サイズ<= max_n。特に、サイズとは、Requesterの更新コレクションに現在保存されているDiffエントリの数です。
3. The AS prepares U diff entries. If U is equal to 0 (e.g., because SIZE is equal to 0 at Step 2), then no diff entries are prepared.
3. ASはu diffエントリを準備します。Uが0に等しい場合（たとえば、ステップ2でサイズが0に等しいため）、diffエントリは準備されていません。
The prepared diff entries are related to the U most recent TRL updates pertaining to the requester, as maintained in the update collection for that requester (see Section 6.2). In particular, the first diff entry refers to the most recent of such updates, the second diff entry refers to the second-to-last of such updates, and so on.
準備されたdiffエントリは、その要求者の更新コレクションで維持されているように、リクエスターに関連する最新のTRLアップデートに関連しています（セクション6.2を参照）。特に、最初のDIFFエントリは、このような更新の最新のエントリを指し、2番目のDIFFエントリは、このような更新の2番目から2番目の更新などを指します。
Each diff entry is a CBOR array 'diff_entry', which includes the following two elements:
各diffエントリは、次の2つの要素を含むcbor配列「diff_entry」です。
a. A trl_patch set of token hashes encoded as a CBOR array 'removed'. Each element of the array is a CBOR byte string, whose value is the token hash of an access token such that it pertains to the requester and was removed from the TRL during the update associated with the diff entry.
a. CBORアレイ「削除」としてエンコードされたトークンハッシュのTRL_PATCHセット。配列の各要素はCBORバイト文字列であり、その値はリクエスト担当者に関係するようにアクセストークンのトークンハッシュであり、DIFFエントリに関連付けられた更新中にTRLから削除されました。
b. A trl_patch set of token hashes encoded as a CBOR array 'added'. Each element of the array is a CBOR byte string, whose value is the token hash of an access token such that it pertains to the requester and was added to the TRL during the update associated with the diff entry.
b. CBORアレイ「追加」としてエンコードされたトークンハッシュのTRL_PATCHセット。配列の各要素はCBORバイト文字列であり、その値はアクセストークンのトークンハッシュであり、要求者に関係し、DIFFエントリに関連付けられた更新中にTRLに追加されました。
The CBOR arrays 'removed' and 'added' MUST be treated as sets, i.e., the order of their elements has no meaning.
CBORアレイは「削除」および「追加」をセットとして扱う必要があります。つまり、その要素の順序には意味がありません。
4. The AS prepares a 2.05 (Content) response for the requester. The response MUST have Content-Format set to "application/ace-trl+cbor". The payload of the response is a CBOR map, which MUST be formatted as follows:
4. ASは、要求者の2.05（コンテンツ）応答を準備します。応答には、コンテンツフォーマットが「アプリケーション/ACE-TRL+CBOR」に設定されている必要があります。応答のペイロードはCBORマップであり、次のようにフォーマットする必要があります。
* The 'diff_set' parameter MUST be present and MUST encode a CBOR array 'diff_set_value' of U elements. Each element of 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' prepared above as a diff entry. Note that U might have a value of 0; in this case, 'diff_set_value' is the empty CBOR array.
* 「diff_set」パラメーターが存在する必要があり、u要素のcbor配列「diff_set_value」をエンコードする必要があります。「diff_set_value」の各要素は、上記のdiffエントリとして作成されたcborアレイの1つを指定します。Uは0の値を持っている可能性があることに注意してください。この場合、「diff_set_value」は空のcborアレイです。
Within 'diff_set_value', the 'diff_entry' CBOR arrays MUST be sorted to reflect the corresponding updates to the TRL in reverse chronological order. That is, the first 'diff_entry' element of 'diff_set_value' relates to the most recent TRL update pertaining to the requester. The second 'diff_entry' element relates to the second-to-last most recent TRL update pertaining to the requester, and so on.
「diff_set_value」内で、「diff_entry」cborアレイを並べ替える必要があります。つまり、「diff_set_value」の最初の「diff_entry」要素は、要求者に関する最新のTRLアップデートに関連しています。2番目の「diff_entry」要素は、リクエスターに関連する最新のTRLアップデートなどに関連しています。
* The 'cursor' parameter and the 'more' parameter MUST be included if the AS supports both diff queries and the related "Cursor" extension (see Section 6.2.1). Their values are set as specified in Section 9.2 and provide the requester with information for sending a new request that asks the AS to perform a follow-up query of the TRL (see Section 9.2).
* ASがDIFFクエリと関連する「カーソル」拡張機能の両方をサポートする場合、「カーソル」パラメーターと「その他」パラメーターを含める必要があります（セクション6.2.1を参照）。それらの値は、セクション9.2で指定されているように設定されており、TRLのフォローアップクエリを実行するように尋ねる新しいリクエストを送信するための情報を要求者に提供します（セクション9.2を参照）。
In case the AS supports diff queries but not the "Cursor" extension, these parameters MUST NOT be included. In case the requester supports diff queries but not the "Cursor" extension, the requester MUST silently ignore the 'cursor' parameter and the 'more' parameter, if present.
ASが「カーソル」拡張機能ではなくdiffクエリをサポートしている場合、これらのパラメーターを含める必要はありません。要求者が「カーソル」拡張機能ではなくdiffクエリをサポートしている場合、リクエスタは「カーソル」パラメーターと存在する場合は「より多く」パラメーターを静かに無視する必要があります。
Figure 8 provides the CDDL definition [RFC8610] of the CBOR array 'diff_set_value' specified in the response from the AS, as the value of the 'diff_set' parameter.
図8は、 'diff_set'パラメーターの値としてASからの応答で指定されたCBORアレイ「diff_set_value」のCDDL定義[RFC8610]を示しています。
token_hash = bytes
trl_patch = [* token_hash]
diff_entry = [removed: trl_patch, added: trl_patch]
diff_set_value = [* diff_entry]
Figure 8: CDDL Definition of 'diff_set_value'
図8：「diff_set_value」のCDDL定義
Figure 9 shows an example of a response from the AS following a diff query request to the TRL endpoint, where U = 3 diff entries are included. In this example, the AS does not support the "Cursor" extension; hence, the 'cursor' parameter and the 'more' parameter are not included in the payload of the response. Also, full token hashes are omitted for brevity.
図9は、u = 3 diffエントリが含まれているTRLエンドポイントへのdiffクエリ要求に続いて、ASからの応答の例を示しています。この例では、ASは「カーソル」拡張機能をサポートしていません。したがって、「カーソル」パラメーターと「その他」パラメーターは、応答のペイロードに含まれていません。また、簡潔にするために、完全なトークンのハッシュは省略されています。
Header: Content (Code=2.05)
Content-Format: 262 (application/ace-trl+cbor)
Payload:
{
/ diff_set / 1: [
[
[ h'01fa51cc...0f6a', / elided for brevity /
h'01748190...8bce' / elided for brevity /
],
[ h'01cdf1ca...563d', / elided for brevity /
h'01be41a6...a057' / elided for brevity /
]
],
[
[ h'0144dd12...77bc', / elided for brevity /
h'01231fff...a2ce' / elided for brevity /
],
[]
],
[
[],
[ h'01ca986f...ffc1', / elided for brevity /
h'01fe1a2b...def0' / elided for brevity /
]
]
]
}
Figure 9: Example of Response Following a Diff Query Request to the TRL Endpoint
図9：TRLエンドポイントへの差分クエリ要求に続く応答の例
Appendix A discusses how performing a diff query of the TRL is, in fact, a usage example of the Series Transfer Pattern defined in [STP].
付録Aでは、TRLの差分クエリを実行することが、実際には[STP]で定義されたシリーズ転送パターンの使用例である方法について説明します。
If the AS supports both diff queries and the "Cursor" extension, it composes a response to a full query request or diff query request as defined in Sections 9.1 and 9.2, respectively.
ASがDIFFクエリと「カーソル」拡張機能の両方をサポートする場合、それぞれセクション9.1と9.2で定義されている完全なクエリ要求またはDIFFクエリ要求への応答を構成します。
The exact format of the response depends on:
応答の正確な形式は次のものに依存します。
* the request being a full query or diff query request,
* リクエストは完全なクエリまたはdiffクエリリクエストです。
* the presence of the 'diff' and 'cursor' query parameters and their values in the diff query request, and
* diffクエリ要求に「diff」と「カーソル」クエリパラメーターとその値の存在、および
* the current status of the update collection associated with the requester.
* リクエスターに関連付けられた更新コレクションの現在のステータス。
Error handling and the possible resulting error responses are as defined in Section 6.3.
エラー処理と結果として生じる可能性のあるエラー応答は、セクション6.3で定義されています。
When processing a full query request to the TRL endpoint, the AS composes a response as defined in Section 7.
TRLエンドポイントに完全なクエリ要求を処理する場合、ASはセクション7で定義されている応答を構成します。
In particular, the 'cursor' parameter included in the CBOR map carried in the response payload specifies either the CBOR simple value null (0xf6) or a CBOR unsigned integer.
特に、応答ペイロードに掲載されたCBORマップに含まれる「カーソル」パラメーターは、CBOR Simple Value Null（0xF6）またはCBOR Unsigned Integerのいずれかを指定します。
The 'cursor' parameter MUST encode the CBOR simple value null (0xf6) in case there are currently no TRL updates pertaining to the requester, i.e., the update collection for that requester is empty. This is the case from when the requester registers at the AS until the first update pertaining to that requester occurs to the TRL.
「カーソル」パラメーターは、現在リクエスターに関連するTRL更新がない場合、つまりそのリクエスターの更新コレクションが空である場合に、CBOR Simple Value Null（0xF6）をエンコードする必要があります。これは、要求者がその要求者に関連する最初の更新がTRLに発生するまで、ASでリクエスターが登録されるときからの場合です。
Otherwise, the 'cursor' parameter MUST encode a CBOR unsigned integer. The unsigned integer MUST take the 'index' value of the last series item in the update collection associated with the requester (see Section 6.2.1) as corresponding to the most recent TRL update pertaining to the requester. In fact, such a value is the current value of 'last_index' for the update collection associated with the requester.
それ以外の場合、「カーソル」パラメーターは、CBORの符号なし整数をエンコードする必要があります。署名されていない整数は、リクエスターに関連する最新のTRLアップデートに対応する要求者に関連付けられた更新コレクションの最後のシリーズアイテムの「インデックス」値を取得する必要があります。実際、そのような値は、リクエスターに関連付けられた更新コレクションの「last_index」の現在の値です。
When processing a diff query request to the TRL endpoint, the AS composes a response as defined in the following subsections.
DIFFクエリ要求をTRLエンドポイントに処理する場合、ASは次のサブセクションで定義されているように応答を構成します。
If the update collection associated with the requester has no elements, the AS returns a 2.05 (Content) response. The response MUST have Content-Format set to "application/ace-trl+cbor", and its payload MUST be a CBOR map formatted as follows:
要求者に関連付けられた更新コレクションに要素がない場合、ASは2.05（コンテンツ）応答を返します。応答には、コンテンツフォーマットが「アプリケーション/ACE-TRL+CBOR」に設定されている必要があり、そのペイロードは次のようにフォーマットされているCBORマップでなければなりません。
* The 'diff_set' parameter MUST be included and MUST encode the empty CBOR array.
* 「diff_set」パラメーターを含める必要があり、空のCBORアレイをエンコードする必要があります。
* The 'cursor' parameter MUST be included and MUST encode the CBOR simple value null (0xf6).
* 「カーソル」パラメーターを含める必要があり、CBOR Simple Value Null（0xF6）をエンコードする必要があります。
* The 'more' parameter MUST be included and MUST encode the CBOR simple value false (0xf4).
* 「more」パラメーターを含める必要があり、CBOR Simple Value False（0xf4）をエンコードする必要があります。
Note that the above applies when the update collection associated with the requester has no elements, regardless of whether or not the 'cursor' query parameter is included in the diff query request and irrespective of the specified unsigned integer value if present.
「カーソル」クエリパラメーターがDIFFクエリ要求に含まれているかどうかに関係なく、存在する場合は指定されていない整数整数値に関係なく、リクエスターに関連付けられた更新コレクションに要素がない場合、上記が適用されることに注意してください。
If the update collection associated with the requester is not empty and the diff query request does not include the 'cursor' query parameter, the AS performs the actions defined in Section 8, with the following differences:
リクエスターに関連付けられた更新コレクションが空でなく、diff query requestに「カーソル」クエリパラメーターが含まれていない場合、ASはセクション8で定義されているアクションを実行し、次の違いがあります。
* At Step 3, the AS considers the value MAX_DIFF_BATCH (see Section 6.2.1) and prepares L = min(U, MAX_DIFF_BATCH) diff entries.
* ステップ3では、ASは値max_diff_batch（セクション6.2.1を参照）を考慮し、l = min（u、max_diff_batch）diffエントリを準備します。
If U <= MAX_DIFF_BATCH, the prepared diff entries are the last series items in the update collection associated with the requester, corresponding to the L most recent TRL updates pertaining to the requester.
u <= max_diff_batchの場合、準備されたdiffエントリは、リクエスターに関連する更新コレクションの最後のシリーズアイテムであり、リクエスターに関連する最新のTRLアップデートに対応しています。
If U > MAX_DIFF_BATCH, the prepared diff entries are the eldest of the last U series items in the update collection associated with the requester, as corresponding to the first L of the U most recent TRL updates pertaining to the requester.
u> max_diff_batchの場合、準備されたdiffエントリは、要求者に関連するuの最新のTRLアップデートの最初のlに対応するように、リクエスターに関連付けられた更新コレクションの最後のuシリーズアイテムの中で最も長いものです。
* At Step 4, the CBOR map to carry in the payload of the 2.05 (Content) response MUST be formatted as follows:
* ステップ4では、2.05（コンテンツ）応答のペイロードを持ち込むためのCBORマップを次のようにフォーマットする必要があります。
- The 'diff_set' parameter MUST be present and MUST encode a CBOR array 'diff_set_value' of L elements. Each element of 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff entry.
- 「diff_set」パラメーターが存在する必要があり、l要素のcbor配列「diff_set_value」をエンコードする必要があります。「diff_set_value」の各要素は、diffエントリとして作成されたcborアレイの1つのdiff_entry 'を指定します。
- The 'cursor' parameter MUST be present and MUST encode a CBOR unsigned integer. The unsigned integer MUST take the 'index' value of the series item of the update collection included as first diff entry in the 'diff_set_value' CBOR array, which is specified by the 'diff_set' parameter. That is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the requester and returned in this diff query response.
- 「カーソル」パラメーターが存在する必要があり、CBOR unsigned Integerをエンコードする必要があります。Unsigned Integerは、「diff_set_value」cborアレイの最初のdiffエントリとして含まれる更新コレクションのシリーズアイテムの「インデックス」値を取得する必要があります。つまり、「カーソル」パラメーターは、リクエスターに関連する最新のTRLアップデートに対応し、このdiffクエリ応答で返される最新のTRLアップデートに対応するアップデートコレクションのシリーズアイテムの「インデックス」値を取得します。
Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when U <= MAX_DIFF_BATCH.
u <= max_diff_batchの場合、「カーソル」パラメーターは、更新コレクションの最後のシリーズアイテムの同じ「インデックス」値を取得することに注意してください。
- The 'more' parameter MUST be present. The parameter MUST encode the CBOR simple value false (0xf4) if U <= MAX_DIFF_BATCH; otherwise, it MUST encode the CBOR simple value true (0xf5).
- 「もっと」パラメーターが存在する必要があります。u <= max_diff_batch;の場合、パラメーターはcbor simple値false（0xf4）をエンコードする必要があります。それ以外の場合は、CBOR Simple Value True（0xF5）をエンコードする必要があります。
If the 'more' parameter in the payload of the received 2.05 (Content) response has a value of true, the requester can send a follow-up diff query request including the 'cursor' query parameter with the same value of the 'cursor' parameter specified in this diff query response. As defined in Section 9.2.3, this would result in the AS transferring the following subset of series items as diff entries, thus resuming from where interrupted in the previous transfer.
受信した2.05（コンテンツ）応答のペイロードの「詳細」パラメーターにTrueの値がある場合、要求者は、このDIFFクエリ応答で指定された「カーソル」パラメーターの同じ値を持つ「カーソル」クエリパラメーターを含むフォローアップDIFFクエリ要求を送信できます。セクション9.2.3で定義されているように、これにより、次のシリーズアイテムのサブセットをDIFFエントリとして転送するASが表示されるため、以前の転送で中断された場所から再開されます。
If the update collection associated with the requester is not empty and the diff query request includes the 'cursor' query parameter with value P, the AS proceeds as follows, depending on which of the following two cases hold:
リクエスターに関連付けられた更新コレクションが空でなく、diff query requestが値pを持つ「カーソル」クエリパラメーターを含む場合、次の2つのケースのどれに応じて、次のように進行します。
Case A: The series item X with 'index' having value P and the series item Y with 'index' having value (P + 1) % (MAX_INDEX + 1) are both not found in the update collection associated with the requester. This occurs when the item Y (and possibly further ones after it) has been previously removed from the update collection for that requester (see Step 5 at Section 6.2).
ケースA：値Pを持つ「インデックス」を備えたシリーズアイテムX、および値（P + 1）％（MAX_INDEX + 1）を持つ「インデックス」を持つシリーズアイテムYは、リクエスターに関連付けられた更新コレクションには見つかりません。これは、その要求者の更新コレクションから以前にY（およびおそらくさらにそれ以降のもの）が削除されたときに発生します（セクション6.2のステップ5を参照）。
In this case, the AS returns a 2.05 (Content) response. The response MUST have Content-Format set to "application/ace-trl+cbor", and its payload MUST be a CBOR map formatted as follows:
この場合、ASは2.05（コンテンツ）応答を返します。応答には、コンテンツフォーマットが「アプリケーション/ACE-TRL+CBOR」に設定されている必要があり、そのペイロードは次のようにフォーマットされているCBORマップでなければなりません。
* The 'diff_set' parameter MUST be included and MUST encode the empty CBOR array.
* 「diff_set」パラメーターを含める必要があり、空のCBORアレイをエンコードする必要があります。
* The 'cursor' parameter MUST be included and MUST encode the CBOR simple value null (0xf6).
* 「カーソル」パラメーターを含める必要があり、CBOR Simple Value Null（0xF6）をエンコードする必要があります。
* The 'more' parameter MUST be included and MUST encode the CBOR simple value true (0xf5).
* 「more」パラメーターを含める必要があり、CBOR Simple値True（0xf5）をエンコードする必要があります。
With the combination ('cursor', 'more') = (null, true), the AS is indicating that the update collection is, in fact, not empty, but that one or more series items have been lost due to their removal. These include the item with 'index' value (P + 1) % (MAX_INDEX + 1) that the requester wished to obtain as the first one following the specified reference point with 'index' value P.
組み合わせ（「カーソル」、「more」）=（null、true）で、アップデートコレクションは実際には空ではないことを示していますが、削除により1つ以上のシリーズアイテムが失われていることを示しています。これらには、「インデックス」値が「インデックス」値Pで指定された参照ポイントに従って最初のものとして取得したい「インデックス」値（P + 1）％（MAX_INDEX + 1）のアイテムが含まれます。
When receiving this diff query response, the requester SHOULD send a new full query request to the AS. A successful response provides the requester with the full current pertaining subset of the TRL as well as a valid value of the 'cursor' parameter (see Section 9.1) to be, possibly, used as query parameter in a following diff query request.
このdiffクエリ応答を受信するとき、リクエスターはASに新しい完全なクエリ要求を送信する必要があります。応答を成功させると、リクエクターは、TRLのサブセットを完全に含むサブセットと、「カーソル」パラメーターの有効な値（セクション9.1を参照）を提供します。
Case B: The series item X with 'index' having value P is found in the update collection associated with the requester, or instead the series item X is not found and the series item Y with 'index' having value (P + 1) % (MAX_INDEX + 1) is found in the update collection associated with the requester.
ケースB：値pを持つ「インデックス」を持つシリーズアイテムXは、リクエスターに関連付けられた更新コレクションにあります。代わりに、シリーズアイテムXが見つかりません。値（P + 1）％（MAX_INDEX + 1）を持つ「インデックス」のシリーズアイテムYは、リクエスターに関連付けられた更新コレクションにあります。
In this case, the AS performs the actions defined in Section 8 with the following differences:
この場合、ASは、セクション8で定義されたアクションを実行します。次の違いがあります。
* At Step 3, the AS considers the value MAX_DIFF_BATCH (see Section 6.2.1) and prepares L = min(SUB_U, MAX_DIFF_BATCH) diff entries, where SUB_U = min(NUM, SUB_SIZE) and SUB_SIZE is the number of series items in the update collection starting from and including the series item added immediately after X. If L is equal to 0 (e.g., because SUB_U is equal to 0), then no diff entries are prepared.
* ステップ3で、ASは値max_diff_batch（セクション6.2.1を参照）を考慮し、l = min（sub_u、max_diff_batch）diffエントリを準備します。エントリが準備されています。
If SUB_U <= MAX_DIFF_BATCH, the prepared diff entries are the last series items in the update collection associated with the requester, corresponding to the L most recent TRL updates pertaining to the requester.
sub_u <= max_diff_batchの場合、準備されたdiffエントリは、リクエスターに関連付けられた更新コレクションの最後のシリーズアイテムであり、リクエスターに関連する最新のTRLアップデートに対応しています。
If SUB_U > MAX_DIFF_BATCH, the prepared diff entries are the eldest of the last SUB_U series items in the update collection associated with the requester, corresponding to the first L of the SUB_U most recent TRL updates pertaining to the requester.
sub_u> max_diff_batchの場合、準備されたdiffエントリは、リクエスターに関連付けられた更新コレクションの最後のsub_uシリーズアイテムの中で最も長く、リクエスターに関連する最新のtrl更新の最初のlに対応します。
* At Step 4, the CBOR map to carry in the payload of the 2.05 (Content) response MUST be formatted as follows:
* ステップ4では、2.05（コンテンツ）応答のペイロードを持ち込むためのCBORマップを次のようにフォーマットする必要があります。
- The 'diff_set' parameter MUST be present and MUST encode a CBOR array 'diff_set_value' of L elements. Each element of 'diff_set_value' specifies one of the CBOR arrays 'diff_entry' prepared as a diff entry. Note that L might have value 0, in which case 'diff_set_value' is the empty CBOR array.
- 「diff_set」パラメーターが存在する必要があり、l要素のcbor配列「diff_set_value」をエンコードする必要があります。「diff_set_value」の各要素は、diffエントリとして作成されたcborアレイの1つのdiff_entry 'を指定します。lには値0がある場合があります。この場合、「diff_set_value」は空のcborアレイです。
- The 'cursor' parameter MUST be present and MUST encode a CBOR unsigned integer. In particular:
- 「カーソル」パラメーターが存在する必要があり、CBOR unsigned Integerをエンコードする必要があります。特に：
o If L is equal to 0, i.e., the series item X is the last one in the update collection, then the 'cursor' parameter MUST take the same 'index' value of the last series item in the update collection. In fact, such a value is the current value of 'last_index' for the update collection.
o Lが0に等しい場合、つまりシリーズアイテムXがアップデートコレクションの最後のものである場合、「カーソル」パラメーターは、更新コレクションの最後のシリーズアイテムの同じ「インデックス」値を取得する必要があります。実際、このような値は、更新コレクションの「last_index」の現在の値です。
o If L is different than 0, then the 'cursor' parameter MUST take the 'index' value of the series element of the update collection included as first diff entry in the 'diff_set' CBOR array. That is, the 'cursor' parameter takes the 'index' value of the series item in the update collection corresponding to the most recent TRL update pertaining to the requester and returned in this diff query response.
o Lが0と異なる場合、「カーソル」パラメーターは、「diff_set」cborアレイの最初のdiffエントリとして含まれる更新コレクションのシリーズ要素の「インデックス」値を取得する必要があります。つまり、「カーソル」パラメーターは、リクエスターに関連する最新のTRLアップデートに対応し、このdiffクエリ応答で返される最新のTRLアップデートに対応するアップデートコレクションのシリーズアイテムの「インデックス」値を取得します。
Note that the 'cursor' parameter takes the same 'index' value of the last series item in the update collection when SUB_U <= MAX_DIFF_BATCH.
sub_u <= max_diff_batchの場合、更新コレクションの最後のシリーズアイテムの「カーソル」パラメーターが同じ「インデックス」値を取得することに注意してください。
- The 'more' parameter MUST be present. The parameter MUST encode the CBOR simple value false (0xf4) if SUB_U <= MAX_DIFF_BATCH; otherwise, it MUST encode the CBOR simple value true (0xf5).
- 「もっと」パラメーターが存在する必要があります。パラメーターは、sub_u <= max_diff_batch;の場合、Cbor simple値false（0xf4）をエンコードする必要があります。それ以外の場合は、CBOR Simple Value True（0xF5）をエンコードする必要があります。
If the 'more' parameter in the payload of the received 2.05 (Content) response has value true, the requester can send a follow-up diff query request including the 'cursor' query parameter with the same value of the 'cursor' parameter specified in this diff query response. This would result in the AS transferring the following subset of series items as diff entries, thus resuming from where interrupted in the previous transfer.
受信した2.05（コンテンツ）応答のペイロードの「詳細」パラメーターが値が真である場合、リクエスタは、このDIFFクエリ応答で指定された「カーソル」パラメーターの同じ値を持つ「カーソル」クエリパラメーターを含むフォローアップDIFFクエリ要求を送信できます。これにより、次のシリーズアイテムのサブセットをDIFFエントリとして転送すると、以前の転送で中断された場所から再開されます。
During the registration process at the AS, an administrator or a registered device receives the following information as part of the registration response:
ASでの登録プロセス中に、管理者または登録デバイスが登録回答の一部として次の情報を受信します。
* The url-path to the TRL endpoint at the AS.
* ASのTRLエンドポイントへのURLパス。
* The hash function used to compute token hashes. This is specified by identifying an entry in the "Named Information Hash Algorithm Registry" [IANA.Hash.Algorithms]. The specific means for this is outside the scope of this document.
* ハッシュ関数は、トークンのハッシュを計算するために使用されます。これは、「名前付き情報ハッシュアルゴリズムレジストリ」[iana.hash.algorithms]のエントリを識別することによって指定されます。これに対する特定の手段は、このドキュメントの範囲外です。
* A positive integer MAX_N, if the AS supports diff queries of the TRL (see Sections 6.2 and 8).
* ASがTRLのdiffクエリをサポートする場合、正の整数max_n（セクション6.2および8を参照）。
* A positive integer MAX_DIFF_BATCH, if the AS supports diff queries of the TRL as well as the related "Cursor" extension (see Sections 6.2.1 and 9).
* ASがTRLのdiffクエリと関連する「カーソル」拡張機能をサポートする場合、正の整数max_diff_batch（セクション6.2.1および9を参照）。
Once the registration process is completed, the AS maintains the registration and related information until a possible deregistration occurs, hence keeping track of active administrators and registered devices. The particular way to achieve this is implementation specific. In any case, such a mechanism to maintain registrations is enforced at the AS in order to ensure that requests sent by clients to the /token endpoint (see Section 5.8 of [RFC9200]) and by RSs to the /introspect endpoint (see Section 5.9 of [RFC9200]) are processed as intended.
登録プロセスが完了すると、登録プロセスが完了すると、登録および関連情報が発生するまで登録情報と関連情報を維持するため、アクティブな管理者と登録デバイスを追跡します。これを達成するための特定の方法は、実装固有です。いずれにせよ、クライアントから /トークンのエンドポイント（[RFC9200]のセクション5.8を参照）にクライアントから送信されたリクエスト、および /内省的エンドポイント（[RFC9200]のセクション5.9を参照）に送信されるリクエストを確実に保証するために、登録を維持するためのこのようなメカニズムは、ASで実施されます。
When communicating with one another, the registered devices and the AS have to use a secure communication association and be mutually authenticated (see Section 5 of [RFC9200]).
互いに通信する場合、登録されたデバイスとASは安全な通信関連を使用し、相互に認証される必要があります（[RFC9200]のセクション5を参照）。
In the same spirit, communications between the AS and an administrator MUST be ensured to be mutually authenticated, encrypted, and integrity protected as well as protected against message replay.
同様に、ASとASと管理者の間のコミュニケーションは、メッセージリプレイから保護され、保護され、保護されていることを保証する必要があります。
Before starting its registration process at the AS, an administrator has to establish such a secure communication association with the AS, if they do not share one already. In particular, mutual authentication is REQUIRED during the establishment of the secure association. To this end, the administrator and the AS can rely, e.g., on establishing a TLS or DTLS secure session with mutual authentication (see [RFC8446] and [RFC9147]) or an Object Security for Constrained RESTful Environments (OSCORE) Security Context [RFC8613] by running the authenticated key exchange protocol EDHOC [RFC9528].
ASで登録プロセスを開始する前に、管理者はASとのこのような安全な通信関連を確立する必要があります。特に、安全な協会の設立中に相互認証が必要です。この目的のために、管理者とASは、たとえば、相互認証によるTLSまたはDTLSセキュアセッションの確立に依存することができます（[RFC8446]および[RFC9147]を参照）
When receiving authenticated requests from the administrator for accessing the TRL endpoint, the AS can always check whether the requester is authorized to take such a role, i.e., to access the content of the whole TRL.
TRLエンドポイントにアクセスするために管理者から認証されたリクエストを受信する場合、ASは、リクエスターがそのような役割を果たすことを許可されているかどうか、つまりTRL全体のコンテンツにアクセスすることを常に確認できます。
To this end, the AS may rely on a local access control list or similar, which specifies the authentication credentials of trusted, authorized administrators. In particular, the AS verifies the requester to the TRL endpoint as an authorized administrator only if the access control list includes the same authentication credential used by the requester when establishing the mutually authenticated secure communication association with the AS.
この目的のために、ASはローカルアクセス制御リストなどに依存する可能性があります。これは、信頼できる、認定管理者の認証資格情報を指定します。特に、ASは、ASとの相互に認証された安全な通信関連を確立する際に、アクセス制御リストにリクエスターが使用する同じ認証資格が含まれている場合にのみ、認定管理者としてTRLエンドポイントに要求者を検証します。
Further details about the registration process at the AS are out of scope for this specification. Note that the registration process is also out of the scope of the ACE framework (see Section 5.5 of [RFC9200]).
この仕様の範囲外であるASでの登録プロセスの詳細。登録プロセスもACEフレームワークの範囲外であることに注意してください（[RFC9200]のセクション5.5を参照）。
Once registered at the AS, the administrator or a registered device can send a GET request to the TRL endpoint at the AS. The request can express the wish for a full query (see Section 7) or a diff query (see Section 8) of the TRL. Also, the request can include the CoAP Observe Option set to 0 (register) in order to start an observation of the TRL endpoint as per Section 3.1 of [RFC7641].
ASに登録されると、管理者または登録デバイスはASのTRLエンドポイントにGETリクエストを送信できます。リクエストは、TRLの完全なクエリ（セクション7を参照）またはdiffクエリ（セクション8を参照）の希望を表すことができます。また、リクエストには、[RFC7641]のセクション3.1に従ってTRLエンドポイントの観測を開始するために、0（登録）に設定されたCOAP観測オプションを含めることができます。
In case the request is successfully processed, the AS replies with a 2.05 (Content) response. In particular, if the AS supports diff queries but not the "Cursor" extension (see Sections 6.2 and 6.2.1), then the payload of the response is formatted as defined in Sections 7 or 8, in case the GET request has yielded the execution of a full query or of a diff query of the TRL, respectively. Instead, if the AS supports both diff queries and the related "Cursor" extension, then the payload of the response is formatted as defined in Section 9.
リクエストが正常に処理された場合、ASは2.05（コンテンツ）応答を伴う応答です。特に、ASがdiffクエリをサポートするが「カーソル」拡張機能（セクション6.2および6.2.1を参照）をサポートする場合、ゲットリクエストがそれぞれ完全なクエリまたはTRLの違いの実行をもたらした場合に、応答のペイロードがセクション7または8で定義されているようにフォーマットされます。代わりに、ASがDIFFクエリと関連する「カーソル」拡張機能の両方をサポートする場合、応答のペイロードはセクション9で定義されているようにフォーマットされます。
In case a requester does not receive a response from the TRL endpoint or it receives an error response from the TRL endpoint, the requester does not make any assumptions or draw any conclusions regarding the revocation or expiration of its pertaining access tokens. The requester MAY try again by sending a new request to the TRL endpoint.
要求者がTRLエンドポイントから応答を受け取らない場合、またはTRLエンドポイントからエラー応答を受信した場合、リクエスタは、アクセストークンの取り消しまたは有効期限に関する仮定を立てたり、結論を引き出したりしません。Requesterは、TRLエンドポイントに新しいリクエストを送信して再試行することができます。
When the TRL is updated (see Section 5.1), the AS sends Observe notifications to the observers whose pertaining subset of the TRL has changed. Observe notifications are sent as per Section 4.2 of [RFC7641]. If supported by the AS, an observer may configure the behavior according to which the AS sends those Observe notifications. To this end, a possible way relies on the conditional control parameter "c.pmax" defined in [COND-PARAMETERS], which can be included as a "name=value" query parameter in an Observation Request. This ensures that no more than c.pmax seconds elapse between two consecutive notifications sent to that observer, regardless of whether or not the TRL has changed.
TRLが更新されると（セクション5.1を参照）、ASはTRLのサブセットが変更されたオブザーバーに通知を観察します。[RFC7641]のセクション4.2に従って、通知を観察します。ASによってサポートされている場合、オブザーバーは、ASがそれらを送信して通知を送信する動作を構成する場合があります。この目的のために、可能な方法は、[cond-parameters]で定義された条件制御パラメーター「c.pmax」に依存しています。これにより、TRLが変更されたかどうかにかかわらず、そのオブザーバーに送信された2つの連続した通知の間にC.Pmax秒以下が経過することが保証されます。
Following a first exchange with the AS, an administrator or a registered device can send additional GET requests to the TRL endpoint at any time, analogously to what is defined above. When doing so, the requester towards the TRL endpoint can ask the AS to perform a full query (see Section 7) or a diff query (see Section 8) of the TRL. In the latter case, the requester can additionally rely on the "Cursor" extension (see Sections 6.3 and 9.2).
ASとの最初の交換に続いて、管理者または登録デバイスは、上記のものと同様に、いつでもTRLエンドポイントに追加のGETリクエストを送信できます。その場合、TRLエンドポイントに向かう要求者は、TRLの完全なクエリ（セクション7を参照）またはdiffクエリ（セクション8を参照）を実行するように依頼できます。後者の場合、要求者はさらに「カーソル」拡張子に依存することができます（セクション6.3および9.2を参照）。
As specified in Section 6.2, an AS supporting diff queries maintains an update collection of maximum MAX_N series items for each administrator or registered device, hereafter referred to as a "requester". In particular, if an update collection includes MAX_N series items, adding a further series item to that update collection results in deleting the oldest series item from that update collection.
セクション6.2で指定されているように、ASサポートDIFFクエリは、各管理者または登録デバイスの最大MAX_Nシリーズアイテムの更新コレクションを維持します。特に、更新コレクションにMAX_Nシリーズアイテムが含まれている場合、その更新コレクションにさらにシリーズアイテムを追加すると、その更新コレクションから最古のシリーズアイテムが削除されます。
From then on, the requester associated with the update collection will not be able to retrieve the deleted series item when sending a new diff query request to the TRL endpoint. If that series item reflected the revocation of an access token pertaining to the requester, then the requester will not learn about that when receiving the corresponding diff query response from the AS.
それ以降、更新コレクションに関連付けられているリクエスターは、TRLエンドポイントに新しいDIFFクエリ要求を送信するときに削除されたシリーズアイテムを取得できません。そのシリーズアイテムがリクエスターに関連するアクセストークンの取り消しを反映している場合、RequesterはASから対応するDIFFクエリ応答を受信したときにそれについて学びません。
Sending a diff query request specifically as an Observation Request, and, thus, relying on Observe notifications, largely reduces the chances for a requester to miss updates that have occurred to its associated update collection. In turn, this relies on the requester successfully receiving the Observe notification responses from the TRL (see also Section 14.3).
Diffクエリ要求を観察要求として特に送信するため、通知を監視することに依存すると、リクエスターが関連する更新コレクションに更新を逃す可能性が大幅に減少します。次に、これはリクエスターに依存して、TRLから観察通知応答を正常に受信します（セクション14.3も参照）。
In order to limit the amount of time during which the requester is unaware of pertaining access tokens that have been revoked but are not expired yet, a requester SHOULD NOT rely solely on diff query requests. In particular, a requester SHOULD also regularly send a full query request to the TRL endpoint according to a related application policy.
リクエスターが取り消されたがまだ期限切れになっていないアクセストークンの関係を認識していない時間を制限するために、要求者は差分クエリ要求だけに依存するべきではありません。特に、要求者は、関連するアプリケーションポリシーに従って、TRLエンドポイントに完全なクエリリクエストを定期的に送信する必要があります。
When receiving a response from the TRL endpoint, a registered device MUST expunge every stored access token associated with a token hash specified in the response. In case the registered device is an RS, it MUST NOT delete the stored token hash after having expunged the associated access token.
TRLエンドポイントから応答を受信する場合、登録されたデバイスは、応答で指定されたトークンハッシュに関連付けられたすべての保存されたアクセストークンを削除する必要があります。登録されたデバイスがRSである場合、関連するアクセストークンを抹消した後、保存されたトークンハッシュを削除してはなりません。
If an RS uses the method defined in this document with the AS that has issued an access token, then the RS MUST NOT accept and store that access token if any of the following holds.
RSがこのドキュメントで定義されているメソッドをASを使用してASCASSEトークンを発行した場合、RSは次のいずれかが保持されている場合はそのアクセストークンを受け入れて保存してはなりません。
* The token hash corresponding to the access token is among the currently stored ones.
* アクセストークンに対応するトークンハッシュは、現在保存されているものの1つです。
* The access token is a CWT and any of the following holds:
* アクセストークンはCWTであり、次のいずれかが保持されます。
- The access token includes a non-empty "unprotected" field, i.e., the value of the field is not encoded as the empty CBOR map (0xa0). This applies to the top-level "unprotected" field of the COSE object used for the CWT, the "unprotected" field of each element of the "signatures" array, and the "unprotected" field of each element of any "recipients" array.
- アクセストークンには、空ではない「保護されていない」フィールドが含まれます。つまり、フィールドの値は空のCBORマップ（0xA0）としてエンコードされていません。これは、CWTに使用されるCOSEオブジェクトのトップレベルの「保護されていない」フィールド、「署名」配列の各要素の「保護されていない」フィールド、および「受信者」アレイの各要素の「保護されていない」フィールドに適用されます。
- The received CBOR data item that embodies the access token does not comply with what is defined in Section 3. This concerns:
- アクセストークンを具体化する受信したCBORデータ項目は、セクション3で定義されているものに準拠していません。
o the use of exactly two nested CBOR tags, where the outer tag is the CWT CBOR tag and the inner tag is one of the COSE CBOR tags;
o 外部タグはCWT CBORタグであり、内側のタグがCOSE CBORタグの1つである正確に2つのネストされたCBORタグを使用します。
o the tag numbers encoded with the minimum possible length; and
o タグ番号は、可能な最小の長さでエンコードされました。そして
o the access token being the innermost tag content of the received CBOR data item.
o アクセストークンは、受信したCBORデータ項目の最も内側のタグコンテンツです。
- In the received CBOR data item that embodies the access token, the inner tag has a tag number that is not consistent with the actual COSE data item to process. For instance, the inner tag number is 16 (COSE_Encrypt0) but the CWT is actually a COSE_Sign data item.
- アクセストークンを具体化する受信したCBORデータ項目では、内側のタグには、実際のCOSEデータ項目と一致しないタグ番号があります。たとえば、内側のタグ番号は16（cose_encrypt0）ですが、CWTは実際にはCOSE_SIGNデータ項目です。
* The access token relies on a JSON object for encoding its claims, but it is not a JWT [RFC7519] and any of the following holds:
* アクセストークンは、その主張をエンコードするためにJSONオブジェクトに依存していますが、それはJWT [RFC7519]ではなく、次のいずれかが保持されます。
- The access token uses the JWS JSON Serialization from [RFC7515] and includes the JWS Unprotected Header.
- アクセストークンは、[RFC7515]のJWS JSONシリアル化を使用し、JWSの保護されていないヘッダーを含んでいます。
- The access token uses the JWE JSON Serialization from [RFC7516] and includes the JWE Shared Unprotected Header and/or includes the "header" member in any of the elements of the "recipients" array.
- アクセストークンは、[RFC7516]のJWE JSONシリアル化を使用し、JWEが保護されていないヘッダーを共有し、および/または「レシピエント」アレイのいずれかの要素に「ヘッダー」メンバーを含む。
An RS MUST store the token hash th1 corresponding to an access token t1 until both the following conditions hold:
RSは、次の両方の条件が保持されるまで、アクセストークンT1に対応するトークンハッシュTH1を保存する必要があります。
* The RS has received and seen t1, irrespective of having accepted and stored it.
* RSは、それを受け入れて保存したことに関係なく、T1を受け取り、見ました。
* The RS has gained knowledge that t1 has expired. This can be achieved, e.g., through the following means:
* RSは、T1が期限切れになったという知識を得ています。これは、たとえば、次の手段で達成できます。
- A response from the TRL endpoint indicating that t1 has expired after its earlier revocation, i.e., the token hash th1 has been removed from the TRL. This can be indicated, for instance, in a response from the TRL endpoint following a diff query of the TRL (see Section 8).
- T1が以前の取り消し後に期限切れになったことを示すTRLエンドポイントからの応答、つまりトークンハッシュTH1がTRLから除去されました。これは、たとえば、TRLの違いに続いてTRLエンドポイントからの応答で示される可能性があります（セクション8を参照）。
- The value of the 'exp' claim specified in t1 indicates that t1 has expired.
- T1で指定された「EXP」クレームの値は、T1が期限切れになったことを示しています。
- The locally determined expiration time for t1 has passed, based on the time at the RS when t1 was first accepted and on the value of its 'exi' claim.
- T1のローカルで決定された有効期限は、T1が最初に受け入れられたRSでの時間とその「EXI」請求の価値に基づいて過ぎました。
- The result of token introspection performed on t1 (see Section 5.9 of [RFC9200]), if supported by both the RS and the AS.
- RSとASの両方でサポートされている場合、T1で実行されたトークン内注視の結果（[RFC9200]のセクション5.9を参照）。
The RS MUST NOT delete the stored token hashes whose corresponding access tokens do not fulfill both the two conditions above, unless it becomes necessary due to memory limitations. In such a case, the RS MUST delete the earliest stored token hashes first.
RSは、メモリの制限のために必要にならない限り、対応するアクセストークンが上記の2つの条件の両方を満たしていない保存されたトークンハッシュを削除してはなりません。そのような場合、RSは最初に最も早い保存されたトークンハッシュを削除する必要があります。
Retaining the stored token hashes as specified above limits the impact from a (dishonest) client whose pertaining access token:
上記の指定されたように保存されたトークンハッシュを保持すると、アクセストークンを持つ（不正な）クライアントからの影響が制限されます。
1. includes the 'exi' claim,
1. 「exi」クレームが含まれています、
2. is uploaded at the RS for the first time after it has been revoked and later expired, and
2. RSが取り消されて後で失効した後、RSで初めてアップロードされ、
3. has the sequence number encoded in the 'cti' claim (for CWTs) or in the 'jti' claim (for JWTs) greater than the highest sequence number among the expired access tokens including the 'exi' claim for the RS (see Section 5.10.3 of [RFC9200]).
3. 「CTI」クレーム（CWTSの場合）または「JTI」クレーム（JWTSの場合）でエンコードされたシーケンス番号が、RSの「EXI」クレームを含む有効期限が切れたアクセストークンの中で最高のシーケンス番号よりも大きい（[RFC9200]のセクション5.10.3を参照）。
That is, the RS would not accept such a revoked and expired access token as long as it stores the corresponding token hash.
つまり、RSは、対応するトークンハッシュを保存する限り、そのような取り消された期限切れのアクセストークンを受け入れません。
This risk can be further limited. Specifically, if token introspection is implemented by both the RS and the AS, the RS can introspect the access token (see Section 5.9 of [RFC9200]) when receiving an access token that includes the 'exi' claim and for which a corresponding token hash is not stored.
このリスクはさらに制限される可能性があります。具体的には、トークン内省がRSとASの両方によって実装されている場合、RSは、「exi」クレームを含むアクセストークンと対応するトークンハッシュが保存されないアクセストークンを受信するときに、アクセストークン（[RFC9200]のセクション5.9を参照）を内省することができます。
When, due to the stored and corresponding token hash th2, an access token t2 that includes the 'exi' claim is expunged or is not accepted upon its upload, the RS retrieves the sequence number sn2 encoded in the 'cti' claim (for CWTs) or in the 'jti' claim (for JWTs) (see Section 5.10.3 of [RFC9200]). Then, the RS stores sn2 as associated with th2. If expunging or not accepting t2 yields the deletion of th2, then the RS MUST associate sn2 with th2 before continuing with the deletion of th2.
保存された対応するトークンハッシュTh2により、「exi」クレームが削除されるか、アップロード時に受け入れられないアクセストークンT2がある場合、RSは「CTI」クレーム（CWTS用）または「JTI」クレーム（JWTSについては）でエンコードされたシーケンス番号SN2を取得します。次に、RSはTH2に関連付けられているSN2を保存します。T2の削減または受け入れを受け入れない場合、TH2の削除が得られる場合、RSはTH2の削除を継続する前にSN2をTH2に関連付ける必要があります。
When deleting any token hash, the RS checks whether the token hash is associated with a sequence number sn_th. In such a case, the RS checks whether sn_th is greater than the highest sequence number sn* among the expired access tokens including the 'exi' claim for the RS. If that is the case, sn* MUST take the value of sn_th.
トークンハッシュを削除するとき、RSはトークンハッシュがシーケンス番号SN_THに関連付けられているかどうかを確認します。そのような場合、RSは、RSの「EXI」クレームを含む、期限切れのアクセストークンの中で、SN_THが最も高いシーケンス番号SN*よりも大きいかどうかをチェックします。その場合、sn*はsn_thの値を取る必要があります。
By virtue of what is defined in Section 5.10.3 of [RFC9200], this ensures that, following the deletion of the token hash associated with an access token including the 'exi' claim and uploaded for the first time after it has been revoked and later expired, the RS will not accept the access token at that point in time or in the future.
[RFC9200]のセクション5.10.3で定義されているものにより、これにより、「exi」クレームを含むアクセストークンに関連するトークンハッシュの削除に続いて、それが取り消され、その後有効期限が切れた後に初めてアップロードされることが保証されます。
This specification defines a number of parameters that can be transported in the response from the TRL endpoint, when the response payload is a CBOR map. Note that such a response MUST use the Content-Format "application/ace-trl+cbor" defined in Section 15.2 of this specification.
この仕様では、応答ペイロードがCBORマップである場合、TRLエンドポイントからの応答で転送できる多くのパラメーターを定義します。このような応答は、この仕様のセクション15.2で定義されているコンテンツフォーマット「アプリケーション/ACE-TRL+CBOR」を使用する必要があることに注意してください。
The table below summarizes the parameters. For each of them, it specifies the value to use as CBOR key, i.e., as abbreviation in the key of the map pair for the parameter, instead of the parameter's name as a text string.
以下の表は、パラメーターをまとめたものです。それらのそれぞれについて、パラメーターの名前ではなく、パラメーターのマップペアのキーの略語として、CBORキーとして使用する値を指定します。
+==========+==========+==========================+
| Name | CBOR Key | CBOR Type |
+==========+==========+==========================+
| full_set | 0 | array |
+----------+----------+--------------------------+
| diff_set | 1 | array |
+----------+----------+--------------------------+
| cursor | 2 | Null or unsigned integer |
+----------+----------+--------------------------+
| more | 3 | True or False |
+----------+----------+--------------------------+
Table 1: CBOR Abbreviations for the ACE Token Revocation List Parameters
表1：ACEトークンの取り消しリストパラメーターのCborの略語
This specification defines a number of values that the AS can use as error identifiers. These are used in error responses with Content-Format "application/concise-problem-details+cbor", as values of the 'error-id' field within the Custom Problem Detail entry 'ace-trl-error' (see Section 6.1).
この仕様は、ASがエラー識別子として使用できる多くの値を定義します。これらは、カスタム問題の詳細エントリ「ACE-TRL-ERROR」内の「エラーID」フィールドの値として、コンテンツ形式の「アプリケーション/簡潔な問題」フィールドの値としてエラー応答で使用されます（セクション6.1を参照）。
+=======+===========================+
| Value | Description |
+=======+===========================+
| 0 | Invalid parameter value |
+-------+---------------------------+
| 1 | Invalid set of parameters |
+-------+---------------------------+
| 2 | Out of bound cursor value |
+-------+---------------------------+
Table 2: ACE Token Revocation List Error Identifiers
表2：ACEトークンの取り消しリストエラー識別子
The protocol defined in this document inherits the security considerations from the ACE framework [RFC9200] and those about the usage of CWTs from [RFC8392], the usage of JWTs from [RFC7519] and [RFC8725], the usage of CoAP Observe from [RFC7641], and the computation of the token hashes from [RFC6920]. The following considerations also apply.
このドキュメントで定義されているプロトコルは、ACEフレームワーク[RFC9200]からのセキュリティ上の考慮事項と[RFC8392]からのCWTの使用に関するもの、[RFC7519]および[RFC8725]からのJWTの使用に関するものを継承します。[RFC6920]。以下の考慮事項も適用されます。
The AS MUST ensure that each registered device can access and retrieve only its pertaining subset of the TRL. To this end, the AS can always perform the required filtering based on the authenticated identity of the registered device, i.e., a (non-public) identifier that the AS can securely relate to the registered device and the secure association that they use to communicate.
ASは、登録されている各デバイスがTRLの関連するサブセットのみにアクセスして取得できるようにする必要があります。この目的のために、ASは、登録されたデバイスの認証されたアイデンティティ、すなわち、Aが通信するために使用する安全な関連付けに安全に関連する（非パブリック）識別子に基づいて、必要なフィルタリングを常に実行できます。
The AS MUST ensure that, other than registered devices accessing their own pertaining subset of the TRL, only authorized and authenticated administrators can access the content of the whole TRL (see Section 10).
ASは、TRLの独自の関連するサブセットにアクセスする登録デバイス以外に、承認された認証された管理者のみがTRL全体のコンテンツにアクセスできることを保証する必要があります（セクション10を参照）。
Note that the TRL endpoint supports only the GET method (see Section 6). Therefore, as detailed in Sections 7 and 8, access to the TRL endpoint is performed only by means of protected and authenticated GET requests, which, by definition, are safe in the REST sense and do not alter the content of the TRL. That is, registered devices and administrators can perform exclusively read-only operations when accessing the TRL endpoint.
TRLエンドポイントはGETメソッドのみをサポートしていることに注意してください（セクション6を参照）。したがって、セクション7および8で詳述されているように、TRLエンドポイントへのアクセスは、保護および認証されたGETリクエストによってのみ実行されます。これは、定義上、残りの意味で安全であり、TRLの内容を変更しません。つまり、登録されたデバイスと管理者は、TRLエンドポイントにアクセスするときに独占的に読み取り専用操作を実行できます。
In fact, the content of the TRL can be updated only internally by the AS, in the two circumstances described in Section 5.1. Therefore, an adversary that is not in control of the AS cannot manipulate the content of the TRL, e.g., by removing a token hash and thereby fraudulently allowing a client to access protected resources in spite of a revoked access token or by adding a token hash and thereby fraudulently stopping a client from accessing protected resources in spite of an access token being still valid.
実際、TRLの内容は、セクション5.1で説明されている2つの状況で、ASによって内部的にのみ更新できます。したがって、ASを制御していない敵は、TRLのコンテンツを操作できません。たとえば、トークンハッシュを削除し、それによってクライアントが取り消されたアクセストークンにもかかわらず、クライアントがトークンハッシュを追加して保護されたリソースにアクセスできるようにするか、クライアントが依然として有効なアクセスにアクセスするのを不正に停止します。
If many non-expired access tokens associated with a registered device are revoked, the pertaining subset of the TRL could grow to a size bigger than what the registered device is prepared to handle upon reception of a response from the TRL endpoint, especially if relying on a full query of the TRL (see Section 7).
登録されたデバイスに関連付けられている多くの非公式のアクセストークが取り消された場合、TRLの関連するサブセットは、特にTRLの完全なクエリに依存する場合、TRLエンドポイントからの応答の受信時に登録されたデバイスが処理する準備ができているサイズよりも大きいサイズに成長する可能性があります（セクション7を参照）。
This could be exploited by attackers to negatively affect the behavior of a registered device. Therefore, in order to help reduce the size of the TRL, the AS SHOULD refrain from issuing access tokens with an excessively long expiration time.
これは、攻撃者によって悪用され、登録されたデバイスの動作に悪影響を与える可能性があります。したがって、TRLのサイズを縮小するために、ASは、非常に長い有効期限でアクセストークンを発行することを控える必要があります。
The communication about revoked access tokens presented in this specification is expected to especially rely on CoAP Observe notifications sent from the AS to a requester (i.e., an administrator or a registered device). The suppression of those notifications by an external attacker that has access to the network would prevent requesters from ever knowing that their pertaining access tokens have been revoked.
この仕様で提示された取り消されたアクセストークンに関する通信は、特にリクエスター（つまり、管理者または登録デバイス）に送信された通知通知に特に依存することが期待されています。ネットワークにアクセスできる外部攻撃者によるこれらの通知の抑制は、リクエスト担当者が関連するアクセストークンが取り消されたことを知ることができなくなります。
In order to avoid this, a requester SHOULD NOT rely solely on the CoAP Observe notifications. In particular, a requester SHOULD also regularly poll the AS for the most current information about revoked access tokens by sending GET requests to the TRL endpoint. Specific strategies and schedules for polling the AS are to be defined by a related application policy and by taking into account the expected operational and availability patterns adopted by the requester (e.g., in the interest of energy saving and other optimizations).
これを回避するために、リクエスターはCOAPの観察通知のみに依存してはなりません。特に、リクエスターは、GETリクエストをTRLエンドポイントに送信して、取り消されたアクセストークンに関する最新の情報についても定期的に投票する必要があります。関連するアプリケーションポリシーによって定義されるASを投票するための特定の戦略とスケジュール、および要求者が採用する予想される運用および可用性パターンを考慮して（たとえば、省エネやその他の最適化のために）。
If a client stores an access token that it still believes to be valid, and it accordingly attempts to access a protected resource at the RS, the client may receive an unprotected 4.01 (Unauthorized) response from the RS.
クライアントがまだ有効であると信じているアクセストークンを保存し、それに応じてRSで保護されたリソースにアクセスしようとする場合、クライアントはRsから保護されていない4.01（不正な）応答を受け取ることができます。
This can be due to a number of causes, for example:
これは、多くの原因が原因である可能性があります。
* the access token has been revoked, the RS has become aware of it, and the RS has expunged the access token, but the client is not aware of this (yet).
* アクセストークンは取り消され、RSはそれを認識し、RSはアクセストークンを削除しましたが、クライアントはこれを認識していません（まだ）。
* the access token is still valid, but an on-path active adversary might have injected a forged 4.01 (Unauthorized) response or the RS might have deleted the access token from its local storage due to its dedicated storage space being all consumed.
* アクセストークンは依然として有効ですが、パス上のアクティブな敵が偽造された4.01（不正）応答を注入した可能性があります。または、RSが専用のストレージスペースがすべて消費されているため、ローカルストレージからアクセストークンを削除した可能性があります。
In either case, if the client believes that the access token is still valid, it SHOULD NOT immediately ask for a new access token to the AS upon receiving a 4.01 (Unauthorized) response from the RS. Instead, the client SHOULD send a request to the TRL endpoint at the AS. If the client gains knowledge that the access token is not valid anymore, the client expunges the access token and can ask for a new one. Otherwise, the client can try again to upload the same access token to the RS or request a new one.
どちらの場合でも、クライアントがアクセストークンがまだ有効であると考えている場合、Rsから4.01（不正な）応答を受信したときにASへの新しいアクセストークンをすぐに要求する必要はありません。代わりに、クライアントはASのTRLエンドポイントにリクエストを送信する必要があります。クライアントがアクセストークンがもはや有効でないという知識を獲得した場合、クライアントはアクセストークンを抹消し、新しいものを求めることができます。それ以外の場合、クライアントは同じアクセストークンをRSにアップロードするか、新しいものをリクエストするように再試行できます。
A client may attempt to access a protected resource at an RS after the access token allowing such an access has been revoked but before the RS is aware of the revocation.
クライアントは、アクセストークンを許可するアクセストークンの後にRSで保護されたリソースにアクセスしようとする場合がありますが、RSが取り消しを認識する前に。
In such a case, if the RS is still storing the access token, the client will be able to access the protected resource even though it should not. Such access is a security violation, even if the client is not attempting to be malicious.
そのような場合、RSがまだアクセストークンを保存している場合、クライアントはそうではないにしても、保護されたリソースにアクセスできます。このようなアクセスは、クライアントが悪意を持っていない場合でも、セキュリティ違反です。
In order to minimize such a risk, if an RS relies solely on polling through individual requests to the TRL endpoint to learn of revoked access tokens, the RS SHOULD implement an adequate trade-off between the polling frequency and the maximum length of the vulnerable time window.
このようなリスクを最小限に抑えるために、RSがTRLエンドポイントへの個々の要求を通じて投票のみに依存して取り消されたアクセストークンを学習する場合、RSはポーリング頻度と脆弱な時間ウィンドウの最大長の間に適切なトレードオフを実装する必要があります。
As defined in Section 3, issued access tokens MUST NOT rely on unprotected headers to specify information as header parameters. Also, when issued access tokens are CWTs, they MUST be tagged by using the COSE CBOR tag corresponding to the used COSE object. Further, the result MUST be tagged using the CWT CBOR tag; no further tagging is performed.
セクション3で定義されているように、発行されたアクセストークンは、保護されていないヘッダーに依存して、ヘッダーパラメーターとして情報を指定してはなりません。また、発行されたアクセストークンはCWTSである場合、使用済みのCOSEオブジェクトに対応するCOSE CBORタグを使用してタグ付けする必要があります。さらに、結果はCWT CBORタグを使用してタグ付けする必要があります。それ以上のタグ付けは実行されません。
This ensures that the RS always computes the correct token hash corresponding to an access token, i.e., the same token hash computed by the AS and C for that access token.
これにより、RSは常にアクセストークンに対応する正しいトークンハッシュ、つまりそのアクセストークンのAとCによって計算された同じトークンハッシュを計算します。
By construction, the rules defined in Section 3 prevent an active adversary from successfully performing an attack against the RS, which would otherwise be possible in case the access token is uploaded to the RS over an unprotected communication channel.
建設により、セクション3で定義されている規則は、アクティブな敵がRSに対する攻撃を正常に実行することを防ぎます。これは、保護されていない通信チャネルでアクセストークンがRSにアップロードされた場合に可能な場合があります。
In such an attack, the adversary intercepts the access token en route to the RS. Then, the adversary manipulates the access token in a way that is going to be unnoticed by the RS but without preventing the successful cryptographic validation of the access token at the RS. To this end, the adversary has two possible options:
このような攻撃では、敵はRsに向かう途中でアクセストークンを傍受します。次に、敵はRSによって気付かれない方法でアクセストークンを操作しますが、RSでのアクセストークンの暗号化の検証が成功することを妨げません。この目的のために、敵には2つの可能な選択肢があります。
* Adding and/or removing fields within the unprotected header(s) of the access token, as long as those fields do not play a role in the cryptographic validation of the access token.
* アクセストークンの保護されていないヘッダー内のフィールドを追加および/または削除します。これらのフィールドがアクセストークンの暗号化検証に役割を果たしていない限り。
* Specifically when the access token is a CWT, adding, removing, or manipulating possible CBOR tags enclosing the access token.
* 特に、アクセストークンがCWTである場合、アクセストークンを囲む可能性のあるCBORタグを追加、削除、または操作します。
After that, the adversary sends the manipulated access token to the RS.
その後、敵は操作されたアクセストークンをRSに送ります。
After having successfully validated the manipulated access token, the RS computes a corresponding token hash different from the one computed and stored by C and the AS. Finally, the RS stores the manipulated access token and the corresponding wrong token hash.
操作されたアクセストークンを正常に検証した後、RSは、CおよびASによって計算および保存されたものとは異なる対応するトークンハッシュを計算します。最後に、RSは操作されたアクセストークンと対応する間違ったトークンハッシュを保存します。
Later on, if the access token is revoked and the AS provides the RS with the corresponding correct token hash, the RS does not recognize the received token hash among the stored ones; therefore, the RS does not delete the revoked access token.
後で、アクセストークンが取り消され、ASがRSに対応する正しいトークンハッシュを提供する場合、RSは保存されたものの中で受信されたトークンハッシュを認識しません。したがって、RSは取り消されたアクセストークンを削除しません。
Section 4.3.2 specifies that an RS using JWTs as access tokens has to compute and store two token hashes associated with the same access token. This is because the RS does not know for sure if the AS provided the access token to the client by means of an AS-to-Client response encoded in CBOR or in JSON.
セクション4.3.2は、JWTSをアクセストークンとして使用するRSが、同じアクセストークンに関連付けられた2つのトークンハッシュを計算して保存する必要があることを指定しています。これは、RSが、CBORまたはJSONでエンコードされたASCLIENT応答によってアクセストークンをクライアントに提供しているかどうかを確実に知らないためです。
Taking advantage of that, a dishonest client can attempt to perform an attack against the RS. That is, the client can first receive the JWT in an AS-to-Client response encoded in CBOR (JSON). Then, the client can upload the JWT to the RS in a way that makes the RS believe that the client instead received the JWT in an AS-to-Client response encoded in JSON (CBOR).
それを利用して、不正なクライアントはRSに対する攻撃を実行しようとすることができます。つまり、クライアントは、最初にCBOR（JSON）でエンコードされたクライアントからの応答でJWTを受信できます。次に、クライアントはJSON（CBOR）でエンコードされたASクライアント応答でJWTを受け取ったとRSが信じる方法でJWTをRSにアップロードできます。
Consequently, the RS considers a HASH_INPUT different from the one considered by the AS and the client (see Section 4.2). Hence, the RS computes a token hash h' different from the token hash h computed by the AS and the client. It follows that, if the AS revokes the access token and advertises the right token hash h, then the RS will not learn about the access token revocation; therefore, the RS will not delete the access token.
その結果、RSは、ASおよびクライアントが考慮したものとは異なるHASH_INPUTを考慮します（セクション4.2を参照）。したがって、RSは、ASおよびクライアントによって計算されたトークンハッシュHとは異なるトークンハッシュH 'を計算します。したがって、ASがアクセストークンを取り消し、適切なトークンハッシュHを宣伝する場合、RSはアクセストークンの取り消しについて学習しません。したがって、RSはアクセストークンを削除しません。
Fundamentally, this would happen because the HASH_INPUT used to compute the token hash of a JWT depends on whether the AS-to-Client response is encoded in CBOR or in JSON. This makes the RS vulnerable to the attack described above when JWTs are used as access tokens. However, this is not a problem if the access token is a CWT, since the HASH_INPUT used to compute the token hash of a CWT does not depend on whether the AS-to-Client response is encoded in CBOR or in JSON.
基本的に、これは、JWTのトークンハッシュを計算するためにHash_InputがCBORまたはJSONでエンコードされているかどうかによって異なります。これにより、JWTがアクセストークンとして使用される場合、上記の攻撃に対してRSが脆弱になります。ただし、CWTのトークンハッシュを計算するために使用されるHASH_INPUTはCBORまたはJSONでエンコードされているかどうかに依存しないため、アクセストークンがCWTである場合、これは問題ではありません。
While this asymmetry cannot be avoided altogether, the method defined for the AS and the client in Section 4.2 deliberately penalizes the case where the RS uses JWTs as access tokens. In such a case, the RS effectively neutralizes the attack described above by computing and storing two token hashes associated with the same access token (see Section 4.3.2).
この非対称性を完全に回避することはできませんが、セクション4.2のASとクライアントに対して定義された方法は、RSがJWTSをアクセストークンとして使用する場合を意図的に罰します。そのような場合、RSは、同じアクセストークンに関連する2つのトークンハッシュを計算および保存することにより、上記の攻撃を効果的に中和します（セクション4.3.2を参照）。
Conversely, this design deliberately favors the case where the RS uses CWTs as access tokens, which is a preferable option for resource-constrained RSs as well as the default case in the ACE framework (see Section 3 of [RFC9200]). That is, if an RS uses CWTs as access tokens, then the RS is not exposed to the attack described above; therefore, the RS safely computes and stores only one token hash per access token (see Section 4.3.1).
逆に、この設計は、RSがCWTSをアクセストークンとして使用する場合を意図的に支持します。これは、リソース制約のRSSの好ましいオプションであり、ACEフレームワークのデフォルトのケースです（[RFC9200]セクション3を参照）。つまり、RSがアクセストークンとしてCWTを使用する場合、RSは上記の攻撃にさらされません。したがって、RSは、アクセストークンごとに1つのトークンハッシュのみを安全に計算および保存します（セクション4.3.1を参照）。
By accessing the TRL at the AS, registered devices and administrators are able to learn that their pertaining access tokens have been revoked. However, they cannot learn the reason why, including when that reason is the compromise, misbehavior, or decommissioning of a registered device.
ASでTRLにアクセスすることにより、登録されたデバイスと管理者は、彼らの関連するアクセストークンが取り消されたことを知ることができます。ただし、その理由が登録デバイスの妥協、不正行為、または廃止措置である場合を含め、その理由を学ぶことはできません。
In fact, even the AS might not know that a registered device to which a revoked access token pertains has been specifically compromised, misbehaving, or decommissioned. At the same time, it might not be acceptable to only revoke the access tokens pertaining to such a registered device.
実際、取り消されたアクセストークンが関連する登録されたデバイスが、特に妥協、不正行為、または廃止されたことを知らないかもしれません。同時に、このような登録されたデバイスに関連するアクセストークンのみを取り消すことは受け入れられない場合があります。
Therefore, in order to preserve the security of the system and application, the entity that authoritatively declares a registered device to be compromised, misbehaving, or decommissioned should also promptly trigger the execution of additional revocation processes as deemed appropriate. These include, for instance:
したがって、システムとアプリケーションのセキュリティを維持するために、登録されたデバイスが権威ある登録デバイスが侵害されると宣言するエンティティも、適切と見なされる追加の取り消しプロセスの実行を迅速にトリガーする必要があります。たとえば、これらには次のものが含まれます。
* The deregistration of the registered device from the AS so that the AS does not issue further access tokens pertaining to that device.
* ASから登録されたデバイスの登録デバイスの規制緩和により、ASはそのデバイスに関連するさらにアクセストークンを発行しません。
* If applicable, the revocation of the public authentication credential associated with the registered device (e.g., its public key certificate).
* 該当する場合、登録されたデバイスに関連付けられたパブリック認証資格情報の取り消し（例：その公開証明書）。
The methods by which these processes are triggered and carried out are out of the scope of this document.
これらのプロセスがトリガーおよび実行される方法は、このドキュメントの範囲外です。
The IANA actions for this document are described in the following subsections.
このドキュメントのIANAアクションは、次のサブセクションで説明されています。
IANA has registered the media type "application/ace-trl+cbor" for messages of the protocol defined in this document encoded in CBOR. This registration follows the procedures specified in [RFC6838].
IANAは、CBORでエンコードされたこのドキュメントで定義されているプロトコルのメッセージのメディアタイプ「アプリケーション/ACE-TRL+CBOR」を登録しています。この登録は、[RFC6838]で指定された手順に従います。
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
ace-trl+cbor
ACE-TRL+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 9770.
RFC 9770で定義されているプロトコルパラメーターを含むCBORマップとしてエンコードする必要があります。
Security considerations:
セキュリティ上の考慮事項：
See Section 14 of RFC 9770.
RFC 9770のセクション14を参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9770
RFC 9770
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
The type is used by authorization servers, clients, and RSs that support the notification of revoked access tokens according to a Token Revocation List maintained by the authorization server as specified in RFC 9770.
このタイプは、RFC 9770で指定されているように、承認サーバーが維持するトークンの取り消しリストに従って、取り消されたアクセストークンの通知をサポートする認証サーバー、クライアント、およびRSSによって使用されます。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
ACE WG mailing list (ace@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)
ACE WGメーリングリスト（ace@ietf.org）またはIETFアプリケーションとリアルタイムエリア（art@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
None
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
IANA has registered the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.
IANAは、「制約されたRESTFUL環境（CORE）パラメーター」レジストリグループ内の「COAPコンテンツフォーマット」レジストリへの次のエントリを登録しました。
Content Type:
コンテンツタイプ：
application/ace-trl+cbor
アプリケーション/ACE-TRL+CBOR
Content Coding:
コンテンツコーディング：
-
-
ID:
ID:
262
262
Reference:
参照：
RFC 9770
RFC 9770
IANA has registered the following entry in the "Custom Problem Detail Keys" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group.
IANAは、「Constrained Restful Environments（Core）パラメーター」レジストリグループ内の「カスタム問題詳細キー」レジストリに次のエントリを登録しました。
Key Value:
キー値：
1
1
Name:
名前：
ace-trl-error
ACE-TRL-ERROR
Brief Description:
簡単な説明：
Carry RFC 9770 problem details in a Concise Problem Details data item.
RFC 9770の問題の詳細を簡潔な問題の詳細データ項目。
Change Controller:
Change Controller：
IETF
IETF
Reference:
参照：
Section 6.1 of RFC 9770
RFC 9770のセクション6.1
IANA has established the "ACE Token Revocation List Parameters" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
IANAは、「制約付き環境（ACE）の認証と認証」レジストリグループ内で「ACEトークン取り消しリストパラメーター」レジストリを確立しました。
One of the following registration policies is used: "Standards Action With Expert Review", "Specification Required" per Section 4.6 of [RFC8126], or "Expert Review" per Section 4.5 of [RFC8126]. Expert Review guidelines are provided in Section 15.6.
次の登録ポリシーのいずれかが使用されます：[RFC8126]のセクション4.6ごとに「専門家のレビューを伴う標準アクション」、「必要な仕様」、または[RFC8126]のセクション4.5ごとの「専門家のレビュー」。専門家のレビューガイドラインは、セクション15.6に記載されています。
All assignments according to "Standards Action With Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126] with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].
「Expert Reviewの標準アクション」に従ってすべての割り当ては、[RFC8126]のセクション4.9のセクション4.9に従って「標準アクション」ベースで行われます。[RFC7120]で定義されたコードポイントを追跡する標準の早期配分の手順も適用されます。そのような手順が使用される場合、IANAは指定された専門家に登録前の早期配分を承認するように依頼します。さらに、WG椅子は、[RFC7120]のセクション3.1で概説したプロセスの早い段階で専門家に相談することをお勧めします。
The columns of this registry are as follows:
このレジストリの列は次のとおりです。
* Name: This field contains a descriptive name that enables easier reference to the item. The name MUST be unique, and it is not used in the encoding.
* 名前：このフィールドには、アイテムをより簡単に参照できるようにする記述名が含まれています。名前は一意でなければならず、エンコードでは使用されません。
* CBOR Key: This field contains the value used as CBOR map key of the item. The value MUST be unique. The value is an unsigned integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". 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未満の整数値は、「私的使用」としてマークされています。
* CBOR Type: This field contains the allowable CBOR data types for values of this item or a pointer to the registry that defines its type, when that depends on another item.
* CBORタイプ：このフィールドには、このアイテムの値の許容CBORデータ型または他のアイテムに依存する場合のそのタイプを定義するレジストリへのポインタが含まれています。
* Reference: This field contains a pointer to the public specification for the item.
* 参照：このフィールドには、アイテムの公開仕様へのポインターが含まれています。
This registry has been initially populated by the values in Section 12. The "Reference" column for all of these entries refers to this document.
このレジストリは、当初、セクション12の値によって入力されています。これらすべてのエントリの「参照」列は、このドキュメントを参照しています。
IANA has established the "ACE Token Revocation List Errors" registry within the "Authentication and Authorization for Constrained Environments (ACE)" registry group.
IANAは、「制約された環境（ACE）の認証と承認」レジストリグループ内で「ACEトークン取り消しリストエラー」レジストリを確立しました。
One of the following registration policies is used: "Standards Action With Expert Review", "Specification Required" per Section 4.6 of [RFC8126], or "Expert Review" per Section 4.5 of [RFC8126]. Expert Review guidelines are provided in Section 15.6.
次の登録ポリシーのいずれかが使用されます：[RFC8126]のセクション4.6ごとに「専門家のレビューを伴う標準アクション」、「必要な仕様」、または[RFC8126]のセクション4.5ごとの「専門家のレビュー」。専門家のレビューガイドラインは、セクション15.6に記載されています。
All assignments according to "Standards Action With Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126] with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in Section 3.1 of [RFC7120].
「Expert Reviewの標準アクション」に従ってすべての割り当ては、[RFC8126]のセクション4.9のセクション4.9に従って「標準アクション」ベースで行われます。[RFC7120]で定義されたコードポイントを追跡する標準の早期配分の手順も適用されます。そのような手順が使用される場合、IANAは指定された専門家に登録前の早期配分を承認するように依頼します。さらに、WG椅子は、[RFC7120]のセクション3.1で概説したプロセスの早い段階で専門家に相談することをお勧めします。
The columns of this registry are as follows:
このレジストリの列は次のとおりです。
* Value: The field contains the value to be used to identify the error. The value MUST be unique. The value is an unsigned integer or a negative integer. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 are designated as "Standards Action With Expert Review". 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".
* 値：フィールドには、エラーを識別するために使用する値が含まれています。値は一意でなければなりません。値は、署名されていない整数または負の整数です。さまざまな範囲の値は、異なる登録ポリシーを使用しています[RFC8126]。-256〜255の整数値は、「専門家のレビューを伴う標準アクション」として指定されています。-65536から-257、256〜65535の整数値は、「仕様が必要」として指定されています。65535を超える整数値は、「専門家のレビュー」として指定されています。-65536未満の整数値は、「私的使用」としてマークされています。
* Description: This field contains a brief description of the error.
* 説明：このフィールドには、エラーの簡単な説明が含まれています。
* Reference: This field contains a pointer to the public specification defining the error, if one exists.
* 参照：このフィールドには、存在する場合、エラーを定義する公開仕様へのポインターが含まれています。
This registry has been initially populated by the values in Section 13. The "Reference" column for all of these entries refers to this document.
このレジストリは当初、セクション13の値によって入力されています。これらのすべてのエントリの「参照」列は、このドキュメントを参照しています。
The IANA registries established by this document use "Standards Action With Expert Review", "Specification Required", or "Expert Review" registration procedures depending on the range of values for which an assignment is requested. 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 required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. For the "Expert Review" range of point assignment, specifications are recommended and are needed 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.
* 仕様は、「エキスパートレビューによる標準アクション」のポイント割り当て範囲に必要です。「必要な仕様」範囲の仕様は存在する必要がありますが、仕様が利用可能である前の早期割り当ては許容されると見なされます。「エキスパートレビュー」のポイント割り当ての範囲には、仕様が推奨され、閉じた環境の外側で相互運用可能な方法で使用されることが予想される場合は必要です。仕様が提供されていない場合、提供された説明には、ポイントが使用されているものを識別するのに十分な情報が必要です。
* 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, the size of device it will be used on, and the number of code points left that encode to that size.
* 専門家は、ポイント割り当てを承認する際に、フィールドの予想される使用を考慮する必要があります。標準の追跡ドキュメントの範囲があるという事実は、標準の追跡ドキュメントがその範囲外に割り当てられたポイントを持つことができないことを意味するものではありません。エンコードされた値の長さは、その長さのコードポイントの数、使用されるデバイスのサイズ、およびそのサイズにエンコードするコードポイントの数と比較して計量する必要があります。
[IANA.Hash.Algorithms]
IANA, "Named Information Hash Algorithm Registry",
<https://www.iana.org/assignments/named-information>.
[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>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[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>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[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>.
[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>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[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>.
[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>.
[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>.
[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>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
[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>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[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>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[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>.
[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>.
[RFC9290] Fossati, T. and C. Bormann, "Concise Problem Details for
Constrained Application Protocol (CoAP) APIs", RFC 9290,
DOI 10.17487/RFC9290, October 2022,
<https://www.rfc-editor.org/info/rfc9290>.
[RFC9431] Sengul, C. and A. Kirby, "Message Queuing Telemetry
Transport (MQTT) and Transport Layer Security (TLS)
Profile of Authentication and Authorization for
Constrained Environments (ACE) Framework", RFC 9431,
DOI 10.17487/RFC9431, July 2023,
<https://www.rfc-editor.org/info/rfc9431>.
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/info/rfc9528>.
[SHA-256] NIST, "Secure Hash Standard", NIST FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[COND-PARAMETERS]
Silverajan, B., Koster, M., and A. Soloway, "Conditional
Query Parameters for CoAP Observe", Work in Progress,
Internet-Draft, draft-ietf-core-conditional-attributes-11,
16 March 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-conditional-attributes-11>.
[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>.
[STP] Bormann, C. and K. Hartke, "The Series Transfer Pattern
(STP)", Work in Progress, Internet-Draft, draft-bormann-
t2trg-stp-03, 7 April 2020,
<https://datatracker.ietf.org/doc/html/draft-bormann-
t2trg-stp-03>.
Performing a diff query of the TRL as specified in Section 8 is, in fact, a usage example of the Series Transfer Pattern (STP) defined in [STP].
セクション8で指定されているTRLの差分クエリを実行することは、実際、[STP]で定義されたシリーズ転送パターン（STP）の使用例です。
That is, a diff query enables the transfer of a series of diff entries with the AS providing U <= MAX_N diff entries as related to the U most recent TRL updates pertaining to a requester, i.e., a registered device or an administrator.
つまり、diffクエリは、リクエスターに関連するuの最新のTRLアップデート、つまり登録済みデバイスまたは管理者に関連するAS ASを提供するASを提供する一連のdiffエントリを提供することを可能にします。
When responding to a diff query request from a requester (see Section 8), 'diff_set' is a subset of the update collection associated with the requester where each 'diff_entry' record is a series item from that update collection. Note that 'diff_set' specifies the whole current update collection when the value of U is equal to SIZE, i.e., the current number of series items in the update collection.
要求者からのdiffクエリ要求に応答する場合（セクション8を参照）、「diff_set」は、各「diff_entry」レコードがその更新コレクションのシリーズアイテムであるリクエスターに関連付けられた更新コレクションのサブセットです。「diff_set」は、uの値がサイズ、つまり更新コレクションの現在のシリーズアイテムの数に等しい場合、現在の更新コレクション全体を指定することに注意してください。
The value N of the 'diff' query parameter in the GET request allows the requester and the AS to trade the amount of provided information with the latency of the information transfer.
Get Requestの「DIFF」クエリパラメーターの値nは、リクエスターと提供された情報の量を情報転送の遅延と交換することができます。
Since the update collection associated with each requester includes up to MAX_N series items, the AS deletes the oldest series item when a new one is generated and added to the end of the update collection, due to a new TRL update pertaining to that requester (see Section 6.2). This addresses the question "When can the server decide to no longer retain older items?" raised in Section 3.2 of [STP].
各リクエスターに関連付けられた更新コレクションにはMAX_Nシリーズアイテムが含まれているため、ASは、そのリクエスターに関連する新しいTRLアップデートにより、新しいシリーズアイテムが生成され、更新コレクションの最後に追加されたときに削除されます（セクション6.2を参照）。これは、「サーバーはいつ古いアイテムを保持しないことを決定することができますか？」という質問に対処します。[STP]のセクション3.2で提起されました。
Furthermore, performing a diff query of the TRL together with the "Cursor" extension as specified in Section 9 relies, in fact, on the "cursor" pattern of the STP (see Section 3.3 of [STP]).
さらに、セクション9で指定されている「カーソル」拡張機能とともにTRLの差分クエリを実行すると、実際にはSTPの「カーソル」パターンに依存しています（[STP]のセクション3.3を参照）。
Table 3 provides an aggregated overview of the local supportive parameters that the AS internally uses at its TRL endpoint when supporting diff queries (see Section 6) and the "Cursor" extension (see Section 6.2.1).
表3は、DIFFクエリ（セクション6を参照）および「カーソル」拡張（セクション6.2.1を参照）をサポートするときに、ASがTRLエンドポイントで内部的に使用するローカルサポートパラメーターの集計された概要を示しています。
Except for MAX_N defined in Section 6.2, all the other parameters are defined in Section 6.2.1 and are used only if the AS supports the "Cursor" extension.
セクション6.2で定義されているMAX_Nを除き、他のすべてのパラメーターはセクション6.2.1で定義されており、ASが「カーソル」拡張機能をサポートする場合にのみ使用されます。
For each parameter, the columns of the table provide the following information. Both a registered device and an administrator are referred to as "requester".
各パラメーターについて、テーブルの列は次の情報を提供します。登録されたデバイスと管理者の両方が「リクエスター」と呼ばれます。
Name:
名前：
The parameter name. A name with letters in uppercase denotes a parameter whose value does not change after its initialization.
パラメーター名。大文字の文字がある名前は、初期化後に値が変わらないパラメーターを示します。
Single instance:
単一のインスタンス：
"Y" if there is a single parameter instance associated with the TRL or "N" if there is one parameter instance per update collection (i.e., per requester).
「Y」は、TRLまたは「N」に関連付けられた単一のパラメーターインスタンスがある場合、更新コレクションごと（リクエスターごと）1つのパラメーターインスタンスがある場合。
Description:
説明：
A short description of the parameter.
パラメーターの簡単な説明。
Values:
値：
The unsigned integer values that the parameter can assume, where LB and UB denote the inclusive lower bound and upper bound, respectively.
パラメーターが想定できる符号なしの整数値。LBとUBは、それぞれ包括的下限と上限を示します。
+================+==========+====================+==================+
| Name | Single | Description | Values |
| | instance | | |
+================+==========+====================+==================+
| MAX_N | Y | Max number of | LB = 1 |
| | | series items in | |
| | | the update | If supporting |
| | | collection of each | the "Cursor" |
| | | requester | extension, then |
| | | | UB = |
| | | | MAX_INDEX+1 |
+----------------+----------+--------------------+------------------+
| MAX_DIFF_BATCH | N | Max number of diff | LB = 1 |
| | | entries included | |
| | | in a diff query | UB = MAX_N |
| | | response when | |
| | | using the "Cursor" | |
| | | extension | |
+----------------+----------+--------------------+------------------+
| MAX_INDEX | Y | Max value of each | LB = MAX_N-1 |
| | | instance of | |
| | | 'index' | UB = (2^64)-1 |
+----------------+----------+--------------------+------------------+
| index | N | Value associated | LB = 0 |
| | | with a series item | |
| | | of an update | UB = MAX_INDEX |
| | | collection | |
+----------------+----------+--------------------+------------------+
| last_index | N | The 'index' value | LB = 0 |
| | | of the most | |
| | | recently added | UB = MAX_INDEX |
| | | series item in an | |
| | | update collection | |
+----------------+----------+--------------------+------------------+
Table 3: Local Supportive Parameters of the TRL Endpoint
表3：TRLエンドポイントのローカルサポートパラメーター
This section provides examples of interactions between an RS as a registered device and an AS. In the examples, all the access tokens issued by the AS are intended to be consumed by the considered RS.
このセクションでは、登録されたデバイスとしてのRS間の相互作用の例とASを示します。例では、考慮されたRsによって消費されることを目的としたASによって発行されたすべてのアクセストークンがあります。
The AS supports both full queries and diff queries of the TRL, as defined in Sections 7 and 8, respectively.
ASは、それぞれセクション7と8で定義されているように、TRLの完全なクエリとdiffクエリの両方をサポートしています。
The RS registration is assumed to be done by the RS sending a POST request with an unspecified payload to the AS, which replies with a 2.01 (Created) response. The payload of the registration response is assumed to be a CBOR map, which, in turn, is assumed to include the following entries:
RS登録は、ASに不特定のペイロードを含むPOSTリクエストを送信するRSによって行われると想定されています。これは2.01（作成）応答で応答します。登録応答のペイロードは、CBORマップであると想定されており、次のエントリを含むと想定されています。
* a 'trl_path' parameter specifying the path of the TRL endpoint;
* TRLエンドポイントのパスを指定する「TRL_PATH」パラメーター。
* a 'trl_hash' parameter specifying the "Hash Name String" of the hash function used to compute token hashes as defined in Section 4;
* セクション4で定義されているようにトークンハッシュを計算するために使用されるハッシュ関数の「ハッシュ名文字列」を指定する「TRL_HASH」パラメーター。
* a 'max_n' parameter specifying the value of MAX_N, i.e., the maximum number of series items that the AS retains in the update collection associated with a registered device (see Section 6.2);
* MAX_Nの値を指定する「MAX_N」パラメーター、つまり、登録されたデバイスに関連付けられた更新コレクションにASが保持するシリーズアイテムの最大数（セクション6.2を参照）。
* possible further parameters related to the registration process.
* 登録プロセスに関連する可能性のあるさらなるパラメーター。
Furthermore, 'h(x)' refers to the hash function used to compute the token hashes, as defined in Section 4 of this specification and according to [RFC6920]. Assuming the usage of CWTs transported in AS-to-Client responses encoded in CBOR (see Section 4.2.1), 'bstr.h(t1)' and 'bstr.h(t2)' denote CBOR byte strings, whose values are the token hashes of the access tokens t1 and t2, respectively.
さらに、「H（x）」とは、この仕様のセクション4で定義され、[RFC6920]に従って、トークンハッシュの計算に使用されるハッシュ関数を指します。CBORでエンコードされたASクライアント応答で輸送されたCWTの使用法（セクション4.2.1を参照）、「BSTR.H（T1）」、および「BSTR.H（T2）」はCBORバイト文字列を示しています。
Figure 10 shows an interaction example of a CoAP observation and a full query of the TRL.
図10は、COAP観測の相互作用の例とTRLの完全なクエリを示しています。
In this example, the AS does not support the "Cursor" extension. Hence, the 'cursor' parameter is not included in the payload of the responses to a full query request.
この例では、ASは「カーソル」拡張機能をサポートしていません。したがって、「カーソル」パラメーターは、完全なクエリリクエストへの応答のペイロードに含まれていません。
RS AS
| |
| Registration: POST |
+------------------------------------------------------>|
| |
|<------------------------------------------------------+
| 2.01 Created |
| Payload: { |
| / ... / |
| "trl_path": "/revoke/trl", |
| "trl_hash": "sha-256", |
| "max_n": 10 |
| } |
| |
| GET coap://as.example.com/revoke/trl/ |
| Observe: 0 |
+------------------------------------------------------>|
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 42 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [] |
| } |
| |
| ... |
| |
| (Access tokens t1 and t2 issued |
| and successfully submitted to RS) |
| |
| ... |
| |
| (Access token t1 is revoked) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 53 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t1)] |
| } |
| |
| ... |
| |
| (Access token t2 is revoked) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 64 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t1), bstr.h(t2)] |
| } |
| |
| ... |
| |
| (Access token t1 expires) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 75 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t2)] |
| } |
| |
| ... |
| |
| (Access token t2 expires) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 86 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [] |
| } |
| |
Figure 10: Interaction for Full Query with Observe
図10：観察を使用した完全なクエリの相互作用
Figure 11 shows an interaction example of a CoAP observation and a diff query of the TRL.
図11は、COAP観測の相互作用の例とTRLの違いを示しています。
The RS indicates N = 3 as the value of the 'diff' query parameter, i.e., as the maximum number of diff entries to be included in a response from the AS.
RSは、n = 3を「diff」クエリパラメーターの値として示します。つまり、ASからの応答に含まれるDiffエントリの最大数として。
In this example, the AS does not support the "Cursor" extension. Hence, the 'cursor' parameter and the 'more' parameter are not included in the payload of the responses to a diff query request.
この例では、ASは「カーソル」拡張機能をサポートしていません。したがって、「カーソル」パラメーターと「その他」パラメーターは、DIFFクエリ要求への応答のペイロードに含まれていません。
RS AS
| |
| Registration: POST |
+------------------------------------------------------>|
| |
|<------------------------------------------------------+
| 2.01 Created |
| Payload: { |
| / ... / |
| "trl_path": "/revoke/trl", |
| "trl_hash": "sha-256", |
| "max_n": 10 |
| } |
| |
| GET coap://as.example.com/revoke/trl?diff=3 |
| Observe: 0 |
+------------------------------------------------------>|
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 42 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [] |
| } |
| |
| ... |
| |
| (Access tokens t1 and t2 issued |
| and successfully submitted to RS) |
| |
| ... |
| |
| (Access token t1 is revoked) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 53 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [], [bstr.h(t1)] ] |
| ] |
| } |
| |
| ... |
| |
| (Access token t2 is revoked) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 64 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [], [bstr.h(t2)] ], |
| [ [], [bstr.h(t1)] ] |
| ] |
| } |
| |
| ... |
| |
| (Access token t1 expires) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 75 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t1)], [] ], |
| [ [], [bstr.h(t2)] ], |
| [ [], [bstr.h(t1)] ] |
| ] |
| } |
| |
| ... |
| |
| (Access token t2 expires) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 86 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t2)], [] ], |
| [ [bstr.h(t1)], [] ], |
| [ [], [bstr.h(t2)] ] |
| ] |
| } |
| |
Figure 11: Interaction for Diff Query with Observe
図11：diff queryの相互作用と観察
Figure 12 shows an interaction example of a CoAP observation and a full query of the TRL.
図12は、COAP観測の相互作用の例とTRLの完全なクエリを示しています。
The example also shows one of the notifications from the AS getting lost in transmission; thus, that notification does not reach the RS.
この例は、トランスミッションで迷子になっていることからの通知の1つを示しています。したがって、その通知はRsに到達しません。
When this happens, and after a waiting time defined by the application has elapsed, the RS sends a GET request with no Observe Option to the AS, asking the AS to perform a diff query of the TRL. The RS indicates N = 8 as the value of the 'diff' query parameter, i.e., as the maximum number of diff entries to be included in a response from the AS.
これが発生し、アプリケーションによって定義された待ち時間が経過した後、RSはasにオプションのないgetリクエストを送信し、trlの差分クエリを実行するように依頼します。RSは、n = 8を「diff」クエリパラメーターの値として示します。つまり、ASからの応答に含まれるDiffエントリの最大数として。
In this example, the AS does not support the "Cursor" extension. Hence, the 'cursor' parameter is not included in the payload of the responses to a full query request. Also, the 'cursor' parameter and the 'more' parameter are not included in the payload of the responses to a diff query request.
この例では、ASは「カーソル」拡張機能をサポートしていません。したがって、「カーソル」パラメーターは、完全なクエリリクエストへの応答のペイロードに含まれていません。また、「カーソル」パラメーターと「その他」パラメーターは、DIFFクエリ要求への応答のペイロードに含まれていません。
RS AS
| |
| Registration: POST |
+------------------------------------------------------>|
| |
|<------------------------------------------------------+
| 2.01 Created |
| Payload: { |
| / ... / |
| "trl_path": "/revoke/trl", |
| "trl_hash": "sha-256", |
| "max_n": 10 |
| } |
| |
| GET coap://as.example.com/revoke/trl/ |
| Observe: 0 |
+------------------------------------------------------>|
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 42 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [] |
| } |
| |
| ... |
| |
| (Access tokens t1 and t2 issued |
| and successfully submitted to RS) |
| |
| ... |
| |
| (Access token t1 is revoked) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 53 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t1)] |
| } |
| |
| ... |
| |
| (Access token t2 is revoked) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 64 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t1), bstr.h(t2)] |
| } |
| |
| ... |
| |
| (Access token t1 expires) |
| |
|<------------------------------------------------------+
| 2.05 Content |
| Observe: 75 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t2)] |
| } |
| |
| ... |
| |
| (Access token t2 expires) |
| |
| Lost X <---------------------------------------------+
| 2.05 Content |
| Observe: 86 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [] |
| } |
| |
| ... |
| |
| (Enough time has passed since |
| the latest received notification) |
| |
| |
| GET coap://as.example.com/revoke/trl?diff=8 |
+------------------------------------------------------>|
| |
|<------------------------------------------------------+
| 2.05 Content |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t2)], [] ], |
| [ [bstr.h(t1)], [] ], |
| [ [], [bstr.h(t2)] ], |
| [ [], [bstr.h(t1)] ] |
| ] |
| } |
| |
Figure 12: Interaction for Full Query with Observe and Diff Query
図12：観察とdiffクエリを使用した完全なクエリの相互作用
In this example, the AS supports the "Cursor" extension. Hence, the CBOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries that can be included in a response to a diff query request from this RS.
この例では、ASは「カーソル」拡張機能をサポートします。したがって、登録応答のペイロードとして伝えられたCBORマップには、「max_diff_batch」パラメーターが含まれています。これは、MAX_DIFF_BATCHの値、つまり、このRSからのDIFFクエリ要求への応答に含めることができるDIFFエントリの最大数を指定します。
Figure 13 shows an interaction example of a CoAP observation and a diff query of the TRL.
図13は、COAP観測の相互作用の例とTRLの違いを示しています。
The RS specifies the 'diff' query parameter with a value of 3, i.e., the maximum number of diff entries to be included in a response from the AS.
RSは、値が3の「DIFF」クエリパラメーター、つまりASからの応答に含まれるDIFFエントリの最大数を指定します。
If the RS has not received a notification from the AS for a waiting time defined by the application, the RS sends a GET request with no Observe Option to the AS, asking the AS to perform a diff query of the TRL.
RSがアプリケーションで定義されたASから通知を受信していない場合、RSはASにObserveオプションのないGETリクエストを送信し、TRLの差分クエリを実行するようにASに要求します。
This is followed up by a further diff query request that includes the 'cursor' query parameter. Note that the payload of the corresponding response differs from the payload of the response to the previous diff query request.
これに続いて、「カーソル」クエリパラメーターを含むさらにdiffクエリリクエストが続きます。対応する応答のペイロードは、以前のDIFFクエリ要求に対する応答のペイロードとは異なることに注意してください。
RS AS
| |
| Registration: POST |
+---------------------------------------------------------->|
| |
|<----------------------------------------------------------+
| 2.01 Created |
| Payload: { |
| / ... / |
| "trl_path": "/revoke/trl", |
| "trl_hash": "sha-256", |
| "max_n": 10, |
| "max_diff_batch": 5 |
| } |
| |
| GET coap://as.example.com/revoke/trl?diff=3 |
| Observe: 0 |
+---------------------------------------------------------->|
| |
|<----------------------------------------------------------+
| 2.05 Content |
| Observe: 42 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [], |
| / cursor / 2: null, |
| / more / 3: false |
| } |
| |
| ... |
| |
| (Access tokens t1 and t2 issued |
| and successfully submitted to RS) |
| |
| ... |
| |
| (Access token t1 is revoked) |
| |
|<----------------------------------------------------------+
| 2.05 Content |
| Observe: 53 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [], [bstr.h(t1)] ] |
| ], |
| / cursor / 2: 0, |
| / more / 3: false |
| } |
| |
| ... |
| |
| (Access token t2 is revoked) |
| |
|<----------------------------------------------------------+
| 2.05 Content |
| Observe: 64 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [], [bstr.h(t2)] ], |
| [ [], [bstr.h(t1)] ] |
| ], |
| / cursor / 2: 1, |
| / more / 3: false |
| } |
| |
| ... |
| |
| (Access token t1 expires) |
| |
|<----------------------------------------------------------+
| 2.05 Content |
| Observe: 75 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t1)], [] ], |
| [ [], [bstr.h(t2)] ], |
| [ [], [bstr.h(t1)] ] |
| ], |
| / cursor / 2: 2, |
| / more / 3: false |
| } |
| |
| ... |
| |
| (Access token t2 expires) |
| |
|<----------------------------------------------------------+
| 2.05 Content |
| Observe: 86 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t2)], [] ], |
| [ [bstr.h(t1)], [] ], |
| [ [], [bstr.h(t2)] ] |
| ], |
| / cursor / 2: 3, |
| / more / 3: false |
| } |
| |
| ... |
| |
| (Enough time has passed since |
| the latest received notification) |
| |
| |
| GET coap://as.example.com/revoke/trl?diff=3 |
+---------------------------------------------------------->|
| |
|<----------------------------------------------------------+
| 2.05 Content |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t2)], [] ], |
| [ [bstr.h(t1)], [] ], |
| [ [], [bstr.h(t2)] ] |
| ], |
| / cursor / 2: 3, |
| / more / 3: false |
| } |
| |
| GET coap://as.example.com/revoke/trl?diff=3&cursor=3 |
+---------------------------------------------------------->|
| |
|<----------------------------------------------------------+
| 2.05 Content |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [], |
| / cursor / 2: 3, |
| / more / 3: false |
| } |
| |
Figure 13: Interaction for Diff Query with Observe and "Cursor" Extension
図13：観察と「カーソル」拡張機能を備えたDIFFクエリの相互作用
In this example, the AS supports the "Cursor" extension. Hence, the CBOR map conveyed as payload of the registration response additionally includes a "max_diff_batch" parameter. This specifies the value of MAX_DIFF_BATCH, i.e., the maximum number of diff entries that can be included in a response to a diff query request from this RS.
この例では、ASは「カーソル」拡張機能をサポートします。したがって、登録応答のペイロードとして伝えられたCBORマップには、「max_diff_batch」パラメーターが含まれています。これは、MAX_DIFF_BATCHの値、つまり、このRSからのDIFFクエリ要求への応答に含めることができるDIFFエントリの最大数を指定します。
Figure 14 shows an interaction example of a CoAP observation and a full query of the TRL.
図14は、COAP観測の相互作用の例とTRLの完全なクエリを示しています。
The example also shows some of the notifications from the AS getting lost in transmission; thus, those notifications do not reach the RS.
この例は、伝送で迷子になっているように、通知の一部を示しています。したがって、これらの通知はRsに到達しません。
When this happens, and after a waiting time defined by the application has elapsed, the RS sends a GET request with no Observe Option to the AS, asking the AS to perform a diff query of the TRL. In particular, the RS specifies:
これが発生し、アプリケーションによって定義された待ち時間が経過した後、RSはasにオプションのないgetリクエストを送信し、trlの差分クエリを実行するように依頼します。特に、RSは以下を指定します。
* The 'diff' query parameter with a value of 8, i.e., the maximum number of diff entries to be included in a response from the AS.
* 値が8の「diff」クエリパラメーター、つまりASからの応答に含まれるDIFFエントリの最大数。
* The 'cursor' query parameter with a value of 2, thus requesting from the update collection the series items following the one with the 'index' value equal to 2 (i.e., following the last series item that the RS successfully received in an earlier notification response).
* 値は2の「カーソル」クエリパラメーターであるため、更新コレクションから「インデックス」値が2に等しいものに続くシリーズアイテムをリクエストします（つまり、RSが以前の通知応答で正常に受信した最後のシリーズアイテムに従います）。
The response from the AS conveys a first batch of MAX_DIFF_BATCH = 5 series items from the update collection corresponding to the RS. The AS indicates that further series items are actually available in the update collection by setting the 'more' parameter of the response to true. Also, the 'cursor' parameter of the response is set to 7, i.e., to the 'index' value of the most recent series item included in the response.
ASからの応答は、RSに対応する更新コレクションのMAX_DIFF_BATCH = 5シリーズアイテムの最初のバッチを伝えます。ASは、Trueへの応答の「より多くの」パラメーターを設定することにより、さらなるシリーズアイテムが実際に更新コレクションで利用可能であることを示しています。また、応答の「カーソル」パラメーターは7に設定されます。つまり、応答に含まれる最新のシリーズアイテムの「インデックス」値に設定されます。
After that, the RS follows up with a further diff query request including the 'cursor' query parameter with a value of 7 in order to retrieve the next and last batch of series items from the update collection.
その後、RSは、アップデートコレクションのシリーズアイテムの次のバッチと最後のバッチを取得するために、7の値を持つ「カーソル」クエリパラメーターを含む、さらにDiffクエリリクエストをフォローアップします。
RS AS
| |
| Registration: POST |
+----------------------------------------------------------------->|
| |
|<-----------------------------------------------------------------+
| 2.01 Created |
| Payload: { |
| / ... / |
| "trl_path": "/revoke/trl", |
| "trl_hash": "sha-256", |
| "max_n": 10, |
| "max_diff_batch": 5 |
| } |
| |
| GET coap://as.example.com/revoke/trl/ |
| Observe: 0 |
+----------------------------------------------------------------->|
| |
|<-----------------------------------------------------------------+
| 2.05 Content |
| Observe: 42 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [], |
| / cursor / 2: null |
| } |
| |
| ... |
| |
| (Access tokens t1, t2, t3 issued |
| and successfully submitted to RS) |
| |
| ... |
| |
| (Access tokens t4, t5, t6 issued |
| and successfully submitted to RS) |
| |
| ... |
| |
| (Access token t1 is revoked) |
| |
|<-----------------------------------------------------------------+
| 2.05 Content |
| Observe: 53 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t1)], |
| / cursor / 2: 0 |
| } |
| |
| ... |
| |
| (Access token t2 is revoked) |
| |
|<-----------------------------------------------------------------+
| 2.05 Content |
| Observe: 64 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t1), bstr.h(t2)], |
| / cursor / 2: 1 |
| } |
| |
| ... |
| |
| (Access token t1 expires) |
| |
|<-----------------------------------------------------------------+
| 2.05 Content |
| Observe: 75 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t2)], |
| / cursor / 2: 2 |
| } |
| |
| ... |
| |
| (Access token t2 expires) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 86 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [], |
| / cursor / 2: 3 |
| } |
| |
| ... |
| |
| (Access token t3 is revoked) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 88 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t3)], |
| / cursor / 2: 4 |
| } |
| |
| ... |
| |
| (Access token t4 is revoked) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 89 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t3), bstr.h(t4)], |
| / cursor / 2: 5 |
| } |
| |
| ... |
| |
| (Access token t3 expires) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 90 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t4)], |
| / cursor / 2: 6 |
| } |
| |
| ... |
| |
| (Access token t4 expires) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 91 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [], |
| / cursor / 2: 7 |
| } |
| |
| ... |
| |
| (Access tokens t5 and t6 are revoked) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 92 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t5), bstr.h(t6)], |
| / cursor / 2: 8 |
| } |
| |
| ... |
| |
| (Access token t5 expires) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 93 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [bstr.h(t6)], |
| / cursor / 2: 9 |
| } |
| |
| ... |
| |
| (Access token t6 expires) |
| |
| Lost X <--------------------------------------------------------+
| 2.05 Content |
| Observe: 94 |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / full_set / 0: [], |
| / cursor / 2: 10 |
| } |
| |
| ... |
| |
| (Enough time has passed since |
| the latest received notification) |
| |
| |
| GET coap://as.example.com/revoke/trl?diff=8&cursor=2 |
+----------------------------------------------------------------->|
| |
|<-----------------------------------------------------------------+
| 2.05 Content |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t4)], [] ], |
| [ [bstr.h(t3)], [] ], |
| [ [], [bstr.h(t4)] ], |
| [ [], [bstr.h(t3)] ], |
| [ [bstr.h(t2)], [] ] |
| ], |
| / cursor / 2: 7, |
| / more / 3: true |
| } |
| |
| GET coap://as.example.com/revoke/trl?diff=8&cursor=7 |
+----------------------------------------------------------------->|
| |
|<-----------------------------------------------------------------+
| 2.05 Content |
| Content-Format: 262 (application/ace-trl+cbor) |
| Payload: { |
| / diff_set / 1: [ |
| [ [bstr.h(t6)], [] ], |
| [ [bstr.h(t5)], [] ], |
| [ [], [bstr.h(t5), bstr.h(t6)] ] |
| ], |
| / cursor / 2: 10, |
| / more / 3: false |
| } |
| |
Figure 14: Interaction for Full Query with Observe and Diff Query with "Cursor" Extension
図14：「カーソル」拡張機能を備えたフルクエリの相互作用とdiffクエリ
Ludwig Seitz contributed as a coauthor of initial versions of this document.
Ludwig Seitzは、このドキュメントの最初のバージョンの共著者として貢献しました。
The authors sincerely thank Christian Amsüss, Carsten Bormann, Deb Cooley, Roman Danyliw, Dhruv Dhody, Rikard Höglund, Benjamin Kaduk, David Navarro, Joerg Ott, Marco Rasori, Michael Richardson, Kyle Rose, Zaheduzzaman Sarker, Jim Schaad, Göran Selander, Travis Spencer, Orie Steele, Éric Vyncke, Niklas Widell, Dale Worley, and Paul Wouters for their comments and feedback.
著者は、クリスチャン・アムス、カルステン・ボーマン、デブ・クーリー、ロマン・ダニリウ、ドルフ・ドディ、リカード・ヘグルンド、ベンジャミン・カドゥク、デビッド・ナバロ、ジョーグ・オット、マルコ・ラソリ、マイケル・リチャードソン、カイル・ローズ、ザヘダッツァマン・サルサルク、ザイム・シャアダマン・スペンス、ザイム・シャアダマンスティール、エリック・ヴィンチケ、ニクラス・ワイダー、デール・ウォーリー、ポール・ウーターズのコメントとフィードバック。
The work on this document has been partly supported by the Sweden's Innovation Agency VINNOVA and the Celtic-Next projects CRITISEC and CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).
この文書の作業は、スウェーデンのイノベーションエージェンシーVinnovaとCeltic-Next Projects CritisecとCypressによって部分的にサポートされています。そして、H2020プロジェクトSifis-Home（Grant Agreement 952652）。
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-164 40 Kista
Sweden
Email: marco.tiloca@ri.se
Francesca Palombini
Ericsson AB
Torshamnsgatan 23
SE-164 40 Kista
Sweden
Email: francesca.palombini@ericsson.com
Sebastian Echeverria
CMU SEI
4500 Fifth Avenue
Pittsburgh, PA 15213-2612
United States of America
Email: secheverria@sei.cmu.edu
Grace Lewis
CMU SEI
4500 Fifth Avenue
Pittsburgh, PA 15213-2612
United States of America
Email: glewis@sei.cmu.edu