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 protected] [mailto:[email protected]] 
Sent: Friday, June 07, 2013 5:53 AM
To: [email protected]; [email protected]; [email protected]
Subject: Re: [jose] What are we doing here?

 

+1 to Mike's comments.

 

Usefulness of the standard is the important thing.

 

 

 

From: [email protected] [mailto:[email protected]] On Behalf Of Mike
Jones
Sent: Friday, June 07, 2013 7:19 AM
To: Richard Barnes; [email protected]
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 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose

Reply via email to