Re: [Rats] Profile identifier (was Re: EAT Profiles)

[Laurence Lundblade <[e-mail]>]

This is how I think the profile id works today and should work as an integer too.

The profile definition can be anything — full IETF standard or no standard at all, top secret or public, proprietary or open standard, Chinese or Martian, written down or not written down, expert reviewed or not. It has to be like this to accommodate use cases. This is what it is for the current profile identifier.

For example, it is OK for a Chinese military computer science genius to register profile X for a black box EAT implementation he created and tells no one about (if you don’t like non-standard, private, undocumented profiles, don’t use them).

The only point of the profile identifier is to be globally unique so some one else doesn’t use the same identifier for something different. The OID and URI spaces are very large and are coordinated so they work great, except they are a bit large on the wire.

Main option for me:
- A new IANA registry
- A first-come first-served number kept unique by increasing monotonically
- The name of the entity registering the number
- An optional URI for a document
- An optional description
- Some throttle to prevent mass registration of millions that consumes the whole space
- Possibly ranges for standard action, private, proprietary use...
- Little to no expert review (it’s just a number registration, not profile quality control)
- Typically 3 bytes on the wire

We can also keep the OID and URI forms adding integer as another option. We should say that all receivers of EAT MUST handle all three forms and that creators of EATs can use what ever form they want so there is no interop issue.

Another option is to just have the integer and remove OID and URI. That is simpler for the EAT receiver because they won’t be required to decode multiple forms.

Something based on a PEN could be possible, but would be fourth form. PEN by itself is not enough because one org needs to be able to create multiple profiles. It doesn’t seem worthwhile to me.

No matter what, the EAT document has to change because the profile identifier is not extensible. We really don’t want it extensible either. It would also be really awkward for the reader for this to be elsewhere too. I think this is best handled in the EAT document if we’re going to do it.

Agreed that use of EAT profiles does not require using an EAT profile identifier. You might know a particular profile is in effect implicitly and/or through some other means. For example, when EAT is used in the FOO protocol, it is always the BAR profile.

LL



> On Sep 21, 2022, at 9:30 AM, Smith, Ned <[e-mail]> wrote:
> 
> I agree that lack of clarity around profiles should not be a blocker for EAT draft moving forward. But capturing issues surrounding profiles is important IMO as these questions will come up again. 
> 
> Responding to Henk's original question below but restated here:
> "    >> are you talking about the values of the profile claim (I am assuming numbers for now) to be registered in an IANA registry or are you talking about new claims defined by a profile specification to be registered in the IANA CBOR Web Token (CWT) Claims registry? I am really not sure anymore."
> 
> It wasn't (isn't) clear to me which IANA registry is most appropriate for registering profiles. It could be reasonable that a new IANA registry is created for that purpose. This thread also observes that there isn't necessarily a need to register a profile as there could be other ways to publish profile existence and allowing vendors flexibility to use a PEN and manage profiles locally. 
> 
> It is still ambiguous to me what value is realized by placing a profile ID on a registry (given the properties of profile lifecycle are adhered to).
> 
> -Ned
> 
> 
> On 9/21/22, 8:53 AM, "Giridhar Mandyam" <[e-mail]> wrote:
> 
>> While it is not necessary to register a profile in a registry to achieve the "rough consensus and running code" goal, that should not stop us establish and use an IANA "EAT Profile" registry, right? (specification required + expert review)
> 
>    In my opinion, the establishment of such a registry should not be a blocker to moving the EAT spec forward.  If there are interested persons who feel a profile registry is an absolute necessity, then they could put out an I.-D. that establishes such a registry along with the mechanics for proposing profiles and administering the registry.
> 
>    I personally feel the value of profiles is not solely in the unique claim value, but the CBOR canonicalization that the profile defines.  EAT in this regards inherits the application-specific COSE considerations (https://datatracker.ietf.org/doc/html/rfc8152#section-15).  
> 
>    -Giri
> 
>    -----Original Message-----
>    From: Henk Birkholz <[e-mail]> 
>    Sent: Wednesday, September 21, 2022 7:38 AM
>    To: Giridhar Mandyam <[e-mail]>; Michael Richardson <[e-mail]>; Smith, Ned <[e-mail]>; [e-mail]
>    Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles)
> 
>    WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
> 
>    Hi Giri,
> 
>    the ACE profile example is giving me a lot of more context! And the approach seems to be fine. An EAT analog could be:
> 
>    The claims defined in the EAT framework (including the profile claim), then could simply be registered in the IANA CBOR Web Token (CWT) Claims registry and profiles making use of the EAT framework would be registered in an IANA "EAT Profile" registry, analogous to https://www.rfc-editor.org/rfc/rfc9200.html#name-ace-profiles
> 
>    While it is not necessary to register a profile in a registry to achieve the "rough consensus and running code" goal, that should not stop us establish and use an IANA "EAT Profile" registry, right? (specification required + expert review)
> 
>    Viele Grüße,
> 
>    Henk
> 
>    On 21.09.22 16:22, Giridhar Mandyam wrote:
>>> So "The EAT Framework" document could come with both a definition of the profile claim for the IANA CBOR Web Token (CWT) Claims registry, as well as... a profile '0' (the first set of Claims that will be included in the final EAT framework document) for an IANA EAT Profile registry?
>> 
>> I did not say the above.
>> 
>> Let me try again.  It is not necessary to have an "IANA EAT Profile registry".  The FIDO example demonstrates that this it is possible to deliver "running code" without it.  The CWT claims registry is sufficient.
>> 
>> BTW, RFC 9200 is the precedent in my opinion.  https://www.rfc-editor.org/rfc/rfc9200.html#name-ace-profiles does not require the creation of a new IANA ACE-Profile registry either as far as I can tell.  The reservation of the CWT claim appears to have been sufficient.
>> 
>> -Giri
>> 
>> -----Original Message-----
>> From: Henk Birkholz <[e-mail]>
>> Sent: Wednesday, September 21, 2022 7:16 AM
>> To: Giridhar Mandyam <[e-mail]>; Michael Richardson 
>> <[e-mail]>; Smith, Ned <[e-mail]>; 
>> [e-mail]
>> Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles)
>> 
>> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>> 
>> Hi Giri,
>> 
>> thanks for clarifying. So "The EAT Framework" document could come with both a definition of the profile claim for the IANA CBOR Web Token (CWT) Claims registry, as well as... a profile '0' (the first set of Claims that will be included in the final EAT framework document) for an IANA EAT Profile registry?
>> 
>> Viele Grüße,
>> 
>> Henk
>> 
>> On 21.09.22 16:06, Giridhar Mandyam wrote:
>>> Both.
>>> 
>>> In the case of FIDO, the profile claim value was not registered.  That did not stop us from achieving the "rough consensus and running code" goal.
>>> 
>>> -Giri
>>> 
>>> -----Original Message-----
>>> From: Henk Birkholz <[e-mail]>
>>> Sent: Wednesday, September 21, 2022 7:01 AM
>>> To: Giridhar Mandyam <[e-mail]>; Michael Richardson 
>>> <[e-mail]>; Smith, Ned <[e-mail]>; 
>>> [e-mail]
>>> Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles)
>>> 
>>> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>>> 
>>> Hi Ned, Michael, Giri,
>>> 
>>> are you talking about the values of the profile claim (I am assuming numbers for now) to be registered in an IANA registry or are you talking about new claims defined by a profile specification to be registered in the IANA CBOR Web Token (CWT) Claims registry? I am really not sure anymore.
>>> 
>>> Viele Grüße,
>>> 
>>> Henk
>>> 
>>> On 21.09.22 15:51, Giridhar Mandyam wrote:
>>>> This was not required for the FIDO implementation of EAT.  As per https://www.iana.org/assignments/cwt/cwt.xhtml, the FIDO EAT claims have been registered and the profile has been verified in interop events.  The profile itself was not registered.
>>>> 
>>>>> The IANA registry would point to some RFC that described the semantics.
>>>> 
>>>> Why only RFC's?  Are other standards body documents not suitable?  At least for FIDO, this didn't seem to be a requirement for IANA registry.
>>>> 
>>>> -Giri
>>>> 
>>>> -----Original Message-----
>>>> From: RATS <[e-mail]> On Behalf Of Michael Richardson
>>>> Sent: Wednesday, September 21, 2022 3:27 AM
>>>> To: Smith, Ned <[e-mail]>; [e-mail]
>>>> Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles)
>>>> 
>>>> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>>>> 
>>>> Smith, Ned <[e-mail]> wrote:
>>>>> @Laurence Lundblade<mailto:[e-mail]> What semantics are
>>>>> associated with a profile that appears on an IANA registry?
>>>> 
>>>> The IANA registry would point to some RFC that described the semantics.
>>>> 
>>>> --
>>>> Michael Richardson <[e-mail]>, Sandelman Software Works 
>>>> -= IPv6 IoT consulting =-
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> RATS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rats
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats