Subject: Re: [Rats] Call for Adoption: EAT draft

From: Laurence Lundblade <[email-masked]>
Date: Sun, 2 Jun 2019 03:33:26 -0700

I think it makes sense to separate into two:

1) New rules and advice for registering CWT/JWT claims
2) A basic set of attestation-related claims this WG will define

To go on about 1), it seems we are expanding CWT/JWT from just being auth tokens to also being attestation tokens and also identity certs (draft-birkholz-core-coid-01) and maybe X.509 replacements. This seems like mostly a good idea to me. It will be super cool that code can be shared by all of these for example. Lots of claims will overlap which is good too.

So I don’t think it makes sense to talk about "expert review of EAT claims". Rather we should talk about "expert review of CWT/JWT claims" and how it should be different than it is now.

Also, if you haven’t looked at the register JWT claims, it’s worth checking out: https://www.iana.org/assignments/jwt/jwt.xhtml. Am also curious what people think of bringing them into CWT and especially how we avoid conflicting duplication between CWT and JWT.

To say more about 2), it seems we should really work to come up with a nice, well-thought-out, medium-sized, coherent set of claims for attestation and put them in an RFC. This is roughly what the EAT draft is.

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 3 Jun 2019 15:00:56 +0000

From: Laurence Lundblade, June 2, 2019 6:33 AM

<eric> One thing to consider is that claims from hardware are perceived as more trustworthy, with definitions changing less frequently than from software. (Whether this is true is of course debatable.)

If nothing else, if hardware and software generated claims are to be consolidated into common list(s), then a revised expert review process will need to reconcile the varying timescales and flexibilities of different implementers.

Eric

LL

---

From: Simon Frost <[email-masked]>
Date: Mon, 3 Jun 2019 16:23:49 +0000

> Also, if you haven’t looked at the register JWT claims, it’s worth checking out: https://www.iana.org/assignments/jwt/jwt.xhtml. Am also curious what people think of bringing them into CWT and espe…

When I look at the JWT registry, it looks like an opportunity lost. It’s a mix of claims that could be generalised for reuse, e.g. there are multiple claims iat / auth_time and maybe also toe for time-something-happened, while other claims will always be specific to a single use case. One of the great appeals of EAT is that it offers a standard set of claims while everything else is custom to a use case. As several discussions have indicated, there are several information sets that lend themselves to new standard claims. For example, a chunk of the JWT OpenID claims would make a very useful ‘Person’ standard set. I know not all cases can be captured in standard sets but not having them encourages duplication without reuse.

If the registry included the information for a specific use case to register a custom claim key range and a reference / authority URL where those definitions can be tracked, that might encourage implementations to use both the standard & specific claim sets.

Thanks
Simon

From: Laurence Lundblade <[email-masked]>
Sent: 02 June 2019 11:33
To: Henk Birkholz <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Eric Voit (evoit) <[email-masked]>; [email-masked]; Giridhar Mandyam <[email-masked]>
Subject: Re: [Rats] Call for Adoption: EAT draft

LL

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 11 Jun 2019 11:24:42 -0400

Greetings!

A month later, my assessment of the status of this last call is as follows:

The EAT draft is adopted with identified issues that need to be resolved
through the WG consensus process.  I am listing the identified issues in
this message.  If any issues have been left out, please do correct me and
we'll make sure the WG runs through the full list.  Additional decision
points can be added at any time for WG discussion, as with any WG adopted
draft.  If details within any of the identified issues require
clarification, we can figure that out in an issue tracking format and
ensure we have consensus on each identified item.

   1. Clearly define EAT (token, structured format, protocol message, etc.)
   2. CWT or CWT-like?  My take from the thread is that we move to CWT and
   we use the CWT or JWT registry as appropriate with updated instructions.
   Instructions should account for unused or barely used claims.
   3. Process for review of claims entered into CWT/JWT registry
   4. A basic set of attestation related claims and what makes a good claim
   for use within EAT. Define claims profile for network equipment. Determine
   which other profiles (if any) should be considered.
   5. Limits to what can be populated in an EAT claim

Related work in other drafts may influence this draft in time as well, such
as an information model.  Additional questions came up that I trust will be
addressed in the draft update, such as the ability to create a custom claim
to carry the entire TPM attestation as a payload and relationships to
FIDO/Webauthn.  Examples may be helpful.  Ensuring clean interoperation
with other drafts will be important as well.

If the authors could post a new version with the name formatted as a WG
draft, that can serve as a next step.  If they have felt there is agreement
on some of the items discussed, this new version can include their proposed
text to address those points for WG review.  If the draft is in github,
then a pull request may be used to suggest corrections, but proposed text
should also go to the list.

draft-ietf-rats-eat-00.txt

Thank you,
Kathleen

On Fri, May 10, 2019 at 11:06 AM Kathleen Moriarty <
[email-masked]> wrote:

> Greetings!
>
> At IETF 104, a poll was taken to determine interest in the RATS WG
> adopting:
>
> The Entity Attestation Token (EAT)
> https://datatracker.ietf.org/doc/draft-mandyam-rats-eat/
>
> This begins a 2 week period to determine interest in adopting this draft
> as a working group item.  The poll will close on May 24th EOD PDT.
>
> Minutes from IETF 104:
> https://datatracker.ietf.org/doc/minutes-104-rats/
> --
>
> Best regards,
> Kathleen
>

-- 

Best regards,
Kathleen