Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

[Giridhar Mandyam <[e-mail]>]

>To be very clear - I am opposed to any modifications to the EAT draft to include a profile registry in order to get done soon.

So am I. Note that I never suggested the above.   See below from my previous email.

>>Note that his registry was created completely separate from the underlying specification (https://www.w3.org/TR/webauthn-2/) – so we don’t need to hold up EAT while the issue of a profile registry is resolved based on this example as precedence

-Girj

________________________________
From: RATS <[e-mail]> on behalf of Laurence Lundblade <[e-mail]>
Sent: Thursday, June 2, 2022, 11:46 AM
To: Giridhar Mandyam <[e-mail]>
Cc: Smith, Ned <[e-mail]>; Thomas Fossati <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

To be very clear - I am opposed to any modifications to the EAT draft to include a profile registry in order to get done soon.

I’m personally neutral on an EAT profile registry in the long run.

I would prefer to postpone the discussion of a profile registry until 1) someone publishes a draft proposal and 2) until after EAT is done so we don’t suck up oxygen here that can be used for getting EAT done.

LL


On Jun 2, 2022, at 11:05 AM, Giridhar Mandyam <[e-mail]<mailto:[e-mail]>> wrote:

That covers identifiers – not whether a profile as specified is valid or not.  Registry expert review is meant to assess more than just uniqueness of the ID.

-Giri

From: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 2, 2022 11:00 AM
To: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>
Cc: Smith, Ned <[e-mail]<mailto:[e-mail]>>; Thomas Fossati <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

We picked URI and OID as identifier for profiles so we don’t need a registry for profiles. They are both globally unique (because they have their own registry-like system for uniqueness).

LL



On Jun 2, 2022, at 10:27 AM, Giridhar Mandyam <[e-mail]<mailto:[e-mail]>> wrote:

I have one experience with creating an IETF registry from scratch:  https://datatracker.ietf.org/doc/rfc8809/.  Note that his registry was created completely separate from the underlying specification (https://www.w3.org/TR/webauthn-2/) – so we don’t need to hold up EAT while the issue of a profile registry is resolved based on this example as precedence.

Regarding the above-referenced specification, before it was even proposed the following took place:


  1.  Well-established rules for what constitutes a valid extension/attestation were laid out in a specification (in this case RFC 8809, but derived from practices laid out in the W3C Webauthn Spec)
  2.  A team of individual expert reviewers were clearly identified
  3.  An AD was identified to shepherd the above draft to completion
  4.  There were a set of defined attestation/extensions to seed the registry (from the W3C spec)


We can follow the same approach, with the following:


  1.  If we feel the profile guidance is insufficient in EAT, it can be revisited in a separate registry doc.  This could govern certain minimum criteria (e.g. CBOR EAT’s should follow header/payload/sig format and are not extensible)
  2.  Expert reviewers at a minimum could be drawn from EAT editors/contributors
  3.  AD:  I assume we can get someone’s attention for this
  4.  Seeding:  Examples include PSA-Token or the FDO EAT profile


-Giri

From: Smith, Ned <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 2, 2022 9:35 AM
To: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>; Thomas Fossati <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>the profile definition addresses interop
Section 7 suggests that a profile can take on many forms. The EAT draft accommodates this by offering a way to reference the profile document (or whatever it happens to be). I interpret Thomas’s point that “the claims-set is governed by the CWT Claims registry, whilst the EAT type system has no
such mechanism (yet)” to mean there isn’t a profile yet defined that operates like a global registry.

It seems IANA is being used as the global registry for code point names/values currently. IANA CBOR registry could be used for CBOR top level EAT structures, but such equivalent exists for JSON structures.

However, it seems some EAT CBOR structures that could be considered ‘top level’ don’t currently have IANA CBOR registry entries.

Is the way forward for EAT draft to create IANA CBOR tags for top level EAT structures?

Thx,
Ned

From: RATS <[e-mail]<mailto:[e-mail]>> on behalf of Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 2, 2022 at 6:20 AM
To: Thomas Fossati <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

>> I think the underlying data structures make it extensible, independent of the CDDL notation.  However if an implementor chooses to extend EAT without an accompanying standard as a result, then interoperability may not be assured.  Therefore it is in an implementor’s interest to define a standard if they are seeking interop.

>The core difference is the extensibility story for the claims-set is governed by the CWT Claims registry, whilst the EAT type system has no such mechanism (yet).

I don’t agree:  the profile definition addresses interop – see https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat#section-7.  Up to this point, no-one has objected to the way profiles are defined in the specification, nor the lack of a registry.

-Giri

From: Thomas Fossati <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, June 2, 2022 6:13 AM
To: Giridhar Mandyam <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Rats] Where does a EAT end? (was: Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> Giridhar Mandyam <[e-mail]<mailto:[e-mail]>> wrote:
> I think the underlying data structures make it extensible, independent
> of the CDDL notation.  However if an implementor chooses to extend EAT
> without an accompanying standard as a result, then interoperability
> may not be assured.  Therefore it is in an implementor’s interest to
> define a standard if they are seeking interop.

The core difference is the extensibility story for the claims-set is
governed by the CWT Claims registry, whilst the EAT type system has no
such mechanism (yet).




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.
_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats