Re: [Rats] EAT implementation (hackathon report)

[Thomas Fossati <[e-mail]>]

Hi Laurence, Nancy, Kathleen and Michael,

(Apologies for top-posting.)  Following Nancy's advice, I've opened
the following issues:

https://github.com/ietf-rats-wg/eat/issues/74
https://github.com/ietf-rats-wg/eat/issues/75
https://github.com/ietf-rats-wg/eat/issues/76
https://github.com/ietf-rats-wg/eat/issues/77
https://github.com/ietf-rats-wg/eat/issues/78
https://github.com/ietf-rats-wg/eat/issues/79

including Laurence's replies below.

cheers!

On Sat, Nov 14, 2020 at 7:17 PM Laurence Lundblade
<[e-mail]> wrote:
>
>
>
> On Nov 12, 2020, at 9:16 AM, Thomas Fossati <[e-mail]> wrote:
>
> Hi all,
>
> Sergei and I have been busy implementing the latest EAT spec at the hackathon.
>
> We started from scratch and in three days we managed to produce a full
> implementation [1] that is about 2.5KLOC, including 50+ accompanying
> tests.
>
> Overall, the impression is that the document is in pretty good shape
> and can be implemented without too much ambiguity.
>
> Here are a few random things we noticed in the process and that we
> wanted to share with the EAT editors as well as the wider group:
>
> 1. It's not clear what is the story around the extensibility of single
> claims?  E.g., if I wanted to expand the semantics of "Debug Disable"
> or "Security Level" with my own local semantics, how would I do that?
> This question popped when discussing whether the decoder should accept
> values not currently listed and make them available to the user?
>
>
> I don’t think these should be extensible. You can’t make up your own corporate bond rating category or restaurant hygene rating category and such. If that is allowed the scheme becomes much less useful.
>
> I’ve added text for that in this PR. It says that when you can’t live with the defined security level schema, omit the claim, make up your own claim or do both.
>
> Also, see this old but unresolved discussion on security level. One thing nice about a very simple three-level scheme is that it becomes clear this is a very rough top-level characterization only.
>
>
>
> 2. Typo: The "nonce" JSON label is missing from Section 4.3.1
>
>
> The JWT nonce was already in the IANA registry for JWT. I added CDDL for it and note that some of the CDDL in EAT is for things defined elsewhere before there was CDDL.  See this PR.
>
>
>
> 3. The JSON story is nearly OK, except for two things: the Submods
> claim where the JSON:CBOR equivalency is broken by allowing unbounded
> int keys in CBOR that can't have an equivalent in JSON; the
> StringOrURI type whose semantics can be preserved when transcoding.
> The former could be solved by only allowing string labels.  The latter
> by declaring we only deal in strings.
>
>
> Pushed a fix for StringOrURI to master.
>
> Made submodule names string only as part of this PR. Was thinking that they should only be strings myself.
>
>
> No progress on the others yet. Would appreciate issues being opened.
>
>
> Really appreciate the work and the validation of the application of CDDL to JSON! Thanks for the good comments.
>
> LL
>


-- 
Thomas