RFC 9781

A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)

📅 published May 2025, from ietf

RFC 9781 🎀 A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)

Authors: H. Birkholz (Fraunhofer SIT), J. O'Donoghue (Qualcomm Technologies Inc.), N. Cam-Winget (Cisco Systems), and C. Bormann (Universität Bremen TZI) 👯‍♀️

Category: Standards Track 📋 ISSN: 2070-1721 Date: May 2025 📅 Obsoletes / Updates: nothing is listed in the header, so this one doesn't obsolete or update any other RFC 🙌

Abstract 🌸

Okay so this doc defines the Unprotected CWT Claims Set (UCCS), which is a data format for a CBOR Web Token (CWT) Claims Set that isn't signed, MACed, or encrypted 🦋. The whole point is letting you use CWT claims when something else is doing the protecting, like a secure communication channel or a trusted execution environment 🔐. The spec gives you a CBOR tag for UCCS and walks through the format, its encoding, and how to process it 🧚. It also talks through the security implications of using unprotected claims sets, and yes, that part matters 💀.

Status of This Memo ✨

This is an Internet Standards Track document. 🏆

It's a product of the Internet Engineering Task Force (IETF) 💜. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶. If you want more on Internet Standards, check Section 2 of RFC 7841 📚.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9781 🔗.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 🧾.

Table of Contents 🗂️

1.  Introduction
  1.1.  Terminology
  1.2.  Structure of This Document
2.  Deployment and Usage of UCCS
3.  Characteristics of a Secure Channel
4.  UCCS in RATS Conceptual Message Conveyance
5.  Considerations for Using UCCS in Other RATS Contexts
  5.1.  Delegated Attestation
  5.2.  Privacy Preservation
6.  IANA Considerations
  6.1.  CBOR Tag Registration
  6.2.  Media-Type application/uccs+cbor Registration
  6.3.  Media-Type application/ujcs+json Registration
  6.4.  Content-Format Registration
7.  Security Considerations
  7.1.  General Considerations
  7.2.  Algorithm-Specific Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  CDDL
Appendix B.  Example
Appendix C.  EAT
Acknowledgements
Authors' Addresses

1. Introduction ✨

So a CBOR Web Token (CWT) as defined in [RFC8392] is always wrapped in a CBOR Object Signing and Encryption (COSE) envelope [STD96] 📦. COSE gives you end-to-end data origin authentication and integrity protection, which [RFC8392] uses, plus optional encryption for CWTs 🔒. Here's the twist: under the right circumstances (Section 3), the transfer protocol can provide the signature that proves authenticity and integrity, so you can leave it out of the CWT and still keep the goal of authenticity and integrity intact 🙌. If communicating parties already have a security association, they can reuse it to protect their messages, which is the whole "use resources parsimoniously" energy 🌿. Specifically, if a mutually secured channel is set up between two remote peers, and that channel gives the required properties (more on that below), you can drop the COSE protection and you get a use case for unprotected CWT Claims Sets 🦋. Similarly, if there's only one-way authentication, the party that didn't authenticate can send authentication information through this channel, so the already-authenticated party can authenticate the other one. Basically the channel becomes a mutually secured channel 🫶.

This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets (UCCS) as such 🏷️. It also discusses the conditions for using them properly within Remote Attestation Procedures (RATS [RFC9334]) for conveying RATS Conceptual Messages 🧚.

This specification does not change [RFC8392] 🙅‍♀️. A CWT as defined by [RFC8392] does not use the tag allocated here. The UCCS tag is an alternative to using COSE protection and a CWT tag 💅. So inside the well-defined scope of a secure channel, it can be acceptable and economical to take the contents of a CWT, drop its COSE container, tag it with a UCCS CBOR tag, and process it further within that scope. Or you can go the other way: take the contents of a UCCS CBOR tag and build a CWT that some entity who can vouch for those contents then signs 🎀.

1.1. Terminology 📖

The term Claim is used as in [RFC7519] 💕.

The terms Claim Key, Claim Value, and CWT Claims Set are used as in [RFC8392] 🌷.

The terms Attester, Attesting Environment, Evidence, Relying Party and Verifier are used as in [RFC9334] 🕵️‍♀️.

UCCS: Unprotected CWT Claims Set(s). These are CBOR map(s) of Claims, as defined by the CWT Claims Registry, made up of pairs of Claim Keys and Claim Values 🍓.

Secure Channel: [NIST-SP800-90Ar1] defines a Secure Channel like this:

"A path for transferring data between two entities or components that ensures confidentiality, integrity and replay protection, as well as mutual authentication between the entities or components. The secure channel may be provided using approved cryptographic, physical or procedural methods, or a combination thereof."

For this document, we're focused on a protected communication channel used for conveyance that can ensure the same qualities as a CWT without COSE protection being available. That includes mutual authentication, integrity protection, and confidentiality 🔐. (Replay protection can be added by including a nonce claim such as Nonce (claim 10 [IANA.cwt]).) Examples include conveyance via PCIe (Peripheral Component Interconnect Express) IDE (Integrity and Data Encryption) or a TLS tunnel 🚇.

All terms referenced or defined in this section are capitalized in the rest of this document 🔠.

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

1.2. Structure of This Document 🗺️

Section 2 briefly covers use cases for UCCS 🎬. Section 3 covers the general characteristics of secure channels, followed by a specific discussion of using them for RATS Conceptual Message Conveyance in Section 4 💫. Section 5 looks at more forward-looking considerations for using UCCS in other RATS contexts 🔭. After that come the IANA Considerations, Security Considerations, Normative References, and Informative References 📚.

The normative Appendix A gives a formal definition of the structure of UCCS. That's needed because no formal definition of CWT Claims Sets was provided in [RFC8392] 🧩. It uses the Concise Data Definition Language (CDDL) [RFC8610], and it can describe the structurally similar JWT Claims Sets [RFC7519] in the same definition. Those appear with no protective wrapper, such as JWS, applied, and they're called Unprotected JWT Claims Sets (UJCS) 🪄.

Appendix B gives an informative example for CBOR-Tagged UCCS 🎁. The normative Appendix C gives CDDL rules that add UCCS-format tokens to Entity Attestation Tokens (EATs) [RFC9711] using their predefined extension points 🧁.

2. Deployment and Usage of UCCS 🚀

Usage scenarios that involve conveying Claims (RATS especially) need a standardized data definition and encoding format that can be transferred and transported over different communication channels 📬. Since these are Claims, the Claims Sets defined in [RFC8392] are a suitable format 👍. But how those Claims get secured depends on the deployment, the device's security capabilities, and its software stack 🛠️. For example, a Claim might be stored and conveyed securely using a device's Trusted Execution Environment (TEE) [RFC9397] or a Trusted Platform Module (TPM) [TPM2] 🔏. Especially in some resource-constrained environments, the same process that provides the secure communication transport is also the one that composes the Claim being conveyed 🐣. Whether it's a transfer or a transport, a Secure Channel is presumed to be used for conveying such UCCS 🤝. The following sections dig into Secure Channel characteristics in general, and then describe RATS usage scenarios and the matching requirements for UCCS deployment 💖.

3. Characteristics of a Secure Channel ✨

okay so a Secure Channel has to bring the security properties that COSE would normally bring to a CWT 🔐 UCCS are lowkey similar to JWTs using the algorithm "none" [BCP225] 💅 Section 3.2 of RFC 8725 [BCP225] says:

[...] if a JWT is cryptographically protected end-to-end by a transport layer, such as TLS using cryptographically current algorithms, there may be no need to apply another layer of cryptographic protections to the JWT. In such cases, the use of the "none" algorithm can be perfectly acceptable.

The security considerations in Sections 2.1, 3.1, and 3.2 of RFC 8725 [BCP225] apply in an analogous way to UCCS as this document describes them 🦋 The big one is "Use Appropriate Algorithms" (Section 3.2 of RFC 8725 [BCP225]), which covers picking good cryptographic algorithms for setting up and protecting the Secure Channel 🫶 For example, their cryptographic strength should be at least as strong as any cryptographic keys the Secure Channel will be used to protect in transport. Table 5 in Section 7.2 has references to more security considerations for specific cryptography choices, which are discussed in the COSE initial algorithms specification [RFC9053] 📚

Secure Channels are often set up with a handshake protocol that mutually derives a session key 🔑 The handshake establishes the (identity and thus) authenticity of one or both ends of the communication. The session key can then provide confidentiality and integrity for the information moving through the Secure Channel. (If the handshake didn't give a mutually secure channel, the party that isn't authenticated yet can send further authentication information, which leads to a mutually secured channel.) A well-known example of this setup is the TLS [RFC8446] handshake, and the TLS record protocol can then be used for secure conveyance 🌈

UCCS were originally created for RATS Secure Channels, so the next section talks about how they're used in these channels 💖 If other environments are going to convey UCCS, similar considerations need to be documented before UCCS can be used there 🧚

4. UCCS in RATS Conceptual Message Conveyance 🎀

This section walks through a detailed usage scenario for UCCS in the context of RATS, along with the security requirements that come with it 🔥 The use of UCCS tag 601 outside of the RATS context MUST come with additional instruction leaflets and security considerations. Be careful with that one, bestie 💀

For this section, any RATS role can be the sender or the receiver of the UCCS 🦋

Secure Channels can be transient 🌸 For this specification, the mechanisms used to establish a Secure Channel are out of scope, so we're not covering them here 🙈

For RATS Claims, the receiver MUST authenticate the sender as part of establishing the Secure Channel 👑 The channel MUST also provide integrity of the communication between the communicating RATS roles ✨ For data confidentiality [RFC4949], the receiving side MUST be authenticated as well. That happens when the sender and receiver mutually authenticate while the Secure Channel is being set up 🫶 How good the receiver's authentication and authorization are will affect whether the sender can disclose the UCCS 😭

How far a Secure Channel can assure you that UCCS came from a trustworthy Attesting Environment depends on two things: the cryptographic mechanisms used to set up the channel, and the characteristics of the Attesting Environment itself 🧚 The assurance a Relying Party gets depends, among other things, on the authenticity and integrity properties of the Secure Channel used to convey the UCCS to that Relying Party 💜

In the end, it's up to the receiver's policy to decide whether to accept a UCCS from the sender and what type of Secure Channel it must negotiate 🙌 The security considerations for the cryptographic algorithms are similar to COSE, but the Secure Channel considerations should also follow the policy configured at each end of the channel 🍓 The policy controls and definitions themselves are out of scope for this document 🙈

When an Attesting Environment is the endpoint of a Secure Channel used to convey a UCCS, the security assurance a Relying Party needs from it usually means the Attesting Environment is built with techniques meant to protect it from an attacker trying to tamper with or forge a UCCS that came from it 🛡️ One possible approach is to implement the Attesting Environment in a hardened environment, such as a TEE [RFC9397] or a TPM [TPM2] 💅

When a UCCS comes out of the Secure Channel and reaches the receiver, the Secure Channel's security properties no longer protect it 😭 At that point the UCCS has the same security properties as any other unprotected data in the Verifier environment 🌈 If the receiver forwards UCCS later on, they're treated as though they originated within the receiver 🦋

The Secure Channel context doesn't govern fully formed CWTs the way it governs UCCS 🎀 As with EATs (see [RFC9711]) nested in other EATs (Section 4.2.18.3 (Nested Tokens) of [RFC9711]), the Secure Channel does not endorse fully formed CWTs transferred through it 💅 Basically, the COSE envelope of a CWT (or a nested EAT) shields the CWT Claims Set from the Secure Channel's endorsement. (Note that a nested UCCS Claim might be added to an EAT. This statement doesn't apply to UCCS nested into UCCS; it only applies to fully formed CWTs 🧚)

5. Considerations for Using UCCS in Other RATS Contexts 🌸

This section covers two more usage scenarios for UCCS in the context of RATS 💖

5.1. Delegated Attestation

Another scenario is a sub-Attester that has no signing keys (for example, to keep the implementation complexity to a minimum) but does have a Secure Channel, such as local inter-process communication, to talk to a lead Attester (see "Composite Device", Section 3.3 of [RFC9334]) 🧩 The sub-Attester makes a UCCS with the required CWT Claims Set and sends it through the Secure Channel to the lead Attester 📨 The lead Attester then computes a cryptographic hash of the UCCS and protects that hash with its signing key for Evidence. For example, it might use a Detached-Submodule-Digest or Detached EAT Bundle (Section 5 of [RFC9711]) 🔏

5.2. Privacy Preservation

A Secure Channel that preserves the Attester's privacy may provide security properties equivalent to COSE, but only for the lifespan of the session it establishes 🦋 In general, when a privacy-preserving Secure Channel is used to convey a conceptual message, the receiver can't correlate that message with the senders of other received UCCS messages beyond what the Secure Channel authentication already tells it 🙈

An Attester has to think about whether any UCCS it returns over a privacy-preserving Secure Channel compromises privacy in unacceptable ways 👀 For example, using the EAT UEID Claim (Section 4.2.1 of [RFC9711]) in UCCS over a privacy-preserving Secure Channel lets a Verifier correlate UCCS from a single Attesting Environment across many Secure Channel sessions 😭 That might be fine in some use cases (e.g., if the Attesting Environment is a physical sensor in a factory) and totally unacceptable in others (e.g., if the Attesting Environment is a user device belonging to a child) 🥺

6. IANA Considerations 📋

6.1. CBOR Tag Registration

In the "CBOR Tags" registry [IANA.cbor-tags], as defined in Section 9.2 of RFC 8949 [STD94], IANA has allocated the tag in Table 1 from the Specification Required space (1+2 size), with the present document as the specification reference 🎀

      +=====+==========================+======================+
      | Tag | Data Item                | Semantics            |
      +=====+==========================+======================+
      | 601 | map (Claims-Set as per   | Unprotected CWT      |
      |     | Appendix A of [RFC9781]) | Claims Set [RFC9781] |
      +-----+--------------------------+----------------------+

                       Table 1: Values for Tags

6.2. Media-Type application/uccs+cbor Registration

IANA has added the following to the "Media Types" registry [IANA.media-types] 💖

   +===========+=======================+=========================+
   | Name      | Template              | Reference               |
   +===========+=======================+=========================+
   | uccs+cbor | application/uccs+cbor | Section 6.2 of RFC 9781 |
   +-----------+-----------------------+-------------------------+

                   Table 2: Media Type Registration

Here are the registration details, bestie 📝

  • Type name: application
  • Subtype name: uccs+cbor
  • Required parameters: N/A
  • Optional parameters: N/A
  • Encoding considerations: binary (CBOR data item)
  • Security considerations: Section 7 of RFC 9781
  • Interoperability considerations: none
  • Published specification: RFC 9781
  • Applications that use this media type: Applications that transfer Unprotected CWT Claims Set(s) (UCCS) over Secure Channels
  • Fragment identifier considerations: The syntax and semantics of fragment identifiers is as specified for "application/cbor". (At publication of this document, there is no fragment identification syntax defined for "application/cbor".)
  • Additional information:
    • Deprecated alias names for this type: N/A
    • Magic number(s): N/A
    • File extension(s): .uccs
    • Macintosh file type code(s): N/A
  • Person and email address to contact for further information: RATS WG mailing list (rats@ietf.org)
  • Intended usage: COMMON
  • Restrictions on usage: none
  • Author/Change controller: IETF

6.3. Media-Type application/ujcs+json Registration ✨

okay so IANA added a new entry to the "Media Types" registry [IANA.media-types] 🎀 here's the vibe:

+===========+=======================+=========================+
| Name      | Template              | Reference               |
+===========+=======================+=========================+
| ujcs+json | application/ujcs+json | Section 6.3 of RFC 9781 |
+-----------+-----------------------+-------------------------+

             Table 3: JSON Media Type Registration
  • Type name: application
  • Subtype name: ujcs+json
  • Required parameters: N/A
  • Optional parameters: N/A
  • Encoding considerations: binary (UTF-8)
  • Security considerations: Section 7 of RFC 9781
  • Interoperability considerations: none
  • Published specification: RFC 9781
  • Applications that use this media type: Applications that transfer Unprotected JWT Claims Set(s) (UJCS) over Secure Channels 🦋
  • Fragment identifier considerations: The syntax and semantics of fragment identifiers is as specified for application/json. (At publication of this document, there is no fragment identification syntax defined for application/json.) 🌸
  • Additional information:
    • Deprecated alias names for this type: N/A
    • Magic number(s): N/A
    • File extension(s): .ujcs
    • Macintosh file type code(s): N/A
  • Person and email address to contact for further information: RATS WG mailing list (rats@ietf.org)
  • Intended usage: COMMON
  • Restrictions on usage: none
  • Author/Change controller: IETF

6.4. Content-Format Registration 💅

IANA registered the following in the "CoAP Content-Formats" registry, which lives inside the "Constrained RESTful Environments (CoRE) Parameters" registry group [IANA.core-parameters]. 🧚

+=======================+================+=====+=============+
| Content Type          | Content Coding | ID  | Reference   |
+=======================+================+=====+=============+
| application/uccs+cbor | -              | 601 | Section 6.4 |
|                       |                |     | of RFC 9781 |
+-----------------------+----------------+-----+-------------+

             Table 4: Content-Format Registration

7. Security Considerations 🔥

okay this section is SERIOUS bestie, so pay attention 🙈 The security considerations of [STD94] apply. The security considerations of [RFC8392] also need to be applied analogously, with the function of COSE swapped for that of the Secure Channel. In particular, "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". 💀

Section 3 talks through security considerations for Secure Channels that UCCS might be used over. This document gives the CBOR tag definition for UCCS and a discussion of security considerations for using UCCS in RATS. Uses of UCCS outside the scope of RATS are not covered here. ✨

The UCCS specification, and the use of the UCCS CBOR tag along with it, is not intended for a scope where a scope-specific security consideration discussion has not been conducted, vetted, and approved for that use. 🫶 If you want to use the UCCS CBOR tag in another such scope, the secure channel and/or the application protocol (e.g., TLS and the protocol identified by ALPN) MUST specify the roles of the endpoints in a fashion that the security properties of conveying UCCS via a Secure Channel between the roles are well-defined. This part is non-negotiable, periodt 👑

7.1. General Considerations 🌈

Secure Channel implementations are often separate from the application logic that has security requirements on them. Similar security considerations to those described in [STD96] for obtaining the required levels of assurance include:

  • Implementations need to provide sufficient protection for private or secret key material used to establish or protect the Secure Channel. 🔐
  • Using a key for more than one algorithm can leak information about the key and is not recommended. 🙅‍♀️
  • An algorithm used to establish or protect the Secure Channel may have limits on the number of times that a key can be used without leaking information about the key. ⏳
  • Evidence in a UCCS conveyed in a Secure Channel generally cannot be used to support trust in the credentials that were used to establish that secure channel, as this would create a circular dependency. 🔄

The Verifier needs to make sure the management of key material used to establish or protect the Secure Channel is acceptable. This may include factors such as:

  • Ensuring that any permissions associated with key ownership are respected in the establishment of the Secure Channel. 🎀
  • Using cryptographic algorithms appropriately. 💖
  • Using key material in accordance with any usage restrictions such as freshness or algorithm restrictions. 🍓
  • Ensuring that appropriate protections are in place to address potential traffic analysis attacks. 🕵️‍♀️

7.2. Algorithm-Specific Security Considerations 🦋

Table 5 points you to some security considerations for specific cryptography choices that are discussed in [RFC9053]. Iconic reference energy 📚

+===================+============================+
| Algorithm         | Reference                  |
+===================+============================+
| AES-CBC-MAC       | Section 3.2.1 of [RFC9053] |
+-------------------+----------------------------+
| AES-GCM           | Section 4.1.1 of [RFC9053] |
+-------------------+----------------------------+
| AES-CCM           | Section 4.2.1 of [RFC9053] |
+-------------------+----------------------------+
| ChaCha20/Poly1305 | Section 4.3.1 of [RFC9053] |
+-------------------+----------------------------+

             Table 5: Algorithm-Specific Security
                        Considerations

8. References 📖

8.1. Normative References 💜

8.2. Informative References 🌸

Appendix A. CDDL ✨

okay so the Concise Data Definition Language (CDDL), as defined in [RFC8610] and [RFC9165], is basically the cutest way to describe the structure of protocol messages and data formats that use CBOR or JSON 💖 it's unambiguous, so nobody gets to argue about what a structure means 🙈

[RFC8392] does not define CDDL for CWT Claims Sets 💀 so that's where this appendix comes in.

The CDDL model in Figure 1 shows how to use CDDL to define the CWT Claims Set from [RFC8392] 🎀 these rules were built so they can also describe [RFC7519] Claims Sets, just by turning off feature "cbor" and turning on feature "json" 🦋

UCCS-Untagged = Claims-Set
UCCS-Tagged = #6.601(UCCS-Untagged)

Claims-Set = {
 * $$Claims-Set-Claims
 * Claim-Label .feature "extended-claims-label" => any
}
Claim-Label = CBOR-ONLY<int> / text
string-or-uri = text

$$Claims-Set-Claims //= ( iss-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( sub-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( aud-claim-label => string-or-uri )
$$Claims-Set-Claims //= ( exp-claim-label => ~time )
$$Claims-Set-Claims //= ( nbf-claim-label => ~time )
$$Claims-Set-Claims //= ( iat-claim-label => ~time )
$$Claims-Set-Claims //= ( cti-claim-label => bytes )

iss-claim-label = JC<"iss", 1>
sub-claim-label = JC<"sub", 2>
aud-claim-label = JC<"aud", 3>
exp-claim-label = JC<"exp", 4>
nbf-claim-label = JC<"nbf", 5>
iat-claim-label = JC<"iat", 6>
cti-claim-label = CBOR-ONLY<7>  ; jti in JWT: different name and text

JSON-ONLY<J> = J .feature "json"
CBOR-ONLY<C> = C .feature "cbor"
JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>

Figure 1: CDDL definition for Claims-Set 🌈

Specifications that define additional Claims should also supply additions to the $$Claims-Set-Claims socket, e.g.:

; [RFC8747]
$$Claims-Set-Claims //= ( 8: CWT-cnf ) ; cnf
CWT-cnf = {
  (1: CWT-COSE-Key) //
  (2: CWT-Encrypted_COSE_Key) //
  (3: CWT-kid)
}

CWT-COSE-Key = COSE_Key
CWT-Encrypted_COSE_Key = COSE_Encrypt / COSE_Encrypt0
CWT-kid = bytes

;;; Insert the required CDDL from RFC 9052 to complete these
;;; definitions.  This can be done manually or automated by a
;;; tool that implements an import directive such as:
;# import rfc9052

The above definitions, concepts, and security considerations also define a JSON-encoded Claims-Set as encapsulated in a JWT 🫶 such an unsigned Claims-Set can be referred to as a "Unprotected JWT Claims Set", or a "UJCS" 💜 the CDDL definition of Claims-Set in Figure 1 can be used for a UJCS:

UJCS = Claims-Set

Appendix B. Example

This appendix is informative. 🧚

The example CWT Claims Set from Appendix A.1 of [RFC8392] can be turned into a UCCS by enclosing it with a tag number 601 🍓

 601(
   {
     / 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'
   }
 )

Appendix C. EAT 👑

the following CDDL adds UCCS-format and UJCS-format tokens to EAT using its predefined extension points (see Section 4.2.18 (submods) of [RFC9711]) ✨

$EAT-CBOR-Tagged-Token /= UCCS-Tagged
$EAT-CBOR-Untagged-Token /= UCCS-Untagged

$JSON-Selector /= [type: "UJCS", nested-token: UJCS]

Acknowledgements 🫶

Laurence Lundblade suggested some improvements to the CDDL 💅 Carl Wallace provided a very useful review 🌸

Authors' Addresses 🦋

Henk Birkholz 💜

Fraunhofer SIT
Rheinstrasse 75
64295 Darmstadt
Germany
Email: henk.birkholz@ietf.contact

Jeremy O'Donoghue 🌈

Qualcomm Technologies Inc.
279 Farnborough Road
Farnborough
GU14 7LS
United Kingdom
Email: jodonogh@qti.qualcomm.com

Nancy Cam-Winget ⭐

Cisco Systems
3550 Cisco Way
San Jose, CA 95134
United States of America
Email: ncamwing@cisco.com

Carsten Bormann 🎀

Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
📦 where this page comes from