Subject: [jose] Use case for "typ" (Re: What are we doing here?)

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

[Popping out to a separate thread, since we're into specifics here]

Mike:

I asked earlier for an example of an application that that needs "typ",
noting that JWT doesn't count because it can provide that via two other
channels ("cty" and OAuth).  Could you provide one?

Thanks,
--Richard

On Fri, Jun 7, 2013 at 10: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****
>
> ** **
>
> *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]> 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]>
> 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.*
> ***
>
>   - 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****
>
> ** **
>
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose****
>
>
>
> ****
>
> ** **
>
> --
> -- Dick ****
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 7 Jun 2013 15:08:37 +0000

"typ" is there to dynamically answer the question "What is this data structure?" for applications.  It's needed in cases that that's potentially ambiguous.  If for instance, a token might be either a Facebook signed request or a JWT, the "typ" value could be used to distinguish between them.

You're wrong that "cty" could be used for that, because "cty" answers the question "What is the data structure that is the payload of this JOSE message?" - not "What is this data structure?".  The distinction is particularly important because as of -09 we decided to allow additional header parameters to be added by applications that must be ignored if not understood.  So "cty" doesn't provide a comprehensive answer to the question "What is this data structure?".

I know of no OAuth Mechanism for providing a general-case answer to the question "What is this data structure?" (other than the use of "typ" :)).  What specifically were you thinking of there?

So JWT needs it, and is a valid application.  John Bradley has also described a number of other potential uses.  Again, I haven't heard anyone say that Jim's original logic for why "typ" is the way it is today was wrong - only that more clarification is needed, which we'll do.

                                                            -- Mike

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

Mike:

I asked earlier for an example of an application that that needs "typ", noting that JWT doesn't count because it can provide that via two other channels ("cty" and OAuth).  Could you provide one?

Thanks,
--Richard

On Fri, Jun 7, 2013 at 10:48 AM, Mike Jones <[email-masked]<mailto:[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

From: [email-masked]<mailto:[email-masked]> [mailto:[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]<mailto:[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.

  - 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]> [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?

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

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

--
-- Dick

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jun 2013 11:41:07 -0400

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

>  “typ” is there to dynamically answer the question “What is this data
> structure?” for applications.  It’s needed in cases that that’s potentially
> ambiguous.  If for instance, a token might be either a Facebook signed
> request or a JWT, the “typ” value could be used to distinguish between them.
>

A more specific use case would be helpful.  See also the below notes on
"cty" distinction.

> You’re wrong that “cty” could be used for that, because “cty” answers the
> question “What is the data structure that is the payload of this JOSE
> message?” – not “What is this data structure?”.  The distinction is
> particularly important because as of -09 we decided to allow additional
> header parameters to be added by applications that must be ignored if not
> understood.  So “cty” doesn’t provide a comprehensive answer to the
> question “What is this data structure?”.
>

"cty" tells you what the object is at the level of "It's this thing,
wrapped in a JWE/JWS".  In your Facebook vs. JWT example, in the one case,
the content would be "application/facebook-request", in the other
"application/jwt-claims" (using fictive MIME types).  So "cty" is
sufficient to distinguish between the two.

The only way this is unclear is if two applications use the same "cty" and
put different things in the header.  But they shouldn't do that, because
it's bad layering -- JOSE Is Just Crypto.

I know of no OAuth Mechanism for providing a general-case answer to the
> question “What is this data structure?” (other than the use of “typ” J).
> What specifically were you thinking of there?
>

Maybe I'm confused, but I was envisioning something like what's in RFC 6749:
     Authorization: JWT <jwt-object>
<http://tools.ietf.org/html/rfc6749#section-7.1>

Or this in draft-ietf-oauth-jwt-bearer:
     POST /token.oauth2 HTTP/1.1
     Host: authz.example.net
     Content-Type: application/x-www-form-urlencoded

     grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
     &assertion=eyJhbGciOiJFUzI1NiJ9.
     eyJpc3Mi[...omitted for brevity...].
     J9l-ZhwP[...omitted for brevity...]
<http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-05#section-4>

Those are in addition to the "cty" disambiguation above.  I'm not seeing a
use case here.

--Richard

So JWT needs it, and is a valid application.  John Bradley has also
> described a number of other potential uses.  Again, I haven’t heard anyone
> say that Jim’s original logic for why “typ” is the way it is today was
> wrong – only that more clarification is needed, which we’ll do.
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *Sent:* Friday, June 07, 2013 7:54 AM
> *To:* Mike Jones
> *Cc:* [email-masked]; Dick Hardt
> *Subject:* [jose] Use case for "typ" (Re: What are we doing here?)****
>
> ** **
>
> [Popping out to a separate thread, since we're into specifics here]****
>
> ** **
>
> Mike:
>
> channels ("cty" and OAuth).  Could you provide one?  ****
>
> ** **
>
> Thanks,****
>
> --Richard****
>
> ** **
>
> On Fri, Jun 7, 2013 at 10:48 AM, Mike Jones <[email-masked]>
> wrote:****
>

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 8 Jun 2013 23:59:14 +1000

Mike said:
> So JWT needs it ["typ"]

It is hard to understand how JWT needs "typ" when the JWT spec says "use of this header parameter is OPTIONAL"?
[http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08#section-5.1]

Even if a JWT creator decides to include the "typ" header parameter, the spec merely RECOMMENDS using one of two values: "JWT" or "urn:ietf:params:oauth:token-type:jwt". So those or any other value can be included.

I can't see any hint about how a JWT receiver is supposed to react differently based on: the absence of the "typ" header; the presence of either of the two recommended values; or the presence of any other (unrecognized?) value.

--
James Manger