Subject: [Rats] EAT IANA registry

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Nov 2019 14:05:06 +0800

Unrelated to my earlier mail, I would recommend to create a separate registry for EAT claims (I suppose that implies a nested object in the JWT/CWT) rather than to overload the CWT registry. Architecturally it just doesn’t jive to have all these claims as baseline CWT claims, and process-wise, it’s much more convenient for this group to control its own namespace.

Sorry if this has been raised before.

Thanks,

                Yaron

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Nov 2019 06:17:28 +0000

Yaron,
Could you explain why you think that this is a good idea?
Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Yaron Sheffer
Sent: Friday, November 22, 2019 2:05 PM
To: [email-masked]
Subject: [Rats] EAT IANA registry

Thanks,
                Yaron
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: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Nov 2019 22:57:34 +0800

Hi Hannes,

Looking at the JWT claim IANA registry [1], it is already a terrible mess of several different standards, obviously with many more coming. I guess what’s done is done, and I’ll take back my objection.

Thanks,

                Yaron

[1] https://www.iana.org/assignments/jwt/jwt.xhtml#claims

From: Hannes Tschofenig <[email-masked]>
Date: Friday, November 22, 2019 at 14:17
To: Yaron Sheffer <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: EAT IANA registry

Yaron, 

Ciao

Hannes

Thanks,

                Yaron

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 23 Nov 2019 08:29:24 -0800

One of our thoughts is that EAT profiles will help with this. For example, a special profile for toasters might list 5 claims that must be included in every attestation and 10 claims that are optional and maybe even prohibit all others.

LL

> On Nov 22, 2019, at 6:57 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Hannes,
>  
> [1] https://www.iana.org/assignments/jwt/jwt.xhtml#claims <https://www.iana.org/assignments/jwt/jwt.xhtml#claims>
>  
> From: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Yaron Sheffer
> To: [email-masked] <mailto:[email-masked]>
> _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 24 Nov 2019 12:54:57 +0200

Hi Laurence,

Yes, such profiles would certainly be helpful for attestation. 

Unfortunately they would not solve the fundamental problem that a developer who wishes to use JWT for anything, not necessarily attestation, is faced with a registry that he or she has no chance of figuring out.

Thanks,

                Yaron

From: Laurence Lundblade <[email-masked]>
Date: Saturday, November 23, 2019 at 18:29
To: Yaron Sheffer <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] EAT IANA registry

LL

Hi Hannes,

Thanks,

                Yaron

Yaron, 

Ciao

Hannes

Thanks,

                Yaron

_______________________________________________
RATS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 24 Nov 2019 09:26:43 -0800

> On Nov 24, 2019, at 2:54 AM, Yaron Sheffer <[email-masked]> wrote:
>  

But that’s not our problem here in RATS.

LL

---

From: Mike Jones <[email-masked]>
Date: Sun, 24 Nov 2019 22:14:30 +0000

EAT should use the IANA JSON Web Token (JWT) Claims registry for JWT claims and the IANA CBOR Web Token (CWT) Claims registry for CWT claims.  It’s intended that claims from different use cases inhabit the same registry, to facilitate claim reuse across use cases, where appropriate.  If they aren’t reused, no harm is done.

It would be far more confusing to developers to create duplicate, EAT-specific registries.

                                                       -- Mike

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Saturday, November 23, 2019 8:29 AM
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]; Hannes Tschofenig <[email-masked]>
Subject: [EXTERNAL] Re: [Rats] EAT IANA registry

LL

On Nov 22, 2019, at 6:57 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Hi Hannes,

Thanks,
                Yaron

[1] https://www.iana.org/assignments/jwt/jwt.xhtml#claims<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fjwt%2Fjwt.xhtml%23claims&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4dde883a52724dfeca7208d770325916%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637101233926912501&sdata=BdNuJhTcNNPSZwILWxum3RBISkNlmdS7QLiwO7xosxk%3D&reserved=0>

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 22, 2019 at 14:17
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: EAT IANA registry

Yaron,

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Yaron Sheffer
Sent: Friday, November 22, 2019 2:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Rats] EAT IANA registry

Thanks,
                Yaron
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.
_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4dde883a52724dfeca7208d770325916%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637101233926912501&sdata=3ei85Yo%2BWgKEVsozHSJtDIO1s0oyzPbspJ2QH5mGV0M%3D&reserved=0>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 26 Nov 2019 19:19:10 -0800

> It would be far more confusing to developers to create duplicate, EAT-specific registries.

I think the concern here is basically analogous to the difficulty we had
with draft-ietf-oauth-jwsreq, where the protocol mechanics forced us to
treat various field identifiers as both OAuth Parmeters and JWT Claims,
with potentially conflicting registries involved.

Here for EAT we do not have a separate registry already and so can avoid
the worst of the conflicts, but I'm not sure that "avoiding duplicates"
would apply to a proposal that makes a single JWT/CWT claim for "EAT data"
and puts the attestation claims in a map as the value for that "EAT data"
claim.  What existing JWT/CWT claims would duplicate the potential contents
of the EAT data fields?

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 26 Nov 2019 20:39:23 -0800

> On Nov 26, 2019, at 7:19 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> ...but I'm not sure that "avoiding duplicates"

That is an interesting thought — put all of EAT into one JWT/CWT claim that is a map. Other’s have mentioned it to me. It would let EAT re use the most compact integer CBOR integer labels.

Right now we re use the following claims from JWT or CWT by normative reference:
- nonce
- Token ID cti/jti
- Time stamp (iat)

Also these JWT or CWT seem either likely or possible use in EAT:
- cnf (proof of possession of key)
- iss Issuer
- expiration
- not before

That’s a fairly large overlap which makes me disinclined to putting all of EAT into one map that is one JWT/CWT claim, separating EAT claims from CWT/JWT claims.

I’m no OAuth expert, but I wonder if some of the EAT claims might be useful for other than EAT tokens, another reason not to keep them separate.

I suspect we’re going to find at least one more use for a signed map of label-value pairs in the next few years that would be able to re use at least some of these claims — another reason to keep them in the same space.

LL

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 27 Nov 2019 07:08:48 -0500

On Tue, Nov 26, 2019 at 11:39 PM Laurence Lundblade <[email-masked]>
wrote:

> That is an interesting thought — put all of EAT into one JWT/CWT claim
> that is a map. Other’s have mentioned it to me. It would let EAT re use the
> most compact integer CBOR integer labels.
>
> That’s a fairly large overlap which makes me disinclined to putting all of
> EAT into one map that is one JWT/CWT claim, separating EAT claims from
> CWT/JWT claims.
>
> I’m no OAuth expert, but I wonder if some of the EAT claims might be
> useful for other than EAT tokens, another reason not to keep them separate.
>
> I suspect we’re going to find at least one more use for a signed map of
> label-value pairs in the next few years that would be able to re use at
> least some of these claims — another reason to keep them in the same space.
>

One registry might become large, but it sounds like it will be easier and
reuse may happen on occassion.

To Yaron's earlier question, you can use claims that have not been
registered as the requirement to figure out vendor specific claims was
discussed and agreed as important at a previous interim for RATS.  If I
remember correctly, this was not done the same between JWT and CWT and that
was the issue to figure out.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 27 Nov 2019 17:53:32 +0200

To put it into perspective, there are already 57 claims registered [1]. So even if 7 claims overlap, this is a relatively *small* number. IMO there is high value in a separate namespace for EAT claims, and the standard way to create such a namespace in JSON is exactly as Ben is proposing.

Thanks,

                Yaron

[1] https://www.iana.org/assignments/jwt/jwt.xhtml

From: Laurence Lundblade <[email-masked]>
Date: Wednesday, November 27, 2019 at 06:39
To: Benjamin Kaduk <[email-masked]>
Cc: Mike Jones <Michael.Jones=[email-masked]>, Yaron Sheffer <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Tschofenig <[email-masked]>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry

- nonce

- Token ID cti/jti

- Time stamp (iat)

- iss Issuer

- expiration

- not before

LL

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Nov 2019 21:04:25 +0000

The point of having a common JWT Claims registry is to enable future specifications to benefit from reusing applicable claims registered by past specifications.  For instance, the Security Event Token [RFC 8417<https://tools.ietf.org/html/rfc8417>] specification recently registered this general-purpose claim:
   o  Claim Name: "txn"
   o  Claim Description: Transaction Identifier
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [RFC8417]<https://tools.ietf.org/html/rfc8417#section-2.2>

That made it available to EAT and other future specifications using JWTs.  If it had instead put it into its own registry, the potential for reuse would have been lost.

Let’s likewise let future specs benefit from EAT-defined claims by putting them in the normal IANA JWT Claims registry.

                                                       -- Mike

From: Yaron Sheffer <[email-masked]>
Sent: Wednesday, November 27, 2019 7:54 AM
To: Laurence Lundblade <[email-masked]>; Benjamin Kaduk <[email-masked]>
Cc: Mike Jones <[email-masked]>; [email-masked]; Hannes Tschofenig <[email-masked]>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry

Thanks,
                Yaron

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 27, 2019 at 06:39
To: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry

On Nov 26, 2019, at 7:19 PM, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 27 Nov 2019 23:27:18 +0200

Hi Mike,

To me this is a perfect counter-example: it is so generic as to be non-reusable. When used in an attestation, the verifier will want to have well defined syntax and semantics for what is attested, in this case a certain transaction. Here we don’t know what kind of a transaction this is (semantics) and how to interpret the transaction identifier (syntax).

If some particular environment wants to define claims for a particular, private kind of transaction, let’s make it easy for them to define their own, very specific foobar-transaction.

Thanks,

                Yaron

From: Mike Jones <[email-masked]>
Date: Wednesday, November 27, 2019 at 23:04
To: Yaron Sheffer <[email-masked]>, Laurence Lundblade <[email-masked]>, Benjamin Kaduk <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Hannes Tschofenig <[email-masked]>
Subject: RE: [Rats] [EXTERNAL] Re: EAT IANA registry

The point of having a common JWT Claims registry is to enable future specifications to benefit from reusing applicable claims registered by past specifications.  For instance, the Security Event Token [RFC 8417] specification recently registered this general-purpose claim:

   o  Claim Name: "txn"

   o  Specification Document(s): Section 2.2 of [RFC8417]

                                                       -- Mike

Thanks,

                Yaron

 

- nonce

- Token ID cti/jti

- Time stamp (iat)

- iss Issuer

- expiration

- not before

LL

---

From: Mike Jones <[email-masked]>
Date: Wed, 27 Nov 2019 22:22:46 +0000

I disagree.  If EAT JWTs needed a transaction ID, it would be logical and helpful to simply reuse the “txn” claim that already exists, rather defining its own.  (I don’t know whether it needs one or not, but the example is still valid.)  That’s possible because it’s in the registry.

This is just like EAT can reuse the “iat” (issued at) claim, because it’s in the IANA JWT Claims registry.  If it weren’t, EAT would have to reinvent the wheel for all such claims, which defeats the purpose of having registries.

                                                       -- Mike

From: Yaron Sheffer <[email-masked]>
Sent: Wednesday, November 27, 2019 1:27 PM
To: Mike Jones <[email-masked]>; Laurence Lundblade <[email-masked]>; Benjamin Kaduk <[email-masked]>
Cc: [email-masked]; Hannes Tschofenig <[email-masked]>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry

Hi Mike,

Thanks,
                Yaron

From: Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 27, 2019 at 23:04
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rats] [EXTERNAL] Re: EAT IANA registry

The point of having a common JWT Claims registry is to enable future specifications to benefit from reusing applicable claims registered by past specifications.  For instance, the Security Event Token [RFC 8417<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8417&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cad833cc0c2de4a4a335b08d7738096cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637104868433384141&sdata=ZAF0fffpQ0SsCPZjhvBqGYFzuPO7Y7gQ8DfiUV4pPv4%3D&reserved=0>] specification recently registered this general-purpose claim:
   o  Claim Name: "txn"
   o  Claim Description: Transaction Identifier
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [RFC8417]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8417%23section-2.2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cad833cc0c2de4a4a335b08d7738096cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637104868433394096&sdata=LukA4fT9skshqZX%2BqA%2FSwAUvNxazBKGdY0x9hqUKjwE%3D&reserved=0>

                                                       -- Mike

From: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 27, 2019 7:54 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry

Thanks,
                Yaron

[1] https://www.iana.org/assignments/jwt/jwt.xhtml<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fjwt%2Fjwt.xhtml&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cad833cc0c2de4a4a335b08d7738096cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637104868433394096&sdata=2zmM6v47%2BRg%2FHd%2FZYlTzUGtLzuqEFl%2FHz%2FwuKt3T8w4%3D&reserved=0>

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 27 Nov 2019 22:12:33 -0800

A separate EAT registry doesn’t seem like it will solve the issues being brought up.

You’re still going to have the problem of people registering all sorts of things like they have for JWT unless you put in place some more stringent rules about expert review and such. JWT already the most stringent qualification common in the IETF for a new claim short of standards action. (CWT seems not to be widely used yet so it has less than 10 claims, most of which overlap with EAT.)

You’re still going to have very specific things like the foobar-transaction that are not general purpose. A separate EAT registry doesn’t solve that.

Some sort of profile / context seems highly likely to be necessary to narrow EAT when applied to specific use cases. That seems to be the place to address these concerns. Here’s some profiles I can imagine.
   - FIDO Alliance defines how EAT is integrated into FIDO with a FIDO-specific document, probably published outside the IETF
   - Android keystore documentation says how EAT fields apply to Android attestation
   - ARM and Qualcomm have already published their PSA attestation as IETF drafts
   - I hear rumors that Global Platform might have their TEE-related set

LL

> On Nov 27, 2019, at 1:27 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi Mike,
>  
> From: Mike Jones <[email-masked] <mailto:[email-masked]>>
> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Laurence Lundblade <[email-masked] <mailto:[email-masked]>>, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
> The point of having a common JWT Claims registry is to enable future specifications to benefit from reusing applicable claims registered by past specifications.  For instance, the Security Event Token [RFC 8417 <https://tools.ietf.org/html/rfc8417>] specification recently registered this general-purpose claim:
>    o  Claim Name: "txn"
>    o  Specification Document(s): Section 2.2 of [RFC8417] <https://tools.ietf.org/html/rfc8417#section-2.2>
>  
> From: Yaron Sheffer <[email-masked] <mailto:[email-masked]>> 
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>; Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
> [1] https://www.iana.org/assignments/jwt/jwt.xhtml <https://www.iana.org/assignments/jwt/jwt.xhtml>
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
> Cc: Mike Jones <Michael.Jones=[email-masked] <mailto:Michael.Jones=[email-masked]>>, Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
>> On Nov 26, 2019, at 7:19 PM, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 28 Nov 2019 09:05:15 +0000

I can confirm that GlobalPlatform is working on EAT claims related to the technologies it standardises: TEE and Secure Element in particular. As with FIDO, there will be GlobalPlatform-specific documents published outside the IETF specifying how these are used.

From the perspective of other bodies wishing to adopt EAT in their specific use-cases in an interoperable way, a single IANA registry would be easier to manage than registering what are essentially the same claims in JWT and CWT registries separately.

I am probably asking a stupid question, but is there no mechanism by which CWT and JWT claims can be merged in a single registry? It seems to me that CWT and JWT support the same use-cases, and everyone would benefit by having properly interoperable standardized claims for both (would make e.g. conversion between JSON and CBOR representations of the same claim trivial). Such approach would address virtually all arguments for having separate registries for any use-case. I accept that this would be contentious and take time, but it seems a very worthy goal.

Jeremy

On 28/11/2019, 06:13, "RATS on behalf of Laurence Lundblade" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

CAUTION: This email originated from outside of the organization.
A separate EAT registry doesn’t seem like it will solve the issues being brought up.

LL

On Nov 27, 2019, at 1:27 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mike,

Thanks,
                Yaron

                                                       -- Mike

Thanks,
                Yaron

LL