Re: [Rats] Call for Adoption: EAT draft

[Hannes Tschofenig <[e-mail]>]

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.