This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, WebCrypto specifies that usages is an array of enum values. This means that when an unknown value is encountered, the implementation raises a typeError exception, per WebIDL. I think that this is problematic. There is no reason to prevent web applications from creating Key objects with allowed usages added by a future version of the spec. The Key object can be saved to permanent storage, and even if the current version of the browser doesn't understand a particular usage, a future version will. We should store the whole set, not a currently supported slice. Even for non-persistent keys, I don't see a reason to completely reject an importKey or generateKey operation simply because the allowed usages include something the browser doesn't know about. As a web site adopts future WebCrypto features, key creation will raise an exception in old browsers, breaking the site's existing features - as opposed to only having new features that use new WebCrypto functionality broken. It seems that WebCrypto should explicitly specify an appropriate behavior for unknown usage strings, and not rely on enum behavior specified by WebIDL. See also: <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22548>. Given the considerations above, the proposed solution in this bug wouldn't work, we can't just store operations as a bitfield.
Bug 24415 switches from enums to DOMStrings
(Going through old bugs and reviewing the spec) I'm not sure this is really resolved. The change to DOMString doesn't address at all the heart of the issue raised in this bug. Namely, the spec repeatedly includes statements of "If usages includes a value that is not a recognized key usage value, then return an error named InvalidAccessError" That still leads to the situation that was raised by this bug - if you have usage "foo", and a new version of the spec supports it, attempting to generateKey with "foo" raises an exception, rather than breaking the new functionality that depends on "foo" I'm inclined to think the early failure is correct - it avoids situations like typos of usages where you may have meant "deriveBits" and you wrote "deriveBats" - only to find after doing something with the key you can no longer access protected data - but I want to make sure that ap is happy.
Yes, this doesn't seem fully addressed, exactly as Ryan described. I don't feel very strongly about this issue though. If everyone else is OK with the current situation, so be it.
The early failure seems correct to me. It would be odd to be able to create Key objects with an unsupported usage - i.e. an object which can never be used.