Subject: [jose] What are we doing here?

From: Richard Barnes <[email-masked]>
Date: Thu, 6 Jun 2013 17:43:51 -0400

The conversation about "typ" has brought us back to a familiar question for
this working group -- what are we trying to do here?

The current document is ambiguous on this topic.  On the one hand, it
mostly covers the crypto bases, with things like "alg" and "enc".  On the
other hand, it mixes in application design concepts like "typ" and "crit".
 The result is a spec that's ambiguous in purpose and complex.  If I'm
building an application with this, how do I decide what goes in the "crit"
field, or what values to use for "typ"?
The charter for this working group is not ambiguous on this topic.  This
group is chartered to do signing and encryption.  The JOSE formats should
carry the parameters needed to perform those operations.  Anything else is
extraneous, and in the spirit of "The perfect protocol is one from which
nothing can be removed", should be removed.

Now, I'm not going to be a hard-liner on this.  I won't complain about
"zip" and "cty", since they are clearly defined and have clear use cases.
 But "crit" and "typ" are so ambiguous and so little supported by use
cases*, that they really should go.

</rant>

--Richard

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Jun 2013 05:18:57 +0000

Excellent question, Richard, because it gets to the heart of why the JOSE specs are already highly successful and widely adopted.

  - We are building useful tools that solve real problems for developers.
  - We are practically demonstrating the value of rough consensus and running code.
  - We are making simple things simple.
  - We are making complex things possible, when necessary (but not at the expense of keeping simple things simple).
  - We are developing specs with an explicit goal of enabling ubiquitous adoption.
  - We are developing specs guided by practical engineering tradeoffs to enable commonly useful functionality in a straightforward manner.

The level of adoption, with dozens of deployed implementations, is compelling evidence that we've already achieved the goals above.  It's time to "ship it", as making the JOSE specs actual standards will only increase their adoption and value to the industry.

That's what we're doing here.

                                                            -- Mike

P.S.  I would be careful reasoning from the premise of "The perfect protocol is one from which nothing can be removed".  By that logic, the perfect specification is the null specification, which leaves all possibilities open, and solves no actual problems. ;-)

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: [email-masked]
Subject: [jose] What are we doing here?

The conversation about "typ" has brought us back to a familiar question for this working group -- what are we trying to do here?

The current document is ambiguous on this topic.  On the one hand, it mostly covers the crypto bases, with things like "alg" and "enc".  On the other hand, it mixes in application design concepts like "typ" and "crit".  The result is a spec that's ambiguous in purpose and complex.  If I'm building an application with this, how do I decide what goes in the "crit" field, or what values to use for "typ"?
The charter for this working group is not ambiguous on this topic.  This group is chartered to do signing and encryption.  The JOSE formats should carry the parameters needed to perform those operations.  Anything else is extraneous, and in the spirit of "The perfect protocol is one from which nothing can be removed", should be removed.

Now, I'm not going to be a hard-liner on this.  I won't complain about "zip" and "cty", since they are clearly defined and have clear use cases.  But "crit" and "typ" are so ambiguous and so little supported by use cases*, that they really should go.

</rant>

--Richard

---

From: <[email-masked]>
Date: Fri, 7 Jun 2013 11:53:22 +0200

+1 to Mike's comments.

Usefulness of the standard is the important thing.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Friday, June 07, 2013 7:19 AM
To: Richard Barnes; [email-masked]
Subject: Re: [jose] What are we doing here?

                                                            -- Mike

</rant>

--Richard

---

From: John Bradley <[email-masked]>
Date: Fri, 7 Jun 2013 13:23:40 +0200

crit was a relatively recent WG consensus that allowed for non critical header parameters by default.  

Richard holds the unrelenting position that headers should not have integrity protection, and all header parameters should be optional unless defined otherwise in the core spec.

I don't want to rehash the argument, but the compromise allowed for non critical to be the default and future extensions to use crit to mark parameters that need to be understood by the recipient to securely process the message.

I understand the incremental edging towards the outcome you want, but endlessly revisiting consensus decisions will never allow us to finish.

As to "typ" I agree that it's main use is by JWT where it is described. That is a result of splitting the specs into two workgroups.   
It is an optional field, we should clarify its definition so that JWT and other specs that need it have it available without potential namespace issues.

That is what I thought WG decided.

On the topic of changes the clock is running down for projects with dependencies on JOSE.   At some point they will settle for what ever draft is current and ship based on that.
That would be an interoperability tragedy.   I have no control over what Mozzila and others decide,  but at the moment we don't seem to be instilling the confidence in others that we are capable of moving the ball the last yard over the line (My attempt at a sports analogy).

I agree with Axel and Mike on finishing.

John B.
On 2013-06-07, at 11:53 AM, <[email-masked]> wrote:

> +1 to Mike’s comments.
> The level of adoption, with dozens of deployed implementations, is compelling evidence that we’ve already achieved the goals above.  It’s time to “ship it”, as making the JOSE specs actual standards will only increase their adoption and value to the industry.
>  
> That’s what we’re doing here.
>  
>                                                             -- Mike
>  
> P.S.  I would be careful reasoning from the premise of “The perfect protocol is one from which nothing can be removed”.  By that logic, the perfect specification is the null specification, which leaves all possibilities open, and solves no actual problems. ;-)
>  
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Salvatore D'Agostino" <[email-masked]>
Date: Fri, 7 Jun 2013 08:22:45 -0400

We don't have as strong opinion on typ and crit.

In general the effort has focused on flexibility  and encouraging code and
use meeting the needs for signing and encryption.  I believe these are the
spirit of Mike and Axel's comments an d  +1 to both of these.

Apologies if blocked, seems our domain got blacklisted (thanks Register..)

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, June 07, 2013 5:53 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [jose] What are we doing here?

+1 to Mike's comments.

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike
Jones
Sent: Friday, June 07, 2013 7:19 AM
To: Richard Barnes; [email-masked]
Subject: Re: [jose] What are we doing here?

Excellent question, Richard, because it gets to the heart of why the JOSE
specs are already highly successful and widely adopted.

  - We are practically demonstrating the value of rough consensus and
running code.

  - We are making complex things possible, when necessary (but not at the
expense of keeping simple things simple).

  - We are developing specs with an explicit goal of enabling ubiquitous
adoption.

  - We are developing specs guided by practical engineering tradeoffs to
enable commonly useful functionality in a straightforward manner.

The level of adoption, with dozens of deployed implementations, is
compelling evidence that we've already achieved the goals above.  It's time
to "ship it", as making the JOSE specs actual standards will only increase
their adoption and value to the industry.

                                                            -- Mike

P.S.  I would be careful reasoning from the premise of "The perfect protocol
is one from which nothing can be removed".  By that logic, the perfect
specification is the null specification, which leaves all possibilities
open, and solves no actual problems. ;-)

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: [email-masked]
Subject: [jose] What are we doing here?

The current document is ambiguous on this topic.  On the one hand, it mostly
covers the crypto bases, with things like "alg" and "enc".  On the other
hand, it mixes in application design concepts like "typ" and "crit".  The
result is a spec that's ambiguous in purpose and complex.  If I'm building
an application with this, how do I decide what goes in the "crit" field, or
what values to use for "typ"?    

Now, I'm not going to be a hard-liner on this.  I won't complain about "zip"
and "cty", since they are clearly defined and have clear use cases.  But
"crit" and "typ" are so ambiguous and so little supported by use cases*,
that they really should go.

</rant>

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jun 2013 10:23:03 -0400

Of course, motherhood, apple pie, etc. :)

The question is what we're trying to help developers do.  The developers I
talk to want a simple tool to do crypto stuff, full stop.  They don't want
semantic validation, critical fields, etc.

The adoption you're pointing to is not really relevant to the process here.
 The deployed implementations you're talking about are all in a limited
space, covering one use case.  And the current solution comes with baggage
for that use case that adds complexity for everyone else.  If you wanted to
address that one use case, you should have chartered for that, not general
signing and encryption.

Nonetheless, on timing, I agree that I'm getting a little bored with
fighting over this :)  I'm working on a review of -11 that tries to package
up all the remaining comments such that they can get resolved and we can
move on with life.

--Richard

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <[email-masked]>wrote:

>  Excellent question, Richard, because it gets to the heart of why the
> JOSE specs are already highly successful and widely adopted.****
>
> ** **
>
>   - We are building useful tools that solve real problems for developers.*
> ***
>
> running code.****
>   - We are making simple things simple.****
>
> expense of keeping simple things simple).****
>
> adoption.****
> enable commonly useful functionality in a straightforward manner.****
>
> ** **
>
> compelling evidence that we’ve already achieved the goals above.  It’s time
> to “ship it”, as making the JOSE specs actual standards will only increase
> their adoption and value to the industry.****
>
> ** **
>
> That’s what we’re doing here.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> P.S.  I would be careful reasoning from the premise of “The perfect
> protocol is one from which nothing can be removed”.  By that logic, the
> perfect specification is the null specification, which leaves all
> possibilities open, and solves no actual problems. ;-)****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Thursday, June 06, 2013 2:44 PM
> *To:* [email-masked]
> *Subject:* [jose] What are we doing here?****
>
> ** **
>
> The conversation about "typ" has brought us back to a familiar question
> for this working group -- what are we trying to do here?****
>
> ** **
>
> field, or what values to use for "typ"?    ****
>
> nothing can be removed", should be removed.****
>
> ** **
>
> cases*, that they really should go.****
>
> ** **
>
> </rant>****
>
> ** **
>
> --Richard****
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 7 Jun 2013 07:33:10 -0700

MIke: I don't find your response very useful for understanding the question
Richard proposed. I find the spec confusing as to what I am supposed to do
when as an implementer. It seems that it is clear to all the people
associated with OpenID Connect, but without that context, it is confusing,
and frankly, some of the parameters seem like hacks to me. Perhaps some
additional clarification on what the parameters are intended for would
assist?

-- Dick

On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <[email-masked]> wrote:

> The adoption you're pointing to is not really relevant to the process
> here.  The deployed implementations you're talking about are all in a
> limited space, covering one use case.  And the current solution comes with
> baggage for that use case that adds complexity for everyone else.  If you
> wanted to address that one use case, you should have chartered for that,
> not general signing and encryption.
>
>> ****

-- 
-- Dick

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Jun 2013 14:48:10 +0000

I agree that we should provide some additional clarification on the intended purpose for the "typ" and "cty" parameters.  We just did provide substantial additional clarification for "crit" in -11, based on the working group decisions at the interim meeting.  Are there other specific things that you'd suggest that we clarify, Dick?

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Friday, June 07, 2013 7:33 AM
To: Richard Barnes
Cc: Mike Jones; [email-masked]
Subject: Re: [jose] What are we doing here?

MIke: I don't find your response very useful for understanding the question Richard proposed. I find the spec confusing as to what I am supposed to do when as an implementer. It seems that it is clear to all the people associated with OpenID Connect, but without that context, it is confusing, and frankly, some of the parameters seem like hacks to me. Perhaps some additional clarification on what the parameters are intended for would assist?

-- Dick

On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
Of course, motherhood, apple pie, etc. :)

The question is what we're trying to help developers do.  The developers I talk to want a simple tool to do crypto stuff, full stop.  They don't want semantic validation, critical fields, etc.

The adoption you're pointing to is not really relevant to the process here.  The deployed implementations you're talking about are all in a limited space, covering one use case.  And the current solution comes with baggage for that use case that adds complexity for everyone else.  If you wanted to address that one use case, you should have chartered for that, not general signing and encryption.

Nonetheless, on timing, I agree that I'm getting a little bored with fighting over this :)  I'm working on a review of -11 that tries to package up all the remaining comments such that they can get resolved and we can move on with life.

--Richard

On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Excellent question, Richard, because it gets to the heart of why the JOSE specs are already highly successful and widely adopted.

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Thursday, June 06, 2013 2:44 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] What are we doing here?

</rant>

--Richard

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

--
-- Dick

---

From: prateek mishra <[email-masked]>
Date: Fri, 07 Jun 2013 11:23:59 -0400

+1 to Richard's comments.

I havent been able to review the latest drafts (we will provide comments 
from an internal review soon)
but I am very concerned about the embedding of complex application 
semantics into headers defined by a signature/enryption specification.

- prateek
> The question is what we're trying to help developers do.  The 
> developers I talk to want a simple tool to do crypto stuff, full stop. 
>  They don't want semantic validation, critical fields, etc.
>
> limited space, covering one use case.  And the current solution comes 
> with baggage for that use case that adds complexity for everyone else. 
>  If you wanted to address that one use case, you should have chartered 
> for that, not general signing and encryption.
>
> fighting over this :)  I'm working on a review of -11 that tries to 
> package up all the remaining comments such that they can get resolved 
> and we can move on with life.
>
> --Richard
>
>
> On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Excellent question, Richard, because it gets to the heart of why
>     the JOSE specs are already highly successful and widely adopted.
>
>     - We are making complex things possible, when necessary (but not
>     at the expense of keeping simple things simple).
>
>     - We are developing specs guided by practical engineering
>     tradeoffs to enable commonly useful functionality in a
>     straightforward manner.
>
>     compelling evidence that we've already achieved the goals above. 
>     It's time to "ship it", as making the JOSE specs actual standards
>     will only increase their adoption and value to the industry.
>
>     P.S. I would be careful reasoning from the premise of "The perfect
>     protocol is one from which nothing can be removed". By that logic,
>     the perfect specification is the null specification, which leaves
>     all possibilities open, and solves no actual problems. ;-)
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *Richard Barnes
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [jose] What are we doing here?
>
>     The conversation about "typ" has brought us back to a familiar
>     question for this working group -- what are we trying to do here?
>
>     The current document is ambiguous on this topic.  On the one hand,
>     it mostly covers the crypto bases, with things like "alg" and
>     "enc".  On the other hand, it mixes in application design concepts
>     like "typ" and "crit".  The result is a spec that's ambiguous in
>     purpose and complex.  If I'm building an application with this,
>     how do I decide what goes in the "crit" field, or what values to
>     use for "typ"?
>
>     The charter for this working group is not ambiguous on this topic.
>      This group is chartered to do signing and encryption.  The JOSE
>     formats should carry the parameters needed to perform those
>     operations.  Anything else is extraneous, and in the spirit of
>     "The perfect protocol is one from which nothing can be removed",
>     should be removed.
>
>     Now, I'm not going to be a hard-liner on this.  I won't complain
>     about "zip" and "cty", since they are clearly defined and have
>     clear use cases.  But "crit" and "typ" are so ambiguous and so
>     little supported by use cases*, that they really should go.
>
>     </rant>
>
>     --Richard
>
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 7 Jun 2013 10:06:41 -0700

Hi Mike,

Currently I find "typ" and "cty" confusing. Once I understand them, I may
be confused with other aspects. :)

For example, in:

https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11

What "typ" is supposed to be is confusing.

In 3.1, it is defined as "typ":"JWT"

In 4.1.8, it is "typ":"JWS" or "typ":"JWS+JSON"

Which one is it?
When would  you use "cty"?

-- Dick

On Fri, Jun 7, 2013 at 7:48 AM, Mike Jones <[email-masked]>wrote:

>  I agree that we should provide some additional clarification on the
> intended purpose for the “typ” and “cty” parameters.  We just did provide
> substantial additional clarification for “crit” in -11, based on the
> working group decisions at the interim meeting.  Are there other specific
> things that you’d suggest that we clarify, Dick?****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> Of *Dick Hardt
> *Sent:* Friday, June 07, 2013 7:33 AM
> *To:* Richard Barnes
> *Cc:* Mike Jones; [email-masked]
> *Subject:* Re: [jose] What are we doing here?****
>
> ** **
>
> MIke: I don't find your response very useful for understanding the
> question Richard proposed. I find the spec confusing as to what I am
> supposed to do when as an implementer. It seems that it is clear to all the
> people associated with OpenID Connect, but without that context, it is
> confusing, and frankly, some of the parameters seem like hacks to me.
> Perhaps some additional clarification on what the parameters are intended
> for would assist?****
>
> ** **
>
> -- Dick****
>
> ** **
>
> On Fri, Jun 7, 2013 at 7:23 AM, Richard Barnes <[email-masked]> wrote:****
>
> Of course, motherhood, apple pie, etc. :)****
>
> ** **
>
> semantic validation, critical fields, etc.  ****
>
> ** **
>
> not general signing and encryption.****
>
> ** **
>
> move on with life.****
> On Fri, Jun 7, 2013 at 1:18 AM, Mike Jones <[email-masked]>
> wrote:****
>
> specs are already highly successful and widely adopted.****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
>
>
> ****
>
> ** **
>
> --
> -- Dick ****
>

-- 
-- Dick

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 17 Jun 2013 22:59:08 +0200

Maybe a bit late but anyway.

+1 to Dick,

When I read the specs in May I had the same problem with these fields and
did similar assumptions as Dick and Richard.

Assumptions:
typ would  be used for saying JWE or JWS and
cty would be used to tell what's in the JWE or JWS.

I could not see the need to have a type value for JWT. As it looks today I
do not even see the need for a JWT header at al since as I see the JWT as
content and hence described by cty.

However by reading the conversation hear I can see how the reasoning to get
here has been done. I would prefer to change the meaning of cty and typ in
the way Richard proposes but it might be to much at this stage, in that
case a clarification would be great.

Best Regards
Samuel

Sent from my iPhone

On 7 jun 2013, at 19:06, Dick Hardt <[email-masked]> wrote:

Hi Mike,

For example, in:

Which one is it?

-- Dick

-- 
-- Dick