Subject: [Rats] CWT and JWT are good enough?

From: Laurence Lundblade <[email-masked]>
Date: Mon, 16 Sep 2019 08:30:35 -0700

I’ve been trying to take the position to avoid even minor divergences from CWT and JWT in EAT. I wish there wasn’t inconsistency between the two, particularly in how the claims registry is handled. That inconsistency has already consumed many hours, even days, of this WG. There’s been some really long email threads about it.

Fixing it only for EAT seems half-baked. Fixing it for all of CWT and JWT would have to go through those WGs. Seems like a lot of work. We have enough to do, so I’m inclined to live with it.

LL

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 16 Sep 2019 11:44:45 -0400

On Mon, Sep 16, 2019 at 11:30 AM Laurence Lundblade <[email-masked]>
wrote:

> I’ve been trying to take the position to avoid even minor divergences from
> CWT and JWT in EAT. I wish there wasn’t inconsistency between the two,
> particularly in how the claims registry is handled. That inconsistency has
> already consumed many hours, even days, of this WG. There’s been some
> really long email threads about it.
>
> Fixing it only for EAT seems half-baked. Fixing it for all of CWT and JWT
> would have to go through those WGs. Seems like a lot of work. We have
> enough to do, so I’m inclined to live with it.
>

The COSE WG is the one the decided to diverge from lessons learned.  That
WG is open again, so if you'd like to pose this problem somewhere, that
would be the place to do it.  I'm guessing people thought one or the other
would be used, but not both resulting in this issue of inconsistency we are
seeing.

Best regards,
Kathleen

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

-- 

Best regards,
Kathleen

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 16 Sep 2019 17:46:53 +0200

> Fixing it only for EAT seems half-baked. Fixing it for all of CWT and JWT would have to go through those WGs. Seems like a lot of work. We have enough to do, so I’m inclined to live with it.

Since everything crypto-wise in the JOSE stack anyway is covered in Base64Url, I don't see why one would bother with JWTs (or JSON at all for that matter) in EAT.

Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 16 Sep 2019 09:25:48 -0700

Hi Kathleen

> On Sep 16, 2019, at 8:44 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> 
> 
> On Mon, Sep 16, 2019 at 11:30 AM Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
> The COSE WG is the one the decided to diverge from lessons learned. 

The divergence I’m referring to is for the claims registry. That is definitely a CWT / JWT thing. COSE doesn’t have claims.

> That WG is open again, so if you'd like to pose this problem somewhere, that would be the place to do it.  I'm guessing people thought one or the other would be used, but not both resulting in this issue of inconsistency we are seeing.

My personal chosen path is NOT to raise the issue and live with the issue. Particularly:
 - The way to do vendor specific non-registered claims is different between CWT and JWT
 - All EAT claims are Specification Required. No EAT claims and be just Expert Review.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 16 Sep 2019 09:29:05 -0700

> On Sep 16, 2019, at 8:46 AM, Anders Rundgren <[email-masked]> wrote:
> 

Pretty sure lots of people want to be able to express claims in JSON. It is far more prevalent (so I understand) on the server side than CBOR. I think there is consensus in this WG that we will support JSON and CBOR (and thus COSE and JOSE) for claims.

LL

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 16 Sep 2019 18:35:26 +0200

On 2019-09-16 18:29, Laurence Lundblade wrote:
> Pretty sure lots of people want to be able to express claims in JSON. It is far more prevalent (so I understand) on the server side than CBOR.

Yes, but EAT is (IMO) not comparable to "normal" applications.

> I think there is consensus in this WG that we will support JSON and CBOR (and thus COSE and JOSE) for claims.

Right and it will effectively force server-side software vendors creating TWO versions of everything.
That's the hallmark of design by committee :-)

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 16 Sep 2019 19:32:47 +0200

The W3C apparently came to another conclusion although they target the most JSON-friendly place there is, the Web:
https://www.w3.org/TR/webauthn/#sctn-extension-request-parameters
That is, WebAuthn requires CBOR.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Sep 2019 13:41:24 -0400

> - The way to do vendor specific non-registered claims is different

I think that's okay.  Vendors that want to private things can cope with this,
or likely are just doing one or the other.

    > - All EAT claims are Specification Required. No EAT claims and be just

I can live with that.

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

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 16 Sep 2019 17:42:14 +0000

Yes, but that does not mean that JSON support is not required by Webauthn.

Webauthn allows for the Android SafetyNet attestation format - see https://www.w3.org/TR/webauthn/#android-safetynet-attestation.  And SafetyNet comes in the form of a JSON object:  https://developer.android.com/training/safetynet/attestation#compat-check-response.

In other words, a Webauthn RP cannot just support CBOR and hope to cover all of the deployed implementations.  

-Giri Mandyam

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Anders Rundgren
Sent: Monday, September 16, 2019 10:33 AM
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] CWT and JWT are good enough?

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

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 16 Sep 2019 20:14:10 +0200

> Webauthn allows for the Android SafetyNet attestation format - see https://www.w3.org/TR/webauthn/#android-safetynet-attestation.  And SafetyNet comes in the form of a JSON object:  https://develop…

I would not base a major design decision on a single and rather unusual solution which BTW already is defined.

Anders

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 16 Sep 2019 18:28:54 +0000

> I would not base a major design decision on a single and rather unusual solution which BTW already is defined.

I understand the sentiment, and we have had this discussion on the mailing list before (e.g. https://mailarchive.ietf.org/arch/msg/rats/T1OmyXyprQ5ItvBm_9PxZ7LRrmA).  But I don't agree that CBOR should be our sole focus.

I think if we have the opportunity to define interoperable attestation formats for CBOR and JSON, it would be a mistake not to take it.  If solutions such as the SafetyNet Attestation follow our lead and evolve to supporting EAT then I think that would be a positive.

-Giri

-----Original Message-----
From: Anders Rundgren <[email-masked]> 
Sent: Monday, September 16, 2019 11:14 AM
To: Giridhar Mandyam <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] CWT and JWT are good enough?

Anders

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Sep 2019 18:59:28 +0000

> I can live with that.

I am not OK with that. For JWTs we have been using an expert review approach and that served the committee well.
We would like to register vendor-specific claims for use within EAT tokens and I can hardly see why anyone should have problems with it.
Furthermore, attestation is such a special field that there is no reason to be worried about companies flooding IANA with requests.

Ciao
Hannes

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: Laurence Lundblade <[email-masked]>
Date: Mon, 16 Sep 2019 12:24:26 -0700

> On Sep 16, 2019, at 11:59 AM, Hannes Tschofenig <[email-masked]> wrote:
> 

JWT doesn’t allow Expert Review. It only allows Specification Required.

Even with that there’s plenty of stuff in the JWT registry. Some have even called it questionable.

Also, the reason I say all EAT claims must be Specification Required is to avoid the divergence between CWT and JWT. I want to avoid “well, if you were using CWT then you could use that claim, but since you are using JWT, you can’t because it is not defined” and vice versa.

Unless we go out of our way anyone can register a CWT claim under Expert Review only. They just can’t register it under JWT until publish a Specification so they can get to the Specification Required level.

LL

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 17 Sep 2019 06:25:00 +0200

> I understand the sentiment, and we have had this discussion on the mailing list before (e.g. https://mailarchive.ietf.org/arch/msg/rats/T1OmyXyprQ5ItvBm_9PxZ7LRrmA).  But I don't agree that CBOR sh…

I got that.

> I think if we have the opportunity to define interoperable attestation formats for CBOR and JSON,

To solve what problem?  Attestations are not comparable to word processors that typically need to read and write a plethora of document formats.

> it would be a mistake not to take it. 

It is IMO rather a mistake confusing future implementers with technically redundant choices.  Note: for protocols like TEEP it is no big deal using Base64Url encoded attestations either.

> If solutions such as the SafetyNet Attestation follow our lead and evolve to supporting EAT then I think that would be a positive.

Yes, but for application developers, attestations are presumably exposed as APIs and objects making the CBOR/JSON issue limited to implementors.

I leave this thread now and let you continue doing TWO things of everything :-)

Anders

---

From: Mike Jones <[email-masked]>
Date: Tue, 17 Sep 2019 05:12:32 +0000

+1 for EAT claims being Specification Required.

				-- Mike

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Monday, September 16, 2019 12:24 PM
To: Hannes Tschofenig <[email-masked]>
Cc: Michael Richardson <[email-masked]>; Kathleen Moriarty <[email-masked]>; [email-masked]
Subject: Re: [Rats] CWT and JWT are good enough?

LL

_______________________________________________
RATS mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C19c938fee6ba4c35b37908d73adb89b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637042586892636843&amp;sdata=uAXguU1iobLt%2B1QNsUjzQtgFvHHHfsVR%2FO6pZC9vtjA%3D&amp;reserved=0

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Sep 2019 08:03:52 +0000

Hey Laurence,

I misread. Sorry. Specification required is OK for me as well.

While there are entries in the JWT registry that don't make sense to you that does not mean it makes no sense to those who use that specification in a different context. For that reason I want to avoid having the IETF to become a gatekeeper and the DEs to make a judgment about what they consider useful or not.

Ciao
Hannes

-----Original Message-----
From: Laurence Lundblade <[email-masked]>
Sent: Montag, 16. September 2019 21:24
To: Hannes Tschofenig <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]; Kathleen Moriarty <[email-masked]>
Subject: Re: [Rats] CWT and JWT are good enough?

LL

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Sep 2019 12:13:18 +0000

>    +1 for EAT claims being Specification Required.
 
+2 :)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Sep 2019 08:25:18 -0400

> I am not OK with that. For JWTs we have been using an expert review
    > approach and that served the committee well.

I think we are not discussing the same things!
EAT claims that are standards need to be Specification Required, because
that's the "bigger" of the JWT (Specification Required) and CWT requirements.

    > We would like to register vendor-specific claims for use within EAT
    > tokens and I can hardly see why anyone should have problems with it.

Please distinguish between vendor-proprietary claims (private-use) ones from
standards!  You are not talking about the same thing now.

rfc7519 section 4.2 allows for claims based upon Public Names, which means
using a Collision-Resistant Name:

  Collision-Resistant Name
        A name in a namespace that enables names to be allocated in a
        manner such that they are highly unlikely to collide with other
        names.  Examples of collision-resistant namespaces include: Domain
        Names, Object Identifiers (OIDs) as defined in the ITU-T X.660
        and X.670 Recommendation series, and Universally Unique IDentifiers
        (UUIDs) [RFC4122].  When using an administratively
        delegated namespace, the definer of a name needs to take reasonable
        precautions to ensure they are in control of the portion of the
        namespace they use to define the name.

So any vendor-specific claim can be created by any vendor possessing a domain
name, a PEN, or who can run "uuidgen" (on a development system)

RFC8392 provides for: Integer values less than -65536 are marked as Private Use.
But,  Integer values greater than 65535 and strings of length
      greater than 2 are designated as Expert Review.

So it shouldn't be hard for a vendor-specific claim to get a number for CWT.
And within the space of "strings of length greater than 2" would be the
identical string used for JWT, if you like.  Yes, shorter is better.

The point of this thread was that for Standards Track *RATS* WG claims, that
we will have to go with Specification Required, because that's the minimum
common process for CWT and JWT.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Sep 2019 14:37:29 +0000

Hi Michael,

As mentioned in a follow-up email, I misread the mail from Laurence. Everything is cool.

Ciao
Hannes

-----Original Message-----
From: Michael Richardson <[email-masked]>
Sent: Dienstag, 17. September 2019 14:25
To: [email-masked]
Cc: Hannes Tschofenig <[email-masked]>
Subject: Re: [Rats] CWT and JWT are good enough?

I think we are not discussing the same things!
EAT claims that are standards need to be Specification Required, because that's the "bigger" of the JWT (Specification Required) and CWT requirements.

    > tokens and I can hardly see why anyone should have problems with it.

Please distinguish between vendor-proprietary claims (private-use) ones from standards!  You are not talking about the same thing now.

rfc7519 section 4.2 allows for claims based upon Public Names, which means using a Collision-Resistant Name:

  Collision-Resistant Name

So any vendor-specific claim can be created by any vendor possessing a domain name, a PEN, or who can run "uuidgen" (on a development system)

So it shouldn't be hard for a vendor-specific claim to get a number for CWT.
And within the space of "strings of length greater than 2" would be the identical string used for JWT, if you like.  Yes, shorter is better.

The point of this thread was that for Standards Track *RATS* WG claims, that we will have to go with Specification Required, because that's the minimum common process for CWT and JWT.

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 19 Sep 2019 19:32:45 +0000

And another +1