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

[Laurence Lundblade <[e-mail]>]

> On Nov 12, 2019, at 11:12 PM, Schönwälder, Jürgen <[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