We had this, then removed it in https://dvcs.w3.org/hg/webcrypto-api/rev/737e12c5ad33

See Bug 24415 - https://www.w3.org/Bugs/Public/show_bug.cgi?id=24415

The main issue at the time was the handling of synchronous exceptions during WebIDL conversion. However, as Boris Z. pointed out on list, this has been addressed by the ED of WebIDL (Specifically, http://heycam.github.io/webidl/#es-operations
"And then, if an exception was thrown:
- If O has a return type that is a promise type, then:
  - Let reject be the initial value of %Promise%.reject.
  - Return the result of calling reject with %Promise% as the this object and the exception as the single argument value."

Right, since promises in general are also only in latest drafts of IDL, that seems fine.

Should KeyUsage similarly be changed to an enum?

Yes. 

KeyType as well.

KeyAlgorithm.name too maybe.

NamedCurve does not seem defined either at the moment.

I think this would make sense for the fields that are not extensible: KeyFormat and KeyType.

KeyAlgorithm.name is extensible, though the defined process for registering new algorithms and (unless I am mis-understanding) making it an enum would interact badly with that extensibility point.

I believe future specifications could also add new methods to SubtleCrypto, which might come with new algorithms and new KeyUsage values, so I suggest we leave KeyUsage as a DOMString.

[Note that we can't use a key generated or imported with an existing algorithm with a new KeyUsage, because the import/generate procedures in the specification are specific about what usages are valid and we have not provided for extensibility on that axis.]

(In reply to Mark Watson from comment #6)
> KeyAlgorithm.name is extensible, though the defined process for registering
> new algorithms and (unless I am mis-understanding) making it an enum would
> interact badly with that extensibility point.

How does the extensibility work? Why can't the specification be revised?


> I believe future specifications could also add new methods to SubtleCrypto,
> which might come with new algorithms and new KeyUsage values, so I suggest
> we leave KeyUsage as a DOMString.

New specification could also simply update the enum, I don't see the problem.

(In reply to Anne from comment #7)
> (In reply to Mark Watson from comment #6)
> > KeyAlgorithm.name is extensible, though the defined process for registering
> > new algorithms and (unless I am mis-understanding) making it an enum would
> > interact badly with that extensibility point.
> 
> How does the extensibility work? Why can't the specification be revised?

Mostly, our procedures say things like 'perform the encrypt operation for the algorithm identified by the name attribute ...' and so there is the possibility there that this algorithm and operation are defined in another specification.

The algorithm normalization rules (Section 20.4) make use of an 'internal object' [[supportedAlgorithms]] which contains argument normalization information for all the algorithms supported by the UA. There is a sub-section on what needs to go into this object when a new algorithm is added and again, there is nothing which restricts the use of this mechanism to the current specification.

If I understand correctly, though, if we made KeyAlgorithm.name an enum, then adding values to this enum in another specification would be a monkey-patch.

> 
> 
> > I believe future specifications could also add new methods to SubtleCrypto,
> > which might come with new algorithms and new KeyUsage values, so I suggest
> > we leave KeyUsage as a DOMString.
> 
> New specification could also simply update the enum, I don't see the problem.

A new version of the WebCrypto specification could, but if other specifications did that, surely that's the very essence of monkey-patching ?

A specification extending another specification without that other specification needing to be aware of it is rather problematic in my opinion. How would an implementer of Web Crypto find out about that other specification?

E.g. HTML defines the canvas API which has an enumeration for a canvas context which is either 2d or webgl. webgl is defined elsewhere, but its enumeration is covered by HTML, along with a forward reference. If someone were to mint a new context, that would have to go through HTML.

(In reply to Anne from comment #9)
> A specification extending another specification without that other
> specification needing to be aware of it is rather problematic in my opinion.
> How would an implementer of Web Crypto find out about that other
> specification?

Same way they found out about WebCrypto itself. Such specifications would only be in scope of the W3C WebCrypto working group.

> 
> E.g. HTML defines the canvas API which has an enumeration for a canvas
> context which is either 2d or webgl. webgl is defined elsewhere, but its
> enumeration is covered by HTML, along with a forward reference. If someone
> were to mint a new context, that would have to go through HTML.

No, the way you find Web Crypto is by searching for it.

> Same way they found out about WebCrypto itself.

They found out about WebCrypto because some web developer came to them and asked them to implement it, with a link to the spec.

> Such specifications would only be in scope of the W3C WebCrypto working group.

In which implementors are likely not active participants.  The individuals, not the organizations.

I have no opinion on what KeyFormat should be, but specifications that add comefrom-style hooks to other specifications are just a bad idea...  the right way to add new key formats, imo, is to add them directly to the specification hat defines KeyFormat (possibly by reference to the spec that actually defines the behavior, but the idea would be that a single entry point leads, via links, to all the relevant spec text).

This is more relevant to the overall extensibility story for WebCrypto. It was argued that we needed to provide explicit extensibility points exactly to enable future extension of the specification without either modifying the base specification itself or modifying it "from afar" (monkey-patching).

If, on the other hand, extension of the base always requires modification of the base specification itself, then I don't see the advantage of defining extension points a priori: they can be provided in future versions when then are needed.

I'm fine either way, but it seems the only value in explicitly defining and constraining extension points now is that what you're constraining is what can and can't be done from other future specifications, without modification of the base. You can always do whatever you want by modifying the base itself.

We will always need to maintain the base specification. There is no way you can get around that. There's not a single specification that can get away without updates.

Ok, so in our case we have a single specification. If we're always happy to update it, why is 'monkey-patching' an issue ? We'll never do that because we'll just update the thing. Why is there any need for explicit extension points ?

There's not. Sounds like we're in agreement.

Good. Can you convince Ryan of this ?

Ok, so the extensibility bug has been closed with the resolution that we will provide extension points but these are only to be used by specifications which are explicitly referenced from the base. This list may be updated by means of errata, rather than the full specification update process.

For this bug, we can either
(i) leave things as they are
(ii) change KeyFormat, KeyUsage etc. to enums

In both cases, extension specifications can define new values. In (ii) these new values would need to be included in the Errata, as modifications to the base enum, as well as adding the reference to the extension specification.

Agreed at f2f to change KeyFormat, KeyType and KeyUsage to enums.

KetFormat: https://dvcs.w3.org/hg/webcrypto-api/rev/c837a411bbb3
KeyType: https://dvcs.w3.org/hg/webcrypto-api/rev/859e993ccd8b
KeyUsage: https://dvcs.w3.org/hg/webcrypto-api/rev/c0b3b769b9df
Remove redundant checks for KeyUsage: https://dvcs.w3.org/hg/webcrypto-api/rev/be842bc4f511
Remove redundant checks for KeyFormat: https://dvcs.w3.org/hg/webcrypto-api/rev/42b6c67b5954