Re: On Registries

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.

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.
On Aug 10, 2014 5:58 PM, "Harry Halpin" <hhalpin@w3.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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)
>
> iQIcBAEBAgAGBQJT6BULAAoJEPgwUoSfMzqcreQQAJLv9VKBBENRSZ1Jbio0LLXO
> EDCEvArcmwTh6zki6YIFRwpjrWuX6ajXryt7RAhagLR2yg0982gTVQK1vn76W6hd
> 6+7sEMBSrFocfxDgSfvs/EnN+nOmU7BUJ3F2PY1lQaC6SfLY6Ze7qJy2/FzoC6l4
> 7PDEnd8MwTJeccFbkyimVeGr3TWKdcg/PBjwLvPp+s+iFkaoaVsb6/JbtwJp89ma
> YwoM8Oy3VfkpRP5LvRc4hXe7gTsBPTBZXyK/Y813ion5huRKaEfoOC901bYgQNZa
> b8E63v+TpF7Dbi8mvQ1weh0147KF9cRDLvOzTHlVTiwVlT0PtLtLoNvVRmA6Kdxi
> TITamhjlnVx5vndIu4lgFdFyqYmGWxOMgaGRlyLRSnJ1M51YwtRNeF79UYq89f75
> Gsa9LmN/UbZYzXwvRSrPaL1YKxOyHqM3TB52w/ssoKMXG9qY1JSeykwhh6hvjhFz
> kkBAROC2AoKHGnGIcf7MkMoEQOjnbGBHemJkeSQOUTTpRwmtKSKZTbSW8TlQlpLu
> EBC8sdTAEUb/TZrmlGIgc+3xn2cfMO4hkpXU4B1ofBm0s8RSAvmqzlaYoEqmomps
> kut7dF6ORJChsdlSTlkcUr5yIYy9e85hJSKZRnPNIyJ/LabsoTWzhSveCTFrEGxS
> YyrdO7BL/cmHNg+hd8kY
> =Zb7K
> -----END PGP SIGNATURE-----
>