Internet Engineering Task Force (IETF) L. Lundblade
Request for Comments: 9782 Security Theory LLC
Category: Standards Track H. Birkholz
ISSN: 2070-1721 Fraunhofer SIT
T. Fossati
Linaro
May 2025
The payloads used in Remote ATtestation procedureS (RATS) may require an associated media type for their conveyance, for example, when the payloads are used in RESTful APIs.
リモートの証明手順（RAT）で使用されるペイロードは、たとえば、パイロードがRESTFUL APIで使用される場合、それらの伝達に関連するメディアタイプを必要とする場合があります。
This memo defines media types to be used for Entity Attestation Tokens (EATs).
このメモは、エンティティの証明トークン（EAT）に使用されるメディアタイプを定義します。
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/rfc9782.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9782で取得できます。
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. EAT Types
3. A Media Type Parameter for EAT Profiles
4. Examples
5. Security Considerations
6. IANA Considerations
6.1. +cwt Structured Syntax Suffix
6.1.1. Registry Contents
6.2. Media Types
6.3. application/eat+cwt Registration
6.4. application/eat+jwt Registration
6.5. application/eat-bun+cbor Registration
6.6. application/eat-bun+json Registration
6.7. application/eat-ucs+cbor Registration
6.8. application/eat-ucs+json Registration
6.9. CoAP Content-Format Registrations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
Payloads used in Remote ATtestation procedureS (RATS) [RATS-ARCH] may require an associated media type for their conveyance, for example, when used in RESTful APIs (Figure 1).
リモートの証明手順（RATS）[RATS-ARCH]で使用されるペイロードは、たとえばRESTFUL APIで使用する場合、それらの伝達に関連するメディアタイプを必要とする場合があります（図1）。
.---------------. .----------. .----------.
| Relying Party | | Attester | | Verifier |
'-+-------------' '----+-----' '--------+-'
| | POST /verify |
| | EAT(Evidence) |
| +--------------------------->|
| | 200 OK |
| | EAT(Attestation Results) |
| |<---------------------------+
| POST /auth | |
| EAT(Attestation Results) | |
|<---------------------------+ |
| 201 Created | |
+--------------------------->| |
| | |
| | |
Figure 1: Conveying RATS Conceptual Messages in REST APIs Using EATs
図1：食事を使用して、レストAPIでラットの概念メッセージを伝える
This memo defines media types to be used for EAT payloads [EAT] independently of the RATS Conceptual Message in which they manifest themselves. The objective is to give protocol, API, and application designers a number of readily available and reusable media types for integrating EAT-based messages in their flows, e.g., when using HTTP [BUILD-W-HTTP] or the Constrained Application Protocol (CoAP) [REST-IoT].
このメモは、ペイロードを食べるために使用されるメディアタイプを定義します。目的は、HTTP [build-w-http]または制約付きアプリケーションプロトコル（COAP）[REST-iot]を使用する場合、フローにEATベースのメッセージを統合するために、プロトコル、API、およびアプリケーションデザイナーに、容易に利用可能な再利用可能なメディアタイプを提供することです。
This document uses the terms and concepts defined in [RATS-ARCH].
このドキュメントでは、[rats-arch]で定義されている用語と概念を使用しています。
Figure 2 illustrates the six EAT wire formats and how they relate to each other. [EAT] defines four of them (CBOR Web Token (CWT), JSON Web Token (JWT), and the detached EAT bundle in its JSON and CBOR flavours), while [UCCS] defines the Unprotected CWT Claims Set (UCCS) and Unprotected JWT Claims Sets (UJCS).
図2は、6つのイートワイヤー形式と互いにどのように関連するかを示しています。[EAT]は、そのうちの4つ（CBOR Webトークン（CWT）、JSON Webトークン（JWT）、およびDetached Eat BundleをJSONおよびCBORフレーバー）を定義し、[UCCS]は、保護されていないCWTクレームセット（UCCS）および保護されていないJWTクレームセット（UJCS）を定義します。
.-----.
.----+ UJCS |<-------------------------.
| '-----' |
| |
| .-----. |
+-----+ UCCS |<-----------------------. |
| '-----' | |
| | |
| .------. | |
+-----+ JWT |<------. | |
| '------' .--+---. | |
| | Crypto |<------. | |
| .------. '--+---' | | |
+-----+ CWT |<------' | | |
| '------' .---+-+-+----.
| | Claims-Set +--.
| .------. '---+---+----' |
+-----+ BUN-J |<------. | ^ | v
| '------' .--+---. | | | .------.
| | Bundle |<------' | | | Digest |
| .------. '--+---' | v '--+---'
+-----+ BUN-C |<------' ^ .---+----. |
| '------' | | submod |<---'
| | '--------'
v | ^
.--------------. | |
| Nested-Token +-----------------+------------'
'--------------'
.-------. .---------. .------.
Legend: | Process | | Wire Fmt | | CDDL |
'-------' '---------' '------'
Figure 2: EAT Types
図2：タイプを食べます
EAT is an open and flexible format. To improve interoperability, Section 6 of [EAT] defines the concept of EAT profiles. Profiles are used to constrain the parameters that producers and consumers of a specific EAT profile need to understand in order to interoperate, e.g., the number and type of claims, which serialisation format, the supported signature schemes, etc. EATs carry an in-band profile identifier using the "eat_profile" claim (see Section 4.3.2 of [EAT]). The value of the "eat_profile" claim is either an OID or a URI.
Eatはオープンで柔軟な形式です。相互運用性を向上させるために、[EAT]のセクション6では、EATプロファイルの概念を定義します。プロファイルは、特定のEATプロファイルの生産者と消費者が理解する必要があるパラメーターを制約するために使用されます。たとえば、サポートされている署名スキームなどのクレームの数と種類、EATには「EAT_Profile」クレームを使用して帯域内プロファイル識別子を搭載しています（[EAT]のセクション4.3.2を参照）。「EAT_Profile」クレームの価値は、OIDまたはURIのいずれかです。
The media types defined in this document include an optional "eat_profile" parameter that can be used to mirror the "eat_profile" claim of the transported EAT. Exposing the EAT profile at the API layer allows API routers to dispatch payloads directly to the profile-specific processor without having to snoop into the request bodies. This design also provides a finer-grained and scalable type system that matches the inherent extensibility of EAT. The expectation being that a certain EAT profile automatically obtains a media type derived from the base (e.g., application/eat+cwt) by populating the "eat_profile" parameter with the corresponding OID or URL.
このドキュメントで定義されているメディアタイプには、輸送されたEATの「EAT_Profile」クレームをミラーリングするために使用できるオプションの「EAT_Profile」パラメーターが含まれています。APIレイヤーでEATプロファイルを公開すると、APIルーターは、リクエストボディにスヌープすることなく、プロファイル固有のプロセッサにペイロードを直接発送できます。このデザインは、食事の固有の拡張性に一致するより細かい粒度のあるスケーラブルなタイプシステムも提供します。特定のEATプロファイルは、「EAT_Profile」パラメーターに対応するOIDまたはURLを入力することにより、ベース（アプリケーション/EAT+CWTなど）から派生したメディアタイプを自動的に取得することです。
When the parameterised version of the EAT media type is used in HTTP (for example, with the "Content-Type" and "Accept" headers) and the value is an absolute URI (Section 4.3 of [URI]), the parameter-value (Appendix A of [HTTP]) uses the quoted-string encoding, for example:
EATメディアタイプのパラメーター化されたバージョンがHTTP（たとえば、「コンテンツタイプ」と「受け入れ」ヘッダー）で使用され、値は絶対URI（[URI]のセクション4.3）である場合、パラメーター値（[HTTP]の付録A）は引用符のあるエンコードを使用します。
application/eat+jwt; eat_profile="tag:evidence.example,2022"
アプリケーション/EAT+JWT;eat_profile = "tag：emsimay.example、2022"
Instead, when the EAT profile is an OID, the token encoding (i.e., without quotes) can be used. For example:
代わりに、EatプロファイルがOIDである場合、トークンエンコード（つまり、引用符なし）を使用できます。例えば：
application/eat+cwt; eat_profile=2.999.1.
アプリケーション/EAT+CWT;eat_profile = 2.999.1。
The example in Figure 3 illustrates the usage of EAT media types for transporting attestation evidence as well as negotiating the acceptable format of the attestation result.
図3の例は、証明の証拠を輸送するためのEATメディアタイプの使用と、認証結果の許容可能な形式を交渉することを示しています。
NOTE: '\' line wrapping per RFC 8792
POST /challenge-response/v1/session/1234567890 HTTP/1.1
Host: verifier.example
Accept: application/eat+cwt; eat_profile="tag:ar4si.example,2021"
Content-Type: application/eat+cwt; \
eat_profile="tag:evidence.example,2022"
[ CBOR-encoded EAT w/ eat_profile="tag:evidence.example,2022" ]
Figure 3: Example REST Verification API (request)
図3：例の休憩検証API（リクエスト）
The example in Figure 4 illustrates the usage of EAT media types for transporting attestation results.
図4の例は、証明の結果を輸送するためのEATメディアタイプの使用を示しています。
NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK
Content-Type: application/eat+cwt; \
eat_profile="tag:ar4si.example,2021"
[ CBOR-encoded EAT w/ eat_profile="tag:ar4si.example,2021" ]
Figure 4: Example REST Verification API (response)
図4：休憩検証APIの例（応答）
In both cases, a tag URI [TAG] identifying the profile is carried as an explicit parameter.
どちらの場合も、プロファイルを識別するタグURI [TAG]は、明示的なパラメーターとして運ばれます。
Media types only provide clues to the processing application. The application must verify that the received data matches the expected format, regardless of the advertised media type, and stop further processing on failure. Failing to do so could expose the user to security risks, such as privilege escalation and cross-protocol attacks.
メディアタイプは、処理アプリケーションの手がかりのみを提供します。アプリケーションは、受信したデータが広告されたメディアタイプに関係なく、予想される形式と一致することを確認し、障害時にさらに処理を停止する必要があります。そうしないと、特権のエスカレーションやクロスプロトコル攻撃など、ユーザーがセキュリティリスクにさらされる可能性があります。
The security considerations of [EAT] and [UCCS] apply in full.
[EAT]と[UCCS]のセキュリティ上の考慮事項は完全に適用されます。
When using application/eat-ucs+json and application/eat-ucs+cbor in particular, the reader should review Section 3 of [UCCS], which contains a detailed discussion about the characteristics of a "Secure Channel" for conveyance of such messages.
アプリケーション/EAT-UCS+JSONおよびアプリケーション/EAT-UCS+CBORを使用する場合、読者は[UCCS]のセクション3を確認する必要があります。
IANA has registered +cwt in the "Structured Syntax Suffixes" registry [STRUCT-SYNTAX] in the manner described in [MEDIATYPES]. +cwt can be used to indicate that the media type is encoded as a CWT.
IANAは、[mediatypes]で説明されている方法で、「構造化された構文サフィックス」レジストリ[struct-syntax]に +CWTを登録しています。+CWTを使用して、メディアタイプがCWTとしてエンコードされていることを示すことができます。
Name:
名前：
CBOR Web Token (CWT)
Cbor Webトークン（CWT）
+suffix:
+接尾辞：
+cwt
+cwt
References:
参考文献：
[CWT]
[CWT]
Encoding Considerations:
考慮事項のエンコード：
binary
バイナリ
Interoperability Considerations:
相互運用性の考慮事項：
N/A
n/a
Fragment Identifier Considerations:
フラグメント識別子の考慮事項：
The syntax and semantics of fragment identifiers specified for +cwt SHOULD be as specified for application/cwt. (At the time of publication, there is no fragment identification syntax defined for application/cwt.)
+CWTに指定されたフラグメント識別子の構文とセマンティクスは、アプリケーション/CWTに指定されている必要があります。（出版時には、アプリケーション/CWT用に定義されたフラグメント識別構文はありません。）
Security Considerations:
セキュリティ上の考慮事項：
See Section 8 of [CWT]
[CWT]のセクション8を参照してください
Contact:
接触：
RATS WG mailing list (rats@ietf.org), or IETF Security Area (saag@ietf.org)
ラットWGメーリングリスト（rats@ietf.org）、またはIETFセキュリティエリア（saag@ietf.org）
Author/Change Controller:
著者/変更コントローラー：
Remote ATtestation ProcedureS (RATS) Working Group. The IETF has change control over this registration.
リモート証明手順（ラット）ワーキンググループ。IETFには、この登録を変更することができます。
IANA has registered the following media types in the "Media Types" registry [MEDIA-TYPES].
IANAは、「メディアタイプ」レジストリ[メディアタイプ]に次のメディアタイプを登録しています。
+==============+=====================+=======================+
| Name | Template | Reference |
+==============+=====================+=======================+
| EAT CWT | application/eat+cwt | RFC 9782, Section 6.3 |
+--------------+---------------------+-----------------------+
| EAT JWT | application/eat+jwt | RFC 9782, Section 6.4 |
+--------------+---------------------+-----------------------+
| Detached EAT | application/eat- | RFC 9782, Section 6.5 |
| Bundle CBOR | bun+cbor | |
+--------------+---------------------+-----------------------+
| Detached EAT | application/eat- | RFC 9782, Section 6.6 |
| Bundle JSON | bun+json | |
+--------------+---------------------+-----------------------+
| EAT UCCS | application/eat- | RFC 9782, Section 6.7 |
| | ucs+cbor | |
+--------------+---------------------+-----------------------+
| EAT UJCS | application/eat- | RFC 9782, Section 6.8 |
| | ucs+json | |
+--------------+---------------------+-----------------------+
Table 1: New Media Types
表1：新しいメディアタイプ
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
eat+cwt
EAT+CWT
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
"EAT_Profile"（文字列形式でプロファイルをEAT。OIDSは点線型程度表記を使用する必要があります。パラメーター値はケースで鈍感です。）
Encoding considerations:
考慮事項のエンコード：
binary
バイナリ
Security considerations:
セキュリティ上の考慮事項：
Section 9 of [EAT]
[EAT]のセクション9
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9782
RFC 9782
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Atesters、Verifiers、Andorser、およびReference-Valueプロバイダー、およびHTTP、COAP（S）、およびその他の輸送を介して、Payloadsを譲渡する必要がある当事者に依存しています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
RATS WG mailing list (rats@ietf.org)
ラットWGメーリングリスト（rats@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
Provisional registration:
暫定登録：
no
いいえ
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
eat+jwt
食べる+jwt
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
"EAT_Profile"（文字列形式でプロファイルをEAT。OIDSは点線型程度表記を使用する必要があります。パラメーター値はケースで鈍感です。）
Encoding considerations:
考慮事項のエンコード：
8bit
8ビット
Security considerations:
セキュリティ上の考慮事項：
Section 9 of [EAT] and [BCP225]
[EAT]と[BCP225]のセクション9
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9782
RFC 9782
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Atesters、Verifiers、Andorser、およびReference-Valueプロバイダー、およびHTTP、COAP（S）、およびその他の輸送を介して、Payloadsを譲渡する必要がある当事者に依存しています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
RATS WG mailing list (rats@ietf.org)
ラットWGメーリングリスト（rats@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
Provisional registration:
暫定登録：
no
いいえ
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
eat-bun+cbor
Eat-Bun+Cbor
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
"EAT_Profile"（文字列形式でプロファイルをEAT。OIDSは点線型程度表記を使用する必要があります。パラメーター値はケースで鈍感です。）
Encoding considerations:
考慮事項のエンコード：
binary
バイナリ
Security considerations:
セキュリティ上の考慮事項：
Section 9 of [EAT]
[EAT]のセクション9
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9782
RFC 9782
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Atesters、Verifiers、Andorser、およびReference-Valueプロバイダー、およびHTTP、COAP（S）、およびその他の輸送を介して、Payloadsを譲渡する必要がある当事者に依存しています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
RATS WG mailing list (rats@ietf.org)
ラットWGメーリングリスト（rats@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
Provisional registration:
暫定登録：
no
いいえ
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
eat-bun+json
Eat-Bun+JSON
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
"EAT_Profile"（文字列形式でプロファイルをEAT。OIDSは点線型程度表記を使用する必要があります。パラメーター値はケースで鈍感です。）
Encoding considerations:
考慮事項のエンコード：
Same as [JSON]
[JSON]と同じ
Security considerations:
セキュリティ上の考慮事項：
Section 9 of [EAT]
[EAT]のセクション9
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9782
RFC 9782
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Atesters、Verifiers、Andorser、およびReference-Valueプロバイダー、およびHTTP、COAP（S）、およびその他の輸送を介して、Payloadsを譲渡する必要がある当事者に依存しています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
RATS WG mailing list (rats@ietf.org)
ラットWGメーリングリスト（rats@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
Provisional registration:
暫定登録：
no
いいえ
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
eat-ucs+cbor
EAT-UCS+CBOR
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
"EAT_Profile"（文字列形式でプロファイルをEAT。OIDSは点線型程度表記を使用する必要があります。パラメーター値はケースで鈍感です。）
Encoding considerations:
考慮事項のエンコード：
binary
バイナリ
Security considerations:
セキュリティ上の考慮事項：
Sections 3 and 7 of [UCCS]
[UCCS]のセクション3および7
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9782
RFC 9782
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Atesters、Verifiers、Andorser、およびReference-Valueプロバイダー、およびHTTP、COAP（S）、およびその他の輸送を介して、Payloadsを譲渡する必要がある当事者に依存しています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
RATS WG mailing list (rats@ietf.org)
ラットWGメーリングリスト（rats@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
Provisional registration:
暫定登録：
no
いいえ
Type name:
タイプ名：
application
応用
Subtype name:
サブタイプ名：
eat-ucs+json
EAT-UCS+JSON
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
"eat_profile" (EAT profile in string format. OIDs must use the dotted-decimal notation. The parameter value is case insensitive.)
"EAT_Profile"（文字列形式でプロファイルをEAT。OIDSは点線型程度表記を使用する必要があります。パラメーター値はケースで鈍感です。）
Encoding considerations:
考慮事項のエンコード：
Same as [JSON]
[JSON]と同じ
Security considerations:
セキュリティ上の考慮事項：
Sections 3 and 7 of [UCCS]
[UCCS]のセクション3および7
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9782
RFC 9782
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer EAT payloads over HTTP(S), CoAP(S), and other transports.
Atesters、Verifiers、Andorser、およびReference-Valueプロバイダー、およびHTTP、COAP（S）、およびその他の輸送を介して、Payloadsを譲渡する必要がある当事者に依存しています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
RATS WG mailing list (rats@ietf.org)
ラットWGメーリングリスト（rats@ietf.org）
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なし
Author/Change controller:
著者/変更コントローラー：
IETF
IETF
Provisional registration:
暫定登録：
no
いいえ
IANA has registered the following Content-Format numbers in the "CoAP Content-Formats" registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group [CORE-PARAMS]:
IANAは、「COAPコンテンツフォーマット」レジストリに次のコンテンツフォーマット番号を登録しています。
+==========================+================+=====+===========+
| Content Type | Content Coding | ID | Reference |
+==========================+================+=====+===========+
| application/eat+cwt | - | 263 | RFC 9782 |
+--------------------------+----------------+-----+-----------+
| application/eat+jwt | - | 264 | RFC 9782 |
+--------------------------+----------------+-----+-----------+
| application/eat-bun+cbor | - | 265 | RFC 9782 |
+--------------------------+----------------+-----+-----------+
| application/eat-bun+json | - | 266 | RFC 9782 |
+--------------------------+----------------+-----+-----------+
| application/eat-ucs+cbor | - | 267 | RFC 9781 |
+--------------------------+----------------+-----+-----------+
| application/eat-ucs+json | - | 268 | RFC 9782 |
+--------------------------+----------------+-----+-----------+
Table 2: New Content-Formats
表2：新しいコンテンツフォーマット
[BCP225] Best Current Practice 225,
<https://www.rfc-editor.org/info/bcp225>.
At the time of writing, this BCP comprises the following:
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>.
[CORE-PARAMS]
IANA, "CoAP Content-Formats",
<https://www.iana.org/assignments/core-parameters>.
[CWT] 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>.
[EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[JSON] 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>.
[MEDIA-TYPES]
IANA, "Media Types",
<https://www.iana.org/assignments/media-types>.
[MEDIATYPES]
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>.
[STRUCT-SYNTAX]
IANA, "Structured Syntax Suffixes",
<https://www.iana.org/assignments/media-type-structured-
suffix>.
[UCCS] Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A Concise Binary Object Representation (CBOR)
Tag for Unprotected CBOR Web Token Claims Sets (UCCS)",
RFC 9781, DOI 10.17487/RFC9781, April 2025,
<https://www.rfc-editor.org/info/rfc9781>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[BUILD-W-HTTP]
Best Current Practice 56,
<https://www.rfc-editor.org/info/bcp56>.
At the time of writing, this BCP comprises the following:
Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/info/rfc9205>.
[RATS-ARCH]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[REST-IoT] Keränen, A., Kovatsch, M., and K. Hartke, "Guidance on
RESTful Design for Internet of Things Systems", Work in
Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-16, 23
April 2025, <https://datatracker.ietf.org/doc/html/draft-
irtf-t2trg-rest-iot-16>.
[TAG] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
RFC 4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/info/rfc4151>.
Thank you Carl Wallace, Carsten Bormann, Dave Thaler, Deb Cooley, Éric Vyncke, Francesca Palombini, Jouni Korhonen, Kathleen Moriarty, Michael Richardson, Murray Kucherawy, Orie Steele, Paul Howard, Roman Danyliw, and Tim Hollebeek for your comments and suggestions.
カール・ウォレス、カルステン・ボーマン、デイブ・ターラー、デブ・クーリー、エリック・ヴィンケ、フランチェスカ・パロンビニ、ジュニア・コルホネン、キャスリーン・モリアーティ、マイケル・リチャードソン、マレー・クチェラウィー、オリー・スティール、ポール・ハワード、ロマン・ダニリュー、ティム・ホリーのコメントに感謝します。
Laurence Lundblade
Security Theory LLC
Email: lgl@securitytheory.com
Henk Birkholz
Fraunhofer Institute for Secure Information Technology
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contact
Thomas Fossati
Linaro
Email: thomas.fossati@linaro.org