Subject: Re: [jose] Discussion of open issues in JOSE drafts

From: Mike Jones <[email-masked]>
Date: Sun, 13 May 2012 00:23:03 +0000

Hi Matt,

Many of your recommendations below were incorporated in the just-published -02 versions of the JOSE specs.  I'd appreciate it if you could have a look at the new text covering these.  Thanks again for the review.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Miller
Sent: Monday, February 13, 2012 10:34 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [jose] Discussion of open issues in JOSE drafts

Trimming non-considered concerns...

Also, another JWE concern that was stated in Taipei and on list:

* Accommodating multiple recipients

On Feb 10, 2012, at 14:31, Mike Jones wrote:

> 
> From http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-00#section-12:
> 
> *         Consider whether to add parameters for directly including keys in the header, either as JWK Key Objects, or X.509 cert values, or both.
> As for JWS, I suspect this will be required by some use cases.  Any disagreement or discussion?
> 

I need this for my use-cases.

> *         Consider which of the open issues from the JWS and JWT specs also apply here.
> Having just reviewed them, the only one that seems that it may apply is a decision on whether to create a JSON serialization whose final representation is JSON (probably in separate specifications) in addition to the current compact serializations, whose representation is base64url encoded data structures.  One problem with the JSON serialization is the possible need for canonicalization algorithms.  (Bear in mind that not needing canonicalization is one of the major advantages of the present specs over the corresponding XML ones.)  I don't think, however that the outcome of this decision will affect the current specs either way.
> 

I would concur on efforts to avoid canonicalization.  I can see the appeal to having a "JSON-Stringified" representation (e.g. value = JSON.parse(JSON.parse(input).field) ), but I personally have no problem sticking with base64 or base64url.

> *         Should StringOrURI use IRIs rather than RFC 3986 URIs?
> Opinions?  Is this a standing IETF requirement now, or is this being handled on case-by-case basis as makes sense in context?
> 

If humans are involved, then i18n is a concern.  I suspect, at the least, "jku" and "x5u" will require support for internationalized values.

> From http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-00#section-7:
> 
> 
>  *   Consider whether to define "alg":"none" here, rather than in the JWT spec.

> This would seem to make sense, as other application contexts may also want this capability.  Any disagreement?
> 

I would find this very useful for some of my use-cases.

> 
>  *   Decide whether to move the JWK algorithm family definitions "EC" and "RSA" here. This would likely result in all the family-specific parameter definitions also moving here ("crv", "x", "y", "mod", "exp"), leaving very little normative text in the JWK spec itself. This seems like it would reduce spec readability and so was not done.
> After discussion, unless the WG disagrees, I propose to delete this open issue.
> 

I personally don't see a problem with moving them, as long as there's plenty of (expanded) examples in the affected specs.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.