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

["Smith, Ned" <[e-mail]>]

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