Subject: [Rats] EAT and Attestation Results schemes

From: Laurence Lundblade <[email-masked]>
Date: Wed, 3 Nov 2021 12:42:45 -0700

Hi folks,

There’s been a side discussion on Attestation Results and I want to bring some of it to the general list. To start, here’s some framing on how I see Attestation Results and EAT.

First, I think there will be several, perhaps many, schemes/drafts/claims for Attestation Results because of varying use cases and requirements. Financial use cases may be different than phones which may be different from routers, tiny IoT devices… I don’t think one-size-fits all is possible.

Here’s some examples:
HTTPS/JSON/EAT-based with a very simple yeah/nay result for allowing devices onto the network
Eric’s proposal using HTTP/JWT/EAT for encoding, perhaps for TPM-using devices
Eric’s proposal using YANG
Composite chain of Verifiers with partially results using EAT with both CBOR and JSON (we have composite Attester so we’ll probably have corresponding composite Verifiers) involving high-security devices with both a TEE and SE
RP uses a ML-based risk engine and wants every claim from the Attester plus all the implicit claims added by the Verifier for a widely used financial use case

Just like with Attestation Evidence, I see EAT as a basis to serve many different use cases for Attestation Results, roughly as follows:

Other AR encodings and formats (YANG,...) are fine, along side of EAT
EAT has a few claims for AR now, and I expect lots of others to be added
Easy to use CDDL to define new AR claims that go into EAT and can be encoded in both JSON and CBOR
EAT is not an AR solution in and of itself; it is more of a framework
EAT profiles can be made for locked down specific AR solutions

Last, I’ve made a PR for a very simple enumerated result code for EAT <https://github.com/ietf-rats-wg/eat/pull/137> — success, fail, malfunction, wrong input type. It is intended for use for AR, but not exclusively, nor is there any requirement that every AR format use it (or every AR format use EAT). It just seems like a very useful addition to EAT to have such a general result code.

It is not extensible or a framework for error codes. If you want more detail, strings and such create your own claims.

It is intended to be complementary to Eric’s AR draft.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 4 Nov 2021 10:10:24 -0700

> On Nov 3, 2021, at 12:42 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> 

Clarification — I mean they will be added in other documents, through the CWT and JWT registries and other, not to the EAT document itself.

LL