Re: [jose] JWK Parameter Registry Considerations

[Richard Barnes <[e-mail]>]

> 1) Should JWK parameter names be absolutely unique, or are they
> potentially tied to a specific JWK type?  In looking at the specs to date,
> I think there's only one case where a parameter name is re-used ("d" for
> both private RSA and ECC keys); currently syntactically and semantically
> identical, but I'm not sure that's adequate.
>

I think it makes sense for parameter names to be potentially contingent on
key type.  Emphasis on "potentially" -- there could be attributes that are
the same for all key types.  I would also propose that we make "kty" a
mandatory attribute.



> 2) Should JWK parameters be marked as private (confidential, secret,
> privileged, etc etc)?  The current documentation set loosely defines this
> only because they are current split between multiple documents.  However, I
> wonder if there is value in being much more explicit about it, including in
> a parameter's registration.
>

If we fold JPSK in to JWA (which we should do), then ISTM that we should
also note which parameters are private, in the sense of "have a column in
the registry that marks this as a "private" parameter".  Note that
designation as private would not necessarily imply that you MUST do any
particular thing.  One can envision, for example, cases where it might be
safe to pass private keys in plaintext (e.g., over TLS).

One other question:

3) Should we remove "policy" attributes from JWK?  The current JWK spec
includes a variety of attributes that are not directly specifying parts of
the key, namely "use" and "alg".  These are application-related fields, and
run the risk of conflicting with existing applications' attributes.  For
example, the WebCrypto API has a notion of key usages and algorithm
restriction, but the values they use do not map to the "use" and "alg"
values.  Should we align with WebCrypto (and risk conflicting with other
apps), or remove the policy bits altogether (and require apps to align
themselves)?  FWIW, I am fine with "kid" staying there, because (1) it's
opaque, and (2) it's actually used in JOSE processing.