Re: [Rats] Call for Adoption: EAT draft

[Hannes Tschofenig <[e-mail]>]

Hi Henk,

A quick response below.

-----Original Message-----
From: Henk Birkholz <[e-mail]>
Sent: Samstag, 1. Juni 2019 00:52
To: Hannes Tschofenig <[e-mail]>; Laurence Lundblade <[e-mail]>; Eric Voit (evoit) <[e-mail]>
Cc: [e-mail]; Giridhar Mandyam <[e-mail]>
Subject: Re: [Rats] Call for Adoption: EAT draft

Hi Hannes,

just thoughts from the top of my head:

1.) Expert review of course is helpful (feasibility, no overlap in claim semantics, etc.) and a quite straight forward procedure, but the qualifying criteria for CWT claims for EAT review might be defined in the EAT draft?

[Hannes] Yes, we have been talking about what those qualifying criteria for CWT claims in the EAT draft could look like. As mentioned, I don't have an answer for it. Still thinking...

2.) in order to not make this a shopping list, I like the SUIT approach Hannes proposed, I think (not sure, if it is entirely applicable). In a nutshell, going from user story, to requirement, to claims.

[Hannes] I don't think I suggested a specific approach here. The downside of the SUIT approach was/is that it takes very long and it is sometimes hard to decide what content goes where because everything is somewhat interrelated.

But maybe that is on the information model level and should not burden the EAT I-D which is at a nice scope right now?

3.) Additionally, the semantics of a new CWT claim for EAT should be checked against existing YANG statement semantics. If there is semantic equivalence (or superset) defined in YANG already, the claim must reference that one.

[Hannes] If I understand you correctly, then you are given the Yang registry a high priority in the process of defining EAT claims. Is that what you mean? How would this work for someone like Arm interested in the IoT space with the work we have been doing for Arm Trusted Firmware-M?

I though this can be done via

> https://yangcatalog.org/yang-search/

But it seem not work for me right now...


That said, this would probably mitigate the issue, I assume. I might be missing something important here, of course.

[Hannes] No, I don't think so. I think we are just a bit head of the discussion while doing a call for adoption.

Ciao
Hannes


Viele Grüße,

Henk



On 5/31/19 4:10 PM, Hannes Tschofenig wrote:
> Hi Eric, Hi Laurence,
>
> I thought about this a bit more.
>
> If I understand it correctly then your main concern is that we duplicate information in the CWT claims registry that is already available in other registries. Is my understanding correct?
> I also hear a second concern, which is more about whether the existing CWT / JWT registry contains claims that are not suitable for use in an EAT token.
>
> Underlying both concerns is the question about what makes for a good claim for use within an EAT token. Do we know the answer?
>
> Ciao
> Hannes
>
> -----Original Message-----
> From: Hannes Tschofenig
> Sent: Freitag, 31. Mai 2019 09:55
> To: 'Laurence Lundblade' <[e-mail]>; Eric Voit (evoit)
> <[e-mail]>
> Cc: [e-mail]; Giridhar Mandyam <[e-mail]>
> Subject: RE: [Rats] Call for Adoption: EAT draft
>
> Hi Laurence, Hi Eric,
>
>> So if an EAT is a CWT, then the proposal is to change the IANA registry rules for CWT in the EAT draft. Is that allowed? This is really a change to CWT and even JWT. Seems like it is saying that if a YANG-defined claim exists for a possible CWT or JWT claim, the YANG-based claim MUST be used.
>
> IMHO everything can be changed.
>
>> I think Eric’s thought about harmonizing is a good one. Learn from past efforts. Improve interop.
>
> Learning from past efforts sounds always good. Let me pick on the example from below about draft-ietf-netmod-geo-location-01. It appears to me that the netmod group has either not looked at the work from the IETF GEOPRIV working group or ignored it. (I have not been involved in the netmod group and so I cannot say.) GEOPRIV published a number of RFCs that provide details about how to encode different geodetic location shapes (based on a mapping from GML), civic location, relative location, talks about uncertainty and confidence, how to encode moving objects, etc. While there is no need to use the info 1:1 there is a lot that can be learned from the work in that group. Of course, the content for the location encoding in draft-mandyam-eat-01 isn't much better.
>
> For me the biggest question is whether location is actually a good source of information conveyed in an EAT token.
>
> Eric, I understand that you do not want to duplicate information. I don’t want to do that either. I have been wondering about this aspect myself (particularly when I read the location claim). For example, in the LwM2M context we have a (pretty naive) location object as part of the data model as well. The data model we use with LwM2M is different to how data is modelled in the EAT token. Is this unavoidable? In some sense the situation is similar to the Yang-defined data model. The source of information comes from a different part of the system and is conveyed differently. Maybe you could call it a different layering where a device with Yang objects has to treat the EAT token as opaque (particularly since it is digitally signed and potentially encrypted). I am currently leaning towards seeing it that way from a LwM2M perspective.
>
> Ciao
> Hannes
>
> ~ snip ~
>
> However, IANA registry rules revising aside, making it a MUST seems too much. I think the YANG-defined claims should be very much seriously considered, just like any other previous data structure definition, but that there be no blanket requirement.
>
> To go a little further and to be clear. When a YANG-defined claim is used the CBOR encoding of it will be used with CWT and the JSON encoding of it will be used with JWT. This hinges on draft-ietf-core-yang-cbor-10 producing satisfying, compact and sensible CBOR encodings (binary data is really CBOR binary, claim keys are small integers…).
>
> LL
>
>
>> On May 30, 2019, at 12:19 PM, Eric Voit (evoit) <[e-mail]> wrote:
>>
>> Hi Hannes,
>>
>> I do like EAT.  I am hoping that it gets adopted.
>>
>> At the same time, I am trying to avoid unnecessary mapping of claims from a chipmakers domain into system integrator /network operator domains.  I believe much pain can be avoided with a little planning up front.  That is what I am trying to facilitate with this discussion.
>>
>> Specific details/examples in-line...
>>
>>> From: Hannes Tschofenig, May 30, 2019 1:18 PM
>>>
>>> Hi Giri, Hi Eric,
>>>
>>> (a) some principles/guidance to CWT claims registry people on
>>> avoiding the mass registration of lightly-used or unused claims
>>>
>>> Why is this a requirement? When a claim is registered then it is most likely done with the anticipation that it will be used. I have not seen other IETF registries that have raised the bar to a similar level, at least the JWT claims registry does not work that way. Furthermore, what is the harm in registering claims that later turn out to be less frequently used?
>>
>> Let me provide a *best* case example.  In the NETMOD WG, there is a draft-ietf-netmod-geo-location.  Both that draft and this have definitions of latitude, longitude, altitude, accuracy, etc.   The *good* news is that both drafts are based on WGS84.  So at least our experts have lucked in to using a consistent resource.  But are these the same objects?  How does a reader know?   In one of the documents the latitude/longitude attributes are "FloatOrNumber", in the other they are "decimal64 {fraction-digits 16}".
>>
>> It of course gets harder for other objects.   The velocity objects in draft-mandyam-rats-eat are "heading" and "speed".  And draft-ietf-netmod-geo-location has this information "v-north", " v-east", and " v-up".  Here we have different formats, the first of which cannot be easily upgraded to serve three dimensions.
>>
>> And then we get into other harder objects where we will have timestamping, explicit domains of allowed entries, etc.  And is there is no boundaries on what might be claimed as an EAT, in theory we could create a parallel domain of objects without description on how to map between the two, placing the heavy lifting onto the implementer.
>>
>> Now I am not trying to solve world hunger in this thread.  I am just trying to have the draft consider minimizing inter-ecosystem friction where we can see it coming.  I believe with a little foresight we can ensure a consistent population and data typing for a subset of claims.   Without foresight, I see that people will create new CWT to avoid some later mapping.  And more/redundant CWT tags will harm interoperability.
>>
>>> (b) a requirement to map claims to existing YANG objects, if these
>>> YANG objects exist
>>>
>>> I also don’t understand this requirement. Is there some design rational why this would be needed/useful?
>>
>> Per above, EAT claim instances need to be integrated with other work/ecosystems in the IETF after the information comes off of a hardware chip.  A claim registry shouldn't create redundant info/formats to other work/ecosystems when it can be avoided, at least without broad discussion and consensus.   (I.e., lets avoid unconscious object definition and object domain overlaps wherever possible.)
>>
>> Eric
>>
>>> Cia
>>> Hannes
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
>
> 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]
> https://www.ietf.org/mailman/listinfo/rats
>
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.