Re: [Rats] [EXTERNAL] Re: EAT IANA registry

[Jeremy O'Donoghue <[e-mail]>]

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" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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.

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 <[e-mail]<mailto:[e-mail]>> wrote:

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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 27, 2019 at 23:04
To: Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, Laurence Lundblade <[e-mail]<mailto:[e-mail]>>, Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
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://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 <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, November 27, 2019 7:54 AM
To: Laurence Lundblade <[e-mail]<mailto:[e-mail]>>; Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>
Cc: Mike Jones <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry

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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 27, 2019 at 06:39
To: Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>
Cc: Mike Jones <Michael.Jones=[e-mail]<mailto:Michael.Jones=[e-mail]>>, Yaron Sheffer <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Hannes Tschofenig <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rats] [EXTERNAL] Re: EAT IANA registry


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

...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?

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






_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats