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

One way forward on security levels is to have it be flexible. EAT could just leave the space for a security level to be specified. What gets entered could be individual to the use case and groups. While a draft might be helpful, there will likely be use cases that are private and never register security levels outside of the group.

Best regards,
Kathleen 

Sent from my mobile device

> On Jun 2, 2022, at 2:54 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com> wrote:
> 
> 
> >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 <rats-bounces@ietf.org> on behalf of Laurence Lundblade <lgl@island-resort.com>
> Sent: Thursday, June 2, 2022, 11:46 AM
> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>
> Cc: Smith, Ned <ned.smith@intel.com>; Thomas Fossati <Thomas.Fossati@arm.com>; rats@ietf.org <rats@ietf.org>
> 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 <mandyam@qti.qualcomm.com> 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 <lgl@island-resort.com> 
>> Sent: Thursday, June 2, 2022 11:00 AM
>> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>
>> Cc: Smith, Ned <ned.smith@intel.com>; Thomas Fossati <Thomas.Fossati@arm.com>; rats@ietf.org
>> 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 <mandyam@qti.qualcomm.com> 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:
>>  
>> 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)
>> A team of individual expert reviewers were clearly identified
>> An AD was identified to shepherd the above draft to completion
>> 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:
>>  
>> 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)
>> Expert reviewers at a minimum could be drawn from EAT editors/contributors
>> AD:  I assume we can get someone’s attention for this
>> Seeding:  Examples include PSA-Token or the FDO EAT profile 
>>  
>> -Giri
>>  
>> From: Smith, Ned <ned.smith@intel.com> 
>> Sent: Thursday, June 2, 2022 9:35 AM
>> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; Thomas Fossati <Thomas.Fossati@arm.com>; rats@ietf.org
>> 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 <rats-bounces@ietf.org> on behalf of Giridhar Mandyam <mandyam@qti.qualcomm.com>
>> Date: Thursday, June 2, 2022 at 6:20 AM
>> To: Thomas Fossati <Thomas.Fossati@arm.com>, "rats@ietf.org" <rats@ietf.org>
>> 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 <Thomas.Fossati@arm.com> 
>> Sent: Thursday, June 2, 2022 6:13 AM
>> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; rats@ietf.org
>> 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 <mandyam@qti.qualcomm.com> 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
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats