Re: [Rats] Call for Adoption: EAT draft

[Henk Birkholz <[e-mail]>]

Hi list,

there is a lot to unpack here, but I am under time constraints, so I 
will only address a single topic for now.

On 6/1/19 1:46 AM, Smith, Ned wrote:
> I don't believe I'm connecting the dots regarding YANG and EAT/CWT defined claims. YANG is a data definition model (captures semantics) and can be used to generate data formats (syntax) (e.g. https://tools.ietf.org/html/draft-ietf-core-yang-cbor-10). EAT wasn't trying to be a data model AFAIK but seemed to include some semantics in the explanation of claims. However, CBOR/CWT syntax seems to be the context in which the semantic discussion takes place. Although, Laurence seems to agree that these could be separated - and possibly looking to CDDL as a way to express claims logically.
> 
> YANG and CDDL seem to be competing for the same role - that of being a language for capturing information model semantics precisely. Does this make sense to use both?

YANG is a modeling language for 'data at rest' that comes with a 
well-defined number of operations on how operate on this 'data at rest', 
including queries that return instances of the 'data at rest' data model 
via protocol messages.

CDDL is a data modeling language for 'data in motion' or documents 
encoded in JSON/CBOR. Operations are of course also often represented 
via CDDL as they are part of protocol messages. API, though, are typical 
not in the scope of CDDL.

In essence, Ned is correct wrt to semantics of information elements in 
so far that both YANG and CDDL can define them - and effectively 
represent the same semantics (most obviously in coreconf). Therefore, 
there is a requirement for mutual references between CWT and YANG 
semantics (everything else would be super confusing), or aligned 
registration.

But please let me highlight, in general, YANG and CDDL are most 
certainly not competing for the same role: prominent example, you do not 
need the overhead of YANG to define how protocol messages look like in CDDL.

The CDDL authors are working on a simple solution in the form of an 
informative RFC for guidance in this domain right now.


Viele Grüße,

Henk



> 
> If there are other WGs / RFCs that already capture claims semantics that RATS determines is relevant for describing trustworthiness, then the RATS information model could simply reference these other works.
> 
> Nevertheless, there may still be additional work ensuring the data model bindings can be realized for whatever formats the RATS WG determines are necessary (e.g. CBOR, CWT, other?).
> 
> Some discipline may be required to qualify discussion threads in terms of information model (semantics) and relevance to trustworthiness from discussion about formatting and the namespaces that are formatting specific (and therefore potentially semantically overlapping). Maybe consider making better use of the subject to better focus thread discussion? Just a suggestion.
> 
> Thx,
> Ned
> 
> 
> 
> On 5/31/19, 3:52 PM, "RATS on behalf of Henk Birkholz" <[e-mail] on behalf of [e-mail]> wrote:
> 
>      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?
>      
>      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.
>      
>      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.
>      
>      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.
>      
>      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
>      >
>      
>      _______________________________________________
>      RATS mailing list
>      [e-mail]
>      https://www.ietf.org/mailman/listinfo/rats
>      
>