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 - <mamil...@cisco.com> Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
