Not denying it's useful (or "alg"). Just saying that the JWK core spec might not be the place to define them. Or, alternatively, that if we do define them, we should align syntax/semantics with WebCrypto to avoid conflicts.
On Tue, Mar 19, 2013 at 2:45 PM, Brian Campbell <[email protected]>wrote: > "use" is useful in the context of some entity providing its public keys in > a JWK Set somewhere for some other party to consume those keys and know > what to do with them. > > > > > On Tue, 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. >> >> >> >>> 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. >> >> >> >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose >> >> >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
