[Rats] What's to EAT?
Michael Richardson <email@example.com> Tue, 12 November 2019 09:22 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B9D120052 for <firstname.lastname@example.org>; Tue, 12 Nov 2019 01:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([22.214.171.124]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7iFy7mXSXTH for <email@example.com>; Tue, 12 Nov 2019 01:22:22 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [126.96.36.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFFDE120046 for <firstname.lastname@example.org>; Tue, 12 Nov 2019 01:22:22 -0800 (PST)
Received: from [192.168.44.20] (unknown [188.8.131.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id 610153897A for <email@example.com>; Tue, 12 Nov 2019 04:18:59 -0500 (EST)
To: "firstname.lastname@example.org" <email@example.com>
From: Michael Richardson <firstname.lastname@example.org>
Date: Tue, 12 Nov 2019 17:08:05 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
Content-Type: text/plain; charset=utf-8
Subject: [Rats] What's to EAT?
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 09:22:24 -0000
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'm completely perplexed by that thread about "Call for adoption", so I've changed the subject line, and started a new thread. > > 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”. > +1 > > > > 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. > > > I mostly agree. I think that it's okay to say, "The uptime claim is forwarded to the Flu-Flu Processor" rather than saying "The Token containing the uptime claim is forwarded to the Flu-Flu Processor"