A Concise Binary Object Representation (CBOR) Tag for Unprotected CBOR Web Token Claims Sets (UCCS)
Extracted elements (24)
A sub-Attester with no signing keys can use UCCS over a local Secure Channel (e.g., inter-process communication) to a lead Attester, which then hashes and signs the UCCS for Evidence. This allows minimal-complexity components to participate in attestation without holding signing keys.
The CDDL for Claims-Set is defined here because RFC 8392 did not provide a formal CDDL definition for CWT Claims Sets. The same CDDL rules cover both CBOR (UCCS) and JSON (UJCS) encoding by toggling 'cbor'/'json' features, avoiding duplication.
UCCS omits the COSE envelope from CWT when communicating parties have a preexisting security association (e.g., a mutually secured TLS channel), enabling resource-parsimonious use of CWT claims without redundant cryptographic protection. This follows the same principle as JWT 'none' algorithm over TLS.
The JSON analog of UCCS is UJCS (Unprotected JWT Claims Set), defined using the same CDDL with the 'json' feature enabled instead of 'cbor'. UJCS has media type application/ujcs+json and file extension .ujcs.
The Secure Channel does not endorse fully formed CWTs transferred through it — the COSE envelope of a CWT shields the CWT Claims Set from the channel's endorsement. This contrasts with UCCS, which is fully endorsed by the Secure Channel context.
UCCS is defined as an alternative to using COSE protection and a CWT tag. This specification does not change RFC 8392: a CWT as defined by RFC 8392 does not use CBOR tag 601.
For data confidentiality, the receiving side MUST be authenticated as well, achieved if the sender and receiver mutually authenticate when establishing the Secure Channel.
In the scope of RATS Claims, the receiver MUST authenticate the sender as part of the establishment of the Secure Channel, and the channel MUST provide integrity of the communication between the communicating RATS roles.
To use the UCCS CBOR tag in a scope outside RATS, the secure channel and/or the application protocol 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.
Use of UCCS tag 601 outside of the RATS context MUST come with additional instruction leaflets and security considerations.
An Attester must consider whether UCCS returned over a privacy-preserving Secure Channel compromises privacy. For example, including the EAT UEID claim in UCCS allows a Verifier to correlate UCCS from a single Attesting Environment across many sessions, which may be unacceptable for user devices.
A Secure Channel for UCCS conveyance must provide mutual authentication, integrity protection, confidentiality, and optionally replay protection (achievable by including a Nonce claim, CWT claim 10). Examples include PCIe IDE and TLS tunnels.
UCCS can be integrated into Entity Attestation Tokens (EAT) via predefined extension points: $EAT-CBOR-Tagged-Token accepts UCCS-Tagged, $EAT-CBOR-Untagged-Token accepts UCCS-Untagged, and $JSON-Selector accepts UJCS with type discriminator 'UJCS'.
UCCS (Unprotected CWT Claims Set) is a CBOR map of CWT Claims defined by the CWT Claims Registry, composed of pairs of Claim Keys and Claim Values, without any COSE protective wrapper. It is tagged with CBOR tag 601 when in tagged form (UCCS-Tagged = #6.601(UCCS-Untagged)).
IANA allocated CBOR tag 601 in the 'CBOR Tags' registry (Specification Required, 1+2 size) for Unprotected CWT Claims Set, with data item 'map (Claims-Set as per Appendix A of RFC 9781)'.
IANA registered Content-Format ID 601 in the 'CoAP Content-Formats' registry for content type application/uccs+cbor with no content coding.
IANA registered media type application/uccs+cbor in the 'Media Types' registry for applications transferring UCCS over Secure Channels. File extension: .uccs; encoding: binary CBOR.
IANA registered media type application/ujcs+json in the 'Media Types' registry for applications transferring Unprotected JWT Claims Sets (UJCS) over Secure Channels. File extension: .ujcs; encoding: binary (UTF-8).
Evidence in a UCCS conveyed in a Secure Channel generally cannot be used to support trust in the credentials used to establish that Secure Channel, as this would create a circular dependency.
The cryptographic strength of the Secure Channel algorithms should be at least as strong as any cryptographic keys the channel will protect in transport, per the 'Use Appropriate Algorithms' principle analogous to RFC 8725 Section 3.2.
Using a key for more than one algorithm can leak information about the key and is not recommended. Keys used to establish or protect the Secure Channel may have limits on usage count before leaking information.
When a UCCS emerges from the Secure Channel into the receiver, the security properties of the channel no longer protect it; the UCCS is subject to the same security properties as any other unprotected data in the Verifier environment. If subsequently forwarded, it is treated as though it originated within the receiver.
The Claims-Set CDDL defines standard CWT claims with integer keys in CBOR mode: iss(1), sub(2), aud(3), exp(4), nbf(5), iat(6), cti(7). The cti claim label is CBOR-only integer 7; the JWT equivalent jti uses a different name and is text-encoded.
UCCS uses CBOR tag 601 applied to a Claims-Set map. The tagged form is UCCS-Tagged = #6.601(UCCS-Untagged), where the untagged form is a CBOR map conforming to the CWT Claims Set CDDL definition in Appendix A.