Re: [Rats] What's to EAT? - terminology clarification

[Laurence Lundblade <[e-mail]>]

One of the D’s in CDDL is for Data and I think someone told me that CDDL is for Data Models and that what is currently labeled as the Data Model in the EAT document is the Encoding.

It doesn’t matter much to me what we label the different parts of the EAT document. Happy to adjust the labeling. However having 1) the textual claim descriptions, 2) having CDDL as the next level of description and 3) being able to encode CDDL in JSON and CBOR (and maybe ASN.1) mechanically does matter to me.

LL




> On Nov 13, 2019, at 9:51 AM, Henk Birkholz <[e-mail]> wrote:
> 
> Now I am a bit confused. Didn't you attempt to use CDDL as an information model in the EAT I-D?
> 
> On 13.11.19 18:49, Laurence Lundblade wrote:
>>> On Nov 12, 2019, at 11:12 PM, Schönwälder, Jürgen <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Concerning IMs and DMs, here is the (extended) RFC 3444 view that
>>> is commonly used by some parts of the IETF:
>>> 
>>>                 IM               --> conceptual/abstract model
>>>                 |                    for designers and operators
>>>      +----------+---------+
>>>      |          |         |
>>>      DM         DM        DM     --> concrete/detailed model
>>>      |          |         |          for implementors
>>>   +--+--+   +--+--+--+    |
>>>   |     |   |  |  |  |    |
>>>   EN    EN  EN EN EN EN   EN     --> encodings / representation formats
>>>                                      for instance data
>> In the EAT draft, the EAT claims information model is in the largely textual description of each claim.
>> In the EAT draft there is just one EAT claims data model. It is the CDDL in the EAT draft.
>> Currently there are two claims encodings, CBOR and JSON. Thanks to CDDL, we get from data model to encoding in a largely mechanical way and there is little text needed.
>>                 IM: Text
>>                 |
>>                 +
>>                 |
>>                 DM: CDDL
>>                 |
>>             +---+--+
>>             |      |
>>            CBOR   JSON
>> I think this is a good, simple and effective way to proceed.
>> (There are a few things wrong with the way this is written up in the current EAT draft that need to be fixed:
>> - The encodings are mis labeled as the data model
>> - I’m not sure the CDDL is correct)
>> Maybe one more encoding for X.509/ASN.1/DER is added to cover Dave’s use case. Hopefully it could be by saying how to encode the needed subset of CDDL into ASN.1/DER. Android Keystore also uses X.509 for attestations, so this might add motivation. To keep effort down, CDDL->ASN.1 should just be for EAT and a CDDL subset.
>> I do not think we should try to bring YANG in here. So there is no YANG expression of EAT claims. (I did see Eric’s GPS use case, but don’t think it is mainstream enough to motivate the complexity and large effort to bring YANG into play here).
>> This email is just about the “EAT claims information model”. There can be other separate information models for other parts of RATS. I don’t think there should be one global RATS information model that spans all the documents.
>> The gap of sorts here is IANA registered claims, the existing ones and new ones. There’s no requirement to provide an information model or CDDL when you register new claims with IANA or even coordinate between JWT and CWT.
>> LL
>> _______________________________________________
>> RATS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
>