RE: On Registries

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