- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 11 Aug 2014 18:18:56 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: Mark Watson <watsonm@netflix.com>, Mike Jones <Michael.Jones@microsoft.com>, public-webcrypto@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/11/2014 05:55 PM, Ryan Sleevi wrote: > On Aug 11, 2014 8:43 AM, "Harry Halpin" <hhalpin@w3.org> wrote: >> > > > On 08/11/2014 05:39 PM, Ryan Sleevi wrote: >>>> On Aug 11, 2014 8:34 AM, "Harry Halpin" <hhalpin@w3.org> >>>> wrote: >>>>> >>>> >>>> >>>> On 08/11/2014 03:55 AM, Ryan Sleevi wrote: >>>>>>> On Aug 10, 2014 6:43 PM, "Harry Halpin" >>>>>>> <hhalpin@w3.org> wrote: >>>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/11/2014 03:26 AM, Ryan Sleevi wrote: >>>>>>>>>> Considering no other WG has needed such a >>>>>>>>>> pointer, especially all of the work in WebApps, I >>>>>>>>>> think such a pointer would be counterproductive >>>>>>>>>> to the spirit of the spec process and ill-advised >>>>>>>>>> in terms of spec maturity. >>>>>>> >>>>>>> What would you expect say, a developer who goes through >>>>>>> the spec and notices that Curve25519 is not in the spec >>>>>>> to do? >>>>>>> >>>>>>> Seems like a link back to where he could find a list of >>>>>>> specs that the WG is working on in terms of algorithms >>>>>>> could be useful to guide the developer to the right >>>>>>> spec (ideally with test-suite that shows where it is or >>>>>>> isn't implemented). Do you think there's an >>>>>>> alternative? >>>>>>> >>>>>>>> Why ideally with a test suite? How is that any >>>>>>>> different from the main spec linking to a test suite? >>>>>>>> Or having one in-built? Why would algorithm >>>>>>>> extensions be expected to provide something the main >>>>>>>> spec doesn't? >>>>>>> >>>>>>> >>>>>>> As much as I know we all enjoy new bugs asking for new >>>>>>> curves when people read the spec and notice their >>>>>>> favorite curve missing :) >>>>>>> >>>>>>> >>>>>>>> I would rather solve real problems than deal with >>>>>>>> hypothetical strawmen. >>>> >>>> We've had a few of these happen, ala >>>> >>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839 >>>> >>>> but earlier as regards SEED. I know you find it irritating, >>>> but it keeps happening. >>>> >>>>>>> >>>>>>>> Its the same situation as when a 'developer' reads >>>>>>>> the HTML5 spec and notices there's nothing about >>>>>>>> filesystem access. Or notes that there is no way to >>>>>>>> manipulate sound. >>>>>>> >>>>>>>> I have no objection to a wiki stating the PubStatus >>>>>>>> - WebApps has successfully done that for some time. >>>>>>>> What I object to is trying to shoehorn it into the >>>>>>>> spec somehow. >>>>>>> >>>>>>>> The maximal language that should be sufficient is >>>>>>>> "Additional specifications may define other >>>>>>>> algorithms." >>>> >>>> Maybe minimize a bit more with a link? >>>> >>>> "Additional <a >>>> href="@@Publication_Status_Page">specifications</a> may >>>> define other algorithm" suitable? >>>> >>>>> You don't minimize risk with a link. You minimize it with >>>>> process. >>>> >>>>> The omission was intentional. > > Then a link to the process is useful. Do you have one, or do you > want the readers of the spec to just guess the process? > > At least specifying the process is a good thing. Otherwise, folks > could go off and define prefixes, set up their own registry, or > many of the other fun things W3C has had happened over the last > years. Is that what you intend Ryan? > > I was under impression you wanted extensions to go through W3C > process. > >> Harry, > >> While the extreme doom and gloom is as entertaining as a Cormac >> McCarthy novel, its not needed. > >> Linking to the PubStatus does not make it any more or less likely >> that people will do all of the things you said. We know this from >> simple history. > >> We also know that the only thing that matters is what UAs do. It >> doesn't matter if Jane Doe Off the Street goes and writes a spec >> that says "All these identifiers belong to me. Attempt no >> specifications here" - unless and until UAs decide Jane is >> right. > >> Your hypothetical spec authors are either capable and cognizant >> of how the web works, and realize this is no different than any >> other specification activity in the W3C, or they aren't. The goal is to send future requests for Curve 25519 (see Matt Corrallo and Greg Slepak) to proposals such as Trevor Perrin's, to reduce the pain on Bugzilla and mailing lists. > >> Your hypothetical developers are not going to be reading the >> spec, certainly not when >> WebPlatform/StackOverflow/MDN/W3Schools(...ugh) results dominate >> their results. > >> Its equally important not to pretend the W3C _is_ the only >> arbiter here. Do I want stuff to go through the W3C? Absolutely. >> But we know what happens when the W3C ignores the real world for >> the academic, when it embraces unrealistic technologies with no >> interest from UAs, and when it prioritizes member happiness over >> meaningful improvements - UAs migrate to WHATWG and continue >> improving the web, and the W3C gets ignored. I agree people can use whatever process they want, but it seems like pointing them to a process could be useful. Mike suggested IANA and you suggested W3C - both are fine by me (as would be anything really, including a wiki or a list of options), but clarity here would help for those who are just looking at the spec. Also, if certain UA don't want certain non-NIST curves for whatever reason, that's fine - but that doesn't mean that we should forbid other perfectly competent folks from defining them (in extension specs if one wants) and then show in a test-suite which UA's offer which curves and which UA's don't. > >> So, again, the only thing that matters is what UA implements. I wouldn't go far as saying "only thing." Of course, UAs are vitally important but a dictatorship of a single implementation is precisely what we are trying to avoid. The test-suite should again clarify what UAs implement in detail. However, we should also not forget what users and developers want as well, and try to point their energies in the right direction - as we've I think we've done successfully wiht Curve25519. While it's been a long few months with many comments, the point of W3C process is to try to at least give users and developers a voice. > >> But since we haven't seen the doomed and charred wreckage of >> random APIs violating structured clone or getContext, which are >> in far greater use, I do believe we are fine. > Cross fingers! :) > > > > >>>> >>>> >>>> Otherwise we could mean specs defined outside W3C process. >>>> If that's what you mean, then we can state that explicitly as >>>> well. >>>> >>>> Also, do you feel the spec is suitably generic in text yet, >>>> in terms of the original bug [1]? >>>> >>>> We could try to recruit a few proof-readers to check it out - >>>> for example, BAL and Trevor Perrin I likely would be >>>> interested. >>>> >>>> Crossing fingers for getting out of Last Call... >>>> >>>> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618 >>>> >>>> >>>>>>> >>>>>>>> Or split up the algorithms from the main spec, so >>>>>>>> that its obvious the relationship between the two. >>>> >>>> That would be a lot of cut-and-paste editorial work but is >>>> also possible. >>>> >>>>>>> >>>>>>>>>> >>>>>>>>>> I appreciate your attempt to try to balance >>>>>>>>>> things, but again, HTML5 has succeeded without a >>>>>>>>>> 'pointer to things that define structured clone', >>>>>>>>>> or to 'specs which define canvas.getContext', or >>>>>>>>>> to 'supplemental interfaces to the Window >>>>>>>>>> interface', all of which are functionally >>>>>>>>>> equivalent to any such extensibility discussion. >>>>>>> >>>>>>> Perhaps more analogous, >>>>>>> >>>>>>>> No. Its not really analogous to that at all, in that >>>>>>>> their processing mechanisms - and effects on web >>>>>>>> developers - are nothing like the aforementioned >>>>>>>> extension points of HTML5. >>>>>>> >>>>>>> HTML5 also has a wiki for link relationships [1] - see >>>>>>> "Types defined as extensions in the microformats wiki >>>>>>> existing-rel-values page with the status "proposed" or >>>>>>> "ratified" may be used with the rel attribute on link, >>>>>>> a, and area elements in accordance to the "Effect >>>>>>> on..." field. [MFREL]" [1]. I suspect this is something >>>>>>> less formal is what Mike was aiming at with a >>>>>>> "registry" but I agree a formal registry will be >>>>>>> difficult to maintain. >>>>>>> >>>>>>> Historically, XML-DSIG used URIs for algorithms to >>>>>>> avoid the "registry" problem. >>>>>>> >>>>>>>> Great for XML-DSIG. Except its relevance to the Web >>>>>>>> and how the Web works is virtually nonexistent. >>>>>>> >>>>>>>> Among other things, its not an API, nor exposed as >>>>>>>> such. Nor does it affect things in the same way. The >>>>>>>> applicability of the decisions made there are >>>>>>>> equally nonexistent (and more akin to JOSE than >>>>>>>> HTML) >>>>>>> >>>>>>> >>>>>>> [1] http://microformats.org/wiki/existing >>>>>>> rel-values#HTML5_link_type_extensions [2] >>>>>>> http://www.w3.org/TR/html5/links.html#linkTypes >>>>>>> >>>>>>> >>>>>>>>>> On Aug 10, 2014 5:58 PM, "Harry Halpin" >>>>>>>>>> <hhalpin@w3.org> wrote: >>>>>>>>>> >>>>>>>>>> Would the best way forward here simply be a >>>>>>>>>> pointer from the spec to the web-page of the WG >>>>>>>>>> near the "Algorithm" so that authors can check to >>>>>>>>>> see the status of algorithms that may not be not >>>>>>>>>> included the main spec, such as Curve25519? >>>>>>>>>> >>>>>>>>>> Then the WG homepage's list of "extension specs" >>>>>>>>>> (with a clear sign of maturity in terms of Rec >>>>>>>>>> process) serves as a "registry" (for lack of a >>>>>>>>>> better term). >>>>>>>>>> >>>>>>>>>> While a bit more heavyweight than the wiki I >>>>>>>>>> suggested earlier, it would satisfy I think >>>>>>>>>> Ryan's concerns about algorithms going through >>>>>>>>>> process without thorough discussion and consensus >>>>>>>>>> from the UAs and WG, and also Mike's concerns >>>>>>>>>> about where developers would go to find >>>>>>>>>> algorithms they don't see in the spec and where >>>>>>>>>> UAs could ask for them. >>>>>>>>>> >>>>>>>>>> Sound reasonable? A quick sentence or two added >>>>>>>>>> to "18.1. Registered algorithms" pointing back to >>>>>>>>>> the WG homepage would then be enough. >>>>>>>>>> >>>>>>>>>> cheers, harry >>>>>>>>>> >>>>>>>>>> On 08/08/2014 07:26 AM, Ryan Sleevi wrote: >>>>>>>>>>>>> WebCrypto is a Web API. >>>>>>>>>>>>> >>>>>>>>>>>>> There is no need for a registry for >>>>>>>>>>>>> non-Web users. By definition, charter, and >>>>>>>>>>>>> constituency, they do not exist. >>>>>>>>>>>>> >>>>>>>>>>>>> All that matters, for standardization, is >>>>>>>>>>>>> what UAs do. >>>>>>>>>>>>> >>>>>>>>>>>>> If no UA is involved, then having a name >>>>>>>>>>>>> registry only serves to put the Web as >>>>>>>>>>>>> second class. On Aug 7, 2014 10:24 PM, >>>>>>>>>>>>> "Mike Jones" <Michael.Jones@microsoft.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> You’re missing that user agents don’t >>>>>>>>>>>>>> have to implement registered algorithms. >>>>>>>>>>>>>> They’re free to exercise their own best >>>>>>>>>>>>>> judgment. If they weren’t, then you’d be >>>>>>>>>>>>>> on the side of having required >>>>>>>>>>>>>> algorithms, which I know you’re not. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the same way that registering new JWA >>>>>>>>>>>>>> algorithms doesn’t hurt anything, >>>>>>>>>>>>>> registering new WebCrypto algorithms >>>>>>>>>>>>>> doesn’t hurt anything. But it can help. >>>>>>>>>>>>>> There’s nothing to fear there. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *From:* Ryan Sleevi >>>>>>>>>>>>>> [mailto:sleevi@google.com] *Sent:* >>>>>>>>>>>>>> Thursday, August 07, 2014 10:18 PM *To:* >>>>>>>>>>>>>> Mike Jones *Cc:* Mark Watson; >>>>>>>>>>>>>> public-webcrypto@w3.org *Subject:* RE: >>>>>>>>>>>>>> On Registries >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mike, >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we want to talk hyperbole, suggesting >>>>>>>>>>>>>> the W3C is akin to fearing openness is >>>>>>>>>>>>>> right up there. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Every algorithm in WebCrypto represents >>>>>>>>>>>>>> a distinct capability for the Web. Thus >>>>>>>>>>>>>> is, by definition, an API, no different >>>>>>>>>>>>>> than Canvas.getContext is an API ( >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting.html#the-canvas-element >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>> >>>> >>>>> > >> ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> What scares me is individual UAs >>>>>>>>>>>>>> arbitrarily and unilaterally adding new >>>>>>>>>>>>>> capabilities to the web, without >>>>>>>>>>>>>> discussion and consensus of other UAs, >>>>>>>>>>>>>> which you have been so gung-ho on for so >>>>>>>>>>>>>> long and so clearly, and which I can only >>>>>>>>>>>>>> hope is an individual view and not >>>>>>>>>>>>>> current corporate thinking. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That is the ONLY technical purpose a >>>>>>>>>>>>>> registry of allowing arbitrary >>>>>>>>>>>>>> organizations to register new algorithms >>>>>>>>>>>>>> serves. And expert review does NOT cut >>>>>>>>>>>>>> it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The registration of JWA/JWK affects no >>>>>>>>>>>>>> other implementations, except for those >>>>>>>>>>>>>> that developers try to exchange messages >>>>>>>>>>>>>> with. It is, by definition, safe. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Exposing a new capability affects every >>>>>>>>>>>>>> User Agent that ever hopes to visit that >>>>>>>>>>>>>> site, and thus should absolutely be >>>>>>>>>>>>>> treated with fear and trembling, because >>>>>>>>>>>>>> the Web does not remove capabilities >>>>>>>>>>>>>> lightly. Suggesting such a site would >>>>>>>>>>>>>> "only affect/support IE" or "Only >>>>>>>>>>>>>> affect/support Chrome", which is what >>>>>>>>>>>>>> such arbitrary capability extensions >>>>>>>>>>>>>> mean, is the very essence of a return to >>>>>>>>>>>>>> browser wars and extinction through >>>>>>>>>>>>>> interoperability failure. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 7, 2014 9:55 PM, "Mike Jones" >>>>>>>>>>>>>> <Michael.Jones@microsoft.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> So why, exactly, was it OK for you to >>>>>>>>>>>>>> add algorithms to JWA and JWK with a >>>>>>>>>>>>>> registry, when you would deny the same >>>>>>>>>>>>>> ability to others for WebCrypto? Why does >>>>>>>>>>>>>> openness and cooperation scare you so? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> *From:* Ryan Sleevi >>>>>>>>>>>>>> [mailto:sleevi@google.com] *Sent:* >>>>>>>>>>>>>> Thursday, August 07, 2014 9:48 PM *To:* >>>>>>>>>>>>>> Mike Jones *Cc:* Mark Watson; >>>>>>>>>>>>>> public-webcrypto@w3.org *Subject:* RE: >>>>>>>>>>>>>> On Registries >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 7, 2014 9:38 PM, "Mike Jones" >>>>>>>>>>>>>> <Michael.Jones@microsoft.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We’re not talking about adding APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Right, I thought we had agreement that >>>>>>>>>>>>>> this was an API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Without that agreement, I suspect there >>>>>>>>>>>>>> is nothing further of fruit to come of >>>>>>>>>>>>>> this discussion. The points for why it >>>>>>>>>>>>>> is, unquestionably, an API have been laid >>>>>>>>>>>>>> out. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> We’re talking about algorithms. That’s >>>>>>>>>>>>>>> a much more restricted extension >>>>>>>>>>>>>> space than the hypothetical one that >>>>>>>>>>>>>> you’re pontificating about. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cryptographers are more qualified to >>>>>>>>>>>>>>> extend that space than the W3C, the >>>>>>>>>>>>>> WHATWG, ECMA, or you or me. Let’s enable >>>>>>>>>>>>>> them do it, irrespective of the >>>>>>>>>>>>>> organization in which they write their >>>>>>>>>>>>>> spec. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cryptographers, as an abstract >>>>>>>>>>>>>> group/concept, are the LEAST qualified of >>>>>>>>>>>>>> the groups you mentioned to write browser >>>>>>>>>>>>>> APIs, to understand both the limitations >>>>>>>>>>>>>> and the idioms of the platform, of the >>>>>>>>>>>>>> risks and the guarantees, and of how the >>>>>>>>>>>>>> Web and Standards work. >>>>>>>>>>>>>> >>>>>>>>>>>>>> With all due respect to all parties, it's >>>>>>>>>>>>>> like suggesting someone who specializes >>>>>>>>>>>>>> in Computer Aided Design to design a C >>>>>>>>>>>>>> API. Very different roles and functions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If they do so, its no different than me >>>>>>>>>>>>>> writing a spec for cold fusion and hiding >>>>>>>>>>>>>> it under my pillow, because its just a >>>>>>>>>>>>>> piece of paper. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It means nothing without the involvement >>>>>>>>>>>>>> of UAs, to implement, to agree on things >>>>>>>>>>>>>> like IPR, etc. Any UA that went and >>>>>>>>>>>>>> implemented such extensions ad-hoc would >>>>>>>>>>>>>> rightly be called out as breaking the >>>>>>>>>>>>>> web, embracing, extending, and >>>>>>>>>>>>>> extinguishing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can only encourage you to reach out to >>>>>>>>>>>>>> your counterparts on the IE team and in >>>>>>>>>>>>>> WebApps to understand that none of our >>>>>>>>>>>>>> organizations (and yeah, Moz, you too ;D) >>>>>>>>>>>>>> have their hands clean in these matters, >>>>>>>>>>>>>> and that's precisely why we are trying so >>>>>>>>>>>>>> hard to work together to ensure it does >>>>>>>>>>>>>> not happen. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A spec that blesses or condones such API >>>>>>>>>>>>>> extensions, rather than condemning, is a >>>>>>>>>>>>>> step in the wrong direction for >>>>>>>>>>>>>> standards. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: Ryan Sleevi >>>>>>>>>>>>>>> [mailto:sleevi@google.com] Sent: >>>>>>>>>>>>>>> Thursday, August 07, 2014 9:33 PM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To: Mike Jones Cc: Mark Watson; >>>>>>>>>>>>>>> public-webcrypto@w3.org Subject: RE: >>>>>>>>>>>>>>> On Registries >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mike, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you name any organization or >>>>>>>>>>>>>>> individual, outside the W3C, WHATWG, >>>>>>>>>>>>>> and ECMA qualified to extend the web by >>>>>>>>>>>>>> adding new APIs for UAs to implement? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You can easily reach out to Travis L. >>>>>>>>>>>>>>> and co on your side, or to your >>>>>>>>>>>>>> legal team, to better understand >>>>>>>>>>>>>> Microsoft's view against exactly that, >>>>>>>>>>>>>> with respect to participation and >>>>>>>>>>>>>> standardization that occurs in the >>>>>>>>>>>>>> WHATWG. Or you can look towards the >>>>>>>>>>>>>> involvement in TC39 to better understand >>>>>>>>>>>>>> that there is very much a split, in both >>>>>>>>>>>>>> organizations, as to which party is >>>>>>>>>>>>>> responsible for developing and >>>>>>>>>>>>>> standardizing which aspects. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That the IETF, or any similar >>>>>>>>>>>>>>> organization, would and can >>>>>>>>>>>>>>> responsibly >>>>>>>>>>>>>> develop JavaScript APIs used by millions >>>>>>>>>>>>>> of developers, without the involvement of >>>>>>>>>>>>>> UAs, is not a reality. The core >>>>>>>>>>>>>> constituency is and has always been >>>>>>>>>>>>>> wherever the UAs are, since ultimately no >>>>>>>>>>>>>> standard, draft, or spec is ever >>>>>>>>>>>>>> meaningful until UAs sit down and >>>>>>>>>>>>>> implement it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So the only registry that matters is >>>>>>>>>>>>>>> what UAs do. Everything else is a >>>>>>>>>>>>>> figment of a standards dream that >>>>>>>>>>>>>> doesn't exist, much like the debacle of >>>>>>>>>>>>>> XHTML that lead to the formation of the >>>>>>>>>>>>>> WHATWG to begin with. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Put differently, interop is the only >>>>>>>>>>>>>>> registry that matters. And the W3C >>>>>>>>>>>>>> (and WHATWG) is where interop happens. A >>>>>>>>>>>>>> registry doesn't make interop happen - it >>>>>>>>>>>>>> just documents the interop that already >>>>>>>>>>>>>> happened. So does a Wiki. Or a PubStatus. >>>>>>>>>>>>>> Or WebPlatform.org, MDN, MSDN, etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 7, 2014 9:20 PM, "Mike Jones" >>>>>>>>>>>>>>> <Michael.Jones@microsoft.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ryan, it seems that your primary >>>>>>>>>>>>>>> motivation here is preventing things >>>>>>>>>>>>>> that could go wrong. Mine is enabling >>>>>>>>>>>>>> things that can go right. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I find it hypocritical that you’ll >>>>>>>>>>>>>>> happily use the IANA Registry to >>>>>>>>>>>>>> extend JWK for use by WebCrypto in >>>>>>>>>>>>>> http://www.w3.org/TR/WebCryptoAPI/#iana-section >>>>>>>>>>>>>> >>>>>>>>>>>>>> but you’re unwilling to admit that enabling the >>>>>>>>>>>>>> IETF or others to similarly extend >>>>>>>>>>>>>> WebCrypto would likewise be a good >>>>>>>>>>>>>> thing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The IETF is happy to have others extend >>>>>>>>>>>>>>> the Internet in a principled >>>>>>>>>>>>>> fashion. Why are you so afraid to let >>>>>>>>>>>>>> the IETF or others extend the Web in a >>>>>>>>>>>>>> similarly principled fashion? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JWK is stronger because WebCrypto can >>>>>>>>>>>>>>> extend it. It’s better for >>>>>>>>>>>>>> WebCrypto, better for JOSE, and better >>>>>>>>>>>>>> for the Internet. WebCrypto and the Web >>>>>>>>>>>>>> would be similarly stronger if others >>>>>>>>>>>>>> outside the W3C could extend it. So let’s >>>>>>>>>>>>>> make it happen! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’ll be happy continue to advocate that >>>>>>>>>>>>>>> it’s more important to WebCrypto >>>>>>>>>>>>>> and the W3C to enable responsible >>>>>>>>>>>>>> extensions by all, even though it may >>>>>>>>>>>>>> scare you, than to maintain a closed spec >>>>>>>>>>>>>> and closed process that only one >>>>>>>>>>>>>> organization can extend. I believe that >>>>>>>>>>>>>> openness in this respect is “on the >>>>>>>>>>>>>> right side of history”. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Mike >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: Ryan Sleevi >>>>>>>>>>>>>>> [mailto:sleevi@google.com] Sent: >>>>>>>>>>>>>>> Thursday, August 07, 2014 8:12 PM To: >>>>>>>>>>>>>>> Mike Jones Cc: Mark Watson; >>>>>>>>>>>>>>> public-webcrypto@w3.org Subject: RE: >>>>>>>>>>>>>>> On Registries >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 7, 2014 7:56 PM, "Mike Jones" >>>>>>>>>>>>>>> <Michael.Jones@microsoft.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Replies about the W3C’s positive role >>>>>>>>>>>>>>>> in ensuring quality of algorithm >>>>>>>>>>>>>> registry entries inline at the end of >>>>>>>>>>>>>> this message… >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From: Ryan Sleevi >>>>>>>>>>>>>>>> [mailto:sleevi@google.com] Sent: >>>>>>>>>>>>>>>> Thursday, August 07, 2014 7:44 PM To: >>>>>>>>>>>>>>>> Mike Jones Cc: Mark Watson; >>>>>>>>>>>>>>>> public-webcrypto@w3.org Subject: RE: >>>>>>>>>>>>>>>> On Registries >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 7, 2014 7:31 PM, "Mike Jones" >>>>>>>>>>>>>>>> <Michael.Jones@microsoft.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for your insightful reply, >>>>>>>>>>>>>>>>> Mark. A few comments inline below… >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From: Mark Watson >>>>>>>>>>>>>>>>> [mailto:watsonm@netflix.com] Sent: >>>>>>>>>>>>>>>>> Thursday, August 07, 2014 6:02 PM >>>>>>>>>>>>>>>>> To: Mike Jones Cc: Ryan Sleevi; >>>>>>>>>>>>>>>>> public-webcrypto@w3.org Subject: >>>>>>>>>>>>>>>>> Re: On Registries >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thursday, August 7, 2014, Mike >>>>>>>>>>>>>>>>> Jones >>>>>>>>>>>>>>>>> <Michael.Jones@microsoft.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Simple. In the first case, the >>>>>>>>>>>>>>>>> algorithm is a data value. In the >>>>>>>>>>>>>> second case, it’s encoded in an API. >>>>>>>>>>>>>> Data values are easily extensible. APIs >>>>>>>>>>>>>> are not. That’s why extending the space >>>>>>>>>>>>>> of algorithms by registering new data >>>>>>>>>>>>>> values makes a world of sense. Expending >>>>>>>>>>>>>> the algorithms by adding new APIs for >>>>>>>>>>>>>> each would be clunky, procedurally slow, >>>>>>>>>>>>>> and mostly unworkable. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I think what Ryan is saying is that >>>>>>>>>>>>>>>>> it should be no easier to add an >>>>>>>>>>>>>> algorithm than it is to add a new API >>>>>>>>>>>>>> (or, more strongly, that a new algorithm >>>>>>>>>>>>>> *is* a new API and _therefore_ should be >>>>>>>>>>>>>> no easier to add). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I believe you’ve accurately >>>>>>>>>>>>>>>>> identified the heart of the >>>>>>>>>>>>>>>>> disagreement >>>>>>>>>>>>>> here, Mark. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> IF we decided that it should be >>>>>>>>>>>>>>>>> easier than this to add new >>>>>>>>>>>>>> algorithms and especially if we decided >>>>>>>>>>>>>> that groups other than W3C Working Groups >>>>>>>>>>>>>> should be able to do so, then a registry >>>>>>>>>>>>>> makes sense as a mechanism to coordinate >>>>>>>>>>>>>> that. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Agreed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Otherwise (which is where we are >>>>>>>>>>>>>>>>> now), then the definitive list of >>>>>>>>>>>>>> algorithms is to be found in the sum >>>>>>>>>>>>>> total of the output of the W3C WebCrypto >>>>>>>>>>>>>> Working Group and nowhere else. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If we decide that he definitive >>>>>>>>>>>>>>>>> list of algorithms is only to be >>>>>>>>>>>>>> produced by the W3C WebCrypto Working >>>>>>>>>>>>>> Group, I believe that would be a >>>>>>>>>>>>>> significant missed opportunity. The >>>>>>>>>>>>>> WebCrypto API is an exercise in packaging >>>>>>>>>>>>>> algorithms developed by cryptographers >>>>>>>>>>>>>> for use by Web developers, just like JOSE >>>>>>>>>>>>>> is. Neither working group’s primary >>>>>>>>>>>>>> expertise is cryptography. >>>>>>>>>>>>>> Cryptographers should be the ones to >>>>>>>>>>>>>> write the extensions specs defining new >>>>>>>>>>>>>> algorithms – not us. Some of those may >>>>>>>>>>>>>> occur in the W3C but some may occur in >>>>>>>>>>>>>> the IETF and some may be individual >>>>>>>>>>>>>> drafts by people such as Dan Bernstein, >>>>>>>>>>>>>> David McGrew, and Brian LaMacchia. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> We would be doing the WebCrypto API >>>>>>>>>>>>>>>>> and the Web a significant >>>>>>>>>>>>>> disservice if we don’t enable people >>>>>>>>>>>>>> other than us to define and register new >>>>>>>>>>>>>> algorithms for use with WebCrypto. We >>>>>>>>>>>>>> should be humble enough to recognize that >>>>>>>>>>>>>> defining new crypto algorithms is not our >>>>>>>>>>>>>> expertise and let those who are experts >>>>>>>>>>>>>> define them for use with our spec, no >>>>>>>>>>>>>> matter where they choose to do the work. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I agree with the sentiment that >>>>>>>>>>>>>>>> anyone should be able to write >>>>>>>>>>>>>> definitions for algorithms, and am >>>>>>>>>>>>>> excited to see Trevor's Curve25519 >>>>>>>>>>>>>> draft. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I disagree with the sentiment that >>>>>>>>>>>>>>>> it should happen outside the W3C. >>>>>>>>>>>>>> To do so is to return to the browser >>>>>>>>>>>>>> wars, where both Microsoft and Mozilla, >>>>>>>>>>>>>> though well motivated, wrecked great harm >>>>>>>>>>>>>> through "embrace, extend, extinguish" and >>>>>>>>>>>>>> the introduction at large of new >>>>>>>>>>>>>> vendor-specific APIs, often without specs >>>>>>>>>>>>>> (or without free licensing, or with great >>>>>>>>>>>>>> patent encumbrance, or through active >>>>>>>>>>>>>> hostility towards other UAs efforts to >>>>>>>>>>>>>> interop) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The W3C (and the WHATWG) exist to >>>>>>>>>>>>>>>> help prevent that terrible harm from >>>>>>>>>>>>>> ever happening again. The way to do that >>>>>>>>>>>>>> is by having multiple UAs coordinate and >>>>>>>>>>>>>> ship features responsibly, to agree on >>>>>>>>>>>>>> specifications, and to avoid vendor >>>>>>>>>>>>>> lock-in. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regardless of this group's >>>>>>>>>>>>>>>> cryptographic expertise, which i >>>>>>>>>>>>>>>> agree is >>>>>>>>>>>>>> unfortunately lacking, we are filled with >>>>>>>>>>>>>> UA implementors, the sole entities with >>>>>>>>>>>>>> the power to make - or break - the web; >>>>>>>>>>>>>> For developers, for other UA >>>>>>>>>>>>>> implementors, and most importantly, for >>>>>>>>>>>>>> users, for this generation of the web and >>>>>>>>>>>>>> those to come. For that, there can and >>>>>>>>>>>>>> should be no alternative - we must >>>>>>>>>>>>>> agree, as UAs, and the W3C exists >>>>>>>>>>>>>> precisely to support and guide that >>>>>>>>>>>>>> agreement. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Suggesting that using a responsibly >>>>>>>>>>>>>>>> managed registry would be a return >>>>>>>>>>>>>> to the “browser wars” or that features >>>>>>>>>>>>>> would be shipped without specifications >>>>>>>>>>>>>> is hyperbole. I’m only advocating a >>>>>>>>>>>>>> specification-required registry with >>>>>>>>>>>>>> expert review. The W3C would appoint the >>>>>>>>>>>>>> appropriate experts to ensure that the >>>>>>>>>>>>>> specifications registering algorithms >>>>>>>>>>>>>> are clear and well-written and meet any >>>>>>>>>>>>>> other criteria decided by the W3C. The >>>>>>>>>>>>>> W3C can ensure the quality of registered >>>>>>>>>>>>>> algorithms without having to write all >>>>>>>>>>>>>> the drafts itself. It’s unnecessary and >>>>>>>>>>>>>> detrimental hubris to think that we’re >>>>>>>>>>>>>> the only ones qualified to do so. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- Mike >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Expert Review is exactly the >>>>>>>>>>>>>>> detrimental sort of stuff that got us >>>>>>>>>>>>>>> into >>>>>>>>>>>>>> this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The W3C REC track is exactly that. A >>>>>>>>>>>>>>> path for _anyone_ to write specs, >>>>>>>>>>>>>> submit them to the WG, for UAs and users >>>>>>>>>>>>>> to agree in interest, and to develop and >>>>>>>>>>>>>> publish such specifications with clear >>>>>>>>>>>>>> views on patents, interoperability, and >>>>>>>>>>>>>> applicability to the web. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No single expert is qualified to >>>>>>>>>>>>>>> reflect consensus of a >>>>>>>>>>>>>> multi-stakeholder UA community, which is >>>>>>>>>>>>>> a fundamental and nonnegotiable portion >>>>>>>>>>>>>> of any Web API. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So if we talk a panel of experts, who >>>>>>>>>>>>>>> are they? Well, we probably want >>>>>>>>>>>>>> some UAs, those are essential. We >>>>>>>>>>>>>> probably need some cryptographers, since >>>>>>>>>>>>>> security is key. We should hear from >>>>>>>>>>>>>> developers, since this matters to them. >>>>>>>>>>>>>> And we should probably have a few >>>>>>>>>>>>>> representatives from the public. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And suddenly, you have an Expert Panel >>>>>>>>>>>>>>> that is indistinguishable in form >>>>>>>>>>>>>> or function from a WG. And without having >>>>>>>>>>>>>> to reinvent a process for that review. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any solution that fails to go through >>>>>>>>>>>>>>> the W3C/WHATWG process is, in >>>>>>>>>>>>>> spirit and effect, a return to the >>>>>>>>>>>>>> browser wars - including the designation >>>>>>>>>>>>>> of sole experts (which the W3C also has >>>>>>>>>>>>>> readily available if this WG should ever >>>>>>>>>>>>>> need - the TAG and AB) >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJT6OzvAAoJEPgwUoSfMzqcpv4P/j+V+5JDXsBDD6pyPxhWniA+ zwjaq8xXqavx7FOtv1qcy5zgZBH9PBD6ClkL9Fe3W9MsGa8tIENvJLoJ6MwFvFkt gD9Huzwj/0Vzkxv6M94q1pwM2YrZ0b7kZ+bWF9KTmfxkh9MwZS0yKw9BwgZ0RTRA hhHxLDIUbopdU0s0bKaE1/4BN34wwNhNDGRmnJ/lbW3Xme4IGXB7gL5EE0bzCfhG IWoueKpTdDcjkeZmuIEOs6Ne+3s8T0IXcIXFtWumNc9+SyajSqp7ypxkWTi85NOW PGN48HAozzx/7Qty68EER1F8pVy0oD5eQSCIGu/SH5HGk9VbMW7VbyciQBovNehe lEpzjSAnxNcD+1A5DCYnv+y478dknw6e9iCbcVjK6aKnSlmcHHtdXG2ouEB000VD 2WPw00BCDwV3nyDKvEX0Xc8ox7RhfI38OQv1I7lpsdQmGkn7UMaWIK1N74PmmRfh 36GyWrq9H8VVXEmAe8axf92XWLy/tbwg474hZ0ox62McmfZyltTaIor5qQgZm7jx wOU6TlSnFs0wtH5Uo519nnNIshyy3Fk9AjIN/+AZspH3bHtQt1qKiMu9NoawVEUw oELMt+O/tmeKzWY3n3EbsWGLYbcjXDDDXeofM13iyukog5/9YU3AMwd3RxXDtH2P DGzUjkaitPkKeYvXJHQm =8LrM -----END PGP SIGNATURE-----
Received on Monday, 11 August 2014 16:19:07 UTC