Subject: [jose] #103: Rename "alg" to avoid future collision problems

From: "jose issue tracker" <[email-masked]>
Date: Sun, 18 Aug 2013 20:32:57 -0000

#103: Rename "alg" to avoid future collision problems

 In order to support the use case of using key management and MAC
 computation, I would like to re-name alg to be "int" (integrity) or
 something similar (I would equally be happy to re-name "alg" in the
 encryption document to "kmgt" (key management))

 In the future there will be a need to do MAC computations on object with
 key management, the group has decided that this is not an immediate
 priority and this not to revisit that issue.

 However, in the future when this is added, all of the key management
 algorithms from both the JWS and JWE drafts should be placed in the same
 header parameter member according to the rules of header parameter (if
 they have the same name then they should have the same usage).

 This will also facility a reasonable restriction that an algorithm can
 occur only for a single member and not in multiple members.  If it can
 occur in both alg (for JWE) and kmgt (for JWS) then the rules for using
 alg as a determination get broken.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-jose-json-web-
  [email-masked] |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  json-web-    |    Version:
  signature              |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/103>
jose <http://tools.ietf.org/jose/>

---

From: "jose issue tracker" <[email-masked]>
Date: Fri, 23 Aug 2013 16:22:23 -0000

Comment (by [email-masked]):

 Renaming "alg" to "int" would be a breaking change for every JWS and every
 JWT, with no commensurate benefit.

 The premise of this pre-supposes reopening the already (twice!) decided
 issue #2 (No key management for MAC).  Given that the working group has
 already decided not to do this, it should be up to those proposing this as
 future work to propose syntax for this new feature at that time in a way
 that doesn't break what already exists.  We certainly shouldn't make
 breaking changes now for an eventuality that may never occur.

  signature              |  Resolution:
 Keywords:               |

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