Re: On Registries

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/11/2014 12:45 PM, GALINDO Virginie wrote:
> Thanks Harry,
> 
> So this means that we are discussing about two linked things : - (a
> serie of) official extension, being a specification following
> recommendation track

Of course, if something does not get all the way through rec-track it
would be stuck as an Editor's Draft or possibly transformed to a
Working Group Note. Going through Rec track is preferable.

> - a *W3C wiki* maintaining the list of extensions reaching the
> recommendation states (and draft ones).

We could also just use the homepage, but wikis generally are easier to
update. Right now we don't have the problem as we don't really have
extensons for algorithms, but now with Trevor Perrin's contribution we do.

> 
> I am not sure this solves the debate of the new algorithm being new
> piece of API or new piece of data, but I would like to make sure
> that in the end, we don’t end with the situation that someone edits
> a W3C wiki, add a new algorithm in the registry and one could
> believe this algo is part of the W3C Web Crypto API (and is IP
> free).
> 

That's why the Publication Status is included in the wiki/homepage, to
clarify the situation with any proposed extension.


> My 2 cents : The *W3C wiki* is not something to discuss extensively
> : it is about communication, about letting the developers
> understanding what extensions are existing, just like we do for the
> 2 specification that are under development in our WG. Lets do not
> call it an official registry, but a simple communication tool. I am
> not in favor of having algorithms added by external organization to
> W3C deliverables without extensive WG review, but if others
> organization want to maintain a list of draft extension
> specifications (to be submitted to W3C or unofficial), they can do
> what they want, it is out of W3C scope.
> 

Seems sensible to me.  Again, developers should know where W3C and
implementers stand as regards any algorithms not in the main spec and
how to find them.

Anyways, we can close this discussion at the meeting today hopefully!


> Regards, Virginie
> 
> -----Original Message----- From: Harry Halpin
> [mailto:hhalpin@w3.org] Sent: lundi 11 août 2014 12:26 To:
> public-webcrypto@w3.org Subject: Re: On Registries
> 
> 
> 
> On 08/11/2014 11:11 AM, GALINDO Virginie wrote:
>> Dear all, Reading that discussion, I have a simple question. I
>> heard on one side that we want to include easily new algorithms
>> to the web crypto, but on the other side that we want to go
>> through W3C IPR review for any new extension. Can someone explain
>> how could we do that by maintaining a wiki on W3C website ? Where
>> would the IPR review happen in that case ?
> 
> IPR review would happen through W3C process as usual.
> 
> The wiki would simply link to all other proposed crypto and include
> its publication state. For example, it would allow people (see
> Trevor Perrin) to propose extension algorithms also outside of the
> WG as Editor's Drafts for consideration of the WG, and we'd link to
> that. If it got accepted by the WG, then we'd link to it as a W3C
> Working Draft and move it over to w3c.org space.
> 
> cheers, harry
> 
> 
>> Regards, virginie
> 
> 
>> From: Ryan Sleevi [mailto:sleevi@google.com] Sent: lundi 11 août 
>> 2014 03:55 To: Harry Halpin Cc: Mark Watson; Mike Jones; 
>> public-webcrypto@w3.org Subject: Re: On Registries
> 
> 
>> On Aug 10, 2014 6:43 PM, "Harry Halpin" 
>> <hhalpin@w3.org<mailto: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.
> 
>>> 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."
> 
>>> Or split up the algorithms from the main spec, so that its
>>> obvious the relationship between the two.
> 
>>>>> 
>>>>> 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<mailto: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<mailto: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<mailto:sleevi@google.com>]
>>>>>>>>>
>>>>>>>>> 
*Sent:* Thursday, August 07, 2014 10:18 PM *To:* Mike Jones
>>>>>>>>> *Cc:* Mark Watson; 
>>>>>>>>> public-webcrypto@w3.org<mailto: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/scripti
>>>>>
>>>>> 
ng.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<mailto: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<mailto:sleevi@google.com>]
>>>>>>>>>
>>>>>>>>> 
*Sent:* Thursday, August 07, 2014 9:48 PM *To:* Mike Jones
>>>>>>>>> *Cc:* Mark Watson; 
>>>>>>>>> public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>>>>>>>>>
>>>>>>>>> 
*Subject:* RE: On Registries
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Aug 7, 2014 9:38 PM, "Mike Jones" 
>>>>>>>>> <Michael.Jones@microsoft.com<mailto: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<mailto:sleevi@google.com>]
>>>>>>>>>>
>>>>>>>>>> 
Sent: Thursday, August 07, 2014 9:33 PM
>>>>>>>>>> 
>>>>>>>>>> To: Mike Jones Cc: Mark Watson; 
>>>>>>>>>> public-webcrypto@w3.org<mailto: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<mailto:Michael.Jones@microsoft.co
>>>>>>>>>>
>>>>>>>>>> 
m>>
>>>>>>>>> 
>>>>>>>>>> 
> 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<mailto:sleevi@google.com>]
>>>>>>>>>>
>>>>>>>>>> 
Sent: Thursday, August 07, 2014 8:12 PM To: Mike Jones Cc:
>>>>>>>>>> Mark Watson; 
>>>>>>>>>> public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>>>>>>>>>>
>>>>>>>>>> 
Subject: RE: On Registries
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Aug 7, 2014 7:56 PM, "Mike Jones" 
>>>>>>>>>> <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.co
>>>>>>>>>>
>>>>>>>>>> 
m>>
>>>>>>>>> 
>>>>>>>>>> 
> 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<mailto:sleevi@google.com>]
>>>>>>>>>>>
>>>>>>>>>>> 
Sent: Thursday, August 07, 2014 7:44 PM To: Mike Jones Cc:
>>>>>>>>>>> Mark Watson; 
>>>>>>>>>>> public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>>>>>>>>>>>
>>>>>>>>>>> 
Subject: RE: On Registries
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Aug 7, 2014 7:31 PM, "Mike Jones" 
>>>>>>>>>>> <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.c
>>>>>>>>>>>
>>>>>>>>>>> 
om>>
>>>>>>>>> 
>>>>>>>>>>> 
> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks for your insightful reply, Mark.  A
>>>>>>>>>>>> few comments inline below…
>>>>>>>>>>>> 
>>>>>>>>>>>> From: Mark Watson 
>>>>>>>>>>>> [mailto:watsonm@netflix.com<mailto:watsonm@netflix.com>]
>>>>>>>>>>>>
>>>>>>>>>>>> 
Sent: Thursday, August 07, 2014 6:02 PM To:
>>>>>>>>>>>> Mike Jones Cc: Ryan Sleevi; 
>>>>>>>>>>>> public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>>>>>>>>>>>>
>>>>>>>>>>>> 
Subject: Re: On Registries
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thursday, August 7, 2014, Mike Jones 
>>>>>>>>>>>> <Michael.Jones@microsoft.com<mailto: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)
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
> 
>> ________________________________ This message and any attachments
>> are intended solely for the addressees and may contain
>> confidential information. Any unauthorized use or disclosure,
>> either whole or partial, is prohibited. E-mails are susceptible
>> to alteration. Our company shall not be liable for the message if
>> altered, changed or falsified. If you are not the intended
>> recipient of this message, please delete it and notify the
>> sender. Although all reasonable efforts have been made to keep
>> this transmission free from viruses, the sender will not be
>> liable for damages caused by a transmitted virus.
> 
> 
> ________________________________ This message and any attachments
> are intended solely for the addressees and may contain confidential
> information. Any unauthorized use or disclosure, either whole or
> partial, is prohibited. E-mails are susceptible to alteration. Our
> company shall not be liable for the message if altered, changed or
> falsified. If you are not the intended recipient of this message,
> please delete it and notify the sender. Although all reasonable
> efforts have been made to keep this transmission free from viruses,
> the sender will not be liable for damages caused by a transmitted
> virus.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJT6KA8AAoJEPgwUoSfMzqcpw4P/3uiEkiI4pkPaLsgLIciV+5l
EQ2WBmAUlYpYfVie8Sthvyu6+Ed5Qj6eWqoHyHy4QsT/YT+P7NkwFAff9FJOWD82
eFVVyYkbhN+lalV4e4FGj6Yc0K5JPOCxXNm5WYf+Ys6nz4ks5H/F+ntrzI3n0x1P
Gz5RUIGRnQuM2VOU3O51UQSwScIu25CnWWIqul0KShEDmlVLUIYUL8e29crFOTA1
/OYlGjj5Q9lJkJUAcdepNsAx2S355z6h1TzcvlVI4BAouXSGPx5rlFYWRbZQpzCi
LXpg9mYHJjHksSrVON/tmNw8Z3yLKs3Nhvkb1t4y8XQemGVafLeKJmIYZH3yNwzx
VIKAyXg0kH6/Y6ajYAnyACwWri6XCIH73zX4+rGMhfoAwi9E6f48RSYiJeiqf1XK
axvENjFuYhmVnkvUL/RZIT1iV6Fsh6oQTNoQxpd8gov29yWnNjyqJ9vFC8fHyEIY
75v9Yqq8iNHtJyqPCDFQV2HoQ8/Pop6LDy14znHVkYx7H8WYYIs4vMhP89oSMGUj
QI+2s6ada1qySVx6cKPJywK1UPrVlJaaMNBEjmwc+HZqpwGk+lLsdwCBkuIyTae5
chQgOa+kOA9E3EMZPrrWvx4tMnpQvqF3EO/T0hXdY0dRX2Nhtl4hrlhCsR5qiNL4
Ro8QKLV6ifhq7RGx/JjJ
=kRAh
-----END PGP SIGNATURE-----

Received on Monday, 11 August 2014 10:51:49 UTC