Re: [Rats] Interoperability ... RE: EAT Profiles

[Hannes Tschofenig <[e-mail]>]

Hi Ned,

I would like to respond to your statement about the AISS token being an extension to the CWT/JWT rather than the EAT token.

EAT intentionally builds on CWT/JWT. This is a good design approach.

The AISS token re-uses claims in EAT and therefore extends EAT and indirectly the CWT/JWT.

Should the draft provide more information regarding the recommendations in Section 6 of draft-ietf-rats-eat? Yes. Definitely.

In a nutshell, I don't see a problem. FWIW I have implemented a prototype of the AISS token using the EAT library Laurence released.

Ciao
Hannes

-----Original Message-----
From: Thomas Fossati <[e-mail]>
Sent: Thursday, September 22, 2022 3:04 PM
To: Smith, Ned <[e-mail]>
Cc: Laurence Lundblade <[e-mail]>; Hannes Tschofenig <[e-mail]>; Henk Birkholz <[e-mail]>; Michael Richardson <[e-mail]>; [e-mail]
Subject: Re: [Rats] Interoperability ... RE: EAT Profiles

hi Ned,

On Wed, Sep 21, 2022 at 5:51 PM Smith, Ned <[e-mail]> wrote:
> On 9/21/22, 1:55 AM, "RATS on behalf of Thomas Fossati" <[e-mail] on behalf of [e-mail]> wrote:
> > On Tue, Sep 20, 2022 at 8:55 PM Smith, Ned <[e-mail]> wrote:
> > > Profiles should extend standardized statements at a defined
> > > extension point; but existing seem to go beyond this in several
> > > ways.
> >
> > Can you point me to where that is happening?  Speaking for PSA, we
> > do not extend any standardised EAT statement.
>
> [nms]    aiss-token = {
>        aiss-nonce,
>        aiss-instance-id,
>        aiss-profile,
>        aiss-implementation-id,
>        aiss-lifecycle,
>        aiss-boot-odometer,
>        aiss-watermark,
>    }
>
> Aiss-token seems to be an extension of a CWT/JWT token (rather than an
> EAT token). However, this token does integrate with some claims found
> in the EAT draft such as nonce, profile, UEID, and hash-type. Hence,
> it is both a subset of EAT claims as well as a superset of an EAT
> token.

I am not sure I see a problem here.  An EAT can (and typically will) be a CWT/JWT, so anything claiming to be an EAT "profile" can a) inherit the CWT/JWT wrapping, b) extend the claims set using newly registered CWT/JWT claims if the available EAT claims are not sufficient.

> Philosophically, EAT claims could be incorporated into other container
> structures besides CWT/JWT tokens.

True, but.
In order to extend the top-level type one needs a "IETF standards track document." (see §3), so it's not going to be cheap to do that.

> For example, an X.509 certificate
> could define an extension that contains UCCS expression of EAT claims

This X.509 extension would be wrapped in a UCCS which is a top-level EAT (when it gets its RFC number), so this is not the right example of "new bounding container", I think.

> or a protocol frame could do something similar.

If by "similar" you mean UCCS wrapping the EAT/CWT claims then there's no need to define anything for the profile.  Just reference [UCCS].

> It seems reasonable that a profile could specify the bounding
> container for EAT defined claims.

yes, but in order to be called an EAT it needs to be defined in a STD track document.

cheers,
--
Thomas
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.