- From: <bugzilla@jessica.w3.org>
- Date: Tue, 29 Apr 2014 21:00:37 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25388 --- Comment #4 from Ryan Sleevi <sleevi@google.com> --- (In reply to Anne from comment #3) > I would not suggest to nest objects, that does indeed seem bad. Can it be a > keyUsages parameter with values as per Mark's suggestion? > > The main problem is that if you look at a call such as > > window.crypto.subtle.deriveKey({ alg }, key, { derived alg }, false, [ > "encrypt" ]); > > it is not clear what is going on. The same with the last argument being a > length of sorts. A length? Not sure I follow. > > I would need a much better understanding of the problem space to give more > informed feedback as to what a better API would be. :-( I didn't take Mark's comment as suggesting it was a KeyUsage, but in fact a new enumeration. That is window.crypto.subtle.deriveKey({ alg }, key, {derived alg}, "extractable", [ "encrypt " ]); I took your reply as understanding it as window.crypto.subtle.deriveKey({alg}, key, {derived alg}, ["extractable", "encrypt"]); The issue here is that "extractable", as a key usage, doesn't have a 1:1 mapping to a given operation - that is "extractability" ties to both exportKey and wrapKey. Calling it "exportKey" doesn't conceptually fit, since you can extract a key via wrapping. Calling it "wrapKey" is off the table, since "wrapKey" is already a usage (indicating the given key can be used to wrap key, not that it is itself wrappable) As a style design, I can certainly understand why boolean positional arguments are bad when used in abundance - eg: foo(true, false, true); However, it seems a bit dogmatic to suggest that any boolean arguments are bad. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Tuesday, 29 April 2014 21:00:45 UTC