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

From: "Smith, Ned" <[email-masked]>
Date: Tue, 12 Nov 2019 22:55:44 +0000

Including Dave Thaler’s thread from forked subject line in [1].

The eat draft uses “Claim(s)” in the section heading for the Information Model. CDDL expressions are used. I think this is OK. We don’t need to change it to “Evidence” IMO. The architecture draft (birkholz) strongly implies that Evidence is signed (verifiable or provable). This suggests Evidence is in a serialized format (hence isn’t CDDL, YANG or ASN.1). I don’t think “Evidence” would be as precise a way to talk about an information model object as “Claim(s)” would be.

YANG is not a serializable format hence it is more appropriately an information model language for the purposes of RATS (IMO).

Going back to the original question. A Token (EAT, CWT, JWT) is an example of something the architecture calls Evidence. CDDL, YANG are expressions of something that the architecture should call Claims. (agree?)

-Ned

[1] Dave Thaler wrote:
> So far the group has used the term "EAT" to refer to both the information model and data serialization expressions.

I would rather see the term EAT (and any other terms ending in Token, like JWT and CWT) only be used to refer to
data serialization expressions, not the information model.

> When extending information model to YANG or some other serialization (e.g. ASN.1). Given the possibility for an IM
> expression to be realized by different serializations, what term should we give to the IM description?

That’s a fine question, and I don’t have any strong preference right now, other than to not use the same term as something else.
Offhand, my preference would be to not define a term, and just use Evidence and Attestation Result as the terms for
format-independent discussion.  I think it is useful to distinguish between Evidence vs Attestation Results in many cases.
And if you need to refer to both, then we can always use both together, such as “Evidence and Attestation Results”.

> The term "Claim" has been used extensively. Do we want to agree to use "claim" to refer to anything that is an IM
> expression in RATS and "Token" for any serialization (realization) even if it isn't a JWT or CWT?

I would say no. To me, a claim is one particular piece of information, where a “Token” or whatever else has a set of claims.

Dave

On 11/12/19, 11:00 AM, "RATS on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Nov 12, 2019, at 1:08 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

On 2019-11-12 12:19 p.m., Dave Thaler wrote:

Ned Smith wrote:

So far the group has used the term "EAT" to refer to both the
information model and data serialization expressions.

I would rather see the term EAT (and any other terms ending in Token,
like JWT and CWT) only be used to refer to

data serialization expressions, not the information model.
I concur.

I disagree with that.

I don’t think we want one information model for all of RATS.

EAT has an information model and data model for what it expresses.

The YANG Module has an information and data model for what it expresses.

The primary purpose for use of information models (plural!) is so we can described things like claims once and then have a largely mechanical way to serialize them in different ways, CBOR and JSON.

Note that CWT and JWT don’t use the information model concept. They are mostly two independently defined and loosely coordinated data models. We are trying to do different by having a common information model that covers both. One might argue that CWT and JWT should have done what we are doing in EAT.

LL

---

From: Dave Thaler <[email-masked]>
Date: Tue, 12 Nov 2019 23:33:26 +0000

From: RATS <[email-masked]> On Behalf Of Smith, Ned
Sent: Tuesday, November 12, 2019 2:56 PM
To: Laurence Lundblade <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] What's to EAT? - terminology clarification

The eat draft uses “Claim(s)” in the section heading for the Information Model. CDDL expressions are used. I think this is OK. We don’t need to change it to “Evidence” IMO. The architecture draft (birkholz) strongly implies that Evidence is signed (verifiable or provable). This suggests Evidence is in a serialized format (hence isn’t CDDL, YANG or ASN.1).

Sure, Evidence is certainly conveyed in a serialized format.

I don’t think “Evidence” would be as precise a way to talk about an information model object as “Claim(s)” would be.

Going back to the original question. A Token (EAT, CWT, JWT) is an example of something the architecture calls Evidence.

FYI, I (and others I’ve talked to) are far more interested in the use of a Token for what the architecture calls Attestation Format,

much less interested in standardizing what the architecture calls Evidence.

A Verifier can have multiple simultaneous purposes, as mentioned in my draft:

1)     To make policy decisions that include verifying Evidence that chains up to a manufacturer, and then generating an Attestation Result

whose security chains up to the Verifier (or their org) rather than every manufacturer of every Attester, so that the Relying Party’s policy

can be simple and just trust the Verifier.

2)     To allow heterogeneous Attesters, with different Evidence formats (including existing/proprietary/whatever ones), to talk to a common Verifier,
which can then provide a standard Attestation Format to Relying Parties, so that one need not have every Relying Party understand every

Evidence format, of which many already exist.

So I personally will argue against scoping EAT to only Evidence, and for keeping it generic and usable for Attestation Results.

(Others I’ve talked to both inside and outside Microsoft share this view, so I’m also relying it as a messenger, not just an advocate.)

If the WG chooses to only standardize what we now call Evidence and ignore Attestation Results, then I don’t believe it meets the needs

of either Microsoft or, I suspect, the TEEP WG use case.

Dave

CDDL, YANG are expressions of something that the architecture should call Claims. (agree?)

-Ned

Dave

Ned Smith wrote:

I disagree with that.

LL

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 12 Nov 2019 23:59:31 +0000

I agree that the thread regarding “Claims”, “Tokens” and “Evidence” largely is applicable to “Attestation Results”. Like Evidence, Attestation Results are a serialization. Claims are also relevant as information model expressions that may be realized as Attestation Results serialization.

See more inline [nms].

On 11/12/19, 15:33 PM, "Dave Thaler" <[email-masked]<mailto:[email-masked]>> wrote:

[nms] It is also signed in a serialized format.

[nms] I don’t see the term “Attestation Format” occurring in the current arch (editors draft). Maybe this needs disambiguation from the current text that uses “format” in the context of defining other structures – i.e. Evidence, Reference Values and Attestation Results.

[nms] My assumption is that a claim formatted as Evidence could be synonymous with a claim formatted as Attestation Results (and the reverse is also true). This doesn’t imply there couldn’t be other formatted Evidence with different formatting that isn’t suitable for use as Attestation Results. Likewise, Verifiers could produce Attestation Results with claims that are not asserted by any Attester. But the architecture wouldn’t expect (I presume) to define Attestation Results using a format that could not be used as Evidence.

Dave

-Ned

Dave

Ned Smith wrote:

I disagree with that.

LL

---

From: Dave Thaler <[email-masked]>
Date: Wed, 13 Nov 2019 00:06:51 +0000

From: Smith, Ned <[email-masked]>
Sent: Tuesday, November 12, 2019 4:00 PM
To: Dave Thaler <[email-masked]>; Laurence Lundblade <[email-masked]>; Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] What's to EAT? - terminology clarification

I mostly agree with you there.   I would just say Attestation Results are conveyed using a serialization.  I would be fine also using the term to refer to the information, not just the serialization.
as in saying “The Attestation Results are serialized using format XYZ and sent to the Relying Party via protocol ABC”.   Such a sentence uses the term to apply to the information both before and after
serialization.   If the WG chooses to fine it to just post-serialization that’s ok with me, I just think it’s more convenient as I described.

See more inline [nms].

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Smith, Ned
Sent: Tuesday, November 12, 2019 2:56 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] What's to EAT? - terminology clarification

Yes I agree with that part.   I was trying to just make the point I articulated more specifically at the top of this response.   But I don’t feel strongly either way.

Sorry for the confusion, there is no single “arch doc”.   It’s in my arch doc, and it’s in the slides and minutes and discussion from last IETF where everyone agreed on it

(I believe it was Henk’s term originally, I got it from Henk at the hackathon :) then regardless of whether the other arch doc proposal uses the term or not ☺

[nms] My assumption is that a claim formatted as Evidence could be synonymous with a claim formatted as Attestation Results (and the reverse is also true).

Agree

This doesn’t imply there couldn’t be other formatted Evidence with different formatting that isn’t suitable for use as Attestation Results.

Agree.   I’ve heard some people arguing that tcglog is one such format, but other opinions may vary.

Likewise, Verifiers could produce Attestation Results with claims that are not asserted by any Attester.

Agree.

But the architecture wouldn’t expect (I presume) to define Attestation Results using a format that could not be used as Evidence.

Agree.

Sound like you and I are on the same page, modulo minor terminology preference at top that I don’t consider a big deal either way.

Dave

Dave

-Ned

Dave

Ned Smith wrote:

I disagree with that.

LL

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Nov 2019 03:09:47 +0000

When I see discussions using terms like serialization and information model, I start to get traumatized, thinking of what happened when XML was switched from a syntax to an “infoset” and took XML Schema, WSDL, web services, and everything else down with it.

The IETF is about “bits on the wire” and the semantics of those bits.

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 13 Nov 2019 07:12:45 +0000

> When I see discussions using terms like serialization and information model, I start to get traumatized, thinking of what happened when XML was switched from a syntax to an “infoset” and took XML S…

I believe that not agreeing on terminology causes misunderstandings
and ultimately delays progress.

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
With YANG, we have:

          YANG                    --> concrete/detailed model
            |                         for implementors
      +-----+-----+
      |     |     |
     XML  JSON [CBOR]             --> encodings / representation formats
                                      for instance data

IMs that are more abstract than YANG I have seen written informally
(diagrams plus text) or using ad-hoc semi-formal notations.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 13 Nov 2019 09:49:05 -0800

> On Nov 12, 2019, at 11:12 PM, Schönwälder, Jürgen <[email-masked]> wrote:
> 

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

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 13 Nov 2019 18:51:00 +0100

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 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> 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
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 13 Nov 2019 11:30:01 -0800

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 <[email-masked]> wrote:
> 
> Now I am a bit confused. Didn't you attempt to use CDDL as an information model in the EAT I-D?
> 
>>> On Nov 12, 2019, at 11:12 PM, Schönwälder, Jürgen <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 13 Nov 2019 20:39:14 +0100

Up to today, I was looking at the CDDL fragments in the EAT I-D with 
some leniency, as I though the CDDL preludes would not be used, leaving 
the higher level tree composition features for use as a first draft to 
create IM statements in well-defined non-English (a good approach to 
peruse, I thought).

If you are using them now as actual CDDL specification fragments, I'll 
think I have to chime in and provide contribution on how to do that in a 
compliant manner that will result in a valid overall CDDL ROOT 
specification in the end.

We can talk about that in .sg. It will not take very long, if we do that 
in concert, I think.

Viele Grüße,

Henk

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 14 Nov 2019 14:11:39 +0000

> I think this is a good, simple and effective way to proceed.

This basic model works for me.

/js

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 14 Nov 2019 19:57:00 +0000

Protocols and binding of data to protocol can use a protocol modelling (PM) language (e.g. RAML). Another thread cited RFC-8641 which uses YANG to define subscription protocol interaction suggests YANG can be used for protocol modeling. Interestingly, RFC-8642 uses mostly XML encoding (EN) or structured text (IM) for most of its examples. 

YANG fits as a DM and a PM.
RAML is a PM for REST. (though may not be interesting in terms of current drafts).
XML is an EN that can be added. (Though it may not make sense to assume CDDL as an XML encoding).

On 11/14/19, 6:12 AM, "RATS on behalf of Schönwälder, Jürgen" <[email-masked] on behalf of [email-masked]> wrote:

    
    /js

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Nov 2019 12:30:08 +0800

If we are going to use JWT/CWT for the security of EATs, then I am skeptical
that CDDL (or any other Data Modeling language) brings anything to the table.

What we need are clear semantic descriptions of claims.
Often we will need some anciliary data associated with the claim, and
sometimes that data will be more complex than a single binary blob.  In those
cases, a bit of CDDL will benefit us.

I don't think that a YANG model will help us at all for this.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 18 Nov 2019 13:31:08 +0800

Seems to me that the CDDL in the EAT draft is working well to define claims that are mechanically serialized into JSON or CBOR and added to JWT and CWT.

Isn’t that the end of the story? Is there a problem with the EAT doc?

LL

> On Nov 18, 2019, at 12:30 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 18 Nov 2019 06:43:51 +0100

I think the question was: what value does it add?

At the moment you cannot utilize it, and the structure is a bit... loose.

The latter can be remediated by creating a "how to create CDDL IM 
subsections" in a core document and tighten that a bit - so I see no 
real problem there (if it is about IM, I seem to have misunderstood the 
"CDDL is solely used fo DM now" quote).

The former is the thing Michael is inquiring about, I think. It reads as 
a DM and then it provides the "TLA"s for JWT and lables for cbor as tstr 
longer that 3 characters (which is a bit unusual). Therefore it cannot 
be mechanically serialized at the moment, I think. I am willing to chime 
in here, but I might also circling back to the latter item above. Maybe 
both the former and the latter items are more connected than is obvious 
and that is still unclear?

Viele Grüße,

Henk