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

[Dave Thaler <[e-mail]>]

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

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.

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].

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



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


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).



Sure, Evidence is certainly conveyed in a serialized format.

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



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.



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.



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,

[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.



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 ☺



much less interested in standardizing what the architecture calls Evidence.

[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



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



[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" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:


On Nov 12, 2019, at 1:08 AM, Michael Richardson <[e-mail]<mailto:[e-mail]>> 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