Re: [Rats] EAT Review Comments

[Henk Birkholz <[e-mail]>]

Hi Laurence,
hi Hannes,

(Hannes, weirdly I believe I did not receive your reply, but I assume it 
is quoted in the msg below)

I can accept that we are past that point :-) Please consider this a me 
lamenting about bad choices in the past that we have to live with today. 
I also see the argument that you can "reuse" CWT code (and then teach it 
how to treat as an EAT with extra code).

Viele Grüße,

Henk

On 10.12.21 19:11, Laurence Lundblade wrote:
> Below...
> 
>> On Dec 9, 2021, at 11:57 PM, Hannes Tschofenig <[e-mail]> wrote:
>>
>> Hi Henk,
>>
>> You write:
>>
>>> My biggest point of concern is the scope creep into JWT.
>>
>>> EAT was intended to be a CWT (more on that detail below). The
>>> implementation complexity of including JWT now is kind of mind-boggling.
>>> I have been for a while and will continue to be in strong support of
>>> moving JSON encoding related normative text out of the EAT core doucment
>>> to supplemental EAT document.
>>
>>> Fundamentally, I am still opposed to EAT being a CWT. It allows to
>>> include any kind of CWT claims from an increasingly growing CWT Claims
>>> registry. I am allowed to include a nonce and a cnonce Claim
>>> simultaneous due to that. Or simply mix an exi Claim in. How shall an
>>> implementation act on that? That is a valid EAT composition. Is "ignore
>>> what you do not understand" the strategy here? That is not a really
>>> useful approach, if your goal is to establish an interoperable way to
>>> assert trustworthiness. I'd very much prefer a better scoped usage
>>> scenario for EAT for RATS by making an EAT something more specialized
>>> than a CWT (on the CBOR tag level). Maybe someone can explain to my why
>>> this is not an implementer's nightmare as I might miss something obvious
>>> here.
>>
>> We are long past the point of deciding that an EAT is a CWT with special claims. Companies have spend a lot of resources implementing it that way. Practically, there is no problem since you will not randomly add claims to an EAT. As stated in the draft, a profile needs to determine what claims must be present and what to do with optional claims. Then, this is not an issue at all.
> 
> Yes, I think we are long past on that decision.
> 
> The flexibility is necessary for the broad range of use cases, the ones listed in RATS Architecture and more. I doubt we could converge on one set of claims.
> 
> We have profiles to address the problem too many and confusing claims.
> 
> LL
> 
>