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 protected]>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 protected] [mailto:[email protected]] *On Behalf > Of *Dick Hardt > *Sent:* Friday, June 07, 2013 7:33 AM > *To:* Richard Barnes > *Cc:* Mike Jones; [email protected] > *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 protected]> 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 protected]> > 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 protected] [mailto:[email protected]] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, June 06, 2013 2:44 PM > *To:* [email protected] > *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 protected] > https://www.ietf.org/mailman/listinfo/jose**** > > > > **** > > ** ** > > -- > -- Dick **** > -- -- Dick
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
