Subject: [Rats] EAT as a JWT/CWT

From: Laurence Lundblade <[email-masked]>
Date: Sun, 26 May 2019 22:38:31 +0300

I’m pretty sure I’m OK with folding EAT/RATS tokens in with JWT/CWT just like birkholz-core-coid. We’d have a normative reference to JWT and CWT. It seems like things line up with JWT/CWT. For example, all claims are optional in JWT just like we want for EAT. The crypto algorithms are open-ended, just like we want in EAT.

Seems like we would  want an option claim that indicates the purpose of the token. To write my first CDDL:

tokenType = “EAT" / “OAuth" / “Cert” / “CoID"

I suspect it will be hard to tell which it is by the make up of the claims and it will matter for some use cases. I’m not sure “OAuth”, “Cert” and “CoID” are right.  The writing does seem to be on the wall that we will eventually replace X.509 cert hierarchies with CWT/JWT hierarchies and I’m not sure if that is a “CoID” or “Cert”. 

So the EAT document is just becomes the definition of a bunch of claims pertaining to device/entity attestation. An EAT token can use any JWT/CWT claim or any  birkholz-core-coid claims and vice versa. We only want to define a claim once in the "family of token” RFCs.

Most of the text in the EAT document wouldn’t change. We would say explicitly it is a CWT. We would harmonize the claims. 

To go on a little about jti/cti/nonce. The definition of jti isn’t very clear to me. It doesn’t say who assigns it which seems like a gap to me. I would like to fix this somehow by saying that it is generated by the end consumer of the token, transmitted to the generator of the token and included in the token.

As to protocol vs token vs message, the first sentence of the JWT RFC is:

JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters.

To me this makes it a token / message. Also, JWT / CWT (and X.509 / RFC 5280) don’t seem concerned about protocol vs message/token, so I don’t think we need to be concerned. Also, JWT says “jti” is for replay protection which strongly implies it came from the would-be consumer of the token, but doesn’t define a protocol, so it seems OK to not define a protocol even if you have a “nonce”. 

I reserve the right to change my mind if new info comes to light for me, but at this point I’m planning on a EAT draft update before Montreal that does this. Will also fix a lot of the editorial things Henk pointed out.

LL

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 27 May 2019 07:13:16 +0200

I would consider dropping JWT.  AFAIK the FIDO do not use JWT, neither does Android.
The actual consumers of EAT information anyway have to deal with non-JSON data like X.509 certificates.
Thanx,
Anders

On 2019-05-26 21:38, Laurence Lundblade wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 27 May 2019 12:50:29 +0300

Two reasons why I think JWT stays involved.

1) We really do want a JSON format defined for all the claims. Most back end systems are going to greatly prefer JSON to CBOR. We want to define a representation for each claim in both and a deterministic method for converting each claim between CBOR and JSON.

2) CWT RFC 8392 makes normative reference to JWT RFC 7519 so it can’t really be dropped.To some degree CWT is defined as a reformatting of JWT.

Agreed that consumers will have to deal with X.509 (until we create the alternative), but that is true for JWT and JWS too, so I don’t think it changes anything.

LL

> On May 27, 2019, at 8:13 AM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 27 May 2019 12:30:14 +0200

> Agreed that consumers will have to deal with X.509 (until we create the alternative), but that is true for JWT and JWS too, so I don’t think it changes anything.

Well, in theory options introduce a choice, in reality it means that all vendors must implement more an interoperability becomes more challenging.
JSON is as you say undoubtedly preferred over CBOR for traditional back end systems.  What I'm sort of wondering is, if this applies to rather specific security systems as well.

The conversion back and forth between JSON and CBOR is non-trivial.  Things like "BigNums" doesn't even have an *established* format in JSON due to its JavaScript heritage.

If somebody would ask "why don't you support JSON?", I would just point to: https://www.w3.org/TR/webauthn/#attestation-object which target Web developers.

Anyway, it was just a friendly advice.

Cheers,
Anders

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 27 May 2019 15:01:58 +0000

> AFAIK the FIDO do not use JWT, neither does Android.

FIDO 2 allows for the Android SafetyNet Attestation, which is generally considered to return its response as a JWT:  https://medium.com/@herrjemand/verifying-fido2-safetynet-attestation-bd261ce1978d.  The actual SafetyNet attestation documentation lists the returned object as a JWS:  https://developer.android.com/training/safetynet/attestation. 

-Giri Mandyam, Qualcomm

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Anders Rundgren
Sent: Sunday, May 26, 2019 10:13 PM
To: Laurence Lundblade <[email-masked]>; [email-masked]
Subject: Re: [Rats] EAT as a JWT/CWT

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 May 2019 17:28:45 +0200

> FIDO 2 allows for the Android SafetyNet Attestation, which is generally considered to return its response as a JWT:  https://medium.com/@herrjemand/verifying-fido2-safetynet-attestation-bd261ce1978…

Yes.  But why would you want to do this for new stuff?

Of course, you may need to ship around legacy data.  X.509 certificates, some JWS, etc.
But the new EAT tokens?  Why create diversity that virtually doubles specification, implementation, and validation effort?

Grüße, Carsten

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 27 May 2019 16:07:27 +0000

>Yes.  But why would you want to do this for new stuff?

That was not really what I was intending to address.  There was an inaccurate comment on the mailing list, and I was putting out a clarification.

But since you asked, in general with CBOR/COSE/CWT specifications, there is not (IMO) sufficient consideration with respect to interoperability with legacy systems.  What I personally would like to see is a general methodology for casting CWT's to JWT's and vice versa, and x.509's to CBOR certs.  Granted, contributions such as https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-01 seem to begin to address this topic, but such efforts are nascent and it is unclear whether they will achieve widespread adoption.

In the absence of a agreed-upon methodology for casting a CWT (EAT) to a JWT, then we cannot really guarantee that EAT -> JWT transcoding will achieve the intended result.  We could of course insist that all implementors just accept EAT as the future and not worry about legacy interop, but (based on my experience) this is a tough sell to service providers who have invested a lot in their existing authentication systems.  

Note that I have not performed an extensive survey on CBOR/JSON interoperability.  If there is some emerging methodology that will address these issues, then I would say that we wouldn't need to worry about how EAT is cast to a JWT.  We could just point to such a methodology and call it a day.

-Giri

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Monday, May 27, 2019 8:29 AM
To: Giridhar Mandyam <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] EAT as a JWT/CWT

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 27 May 2019 18:37:57 +0200

Hi Giri,

as the JCS effort (that still might have to prove itself)

> https://datatracker.ietf.org/doc/draft-rundgren-json-canonicalization-scheme/

shows, the question on how to serialize JSON in a manner that renders 
signing and validation a simple task is still an open one.

Jumping from that to an "agreed-upon methodology for casting a CWT (EAT) 
to a JWT" might be a quite big jump (maybe omitting some carefully 
considered steps in between). I am not trying to say that it is 
impossible or unfeasible, just that there are quite some factors to take 
into account here.

Viele Grüße,

Henk

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 27 May 2019 18:50:17 +0200

> signing and validation a simple task is still an open one.

JCS actually works great :)  Everything is though not completely transparent.

However, converting a 64-bit integer in CBOR to JSON doesn't have a clear definition.
The EAT authors are therefore essentially on their own if this is what is required.

I would personally abstain from such endeavors.

Anders
JSON serialization guru.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 May 2019 14:08:16 -0400

Laurence Lundblade <[email-masked]> wrote:
    > 1) We really do want a JSON format defined for all the claims. Most
    > back end systems are going to greatly prefer JSON to CBOR. We want to
    > define a representation for each claim in both and a deterministic
    > method for converting each claim between CBOR and JSON.

Signed CBOR (COSE) is not translatable to Signed JSON.
They can be semantically identically, sure.

    > 2) CWT RFC 8392 makes normative reference to JWT RFC 7519 so it can’t
    > really be dropped.To some degree CWT is defined as a reformatting of
    > JWT.

yeah, but it's not really a reformat due to the signatures.

    > Agreed that consumers will have to deal with X.509 (until we create the
    > alternative), but that is true for JWT and JWS too, so I don’t think it
    > changes anything.

A constrained device can sign JWT and CWT without having to process PKIX
stuff.  The device just needs access to it's private key in a format that
suits it.  It may be that only relying parties will need to do a lot of PKIX
things that involve DER encoded ASN1.

CWT is not hard to deal with in most every web framework language.
(Sure JWT is ridiculously trivial in Javascript)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 27 May 2019 23:47:03 +0300

Yes, agreed on all points. 

You still might translate the CBOR claims to JSON in the back end and only deal with JSON in the main logic so it is helpful that there is a deterministic means. (The back end is presumably safe and trustworthy so there’s no need to re sign the CWT as a JWT). 

I assume you are not objecting to support of both CBOR and JSON and claims and defining deterministic translation. You are just pointing out how some of this fits together.

LL

> On May 27, 2019, at 9:08 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 May 2019 18:29:14 -0400

Laurence Lundblade <[email-masked]> wrote:
    > You still might translate the CBOR claims to JSON in the back end and
    > only deal with JSON in the main logic so it is helpful that there is a
    > deterministic means. (The back end is presumably safe and trustworthy
    > so there’s no need to re sign the CWT as a JWT).

Yes, that makes total sense to me, do that after validating the signature.

    > I assume you are not objecting to support of both CBOR and JSON and
    > claims and defining deterministic translation. You are just pointing
    > out how some of this fits together.

Yes, I think that back-ends have to process CBOR(CWT) and JSON(JWT), and
we can't think that they are translateable, just semantically equivalent.