On Tue, Mar 19, 2013 at 1:59 PM, Matt Miller (mamille2) <[email protected]> wrote: > > On Mar 19, 2013, at 11:30 AM, Richard Barnes <[email protected]> > wrote: > >>> 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. >> > > I do think there are attributes that have identical semantics regardless of > key type ("kid", "x5c"? (-: ). Requiring "kty" is probably necessary, but I > don't have a firm opinion yet. > >> >> >>> 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). >> > > Completely agree; it's an indicator to applications and implementations that > this parameter might warrant additional considerations when present. > >> 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. > > > I wouldn't consider "kid" a policy attribute anyway; it's pretty clear to me > this is critical in properly referencing. Otherwise, I don't have an opinion > on the others.
FWIW I think it is a little awkward having kid in the key itself, especially thinking about using a hash or fingerprint of the key as the kid. Depends on whether you think of a jwk should be more of a table-like structure or a kid : value mapping. Totally fine with leaving it in though. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
