Re: [jose] #72: Section 3.3 - "alg" (Algorithm) Parameter

["jose issue tracker" <[e-mail]>]

#72: Section 3.3 - "alg" (Algorithm) Parameter

Description changed by [e-mail]:

Old description:

> A. This should not be tied to specific fields in the JWS and JWE
> structures.  If I define a new item then I want it to apply to that item
> as well.
>
> * FIXXED
>
> B. Registry is not in JWA - it is on iana.org
>
> C. Use of member is OPTIONAL does not convey sufficient information. For
> whom is it optional?
>
> * FIXED
>
> D. What happens if use is absent is not covered in the document.
>
> * WON'T FIX - probably implicit as any can be used.
>
> E. John Bradley made a big deal at the Berlin meeting about the fact that
> this needs to be a single value rather than a multi-value field.  The
> reasoning behind this was that allowing for multiple values was an evil
> thing.  This would imply that this is not an optional field but is, at a
> minimum a SHOULD field with heavy language about when one would not
> specify a value.  all uses (absent) is worse than some usages (multi) is
> worse than one usage (single).
>
> F. Need a statement if the alg is not a known algorithm by the consumer
> of the JWK
>
> G. Need a statement if there are other members that must be included if
> an alg is specfied
>
> H. Need a statement if there are members missing that must be included
> about what to do with this JWK.

New description:

 A. This should not be tied to specific fields in the JWS and JWE
 structures.  If I define a new item then I want it to apply to that item
 as well.

 * FIXXED

 B. Registry is not in JWA - it is on iana.org

 * WON'T FIX - Pet peeve

 C. Use of member is OPTIONAL does not convey sufficient information. For
 whom is it optional?

 * FIXED

 D. What happens if use is absent is not covered in the document.

 * WON'T FIX - probably implicit as any can be used.

 E. John Bradley made a big deal at the Berlin meeting about the fact that
 this needs to be a single value rather than a multi-value field.  The
 reasoning behind this was that allowing for multiple values was an evil
 thing.  This would imply that this is not an optional field but is, at a
 minimum a SHOULD field with heavy language about when one would not
 specify a value.  all uses (absent) is worse than some usages (multi) is
 worse than one usage (single).

 F. Need a statement if the alg is not a known algorithm by the consumer of
 the JWK

 * DUP #79

 G. Need a statement if there are other members that must be included if an
 alg is specified

 * DUP #79

 H. Need a statement if there are members missing that must be included
 about what to do with this JWK.

 * DUP #79

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-ietf-jose-json-web-
  [e-mail] |  [e-mail]
     Type:  defect       |      Status:  new
 Priority:  major        |   Milestone:
Component:  json-web-    |     Version:
  key                    |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/72#comment:2>
jose <http://tools.ietf.org/jose/>