[Rats] Re: UCCS and EAT media types (was: Re: Re: AD follow-up review of draft-ietf-rats-uccs-09)

[Thomas Fossati <[e-mail]>]

Back on this topic.

Carsten has found a cunning way [1] to break the dependency on UCCS:
reference JWT's glossary to get the (authoritative) definition of the
JSON claims-set (aka UJCS).

I hope we can merge the PR before the cut-off, submit -08 and move the
draft forward in the publication process.

cheers, thanks!

[1] https://github.com/ietf-rats-wg/draft-eat-mt/pull/22

On Mon, 3 Jun 2024 at 18:10, Thomas Fossati <[e-mail]> wrote:
>
> Hi Carsten,
>
> On Mon, 3 Jun 2024 at 17:09, Carsten Bormann <[e-mail]> wrote:
> > > On 2024-06-03, at 09:46, Thomas Fossati <[e-mail]> wrote:
> > > Hence, UJCS is *not* defined by draft-ietf-rats-uccs.  Correct?
> >
> > Well, it is *defined*.
>
> We could quibble on the term "defined" :-)
> What I mean is an explicit statement "UJCS = <something>"
> Otherwise, I have the Voldemort problem.
>
> > It is another name for the JWT claims set as defined in RFC 7519.
> > The UCCS document simply supplies CDDL that can be used for this.
> > The UCCS document also describes the role an unprotected claims set can have in the RATS context, specifically for UCCS.
> > There is no normative intent with this definition beyond that, but the description of the role of UCCS can be analogously applied to UJCS.
> > The normative intent of referencing UJCS would be in the document that uses this CDDL definition normatively.
> > Interestingly, Section 4.2.18 already reads exactly like this, without using the term UJCS (it only gives UCCS as an example).
>
> Yes, but again without calling it out explicitly.
>
> > > If so, we need to remove it from draft-ietf-rats-eat-media-type.
> >
> > I don’t think that this is necessarily following.
>
> Ditto Voldemort.
>
> > > As an aside, I am starting to wonder whether it'd be better for
> > > draft-ietf-rats-eat-media-type to just drop the registrations for UCCS
> > > and let draft-ietf-rats-uccs handle it.
> >
> > I think this could also very well be done (media type and content format, that is).
> > Is there a need to have “eat” in the name?
>
> Not necessarily, if their scope is wider than EAT.
> However, they need to be compatible with EAT and therefore allow for
> the eat_profile claim to bubble up as a media type parameter.
>
> > (I would probably also let the names reveal that UJCS and UCCS are not exactly the same data structures, so this would be application/uccs+cbor and application/ujcs+json.)
>
> WFM
>
> cheers, thanks