Re: [Rats] UJCS standardization (relates to UCCS WG last call)

["lgl island-resort.com" <[e-mail]>]

> On Sep 13, 2023, at 11:41 AM, Smith, Ned <[e-mail]> wrote:
> 
> Note also that draft-ietf-rats-eat-media-type mentions "UJCS" but doesn't reference the spec that defines it. 
> 
> Additionally, RFC8392 requires the contents of a CWT to contain CBOR. I don't think UCCS (which defines both CBOR and JSON) clearly explains whether it modifies the RFC8392 content requirements. In other words, is a UCCS (not UJCS) the same as a CWT minus the signature?
> 
> RFC7519 places similar constraints on the JWT payload (that it contains JSON). Does a UJCS expect to preserve the JWT content requirements minus the signature?

Ahh, now your previous comments make sense to me, Ned.

I don’t think we want to use COSE to sign JSON-format claims sets or use JOSE to sign CBOR-format claim sets even though I we could. That seems like unnecessary complexity and flexibility to me and I don’t think anyone is asking for that. Definitely not me!

(EAT allows nesting of a UCCS EAT in a JWT-format EAT or a UJCS EAT in a CWT-format EAT, but that is whole-token nesting defined by EAT and a different thing).

> 
> If draft-ietf-rats-uccs is intended to define "UJCS" then it probably is not named properly.
> 

Yes, I’m using UCCS to refer to an unsigned CBOR-format claims set and UJCS to refer to an unsigned JSON-format claims set. If the draft covered both we’d have to rename the draft to UCS or UTCS or such.

LL



> -Ned
> 
> On 9/13/23, 11:03 AM, "RATS on behalf of lgl island-resort.com" <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> It was noticed during WG last call that UCCS does standardize an unsigned claims set in JSON format, only CBOR (even though it provides a CDDL definition for JSON).
> 
> 
> Here’s a few comments/reasons for standardizing UJCS:
> 
> 
> - EATs carrying attestation results are often B2B/server-server interactions where JSON+TLS is very common and the JWT signing overhead would be redundant.
> 
> 
> - Lack of UJCS standard sticks out a a missing piece in the document set of EAT, UCCS and EAT media types. It’s like we painted all the doors and windows of a house a pretty color except one. It’s a gap in the set of EAT, EAT Nesting, EAT Bundles and EAT collections.
> 
> 
> - It’s true that the original motivating use cases were only for UCCS, but EAT grew up and filled in to support JSON.
> 
> 
> - Beyond attestation, sending JSON claim sets secured with TLS seems like it would get a lot of use. Not my area, but I suspect lots are doing it in some form now and there might be some broader benefit.
> 
> 
> - JWT does have the NULL-cipher option, but its use is awkward, discouraged, a bit complex and wasteful.
> 
> 
> 
> 
> Here’s the document options I can see for UJCS:
> - Add it to UCCS now.
> - A new RATS standards track document. It will be a small document, but it will have to go through the whole process.
> 
> 
> I haven’t heard anyone opposing UJCS, just a preference that we get UCCS done soon. If we don’t put it in the UCCS draft, I will probably write up new document myself and push it through RATS. I feel like EAT is not done without it.
> 
> 
> I feel for the reader of the complicated document set of JWT, CWT, EAT, EAT media types and UCCS (plus COSE and CBOR). One more document adds to this.
> 
> 
> I did look at what it would take to add it to the UCCS raft and it doesn’t seem too difficult. The biggest disruption is seems like the name change. The CDDL is already there. I will try to help with the authorship in UCCS.
> 
> 
> Also, sorry I didn’t notice until now. I had years.
> 
> 
> LL
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
> 
>