[Rats] EAT Review Comments

[Hannes Tschofenig <[e-mail]>]

Hi all,

As promised, here are some high-level review comments, which are most important to us:

- The document would benefit from a normative language. Think in the following way: What does a party creating a claim and a party verifying the claim have to do in order to ensure interoperability. Use SHOULDs and MAYs when you can give the reader a decision path.

- Don't put comments into the CDDL since the same text is already in the draft. You are essentially putting the text in the document twice. This will reduce the size of the document.

- Normative vs. informative references: If you need to read a specification as a developer in order to implement a listed claim then this reference is normative. For example, the location claim cannot be implemented without having to open the W3C geolocation API. Hence, that reference becomes normative.

- Aim for consistent use of terminology. An example is the use of "entity", "entity/device", "device/entity", "entity/client device", "device entity", "entity or submod", "entity (typically a device)". In Section 1.4 you seem to suggest that "entity" is the right term. But throughout the text you mix the terms. The  EAT draft should adopt the terminology established in the architecture doc, which would be "attester" rather than "entity". Section 2 should import the vocabulary from the architecture document **by reference** and establish the aliasing "attester" = "entity" (and maybe = "device") by saying something along these lines: "attester and entity are used interchangeably in this document".

- The spec is long and there is a lot of feature creep. This makes it appear very complex. I believe there are two reasons for this, namely (a) there is suddenly a lot of architectural discussion in this document. This is unnecessary given that there is a separate architecture document. There is no need to repeat the content here as well. Do you expect a reader to go through the architecture document before reading this document? (b) There are claims in this specification that may sound good but I wonder whether they are ready for prime time already. This document does not need to collect all claims that relate to attestation. Most likely there is not much experience implementing some of these claims either, which reduces the quality of the specification. Sometimes less is just more.

- Unprotected CWT Claims Sets (UCCS): I see UCCS as an architectural aspect. Normally, the implications for the EAT spec should be quite small. The purpose of the EAT spec is to define claims that go into a CWT. EAT does not mandate a specific way to protect the claims (digital signature, MAC, encryption, etc.) then UCCS has not much implication besides a short mention in the security consideration section. Given that UCCS is a separate working group document we would remove Section 4 along with any reference to UJCS.

Ciao
Hannes & Thomas




IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.