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

[Orie Steele <[e-mail]>]

[as an individual, media type enthusiast]

On Mon, Jun 3, 2024 at 10:09 AM Carsten Bormann <[e-mail]> wrote:

>
>
> > On 2024-06-03, at 09:46, Thomas Fossati <[e-mail]>
> wrote:
> >
> > Hi Carsten,
> >
> > On Fri, 31 May 2024 at 22:45, Carsten Bormann <[e-mail]> wrote:
> >>> I don’t understand.  This CDDL in Appendix A is normative, and so is
> the flexibility in its design to support JSON.  Otherwise, it would be “C<
> ...>” and not “JC<...>”.  I don’t take exception with providing a JSON
> binding but please explain this in the prose and in the introduction..
> >>
> >> We now made it explicit that this is there as “CDDL you can use” — a
> normative intent when actually using this is desirable but the CDDL itself
> is not changing the specifications in any way, hence it is an informative
> appendix.  Line 462..465.
> >
> > Hence, UJCS is *not* defined by draft-ietf-rats-uccs.  Correct?
>
> Well, it is *defined*.
> 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).
>
> > If so, we need to remove it from draft-ietf-rats-eat-media-type.
>
> I don’t think that this is necessarily following.
>
> > 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?
> (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.)
>

I like these suggestions... especially if uccs and ujcs are indeed
different subtypes.

There are other cases where an unsigned json or cbor claimset might be
useful.

I am specifically thinking of some status lists, such as
https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/

Note a change in -01 : "add option to return an unsigned Status List see
section 8.1:

   *  "application/statuslist+json" for Status List in JSON format
   *  "application/statuslist+jwt" for Status List in JWT format
   *  "application/statuslist+cbor" for Status List in CBOR format
   *  "application/statuslist+cwt" for Status List in CWT format

arguing against myself for a moment, perhaps EAT should remain in the name,
because it is considered a best practice to use more specific media types /
content formats.

Or perhaps the same "uccs != ujcs" logic applies to the JSON and CBOR
status list representations that OAuth contemplates.


> > Transplanting Section 6.7 [1] and moving the "ucs" line from Table 2
> > [2] should do the trick, and disentangle the fate of the two
> > documents.
> >
> > cheers, t
> >
> > [1]
> https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-07.html#section-6.7
> > [2]
> https://www.ietf.org/archive/id/draft-ietf-rats-eat-media-type-07.html#table-2
>
> _______________________________________________
> RATS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>