Internet Engineering Task Force (IETF)                          M. Jones
Request for Comments: 8392                                     Microsoft
Category: Standards Track                                  E. Wahlstroem
ISSN: 2070-1721
                                                              S. Erdtman
                                                              Spotify AB
                                                           H. Tschofenig
                                                                ARM Ltd.
                                                                May 2018
        
Internet Engineering Task Force (IETF)                          M. Jones
Request for Comments: 8392                                     Microsoft
Category: Standards Track                                  E. Wahlstroem
ISSN: 2070-1721
                                                              S. Erdtman
                                                              Spotify AB
                                                           H. Tschofenig
                                                                ARM Ltd.
                                                                May 2018
        

CBOR Web Token (CWT)

CBOR网络令牌(CWT)

Abstract

摘要

CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.

CBOR Web Token(CWT)是一种紧凑的方式,用于表示双方之间要传输的债权。CWT中的声明以简明二进制对象表示(CBOR)编码,CBOR对象签名和加密(COSE)用于增加应用层安全保护。声明是关于主题的声明信息,表示为由声明名称和声明值组成的名称/值对。CWT源于JSON Web令牌(JWT),但使用CBOR而不是JSON。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8392.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问https://www.rfc-editor.org/info/rfc8392.

Copyright Notice

版权公告

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2018 IETF信托基金和确定为文件作者的人员。版权所有。

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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  CBOR-Related Terminology  . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Claims  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Registered Claims . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  iss (Issuer) Claim  . . . . . . . . . . . . . . . . .   5
       3.1.2.  sub (Subject) Claim . . . . . . . . . . . . . . . . .   6
       3.1.3.  aud (Audience) Claim  . . . . . . . . . . . . . . . .   6
       3.1.4.  exp (Expiration Time) Claim . . . . . . . . . . . . .   6
       3.1.5.  nbf (Not Before) Claim  . . . . . . . . . . . . . . .   6
       3.1.6.  iat (Issued At) Claim . . . . . . . . . . . . . . . .   6
       3.1.7.  cti (CWT ID) Claim  . . . . . . . . . . . . . . . . .   6
   4.  Summary of the Claim Names, Keys, and Value Types . . . . . .   7
   5.  CBOR Tags and Claim Values  . . . . . . . . . . . . . . . . .   7
   6.  CWT CBOR Tag  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Creating and Validating CWTs  . . . . . . . . . . . . . . . .   8
     7.1.  Creating a CWT  . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  Validating a CWT  . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  CBOR Web Token (CWT) Claims Registry  . . . . . . . . . .  11
       9.1.1.  Registration Template . . . . . . . . . . . . . . . .  12
       9.1.2.  Initial Registry Contents . . . . . . . . . . . . . .  12
     9.2.  Media Type Registration . . . . . . . . . . . . . . . . .  14
       9.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .  14
     9.3.  CoAP Content-Formats Registration . . . . . . . . . . . .  14
       9.3.1.  Registry Contents . . . . . . . . . . . . . . . . . .  15
     9.4.  CBOR Tag registration . . . . . . . . . . . . . . . . . .  15
       9.4.1.  Registry Contents . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  17
     A.1.  Example CWT Claims Set  . . . . . . . . . . . . . . . . .  17
     A.2.  Example Keys  . . . . . . . . . . . . . . . . . . . . . .  17
       A.2.1.  128-Bit Symmetric Key . . . . . . . . . . . . . . . .  18
       A.2.2.  256-Bit Symmetric Key . . . . . . . . . . . . . . . .  18
       A.2.3.  Elliptic Curve Digital Signature Algorithm (ECDSA)
               P-256 256-Bit COSE Key  . . . . . . . . . . . . . . .  19
     A.3.  Example Signed CWT  . . . . . . . . . . . . . . . . . . .  19
     A.4.  Example MACed CWT . . . . . . . . . . . . . . . . . . . .  20
     A.5.  Example Encrypted CWT . . . . . . . . . . . . . . . . . .  21
     A.6.  Example Nested CWT  . . . . . . . . . . . . . . . . . . .  22
     A.7.  Example MACed CWT with a Floating-Point Value . . . . . .  23
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  CBOR-Related Terminology  . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Claims  . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Registered Claims . . . . . . . . . . . . . . . . . . . .   5
       3.1.1.  iss (Issuer) Claim  . . . . . . . . . . . . . . . . .   5
       3.1.2.  sub (Subject) Claim . . . . . . . . . . . . . . . . .   6
       3.1.3.  aud (Audience) Claim  . . . . . . . . . . . . . . . .   6
       3.1.4.  exp (Expiration Time) Claim . . . . . . . . . . . . .   6
       3.1.5.  nbf (Not Before) Claim  . . . . . . . . . . . . . . .   6
       3.1.6.  iat (Issued At) Claim . . . . . . . . . . . . . . . .   6
       3.1.7.  cti (CWT ID) Claim  . . . . . . . . . . . . . . . . .   6
   4.  Summary of the Claim Names, Keys, and Value Types . . . . . .   7
   5.  CBOR Tags and Claim Values  . . . . . . . . . . . . . . . . .   7
   6.  CWT CBOR Tag  . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Creating and Validating CWTs  . . . . . . . . . . . . . . . .   8
     7.1.  Creating a CWT  . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  Validating a CWT  . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  CBOR Web Token (CWT) Claims Registry  . . . . . . . . . .  11
       9.1.1.  Registration Template . . . . . . . . . . . . . . . .  12
       9.1.2.  Initial Registry Contents . . . . . . . . . . . . . .  12
     9.2.  Media Type Registration . . . . . . . . . . . . . . . . .  14
       9.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .  14
     9.3.  CoAP Content-Formats Registration . . . . . . . . . . . .  14
       9.3.1.  Registry Contents . . . . . . . . . . . . . . . . . .  15
     9.4.  CBOR Tag registration . . . . . . . . . . . . . . . . . .  15
       9.4.1.  Registry Contents . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  17
     A.1.  Example CWT Claims Set  . . . . . . . . . . . . . . . . .  17
     A.2.  Example Keys  . . . . . . . . . . . . . . . . . . . . . .  17
       A.2.1.  128-Bit Symmetric Key . . . . . . . . . . . . . . . .  18
       A.2.2.  256-Bit Symmetric Key . . . . . . . . . . . . . . . .  18
       A.2.3.  Elliptic Curve Digital Signature Algorithm (ECDSA)
               P-256 256-Bit COSE Key  . . . . . . . . . . . . . . .  19
     A.3.  Example Signed CWT  . . . . . . . . . . . . . . . . . . .  19
     A.4.  Example MACed CWT . . . . . . . . . . . . . . . . . . . .  20
     A.5.  Example Encrypted CWT . . . . . . . . . . . . . . . . . .  21
     A.6.  Example Nested CWT  . . . . . . . . . . . . . . . . . . .  22
     A.7.  Example MACed CWT with a Floating-Point Value . . . . . .  23
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25
        
1. Introduction
1. 介绍

The JSON Web Token (JWT) [RFC7519] is a standardized security token format that has found use in OAuth 2.0 and OpenID Connect deployments, among other applications. JWT uses JSON Web Signature (JWS) [RFC7515] and JSON Web Encryption (JWE) [RFC7516] to secure the contents of the JWT, which is a set of claims represented in JSON. The use of JSON for encoding information is popular for Web and native applications, but it is considered inefficient for some Internet of Things (IoT) systems that use low-power radio technologies.

JSON Web令牌(JWT)[RFC7519]是一种标准化的安全令牌格式,已在OAuth 2.0和OpenID Connect部署以及其他应用程序中使用。JWT使用JSON Web签名(JWS)[RFC7515]和JSON Web加密(JWE)[RFC7516]来保护JWT的内容,JWT是用JSON表示的一组声明。使用JSON编码信息在Web和本机应用程序中非常流行,但对于某些使用低功率无线电技术的物联网(IoT)系统来说,这种方法被认为效率低下。

An alternative encoding of claims is defined in this document. Instead of using JSON, as provided by JWTs, this specification uses CBOR [RFC7049] and calls this new structure "CBOR Web Token (CWT)", which is a compact means of representing secured claims to be transferred between two parties. CWT is closely related to JWT. It references the JWT claims and both its name and pronunciation are derived from JWT (the suggested pronunciation of CWT is the same as the English word "cot"). To protect the claims contained in CWTs, the CBOR Object Signing and Encryption (COSE) [RFC8152] specification is used.

本文件中定义了权利要求的替代编码。本规范没有使用JWTs提供的JSON,而是使用CBOR[RFC7049]并将这种新结构称为“CBOR Web Token(CWT)”,这是一种表示要在双方之间转移的担保债权的紧凑方式。CWT与JWT密切相关。它引用了JWT的权利要求,其名称和发音均源自JWT(CWT的建议发音与英语单词“cot”相同)。为了保护CWTs中包含的声明,使用了CBOR对象签名和加密(COSE)[RFC8152]规范。

1.1. CBOR-Related Terminology
1.1. CBOR相关术语

In JSON, maps are called objects and only have one kind of map key: a string. CBOR uses strings, negative integers, and unsigned integers as map keys. The integers are used for compactness of encoding and easy comparison. The inclusion of strings allows for an additional range of short encoded values to be used.

在JSON中,映射称为对象,并且只有一种映射键:字符串。CBOR使用字符串、负整数和无符号整数作为映射键。整数用于压缩编码和易于比较。字符串的包含允许使用额外范围的短编码值。

2. Terminology
2. 术语

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.

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时(如图所示)应按照BCP 14[RFC2119][RFC8174]所述进行解释。

This document reuses terminology from JWT [RFC7519] and COSE [RFC8152].

本文档重用JWT[RFC7519]和COSE[RFC8152]中的术语。

StringOrURI The "StringOrURI" term in this specification has the same meaning and processing rules as the JWT "StringOrURI" term defined in Section 2 of [RFC7519], except that it is represented as a CBOR text string instead of a JSON text string.

StringOrURI本规范中的“StringOrURI”术语与[RFC7519]第2节中定义的JWT“StringOrURI”术语具有相同的含义和处理规则,只是它表示为CBOR文本字符串而不是JSON文本字符串。

NumericDate The "NumericDate" term in this specification has the same meaning and processing rules as the JWT "NumericDate" term defined in Section 2 of [RFC7519], except that it is represented as a CBOR numeric date (from Section 2.4.1 of [RFC7049]) instead of a JSON number. The encoding is modified so that the leading tag 1 (epoch-based date/time) MUST be omitted.

NumericDate本规范中的“NumericDate”术语与[RFC7519]第2节中定义的JWT“NumericDate”术语具有相同的含义和处理规则,但其表示为CBOR数字日期(来自[RFC7049]第2.4.1节),而不是JSON编号。修改了编码,因此必须省略前导标记1(基于历元的日期/时间)。

Claim Name The human-readable name used to identify a claim.

索赔名称用于标识索赔的人类可读名称。

Claim Key The CBOR map key used to identify a claim.

索赔密钥用于标识索赔的CBOR映射密钥。

Claim Value The CBOR map value representing the value of the claim.

声明值表示声明值的CBOR映射值。

CWT Claims Set The CBOR map that contains the claims conveyed by the CWT.

CWT索赔设置包含CWT传达的索赔的CBOR地图。

3. Claims
3. 声称

The set of claims that a CWT must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of CWTs will require implementations to understand and process some claims in particular ways. However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.

CWT必须包含才能被视为有效的声明集取决于上下文,不在本规范的范围内。CWT的特定应用将要求实现以特定方式理解和处理某些声明。然而,在没有此类需求的情况下,必须忽略所有未被实现理解的声明。

To keep CWTs as small as possible, the Claim Keys are represented using integers or text strings. Section 4 summarizes all keys used to identify the claims defined in this document.

为了使CWT尽可能小,使用整数或文本字符串表示声明键。第4节总结了用于识别本文件中定义的索赔的所有关键点。

3.1. Registered Claims
3.1. 登记债权

None of the claims defined below are intended to be mandatory to use or implement. Rather, they provide a starting point for a set of useful, interoperable claims. Applications using CWTs should define which specific claims they use and when they are required or optional.

以下定义的任何权利要求都不是强制使用或实施的。相反,它们为一组有用的、可互操作的声明提供了起点。使用CWT的应用程序应该定义它们使用的特定声明以及它们是必需的还是可选的。

3.1.1. iss (Issuer) Claim
3.1.1. iss(发行人)索赔

The "iss" (issuer) claim has the same meaning and processing rules as the "iss" claim defined in Section 4.1.1 of [RFC7519], except that the value is a StringOrURI, as defined in Section 2 of this specification. The Claim Key 1 is used to identify this claim.

“iss”(发行人)声明与[RFC7519]第4.1.1节中定义的“iss”声明具有相同的含义和处理规则,但该值为本规范第2节中定义的StringOrURI。索赔编号1用于识别该索赔。

3.1.2. sub (Subject) Claim
3.1.2. 次级(主题)索赔

The "sub" (subject) claim has the same meaning and processing rules as the "sub" claim defined in Section 4.1.2 of [RFC7519], except that the value is a StringOrURI, as defined in Section 2 of this specification. The Claim Key 2 is used to identify this claim.

“子”(主体)权利要求与[RFC7519]第4.1.2节中定义的“子”权利要求具有相同的含义和处理规则,但该值是本规范第2节中定义的StringOrURI。索赔编号2用于识别该索赔。

3.1.3. aud (Audience) Claim
3.1.3. 澳元(观众)索赔

The "aud" (audience) claim has the same meaning and processing rules as the "aud" claim defined in Section 4.1.3 of [RFC7519], except that the value of the audience claim is a StringOrURI when it is not an array or each of the audience array element values is a StringOrURI when the audience claim value is an array. (StringOrURI is defined in Section 2 of this specification.) The Claim Key 3 is used to identify this claim.

“aud”(观众)声明与[RFC7519]第4.1.3节中定义的“aud”声明具有相同的含义和处理规则,但观众声明的值不是数组时为StringOrURI,或者观众声明值是数组时,每个观众数组元素值都是StringOrURI。(StringOrURI在本规范第2节中定义。)权利要求编号3用于识别该权利要求。

3.1.4. exp (Expiration Time) Claim
3.1.4. exp(到期时间)索赔

The "exp" (expiration time) claim has the same meaning and processing rules as the "exp" claim defined in Section 4.1.4 of [RFC7519], except that the value is a NumericDate, as defined in Section 2 of this specification. The Claim Key 4 is used to identify this claim.

“exp”(到期时间)索赔与[RFC7519]第4.1.4节中定义的“exp”索赔具有相同的含义和处理规则,但数值是本规范第2节中定义的数字日期。索赔编号4用于识别该索赔。

3.1.5. nbf (Not Before) Claim
3.1.5. nbf(非之前)索赔

The "nbf" (not before) claim has the same meaning and processing rules as the "nbf" claim defined in Section 4.1.5 of [RFC7519], except that the value is a NumericDate, as defined in Section 2 of this specification. The Claim Key 5 is used to identify this claim.

“nbf”(非之前)权利要求与[RFC7519]第4.1.5节中定义的“nbf”权利要求具有相同的含义和处理规则,但数值是本规范第2节中定义的数字日期。索赔编号5用于识别该索赔。

3.1.6. iat (Issued At) Claim
3.1.6. iat(签发日期)索赔

The "iat" (issued at) claim has the same meaning and processing rules as the "iat" claim defined in Section 4.1.6 of [RFC7519], except that the value is a NumericDate, as defined in Section 2 of this specification. The Claim Key 6 is used to identify this claim.

“iat”(于发布)索赔与[RFC7519]第4.1.6节中定义的“iat”索赔具有相同的含义和处理规则,但数值是本规范第2节中定义的数字日期。索赔编号6用于识别该索赔。

3.1.7. cti (CWT ID) Claim
3.1.7. cti(CWT ID)索赔

The "cti" (CWT ID) claim has the same meaning and processing rules as the "jti" claim defined in Section 4.1.7 of [RFC7519], except that the value is a byte string. The Claim Key 7 is used to identify this claim.

“cti”(CWT ID)声明与[RFC7519]第4.1.7节中定义的“jti”声明具有相同的含义和处理规则,不同之处在于该值是字节字符串。索赔编号7用于识别该索赔。

4. Summary of the Claim Names, Keys, and Value Types
4. 声明名称、键和值类型的摘要
             +------+-----+----------------------------------+
             | Name | Key | Value Type                       |
             +------+-----+----------------------------------+
             | iss  | 1   | text string                      |
             | sub  | 2   | text string                      |
             | aud  | 3   | text string                      |
             | exp  | 4   | integer or floating-point number |
             | nbf  | 5   | integer or floating-point number |
             | iat  | 6   | integer or floating-point number |
             | cti  | 7   | byte string                      |
             +------+-----+----------------------------------+
        
             +------+-----+----------------------------------+
             | Name | Key | Value Type                       |
             +------+-----+----------------------------------+
             | iss  | 1   | text string                      |
             | sub  | 2   | text string                      |
             | aud  | 3   | text string                      |
             | exp  | 4   | integer or floating-point number |
             | nbf  | 5   | integer or floating-point number |
             | iat  | 6   | integer or floating-point number |
             | cti  | 7   | byte string                      |
             +------+-----+----------------------------------+
        

Table 1: Summary of the Claim Names, Keys, and Value Types

表1:索赔名称、键和值类型摘要

5. CBOR Tags and Claim Values
5. CBOR标签和索赔值

The claim values defined in this specification MUST NOT be prefixed with any CBOR tag. For instance, while CBOR tag 1 (epoch-based date/ time) could logically be prefixed to values of the "exp", "nbf", and "iat" claims, this is unnecessary since the representation of the claim values is already specified by the claim definitions. Tagging claim values would only take up extra space without adding information. However, this does not prohibit future claim definitions from requiring the use of CBOR tags for those specific claims.

本规范中定义的索赔值不得以任何CBOR标记作为前缀。例如,虽然CBOR标记1(基于历元的日期/时间)可以逻辑上前缀为“exp”、“nbf”和“iat”索赔的值,但这是不必要的,因为索赔定义已经指定了索赔值的表示形式。标记声明值只会占用额外的空间,而不会添加信息。然而,这并不禁止未来的权利要求定义要求对这些特定权利要求使用CBOR标签。

6. CWT CBOR Tag
6. CWT-CBOR标签

How to determine that a CBOR data structure is a CWT is application dependent. In some cases, this information is known from the application context, such as from the position of the CWT in a data structure at which the value must be a CWT. One method of indicating that a CBOR object is a CWT is the use of the "application/cwt" content type by a transport protocol.

如何确定CBOR数据结构是CWT取决于应用程序。在某些情况下,这些信息是从应用程序上下文知道的,例如从CWT在数据结构中的位置知道的,在该数据结构中,值必须是CWT。指示CBOR对象是CWT的一种方法是通过传输协议使用“应用程序/CWT”内容类型。

This section defines the CWT CBOR tag as another means for applications to declare that a CBOR data structure is a CWT. Its use is optional and is intended for use in cases in which this information would not otherwise be known.

本节将CWT CBOR标记定义为应用程序声明CBOR数据结构为CWT的另一种方法。它的使用是可选的,目的是在不知道该信息的情况下使用。

If present, the CWT tag MUST prefix a tagged object using one of the COSE CBOR tags. In this example, the COSE_Mac0 tag is used. The actual COSE_Mac0 object has been excluded from this example.

如果存在,CWT标记必须使用COSE CBOR标记之一作为标记对象的前缀。在本例中,使用COSE_Mac0标记。实际的COSE_Mac0对象已从该示例中排除。

   / CWT CBOR tag / 61(
     / COSE_Mac0 CBOR tag / 17(
       / COSE_Mac0 object /
     )
   )
        
   / CWT CBOR tag / 61(
     / COSE_Mac0 CBOR tag / 17(
       / COSE_Mac0 object /
     )
   )
        

Figure 1: Example of CWT Tag Usage

图1:CWT标记使用示例

7. Creating and Validating CWTs
7. 创建和验证CWT
7.1. Creating a CWT
7.1. 创建CWT

To create a CWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.

要创建CWT,请执行以下步骤。在步骤的输入和输出之间没有依赖关系的情况下,步骤的顺序并不重要。

1. Create a CWT Claims Set containing the desired claims.

1. 创建包含所需声明的CWT声明集。

2. Let the Message be the binary representation of the CWT Claims Set.

2. 让消息成为CWT声明集的二进制表示形式。

3. Create a COSE Header containing the desired set of Header Parameters. The COSE Header MUST be valid per the [RFC8152] specification.

3. 创建包含所需标头参数集的COSE标头。根据[RFC8152]规范,COSE标头必须有效。

4. Depending upon whether the CWT is signed, MACed, or encrypted, there are three cases:

4. 根据CWT是经过签名、MACE还是加密,有三种情况:

* If the CWT is signed, create a COSE_Sign/COSE_Sign1 object using the Message as the COSE_Sign/COSE_Sign1 Payload; all steps specified in [RFC8152] for creating a COSE_Sign/ COSE_Sign1 object MUST be followed.

* 如果CWT已签名,则使用该消息作为COSE_签名/COSE_签名1有效负载创建COSE_签名/COSE_签名1对象;必须遵循[RFC8152]中规定的创建COSE_符号/COSE_符号1对象的所有步骤。

* Else, if the CWT is MACed, create a COSE_Mac/COSE_Mac0 object using the Message as the COSE_Mac/COSE_Mac0 Payload; all steps specified in [RFC8152] for creating a COSE_Mac/COSE_Mac0 object MUST be followed.

* 否则,如果CWT被MACed,则使用该消息作为COSE_Mac/COSE_Mac0有效载荷创建一个COSE_Mac/COSE_Mac0对象;必须遵循[RFC8152]中规定的创建COSE_Mac/COSE_Mac0对象的所有步骤。

* Else, if the CWT is a COSE_Encrypt/COSE_Encrypt0 object, create a COSE_Encrypt/COSE_Encrypt0 using the Message as the plaintext for the COSE_Encrypt/COSE_Encrypt0 object; all steps specified in [RFC8152] for creating a COSE_Encrypt/ COSE_Encrypt0 object MUST be followed.

* 否则,如果CWT是COSE_Encrypt/COSE_Encrypt0对象,则使用消息作为COSE_Encrypt/COSE_Encrypt0对象的明文来创建COSE_Encrypt/COSE_Encrypt0;必须遵循[RFC8152]中为创建COSE_Encrypt/COSE_Encrypt0对象指定的所有步骤。

5. If a nested signing, MACing, or encryption operation will be performed, let the Message be the tagged COSE_Sign/COSE_Sign1, COSE_Mac/COSE_Mac0, or COSE_Encrypt/COSE_Encrypt0, and return to Step 3.

5. 如果要执行嵌套签名、MACing或加密操作,则将消息设为标记的COSE_Sign/COSE_Sign1、COSE_Mac/COSE_Mac0或COSE_Encrypt/COSE_Encrypt0,然后返回步骤3。

6. If needed by the application, prepend the COSE object with the appropriate COSE CBOR tag to indicate the type of the COSE object. If needed by the application, prepend the COSE object with the CWT CBOR tag to indicate that the COSE object is a CWT.

6. 如果应用程序需要,请在COSE对象前面加上适当的COSE CBOR标记,以指示COSE对象的类型。如果应用程序需要,请在COSE对象前面加上CWT CBOR标记,以指示COSE对象是CWT。

7.2. Validating a CWT
7.2. 验证CWT

When validating a CWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of the listed steps fail, then the CWT MUST be rejected -- that is, treated by the application as invalid input.

验证CWT时,将执行以下步骤。在步骤的输入和输出之间没有依赖关系的情况下,步骤的顺序并不重要。如果列出的任何步骤失败,那么必须拒绝CWT——也就是说,应用程序将其视为无效输入。

1. Verify that the CWT is a valid CBOR object.

1. 验证CWT是否为有效的CBOR对象。

2. If the object begins with the CWT CBOR tag, remove it and verify that one of the COSE CBOR tags follows it.

2. 如果该对象以CWT CBOR标记开头,请将其删除,并验证其中一个COSE CBOR标记是否紧随其后。

3. If the object is tagged with one of the COSE CBOR tags, remove it and use it to determine the type of the CWT, COSE_Sign/ COSE_Sign1, COSE_Mac/COSE_Mac0, or COSE_Encrypt/COSE_Encrypt0. If the object does not have a COSE CBOR tag, the COSE message type is determined from the application context.

3. 如果对象使用COSE CBOR标记之一进行标记,请将其移除并使用它确定CWT、COSE_符号/COSE_符号1、COSE_Mac/COSE_Mac0或COSE_加密/COSE_加密0的类型。如果对象没有COSE CBOR标记,则根据应用程序上下文确定COSE消息类型。

4. Verify that the resulting COSE Header includes only parameters and values whose syntax and semantics are both understood and supported or that are specified as being ignored when not understood.

4. 验证生成的COSE标头是否仅包含语法和语义都已理解和支持的参数和值,或者在不理解时指定为忽略的参数和值。

5. Depending upon whether the CWT is a signed, MACed, or encrypted, there are three cases:

5. 根据CWT是签名、MACE还是加密的,有三种情况:

* If the CWT is a COSE_Sign/COSE_Sign1, follow the steps specified in Section 4 of [RFC8152] ("Signing Objects") for validating a COSE_Sign/COSE_Sign1 object. Let the Message be the COSE_Sign/COSE_Sign1 payload.

* 如果CWT是COSE_符号/COSE_符号1,请按照[RFC8152](“签名对象”)第4节中规定的步骤验证COSE_符号/COSE_符号1对象。让消息成为COSE_Sign/COSE_Sign1有效负载。

* Else, if the CWT is a COSE_Mac/COSE_Mac0, follow the steps specified in Section 6 of [RFC8152] ("MAC Objects") for validating a COSE_Mac/COSE_Mac0 object. Let the Message be the COSE_Mac/COSE_Mac0 payload.

* 否则,如果CWT是COSE_Mac/COSE_Mac0,请按照[RFC8152](“Mac对象”)第6节中指定的步骤验证COSE_Mac/COSE_Mac0对象。让消息成为COSE_Mac/COSE_Mac0有效负载。

* Else, if the CWT is a COSE_Encrypt/COSE_Encrypt0 object, follow the steps specified in Section 5 of [RFC8152] ("Encryption Objects") for validating a COSE_Encrypt/ COSE_Encrypt0 object. Let the Message be the resulting plaintext.

* 否则,如果CWT是COSE_Encrypt/COSE_Encrypt0对象,请按照[RFC8152](“加密对象”)第5节中指定的步骤验证COSE_Encrypt/COSE_Encrypt0对象。让消息成为结果明文。

6. If the Message begins with a COSE CBOR tag, then the Message is a CWT that was the subject of nested signing, MACing, or encryption operations. In this case, return to Step 1, using the Message as the CWT.

6. 如果消息以COSE CBOR标记开头,则该消息是一个CWT,它是嵌套签名、MACing或加密操作的主题。在这种情况下,返回步骤1,将消息用作CWT。

7. Verify that the Message is a valid CBOR map; let the CWT Claims Set be this CBOR map.

7. 验证消息是否为有效的CBOR映射;让CWT索赔设置为此CBOR映射。

8. Security Considerations
8. 安全考虑

The security of the CWT relies upon on the protections offered by COSE. Unless the claims in a CWT are protected, an adversary can modify, add, or remove claims.

CWT的安全依赖于COSE提供的保护。除非CWT中的声明受到保护,否则对手可以修改、添加或删除声明。

Since the claims conveyed in a CWT may be used to make authorization decisions, it is not only important to protect the CWT in transit but also to ensure that the recipient can authenticate the party that assembled the claims and created the CWT. Without trust of the recipient in the party that created the CWT, no sensible authorization decision can be made. Furthermore, the creator of the CWT needs to carefully evaluate each claim value prior to including it in the CWT so that the recipient can be assured of the validity of the information provided.

由于CWT中传达的权利要求可用于作出授权决定,因此,不仅要保护运输中的CWT,而且要确保接收者能够认证组装权利要求并创建CWT的一方。如果接收方不信任创建CWT的一方,则无法做出合理的授权决定。此外,CWT的创建者需要在将每项索赔价值纳入CWT之前仔细评估其价值,以便接收方能够确保所提供信息的有效性。

Syntactically, the signing and encryption operations for Nested CWTs may be applied in any order; however, if both signing and encryption are necessary, producers normally should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.

在语法上,嵌套CWT的签名和加密操作可以以任何顺序应用;但是,如果同时需要签名和加密,生产者通常应该对消息进行签名,然后对结果进行加密(从而对签名进行加密)。这可以防止签名被剥离的攻击,只留下加密的消息,并为签名者提供隐私。此外,在许多管辖区,加密文本上的签名被视为无效。

9. IANA Considerations
9. IANA考虑
9.1. CBOR Web Token (CWT) Claims Registry
9.1. CBOR网络令牌(CWT)索赔登记处

IANA has created the "CBOR Web Token (CWT) Claims" registry [IANA.CWT.Claims].

IANA已经创建了“CBOR网络令牌(CWT)声明”注册表[IANA.CWT.Claims]。

Registration requests are evaluated using the criteria described in the Claim Key instructions in the registration template below after a three-week review period on the cwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts [RFC8126]. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.

在对cwt reg进行三周审查后,使用以下注册模板中索赔密钥说明中描述的标准评估注册请求-review@ietf.org邮件列表,根据一名或多名指定专家的建议[RFC8126]。但是,为了允许在发布之前分配值,指定专家在确信此类规范将发布后,可批准注册。

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register claim: example"). Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.

发送至邮件列表供审查的注册请求应使用适当的主题(例如,“注册请求:示例”)。超过21天未确定的注册请求可提请IESG注意(使用iesg@ietf.org邮件列表)以供解决。

Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear. Registrations for the limited set of values between -256 and 255 and strings of length 1 are to be restricted to claims with general applicability.

指定专家应适用的标准包括确定拟议登记是否与现有功能重复,是否可能具有普遍适用性,或是否仅对单一申请有用,以及登记说明是否清楚。对于-256到255之间的有限值集和长度为1的字符串的注册将限于具有一般适用性的权利要求。

IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

IANA必须只接受指定专家的注册更新,并将所有注册请求发送至审查邮件列表。

It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification in order to enable broadly informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.

建议任命多名指定专家,他们能够代表使用本规范的不同应用的观点,以便对注册决定进行广泛知情的审查。如果注册决定可能被视为对某一专家造成利益冲突,该专家应服从其他专家的判断。

Since a high degree of overlap is expected between the contents of the "CBOR Web Token (CWT) Claims" registry and the "JSON Web Token Claims" registry, overlap in the corresponding pools of Designated Experts would be useful to help ensure that an appropriate level of coordination between the registries is maintained.

由于“CBOR Web Token(CWT)索赔”登记册和“JSON Web Token索赔”登记册的内容预计会有高度重叠,相应的指定专家库中的重叠将有助于确保登记册之间保持适当的协调水平。

9.1.1. Registration Template
9.1.1. 注册模板

Claim Name: The human-readable name requested (e.g., "iss").

索赔名称:请求的人类可读名称(例如,“iss”)。

Claim Description: Brief description of the claim (e.g., "Issuer").

索赔说明:索赔的简要说明(例如,“发行人”)。

JWT Claim Name: Claim Name of the equivalent JWT claim, as registered in [IANA.JWT.Claims]. CWT claims should normally have a corresponding JWT claim. If a corresponding JWT claim would not make sense, the Designated Experts can choose to accept registrations for which the JWT Claim Name is listed as "N/A".

JWT索赔名称:在[IANA.JWT.Claims]中注册的等效JWT索赔的索赔名称。CWT索赔通常应有相应的JWT索赔。如果相应的JWT索赔没有意义,指定专家可以选择接受JWT索赔名称列为“不适用”的注册。

Claim Key: CBOR map key for the claim. Different ranges of values use different registration policies [RFC8126]. Integer values from -256 to 255 and strings of length 1 are designated as Standards Action. Integer values from -65536 to -257 and from 256 to 65535 along with strings of length 2 are designated as Specification Required. Integer values greater than 65535 and strings of length greater than 2 are designated as Expert Review. Integer values less than -65536 are marked as Private Use.

声明密钥:声明的CBOR映射密钥。不同的值范围使用不同的注册策略[RFC8126]。从-256到255的整数值和长度为1的字符串被指定为标准操作。从-65536到-257和从256到65535的整数值以及长度为2的字符串被指定为所需的规范。大于65535的整数值和长度大于2的字符串被指定为专家评审。小于-65536的整数值标记为专用。

Claim Value Type(s): CBOR types that can be used for the claim value.

索赔值类型:可用于索赔值的CBOR类型。

Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

更改控制器:对于标准跟踪RFC,请列出“IESG”。对于其他人,请提供责任方的名称。还可以包括其他详细信息(例如,邮政地址、电子邮件地址、主页URI)。

Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

规范文档:指指定参数的一个或多个文档,最好包括可用于检索文档副本的URI。也可以包括相关章节的指示,但不需要。

9.1.2. Initial Registry Contents
9.1.2. 初始注册表内容

o Claim Name: (RESERVED) o Claim Description: This registration reserves the key value 0. o JWT Claim Name: N/A o Claim Key: 0 o Claim Value Type(s): N/A o Change Controller: IESG o Specification Document(s): [RFC8392]

o 声明名称:(保留)o声明描述:此注册保留键值0。o JWT索赔名称:不适用o索赔密钥:0 o索赔值类型:不适用o变更控制器:IESG o规范文档:[RFC8392]

o Claim Name: iss o Claim Description: Issuer o JWT Claim Name: iss o Claim Key: 1 o Claim Value Type(s): text string o Change Controller: IESG o Specification Document(s): Section 3.1.1 of [RFC8392]

o 索赔名称:iss o索赔描述:发卡机构o JWT索赔名称:iss o索赔密钥:1 o索赔值类型:文本字符串o变更控制器:IESG o规范文件:[RFC8392]第3.1.1节

o Claim Name: sub o Claim Description: Subject o JWT Claim Name: sub o Claim Key: 2 o Claim Value Type(s): text string o Change Controller: IESG o Specification Document(s): Section 3.1.2 of [RFC8392]

o 索赔名称:子o索赔描述:主题o JWT索赔名称:子o索赔关键字:2 o索赔值类型:文本字符串o变更控制器:IESG o规范文件:[RFC8392]第3.1.2节

o Claim Name: aud o Claim Description: Audience o JWT Claim Name: aud o Claim Key: 3 o Claim Value Type(s): text string o Change Controller: IESG o Specification Document(s): Section 3.1.3 of [RFC8392]

o 索赔名称:aud o索赔描述:受众o JWT索赔名称:aud o索赔关键字:3 o索赔值类型:文本字符串o变更控制器:IESG o规范文件:[RFC8392]第3.1.3节

o Claim Name: exp o Claim Description: Expiration Time o JWT Claim Name: exp o Claim Key: 4 o Claim Value Type(s): integer or floating-point number o Change Controller: IESG o Specification Document(s): Section 3.1.4 of [RFC8392]

o 索赔名称:exp o索赔描述:到期时间o JWT索赔名称:exp o索赔密钥:4 o索赔值类型:整数或浮点数o变更控制器:IESG o规范文件:[RFC8392]第3.1.4节

o Claim Name: nbf o Claim Description: Not Before o JWT Claim Name: nbf o Claim Key: 5 o Claim Value Type(s): integer or floating-point number o Change Controller: IESG o Specification Document(s): Section 3.1.5 of [RFC8392]

o 索赔名称:nbf o索赔描述:不在o JWT之前索赔名称:nbf o索赔密钥:5 o索赔值类型:整数或浮点数o变更控制器:IESG o规范文件:[RFC8392]第3.1.5节

o Claim Name: iat o Claim Description: Issued At o JWT Claim Name: iat o Claim Key: 6 o Claim Value Type(s): integer or floating-point number o Change Controller: IESG o Specification Document(s): Section 3.1.6 of [RFC8392]

o 索赔名称:iat o索赔描述:在o JWT发布索赔名称:iat o索赔密钥:6 o索赔值类型:整数或浮点数o变更控制器:IESG o规范文件:[RFC8392]第3.1.6节

o Claim Name: cti o Claim Description: CWT ID o JWT Claim Name: jti o Claim Key: 7 o Claim Value Type(s): byte string o Change Controller: IESG o Specification Document(s): Section 3.1.7 of [RFC8392]

o 索赔名称:cti o索赔描述:CWT ID o JWT索赔名称:jti o索赔密钥:7 o索赔值类型:字节字符串o变更控制器:IESG o规范文件:[RFC8392]第3.1.7节

9.2. Media Type Registration
9.2. 媒体类型注册

IANA has registered the "application/cwt" media type in the "Media Types" registry [IANA.MediaTypes] in the manner described in RFC 6838 [RFC6838], which can be used to indicate that the content is a CWT.

IANA已按照RFC 6838[RFC6838]中所述的方式在“媒体类型”注册表[IANA.MediaTypes]中注册了“应用程序/cwt”媒体类型,可用于指示内容是cwt。

9.2.1. Registry Contents
9.2.1. 注册表内容

o Type name: application o Subtype name: cwt o Required parameters: N/A o Optional parameters: N/A o Encoding considerations: binary o Security considerations: See the Security Considerations section of [RFC8392] o Interoperability considerations: N/A o Published specification: [RFC8392] o Applications that use this media type: IoT applications sending security tokens over HTTP(S), CoAP(S), and other transports. o Fragment identifier considerations: N/A o Additional information:

o 类型名称:应用程序o子类型名称:cwt o必需参数:N/A o可选参数:N/A o编码注意事项:二进制o安全注意事项:请参阅[RFC8392]o互操作性注意事项:N/A o已发布规范:[RFC8392]o使用此媒体类型的应用程序:通过HTTP、CoAP和其他传输发送安全令牌的物联网应用程序。o片段标识符注意事项:不适用o其他信息:

         Magic number(s): N/A
         File extension(s): N/A
         Macintosh file type code(s): N/A
        
         Magic number(s): N/A
         File extension(s): N/A
         Macintosh file type code(s): N/A
        

o Person & email address to contact for further information: IESG, iesg@ietf.org o Intended usage: COMMON o Restrictions on usage: none o Author: Michael B. Jones, mbj@microsoft.com o Change controller: IESG o Provisional registration? No

o 联系人和电子邮件地址,以获取更多信息:IESG,iesg@ietf.orgo预期用途:常见o使用限制:无o作者:Michael B.Jones,mbj@microsoft.como变更控制员:IESG o临时注册?不

9.3. CoAP Content-Formats Registration
9.3. 内容格式注册

IANA has registered the CoAP Content-Format ID for the "application/ cwt" media type in the "CoAP Content-Formats" registry [IANA.CoAP.Content-Formats].

IANA已在“CoAP内容格式”注册表[IANA.CoAP.Content Formats]中注册了“application/cwt”媒体类型的CoAP内容格式ID。

9.3.1. Registry Contents
9.3.1. 注册表内容

o Media Type: application/cwt o Encoding: - o Id: 61 o Reference: [RFC8392]

o 媒体类型:应用程序/cwt o编码:-o Id:61 o参考:[RFC8392]

9.4. CBOR Tag registration
9.4. CBOR标签注册

IANA has registered the CWT CBOR tag in the "CBOR Tags" registry [IANA.CBOR.Tags].

IANA已在“CBOR标记”注册表[IANA.CBOR.Tags]中注册了CWT CBOR标记。

9.4.1. Registry Contents
9.4.1. 注册表内容

o CBOR Tag: 61 o Data Item: CBOR Web Token (CWT) o Semantics: CBOR Web Token (CWT), as defined in [RFC8392] o Reference: [RFC8392] o Point of Contact: Michael B. Jones, mbj@microsoft.com

o CBOR标记:61 o数据项:CBOR Web令牌(CWT)o语义:CBOR Web令牌(CWT),如[RFC8392]o参考:[RFC8392]o联系人:Michael B.Jones,mbj@microsoft.com

10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[IANA.CBOR.Tags] IANA, "Concise Binary Object Representation (CBOR) Tags", <http://www.iana.org/assignments/cbor-tags/>.

[IANA.CBOR.Tags]IANA,“简明二进制对象表示(CBOR)标记”<http://www.iana.org/assignments/cbor-tags/>.

[IANA.CoAP.Content-Formats] IANA, "CoAP Content-Formats", <https://www.iana.org/assignments/core-parameters/>.

[IANA.CoAP.Content Formats]IANA,“CoAP内容格式”<https://www.iana.org/assignments/core-parameters/>.

[IANA.CWT.Claims] IANA, "CBOR Web Token (CWT) Claims", <http://www.iana.org/assignments/cwt>.

[IANA.CWT.Claims]IANA,“CBOR网络令牌(CWT)声明”<http://www.iana.org/assignments/cwt>.

[IANA.MediaTypes] IANA, "Media Types", <http://www.iana.org/assignments/media-types>.

[IANA.MediaTypes]IANA,“媒体类型”<http://www.iana.org/assignments/media-types>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<https://www.rfc-editor.org/info/rfc2119>.

[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.

[RFC7049]Bormann,C.和P.Hoffman,“简明二进制对象表示法(CBOR)”,RFC 7049,DOI 10.17487/RFC7049,2013年10月<https://www.rfc-editor.org/info/rfc7049>.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.

[RFC7519]Jones,M.,Bradley,J.和N.Sakimura,“JSON网络令牌(JWT)”,RFC 7519,DOI 10.17487/RFC7519,2015年5月<https://www.rfc-editor.org/info/rfc7519>.

[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>.

[RFC8152]Schaad,J.,“CBOR对象签名和加密(COSE)”,RFC 8152,DOI 10.17487/RFC8152,2017年7月<https://www.rfc-editor.org/info/rfc8152>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174]Leiba,B.,“RFC 2119关键词中大写与小写的歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月<https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References
10.2. 资料性引用

[IANA.JWT.Claims] IANA, "JSON Web Token Claims", <http://www.iana.org/assignments/jwt>.

[IANA.JWT.Claims]IANA,“JSON Web令牌声明”<http://www.iana.org/assignments/jwt>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC6838]Freed,N.,Klensin,J.和T.Hansen,“介质类型规范和注册程序”,BCP 13,RFC 6838,DOI 10.17487/RFC6838,2013年1月<https://www.rfc-editor.org/info/rfc6838>.

[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>.

[RFC7515]Jones,M.,Bradley,J.和N.Sakimura,“JSON网络签名(JWS)”,RFC 7515,DOI 10.17487/RFC7515,2015年5月<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>.

[RFC7516]Jones,M.和J.Hildebrand,“JSON Web加密(JWE)”,RFC 7516,DOI 10.17487/RFC7516,2015年5月<https://www.rfc-editor.org/info/rfc7516>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]Cotton,M.,Leiba,B.,和T.Narten,“在RFC中编写IANA考虑事项部分的指南”,BCP 26,RFC 8126,DOI 10.17487/RFC8126,2017年6月<https://www.rfc-editor.org/info/rfc8126>.

Appendix A. Examples
附录A.示例

This appendix includes a set of CWT examples that show how the CWT Claims Set can be protected. There are examples that are signed, MACed, encrypted, and that use nested signing and encryption. To make the examples easier to read, they are presented both as hex strings and in the extended CBOR diagnostic notation described in Section 6 of [RFC7049].

本附录包括一组CWT示例,说明如何保护CWT声明集。有一些示例是经过签名、标记、加密的,以及使用嵌套签名和加密的。为了使示例更易于阅读,它们以十六进制字符串和[RFC7049]第6节所述的扩展CBOR诊断符号的形式呈现。

Where a byte string is to carry an embedded CBOR-encoded item, the diagnostic notation for this CBOR data item can be enclosed in '<<' and '>>' to notate the byte string resulting from encoding the data item, e.g., h'63666F6F' translates to <<"foo">>.

如果字节字符串携带嵌入式CBOR编码项,则此CBOR数据项的诊断符号可包含在“<<”和“>>”中,以表示编码数据项产生的字节字符串,例如,h'63666F6F'转换为“<<”foo“>>”。

A.1. Example CWT Claims Set
A.1. CWT索赔集示例

The CWT Claims Set used for the different examples displays usage of all the defined claims. For signed and MACed examples, the CWT Claims Set is the CBOR encoding as a byte string.

用于不同示例的CWT声明集显示所有已定义声明的用法。对于带符号和MACE的示例,CWT声明集是作为字节字符串的CBOR编码。

   a70175636f61703a2f2f61732e6578616d706c652e636f6d02656572696b7703
   7818636f61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0
   051a5610d9f0061a5610d9f007420b71
        
   a70175636f61703a2f2f61732e6578616d706c652e636f6d02656572696b7703
   7818636f61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0
   051a5610d9f0061a5610d9f007420b71
        

Figure 2: Example CWT Claims Set as Hex String

图2:设置为十六进制字符串的示例CWT声明

   {
     / iss / 1: "coap://as.example.com",
     / sub / 2: "erikw",
     / aud / 3: "coap://light.example.com",
     / exp / 4: 1444064944,
     / nbf / 5: 1443944944,
     / iat / 6: 1443944944,
     / cti / 7: h'0b71'
   }
        
   {
     / iss / 1: "coap://as.example.com",
     / sub / 2: "erikw",
     / aud / 3: "coap://light.example.com",
     / exp / 4: 1444064944,
     / nbf / 5: 1443944944,
     / iat / 6: 1443944944,
     / cti / 7: h'0b71'
   }
        

Figure 3: Example CWT Claims Set in CBOR Diagnostic Notation

图3:CBOR诊断符号中设置的CWT声明示例

A.2. Example Keys
A.2. 示例键

This section contains the keys used to sign, MAC, and encrypt the messages in this appendix. Line breaks are for display purposes only.

本节包含用于对本附录中的消息进行签名、MAC和加密的密钥。换行符仅用于显示目的。

A.2.1. 128-Bit Symmetric Key
A.2.1. 128位对称密钥

a42050231f4c4d4d3051fdc2ec0a3851d5b3830104024c53796d6d6574726963 313238030a

A42050231F4C4DD3051FDC2EC0A3851DB3830104024C53796D6D657426963 313238030a

Figure 4: 128-Bit Symmetric COSE_Key as Hex String

图4:128位对称COSE_键作为十六进制字符串

   {
     / k /   -1: h'231f4c4d4d3051fdc2ec0a3851d5b383'
     / kty /  1: 4 / Symmetric /,
     / kid /  2: h'53796d6d6574726963313238' / 'Symmetric128' /,
     / alg /  3: 10 / AES-CCM-16-64-128 /
   }
        
   {
     / k /   -1: h'231f4c4d4d3051fdc2ec0a3851d5b383'
     / kty /  1: 4 / Symmetric /,
     / kid /  2: h'53796d6d6574726963313238' / 'Symmetric128' /,
     / alg /  3: 10 / AES-CCM-16-64-128 /
   }
        

Figure 5: 128-Bit Symmetric COSE_Key in CBOR Diagnostic Notation

图5:CBOR诊断符号中的128位对称COSE_密钥

A.2.2. 256-Bit Symmetric Key
A.2.2. 256位对称密钥
   a4205820403697de87af64611c1d32a05dab0fe1fcb715a86ab435f1ec99192d
   795693880104024c53796d6d6574726963323536030a
        
   a4205820403697de87af64611c1d32a05dab0fe1fcb715a86ab435f1ec99192d
   795693880104024c53796d6d6574726963323536030a
        

Figure 6: 256-Bit Symmetric COSE_Key as Hex String

图6:256位对称COSE_键作为十六进制字符串

   {
     / k /   -1: h'403697de87af64611c1d32a05dab0fe1fcb715a86ab435f1
                   ec99192d79569388'
     / kty /  1: 4 / Symmetric /,
     / kid /  4: h'53796d6d6574726963323536' / 'Symmetric256' /,
     / alg /  3: 4 / HMAC 256/64 /
   }
        
   {
     / k /   -1: h'403697de87af64611c1d32a05dab0fe1fcb715a86ab435f1
                   ec99192d79569388'
     / kty /  1: 4 / Symmetric /,
     / kid /  4: h'53796d6d6574726963323536' / 'Symmetric256' /,
     / alg /  3: 4 / HMAC 256/64 /
   }
        

Figure 7: 256-Bit Symmetric COSE_Key in CBOR Diagnostic Notation

图7:CBOR诊断符号中的256位对称COSE_键

A.2.3. Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 256-Bit COSE Key

A.2.3. 椭圆曲线数字签名算法(ECDSA)P-256 256位COSE密钥

a72358206c1382765aec5358f117733d281c1c7bdc39884d04a45a1e6c67c858 bc206c1922582060f7f1a780d8a783bfb7a2dd6b2796e8128dbbcef9d3d168db 9529971a36e7b9215820143329cce7868e416927599cf65a34f3ce2ffda55a7e ca69ed8919a394d42f0f2001010202524173796d6d6574726963454344534132 35360326

A72358206C1382765AEC558F117733D281C1C7BDC39884D04A45A1E6C67C858 bc206c1922582060f7f1a780d8a783bfb7a2dd6b2796e8128dbbcef9d3d168db 9529971A36E7B921582014329CCE7868E416999CF65A34F3CE2FFDA55A7E CA69ED8919A394D42F0F20010102024173796D655747269634434332 35360326

Figure 8: ECDSA 256-Bit COSE Key as Hex String

图8:ECDSA 256位COSE键作为十六进制字符串

   {
     / d /   -4: h'6c1382765aec5358f117733d281c1c7bdc39884d04a45a1e
                   6c67c858bc206c19',
     / y /   -3: h'60f7f1a780d8a783bfb7a2dd6b2796e8128dbbcef9d3d168
                   db9529971a36e7b9',
     / x /   -2: h'143329cce7868e416927599cf65a34f3ce2ffda55a7eca69
                   ed8919a394d42f0f',
     / crv / -1: 1 / P-256 /,
     / kty /  1: 2 / EC2 /,
     / kid /  2: h'4173796d6d657472696345434453413
                   23536' / 'AsymmetricECDSA256' /,
     / alg /  3: -7 / ECDSA 256 /
   }
        
   {
     / d /   -4: h'6c1382765aec5358f117733d281c1c7bdc39884d04a45a1e
                   6c67c858bc206c19',
     / y /   -3: h'60f7f1a780d8a783bfb7a2dd6b2796e8128dbbcef9d3d168
                   db9529971a36e7b9',
     / x /   -2: h'143329cce7868e416927599cf65a34f3ce2ffda55a7eca69
                   ed8919a394d42f0f',
     / crv / -1: 1 / P-256 /,
     / kty /  1: 2 / EC2 /,
     / kid /  2: h'4173796d6d657472696345434453413
                   23536' / 'AsymmetricECDSA256' /,
     / alg /  3: -7 / ECDSA 256 /
   }
        

Figure 9: ECDSA 256-Bit COSE Key in CBOR Diagnostic Notation

图9:CBOR诊断符号中的ECDSA 256位COSE密钥

A.3. Example Signed CWT
A.3. 示例签名CWT

This section shows a signed CWT with a single recipient and a full CWT Claims Set.

本节显示一个已签名的CWT,其中只有一个收件人和完整的CWT声明集。

The signature is generated using the private key listed in Appendix A.2.3, and it can be validated using the public key from Appendix A.2.3. Line breaks are for display purposes only.

签名是使用附录A.2.3中列出的私钥生成的,可以使用附录A.2.3中的公钥进行验证。换行符仅用于显示目的。

d28443a10126a104524173796d6d657472696345434453413235365850a701756 36f61703a2f2f61732e6578616d706c652e636f6d02656572696b77037818636f 61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a5610d 9f0061a5610d9f007420b7158405427c1ff28d23fbad1f29c4c7c6a555e601d6f a29f9179bc3d7438bacaca5acd08c8d4d4f96131680c429a01f85951ecee743a5 2b9b63632c57209120e1c9e30

D28443A1012A104524173796D6D6D65724726966345434453413235365850A701756 36F61703A2F2F61732E6578616D706C652E636D626572696B770781866F 61703A2F2F6C696768742E657616D706C652E636D041A5612EB0051A5610D 9F0061A5610D9F007420B7158405427C1FF282FBAD1F29C4C7C655E601D6F A29BC7476768742E615B8ACD415B1958D4545455F6152B9B632C57209120E1C9E30

Figure 10: Signed CWT as Hex String

图10:作为十六进制字符串的有符号CWT

   18(
     [
       / protected / << {
         / alg / 1: -7 / ECDSA 256 /
       } >>,
       / unprotected / {
         / kid / 4: h'4173796d6d657472696345434453413
                      23536' / 'AsymmetricECDSA256' /
       },
       / payload / << {
         / iss / 1: "coap://as.example.com",
         / sub / 2: "erikw",
         / aud / 3: "coap://light.example.com",
         / exp / 4: 1444064944,
         / nbf / 5: 1443944944,
         / iat / 6: 1443944944,
         / cti / 7: h'0b71'
       } >>,
       / signature / h'5427c1ff28d23fbad1f29c4c7c6a555e601d6fa29f
                       9179bc3d7438bacaca5acd08c8d4d4f96131680c42
                       9a01f85951ecee743a52b9b63632c57209120e1c9e
                       30'
     ]
   )
        
   18(
     [
       / protected / << {
         / alg / 1: -7 / ECDSA 256 /
       } >>,
       / unprotected / {
         / kid / 4: h'4173796d6d657472696345434453413
                      23536' / 'AsymmetricECDSA256' /
       },
       / payload / << {
         / iss / 1: "coap://as.example.com",
         / sub / 2: "erikw",
         / aud / 3: "coap://light.example.com",
         / exp / 4: 1444064944,
         / nbf / 5: 1443944944,
         / iat / 6: 1443944944,
         / cti / 7: h'0b71'
       } >>,
       / signature / h'5427c1ff28d23fbad1f29c4c7c6a555e601d6fa29f
                       9179bc3d7438bacaca5acd08c8d4d4f96131680c42
                       9a01f85951ecee743a52b9b63632c57209120e1c9e
                       30'
     ]
   )
        

Figure 11: Signed CWT in CBOR Diagnostic Notation

图11:CBOR诊断符号中的有符号CWT

A.4. Example MACed CWT
A.4. 示例浸渍CWT

This section shows a MACed CWT with a single recipient, a full CWT Claims Set, and a CWT tag.

本节显示了一个带有单个收件人、完整CWT声明集和CWT标记的MACed CWT。

The MAC is generated using the 256-bit symmetric key from Appendix A.2.2 with a 64-bit truncation. Line breaks are for display purposes only.

MAC使用附录A.2.2中的256位对称密钥和64位截断生成。换行符仅用于显示目的。

   d83dd18443a10104a1044c53796d6d65747269633235365850a70175636f6170
   3a2f2f61732e6578616d706c652e636f6d02656572696b77037818636f61703a
   2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a5610d9f006
   1a5610d9f007420b7148093101ef6d789200
        
   d83dd18443a10104a1044c53796d6d65747269633235365850a70175636f6170
   3a2f2f61732e6578616d706c652e636f6d02656572696b77037818636f61703a
   2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a5610d9f006
   1a5610d9f007420b7148093101ef6d789200
        

Figure 12: MACed CWT with CWT Tag as Hex String

图12:CWT标记为十六进制字符串的MACed CWT

   61(
     17(
       [
         / protected / << {
           / alg / 1: 4 / HMAC-256-64 /
         } >>,
         / unprotected / {
           / kid / 4: h'53796d6d6574726963323536' / 'Symmetric256' /
         },
         / payload / << {
           / iss / 1: "coap://as.example.com",
           / sub / 2: "erikw",
           / aud / 3: "coap://light.example.com",
           / exp / 4: 1444064944,
           / nbf / 5: 1443944944,
           / iat / 6: 1443944944,
           / cti / 7: h'0b71'
         } >>,
         / tag / h'093101ef6d789200'
       ]
     )
   )
        
   61(
     17(
       [
         / protected / << {
           / alg / 1: 4 / HMAC-256-64 /
         } >>,
         / unprotected / {
           / kid / 4: h'53796d6d6574726963323536' / 'Symmetric256' /
         },
         / payload / << {
           / iss / 1: "coap://as.example.com",
           / sub / 2: "erikw",
           / aud / 3: "coap://light.example.com",
           / exp / 4: 1444064944,
           / nbf / 5: 1443944944,
           / iat / 6: 1443944944,
           / cti / 7: h'0b71'
         } >>,
         / tag / h'093101ef6d789200'
       ]
     )
   )
        

Figure 13: MACed CWT with CWT Tag in CBOR Diagnostic Notation

图13:CBOR诊断符号中带有CWT标记的MACE CWT

A.5. Example Encrypted CWT
A.5. 加密CWT示例

This section shows an encrypted CWT with a single recipient and a full CWT Claims Set.

本节显示一个加密的CWT,其中包含一个收件人和完整的CWT声明集。

The encryption is done with AES-CCM mode using the 128-bit symmetric key from Appendix A.2.1 with a 64-bit tag and 13-byte nonce, i.e., COSE AES-CCM-16-64-128. Line breaks are for display purposes only.

加密采用AES-CCM模式,使用附录A.2.1中的128位对称密钥,带有64位标记和13字节nonce,即COSE AES-CCM-16-64-128。换行符仅用于显示目的。

   d08343a1010aa2044c53796d6d6574726963313238054d99a0d7846e762c49ff
   e8a63e0b5858b918a11fd81e438b7f973d9e2e119bcb22424ba0f38a80f27562
   f400ee1d0d6c0fdb559c02421fd384fc2ebe22d7071378b0ea7428fff157444d
   45f7e6afcda1aae5f6495830c58627087fc5b4974f319a8707a635dd643b
        
   d08343a1010aa2044c53796d6d6574726963313238054d99a0d7846e762c49ff
   e8a63e0b5858b918a11fd81e438b7f973d9e2e119bcb22424ba0f38a80f27562
   f400ee1d0d6c0fdb559c02421fd384fc2ebe22d7071378b0ea7428fff157444d
   45f7e6afcda1aae5f6495830c58627087fc5b4974f319a8707a635dd643b
        

Figure 14: Encrypted CWT as Hex String

图14:加密为十六进制字符串的CWT

   16(
     [
       / protected / << {
         / alg / 1: 10 / AES-CCM-16-64-128 /
       } >>,
       / unprotected / {
         / kid / 4: h'53796d6d6574726963313238' / 'Symmetric128' /,
         / iv /  5: h'99a0d7846e762c49ffe8a63e0b'
       },
       / ciphertext / h'b918a11fd81e438b7f973d9e2e119bcb22424ba0f38
                        a80f27562f400ee1d0d6c0fdb559c02421fd384fc2e
                        be22d7071378b0ea7428fff157444d45f7e6afcda1a
                        ae5f6495830c58627087fc5b4974f319a8707a635dd
                        643b'
     ]
   )
        
   16(
     [
       / protected / << {
         / alg / 1: 10 / AES-CCM-16-64-128 /
       } >>,
       / unprotected / {
         / kid / 4: h'53796d6d6574726963313238' / 'Symmetric128' /,
         / iv /  5: h'99a0d7846e762c49ffe8a63e0b'
       },
       / ciphertext / h'b918a11fd81e438b7f973d9e2e119bcb22424ba0f38
                        a80f27562f400ee1d0d6c0fdb559c02421fd384fc2e
                        be22d7071378b0ea7428fff157444d45f7e6afcda1a
                        ae5f6495830c58627087fc5b4974f319a8707a635dd
                        643b'
     ]
   )
        

Figure 15: Encrypted CWT in CBOR Diagnostic Notation

图15:CBOR诊断符号中的加密CWT

A.6. Example Nested CWT
A.6. 示例嵌套CWT

This section shows a Nested CWT, signed and then encrypted, with a single recipient and a full CWT Claims Set.

本节显示一个嵌套的CWT,先签名,然后加密,只有一个收件人和一个完整的CWT声明集。

The signature is generated using the private ECDSA key from Appendix A.2.3, and it can be validated using the public ECDSA parts from Appendix A.2.3. The encryption is done with AES-CCM mode using the 128-bit symmetric key from Appendix A.2.1 with a 64-bit tag and 13-byte nonce, i.e., COSE AES-CCM-16-64-128. The content type is set to CWT to indicate that there are multiple layers of COSE protection before finding the CWT Claims Set. The decrypted ciphertext will be a COSE_sign1 structure. In this example, it is the same one as in Appendix A.3, i.e., a Signed CWT Claims Set. Note that there is no limitation to the number of layers; this is an example with two layers. Line breaks are for display purposes only.

签名是使用附录A.2.3中的专用ECDSA密钥生成的,可以使用附录A.2.3中的公共ECDSA部分进行验证。加密采用AES-CCM模式,使用附录A.2.1中的128位对称密钥,带有64位标记和13字节nonce,即COSE AES-CCM-16-64-128。内容类型设置为CWT,以指示在查找CWT声明集之前存在多个COSE保护层。解密的密文将是COSE_sign1结构。在本例中,其与附录A.3中的相同,即签署的CWT索赔集。注意,对层数没有限制;这是一个具有两层的示例。换行符仅用于显示目的。

   d08343a1010aa2044c53796d6d6574726963313238054d4a0694c0e69ee6b595
   6655c7b258b7f6b0914f993de822cc47e5e57a188d7960b528a747446fe12f0e
   7de05650dec74724366763f167a29c002dfd15b34d8993391cf49bc91127f545
   dba8703d66f5b7f1ae91237503d371e6333df9708d78c4fb8a8386c8ff09dc49
   af768b23179deab78d96490a66d5724fb33900c60799d9872fac6da3bdb89043
   d67c2a05414ce331b5b8f1ed8ff7138f45905db2c4d5bc8045ab372bff142631
   610a7e0f677b7e9b0bc73adefdcee16d9d5d284c616abeab5d8c291ce0
        
   d08343a1010aa2044c53796d6d6574726963313238054d4a0694c0e69ee6b595
   6655c7b258b7f6b0914f993de822cc47e5e57a188d7960b528a747446fe12f0e
   7de05650dec74724366763f167a29c002dfd15b34d8993391cf49bc91127f545
   dba8703d66f5b7f1ae91237503d371e6333df9708d78c4fb8a8386c8ff09dc49
   af768b23179deab78d96490a66d5724fb33900c60799d9872fac6da3bdb89043
   d67c2a05414ce331b5b8f1ed8ff7138f45905db2c4d5bc8045ab372bff142631
   610a7e0f677b7e9b0bc73adefdcee16d9d5d284c616abeab5d8c291ce0
        

Figure 16: Signed and Encrypted CWT as Hex String

图16:作为十六进制字符串的签名和加密CWT

   16(
     [
       / protected / << {
         / alg / 1: 10 / AES-CCM-16-64-128 /
       } >>,
       / unprotected / {
         / kid / 4: h'53796d6d6574726963313238' / 'Symmetric128' /,
         / iv /  5: h'4a0694c0e69ee6b5956655c7b2'
       },
       / ciphertext / h'f6b0914f993de822cc47e5e57a188d7960b528a7474
                        46fe12f0e7de05650dec74724366763f167a29c002d
                        fd15b34d8993391cf49bc91127f545dba8703d66f5b
                        7f1ae91237503d371e6333df9708d78c4fb8a8386c8
                        ff09dc49af768b23179deab78d96490a66d5724fb33
                        900c60799d9872fac6da3bdb89043d67c2a05414ce3
                        31b5b8f1ed8ff7138f45905db2c4d5bc8045ab372bf
                        f142631610a7e0f677b7e9b0bc73adefdcee16d9d5d
                        284c616abeab5d8c291ce0'
     ]
   )
        
   16(
     [
       / protected / << {
         / alg / 1: 10 / AES-CCM-16-64-128 /
       } >>,
       / unprotected / {
         / kid / 4: h'53796d6d6574726963313238' / 'Symmetric128' /,
         / iv /  5: h'4a0694c0e69ee6b5956655c7b2'
       },
       / ciphertext / h'f6b0914f993de822cc47e5e57a188d7960b528a7474
                        46fe12f0e7de05650dec74724366763f167a29c002d
                        fd15b34d8993391cf49bc91127f545dba8703d66f5b
                        7f1ae91237503d371e6333df9708d78c4fb8a8386c8
                        ff09dc49af768b23179deab78d96490a66d5724fb33
                        900c60799d9872fac6da3bdb89043d67c2a05414ce3
                        31b5b8f1ed8ff7138f45905db2c4d5bc8045ab372bf
                        f142631610a7e0f677b7e9b0bc73adefdcee16d9d5d
                        284c616abeab5d8c291ce0'
     ]
   )
        

Figure 17: Signed and Encrypted CWT in CBOR Diagnostic Notation

图17:CBOR诊断符号中的签名和加密CWT

A.7. Example MACed CWT with a Floating-Point Value
A.7. 示例使用浮点值对CWT进行了标记

This section shows a MACed CWT with a single recipient and a simple CWT Claims Set. The CWT Claims Set with a floating-point 'iat' value.

本节显示了一个具有单个收件人和简单CWT声明集的MACed CWT。CWT声明集具有浮点“iat”值。

The MAC is generated using the 256-bit symmetric key from Appendix A.2.2 with a 64-bit truncation. Line breaks are for display purposes only.

MAC使用附录A.2.2中的256位对称密钥和64位截断生成。换行符仅用于显示目的。

d18443a10104a1044c53796d6d65747269633235364ba106fb41d584367c2000 0048b8816f34c0542892

D18443A101041044C53796D6D65747269633235364BA106FB41D584367C2000 0048b8816f34c0542892

Figure 18: MACed CWT with a Floating-Point Value as Hex String

图18:将浮点值作为十六进制字符串的MACed CWT

   17(
     [
       / protected / << {
         / alg / 1: 4 / HMAC-256-64 /
       } >>,
       / unprotected / {
         / kid / 4: h'53796d6d6574726963323536' / 'Symmetric256' /,
       },
       / payload / << {
         / iat / 6: 1443944944.5
       } >>,
       / tag / h'b8816f34c0542892'
     ]
   )
        
   17(
     [
       / protected / << {
         / alg / 1: 4 / HMAC-256-64 /
       } >>,
       / unprotected / {
         / kid / 4: h'53796d6d6574726963323536' / 'Symmetric256' /,
       },
       / payload / << {
         / iat / 6: 1443944944.5
       } >>,
       / tag / h'b8816f34c0542892'
     ]
   )
        

Figure 19: MACed CWT with a Floating-Point Value in CBOR Diagnostic Notation

图19:CBOR诊断符号中带浮点值的MACed CWT

Acknowledgements

致谢

This specification is based on JSON Web Token (JWT) [RFC7519], the authors of which also include Nat Sakimura and John Bradley. It also incorporates suggestions made by many people, including Carsten Bormann, Alissa Cooper, Esko Dijk, Benjamin Kaduk, Warren Kumari, Carlos Martinez, Alexey Melnikov, Kathleen Moriarty, Eric Rescorla, Dan Romascanu, Adam Roach, Kyle Rose, Jim Schaad, Ludwig Seitz, and Goeran Selander.

本规范基于JSON Web令牌(JWT)[RFC7519],其作者还包括Nat Sakimura和John Bradley。它还包含了许多人提出的建议,包括卡斯滕·鲍曼、艾莉莎·库珀、埃斯科·迪克、本杰明·卡杜克、沃伦·库马里、卡洛斯·马丁内斯、阿列克西·梅尔尼科夫、凯瑟琳·莫里亚蒂、埃里克·雷斯科拉、丹·罗马斯库、亚当·罗奇、凯尔·罗斯、吉姆·沙德、路德维希·塞茨和戈兰·塞兰德。

Authors' Addresses

作者地址

Michael B. Jones Microsoft

迈克尔·琼斯微软公司

   Email: mbj@microsoft.com
   URI:   http://self-issued.info/
        
   Email: mbj@microsoft.com
   URI:   http://self-issued.info/
        

Erik Wahlstroem Sweden

埃里克·沃尔斯特伦瑞典

   Email: erik@wahlstromstekniska.se
        
   Email: erik@wahlstromstekniska.se
        

Samuel Erdtman Spotify AB Birger Jarlsgatan 61, 4tr Stockholm 113 56 Sweden

Samuel Erdtman Spotify AB Birger Jarlsgatan 61,4tr斯德哥尔摩113 56瑞典

   Phone: +46702691499
   Email: erdtman@spotify.com
        
   Phone: +46702691499
   Email: erdtman@spotify.com
        

Hannes Tschofenig ARM Ltd. Hall in Tirol 6060 Austria

奥地利蒂罗尔汉内斯·茨霍芬尼武器有限公司大厅6060

   Email: Hannes.Tschofenig@arm.com
        
   Email: Hannes.Tschofenig@arm.com