Re: On Registries

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



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?

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 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, 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.

[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)

iQIcBAEBAgAGBQJT6B+2AAoJEPgwUoSfMzqc4+oP/j01q7jWbjaWvPyqxvsv1zsT
52Qa3K77of3eNzFpr0B+6LtcP++IhE3b2YQ1wcyZL/93uPPtQY5eVj/6QDTSKrWL
s0bngPg/tr5u3qyDNFucV2IjNPORDABoqT9OFXNyFQa8D2fqtGCO+eZzbh6CRrf6
IKYoR0dj2xYwmsIHC2Y1MLUOhYXT0NuG3fNxElVY7qQqyWhQ//VqJvNwGkLW+EfN
bkYOEFkR2hI5HoOQuB3EX4mwLMySE4XHjXk7uGpwC/EwOkvP3wdSLQ3dS2UkcApU
oOjAQ/mtN79FTtSTix+rP32d1k78RtzXxgP2xSZhcebRZD9lrFVcz5sBTlj0eD3r
hp5+D9Em3fWIXLWl9cTaxkkGBWTvNPl/e6C2Yt54gYCpqWJ1bnBzP5vwRzD3hVIE
wejIDGnbTj+osicwTnlvx8OqyxDt88l3O+XF4/xFpejQJ/j70MQq+4WhS+omCvvP
cUsWYYoU7U8rRW0s3zX+ax557mUsQwqrBj5HqmTKbsva3kbMiC/WWIK7q1GnD9Bw
xG2BOjvqJCFye9RPpfak6FvHh7bbgO/ga+jWp9PZDBY/FiTNf7Yi5chGPRBwqd6M
BSUh1mARm4JfBs60MMIlpNiPlsd+zA1iUWVcF0y7ahkslPj+UQutq5nux2/gn2i/
7zNk06zDAgrNxyy3h2Hy
=0qWJ
-----END PGP SIGNATURE-----

Received on Monday, 11 August 2014 01:43:29 UTC