Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Web Crypto API #3
A few things I noticed on a 5-minute skim:
Boris Z. pointed out the notReallyAnArray thing, and they will likely be replaced with sequences<> ( per http://darobin.github.io/api-design-cookbook/#use-sequence-type )
Provide an example of your proposed verbage. The spec makes it clear that the Promise is rejected with a DOMException (eg: 14.3.11 - "If the following steps or referenced procedures say to return an error, execute resolver's reject(value) algorithm, with the returned error as the value argument and then terminate the algorithm. ")
What do you see as redundant for the exceptions? This was requested by multiple vendors. See http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0035.html
What use case is there for SubtleCrypto and WorkerCrypto to having constructors? They are exposed directly on the Window/Worker global object. "New SubtleCrypto()" has seemingly no value for programming patterns.
I would just add that the most fruitful way for feedback is "Here's the issue. Here's a proposal for a solution". There is no question that few in the WG have the necessary WHATWG/WebApps battle-tested spec experience, but we're eager to learn. Highlighting issues without solutions will not lead to any good resolutions :)
Please see https://github.com/w3ctag/promises-guide, especially e.g. https://github.com/w3ctag/promises-guide#delay-ms-
Well, if vendors really want them, I'm likely missing something, but I don't see what value
The issue is not that they should be constructable, it's that they shouldn't be classes if they don't have constructors. See e.g. the two sections starting at https://github.com/w3ctag/spec-reviews/blob/master/2014/02/quota-management-api.md#use-dictionaries-instead-of-non-constructible-classes
Yes, of course! This issue tracker is just for an initial data-gathering pass before we assemble real feedback. The end result of such a document would be significantly more polished, along the lines of our previous reviews, as you can see by perusing this repo's contents.
Doing a full read-through now. Still in proto-notes mode; hoping to write up something better tomorrow.
Whew. Done. Will try to type up in a format that's less raw and contains "here's a proposal for a solution" tomorrow.
On Sun, Apr 27, 2014 at 9:15 PM, Domenic Denicola
Because the current API does not provide for any storage mechanisms (as
You may find your question already answered on this thread -
Consider the proposal from
As you can see in the algorithm-specific sections, KeyAlgorithm is
Creating a Key object (eg: from key material) is inherently an asynchronous
There is no such concept as a Key object without a Key.
Such monkey-patching is essential for any APIs that wish to expose new
Yes, the proposal there does seem to be heading in the right direction.
Right, this is one of those WebIDL limitations I was mentioning. This came up in screen orientation as well, and our strong recommendation is to work around this limitation by returning
A constructor such as
Then it should coordinate with the specification that includes structured clone! Tagging in @annevk to explain this in case his blog post didn't help. I feel that it was explained very well there.
That's why I said "(i.e. plain JS objects)"; clearly WebIDL is limited here.
On Mon, Apr 28, 2014 at 4:07 PM, Domenic Denicola
I can only say that, having read your feedback, I cannot take any changes
I have attempted to closely mirror a variety of Web specs that already
What I mean by this, concretely, is consider the case of a smart card.
I feel there is insufficient explanation or justification for why such
A key, fundamental function of this API is that it exposes an opaque type.
Your proposal seems to create significantly more problems than it solves,
For example, there is no reason to obligate a user implementing the HTML
A Montgomery reduction can be entirely safe in one algorithm, and
The specification of BigInteger here, as a particularly structured
I am surprised and dismayed to see such advice.
On Mon, Apr 28, 2014 at 4:07 PM, Domenic Denicola
Namely, the structured clone specification states (in
"If input is an object that another specification defines how to clone
Let output be a clone of the object as defined by the other specification."
I am disappointed that you cannot see the value in this feedback as-is, and will do my best to present it in a form (with concrete solutions) that can be useful to your group, when I perform the full writeup representing a TAG opinion.
On specific points:
It seems like currently you can create one for a window; one for a worker; and you are proposing that you could create one for a smart card. These seem like three potential constructor overloads to me.
On the other hand, I still can't quite understand what about the SubtleCrypto instances makes them stateful. Remember that a class should encapsulate both data and behavior; if there is no data, just behavior, then you are really looking at a module, which in JS is represented as a plain old object. Perhaps the data encapsulated is which computational resources are being utilized? I'd appreciate your help understanding this point, as in general making it explicit which data is encapsulated by a class is crucial to defining it and allowing it to be constructed.
I appreciate you being willing to explain this, and think I have come around to your perspective on big integers in this matter---especially saying that it is just one of many data encodings. I think the typedef may be misleading in this regard, since one sees "BigInteger" and one thinks "ugh, that should be a language feature, not a typedef." Perhaps a simple clarifying note, or renaming to e.g.
You are completely right; my bad. Thanks for pushing back on this.
I hope you can appreciate, by the fact that I did eventually come around to several of these points, that we are having a constructive dialog here :). Clearly there's still the issue of WebIDL's limitations, but I hope I have explained the problem more clearly in this last message.
I know your most recent message had a rather discouraged tone, but I personally am feeling better: it seems like this exchange is definitely shaping the spec feedback document I am writing up (and that you can take to the working group) into something that will focus on the core issues, without wasting time on points that end up being misguided (like my monkey patching misstep), or overblown (like the big integer question).
@sleevi I put together a writeup what I think is the most important point, which is a concrete explanation of the changes necessary to eliminate the parallel
Let me know if this is heading in the right direction.
I still don't see a solution for how to deal with the fact that Key
That is, a Key represents some set of public, read-only attributes - and
I dislike the notion of "new Key(algorithm, type, extractable, usages)",
And it means that everything that wishes to use a Key object now has to, in
Rather than simply allowing the IDL to describe the fact that a Key object
That said, I can appreciate the concerns about how properties are handled.
"Set the variables associated with the object as follows ..."
and then in the prose again, describes how this is handled (
That is, the one spec that seems to do what you want, does it differently
More importantly, I suspect I may be missing something. Your objections
On Tue, Apr 29, 2014 at 8:43 PM, Domenic Denicola
Thanks for the follow-up! To be clear, you see the value in eliminating
I could be convinced of this, but I---and your spec readers---will need a lot more background on this to justify it. What are the internal resources you refer to? They can't be
Most importantly, how do other parts of the spec use these internal resources? I'm not as well-versed in the spec as you, but after spending some time looking through the algorithms, I can't see anything in the algorithm steps that refers to using internal resources of the key objects that aren't part of their public interface.
This is why formalizing such resources as
The recent Font Loading spec more or less follows the internal slots approach, calling them "internal attributes" and using single brackets for reasons I don't understand (EDIT: I asked Tab to switch this over, and he says he will! Yay :). I have seen this in other recent specs too, e.g. service worker has some form of it (although that spec is still very in flux). More importantly, as we move toward a world in which spec authors produce idiomatic JS APIs, this kind of usage will grow.
In ES5, this was true: people would just use underscored properties to "hide" the data, which isn't enough for security-level integrity, and is ugly, but is certainly enough to explain the object model. This is similar to how in ES3, there were no getters and setters, so the fact that DOM objects had getter-like abilities was magical and strange, and libraries had to emulate them with
But in ES6, internal slots can be represented by weak maps. See e.g. especially.
On Thu, May 1, 2014 at 3:24 PM, Domenic Denicola
Your change has the clear penalty of making the spec harder to read (from
Boris already explained some misconceptions you had regarding
That is, rather than continuing to echo how you would like to see it solved
That is, are you solely concerned with the .prototype chain of the
As a spec author and implementor, what I'm trying to accomplish - and what
The internal resources are opaque handles to the keying material. They are
This is mentioned in Section 12, where it explicitly describes Key as an
That is, there's this magic, internal thing where the phrase "with the key
This is a concept familiar to authors who have ever used other
In all of these APIs, it's a fundamental concept that there's an opaque
That's why it's not possible to create a Key object directly from Key
It is explicitly undefined how the UA gets access to them, because
In every case I mentioned, it's implemented as either a "void_" or some
I think one disconnect is that it is explicitly expected that UAs will NOT
That's also why there's no normative requirements regarding mandatory to
Within WebCrypto, there is absolutely no way to represent the
Now, if you wanted to create a polyfill of WebCrypto that was implemented
Since I suspect we still may not be on the same page, my understanding is
Your request for handling [[slots]] is baking in a concept specific to ES
OK. Let's come back to this, if you don't mind, since I'd like to tie off the other issues first.
Ah! This was what I didn't understand. I agree, now that you have explained it (in great detail, which I seriously appreciate) that there's no point in making these objects constructible, except that it would help explicitness (IMO) and make the spec more terse (as illustrated in the gist). But those are subjective, not normative, things, and don't matter. I'm happy to leave this point alone and make key non-constructible.
BUT! I would encourage you to make this concept more explicit in the spec. "Key represented by key" is really hard to understand, for me at least. I'd expect something near the definition of the Key interface that goes through much of what you've said in this thread, explaining---and preferably naming---the internal opaque data that is being withheld and manipulated. IMO internal slots are a good way of doing this (more on that later); internal slots don't have to have any well-defined type, note. Right now it's a very implicit concept, that I completely missed in my readings and re-readings.
Ah, no! This is not true. WebIDL is explicitly designed for ECMAScript, and we are planning to evolve it that way further. (Indeed, we started a "JSIDL" effort that was a ground-up replacement, but that faltered as its primary instigator ran out of time to work on it, and anyway I at least think an evolutionary approach would work better.)
Now, its historical predecessor OMG IDL---much of which still shows through the skin---was indeed designed to be language neutral. The fact that there is a single "language binding" in WebIDL is just a remnant of evolving OMG IDL, which had multiple language bindings, into WebIDL, by removing all those and leaving the ES one, and then not doing the work necessary to smash down the two conceptual layers into a single one.
Web specs these days are designed specifically for ES, and should only be concerned with exposing themselves in a way that is idiomatic to ES. This is one of the TAG's biggest missions to get across right now, and indeed:
that is exactly what we are saying. The fact that we haven't gotten this message out is sad, and I will make a note of the fact that we need to try a lot harder to do so.
On Thu, May 1, 2014 at 4:21 PM, Domenic Denicola
Works for me. ES6 all the way. Also solves the language specifying how JWK
I think the important thing to keep in mind about the constructible bits is that it's not "no constructor"---it's "there is a constructor (since otherwise the objects couldn't exist), but only the implementation has access to the correct values to call it without getting an error thrown."
OK. Here are my particular concerns:
As for ways to make it easier to determine the return value from the IDL, I guess I am not sure how
On Thu, May 1, 2014 at 4:45 PM, Domenic Denicola
Combined with the fact that we're ditching Algorithm as an input in the
void* DoSomething(void* input);
With the type of |input| and the return value being documented in prose. Is
I agree, we definitely need this. And if it takes me doing a pull request to WebIDL to make it happen, I'm all in. But before we solve that, however, how would this help web crypto?
It seems like the most-common ancestor is Algorithm/KeyAlgorithm, both of which are just
On Thu, May 1, 2014 at 5:05 PM, Domenic Denicola
I agree, you still need Prose to explain how it's handled within the actual
However, having some way to normatively provide a type notation for
Oh! Isn't that just dictionaries? You wouldn't be able to declare them in the signature, due to WebIDL limitations, but you can still use them in your algorithms. The patch I gave above in the gist does exactly that, reusing the
On Thu, May 1, 2014 at 5:13 PM, Domenic Denicola
In that case, yes, simply converting to "object" should be sufficient,
@sleevi using new Key() for something UA-managed is fine. That is pretty much how new Image() and other constructors that exist work. It also does not mean that such an object can be spoofed if you define it through IDL. E.g. if you define a method that takes a Key it will throw unless it was created through the constructor defined by the specification.
@annevk - in the case of new Image(), there's a path to turn something
@domenic - A question/problem with the whole [[internal attributes]] thing.
Let's say I specify that Key.algorithm returns the [[algorithm]] internal
When does this conversion happen? Is it legal for a UA to cache? As far as
This means if I write code like
Apologies if the above is syntactically incorrect, but hopefully you see
Yeah, good catch. This is why the prose I outlined in the gist says "After being set, which is only possible by specification text, it should return the set object for each getter invocation." If you were using the internal slot approach, you'd have say something similar, e.g. "It should return the same
I wonder if it would work to have