Re: [W3C Web Crypto WG] how to progress ?

Ryan,

 I'm sure the W3C would be willing to extend the charter if activity was
shown on the open bugs so we could convince the AC that with only X more
months (rather than years),  we would achieve interoperability. In good
news, I believe Mozilla's Tim Taubert will join the WG soon to help on
the Mozilla side so at least one other UA will be active. I do not know
the state of Edge and Webkit.

If the  UAs have the ability to resource the time and energy to fix
implementation bugs that effect the spec - and if we can make those bug
fixes, then the WG don't need to excise anything from the spec to make
it conformant to implementations. If they don't, then we have no choice
but to remove non-interoperable parts of the spec, but I do not believe
that is necessary *if* we can give one more push at fixing bugs and the
spec.

Since your contributions to the spec have been outstanding and you are
clearly central designer of the API, I hope you can stay involved in
whatever capacity you feel you can devote. Our optimal outcome is a spec
that is compliant with implementations, has activity so we know it will
done in a matter of months rather than years, and your active
involvement and approval.

          cheers,
                  harry


On 01/21/2016 06:56 PM, Ryan Sleevi wrote:
>
>
> On Thu, Jan 21, 2016 at 8:57 AM, GALINDO Virginie
> <Virginie.Galindo@gemalto.com <mailto:Virginie.Galindo@gemalto.com>>
> wrote:
>
>     Dear all,
>
>      
>
>     After the conversation between Harry and Ryan, completed by the
>     recent categorization of bugs done by Harry and clarified by Eric,
>     I understand the following :
>
>     -          Implementations of the web crypto seems to be still in
>     debug
>
>     -          UAs contributions to the web crypto WG does not seem to
>     be high priority (Mozilla mentioning next months, Google
>     mentioning reduced bandwidth)
>
>      
>
>     We have two paths to progress :
>
>     -          One :  we try to deliver something quick, gathering the
>     minimum core of interoperable features (but we will lose our
>     editor who is not supportive to this option) (Ryan, I let you
>     correct if I interpreted wrongly your emails). In that case we
>     answer the developers expectations to have a spec.
>
>     -          Two : we give us 5 to 6 months to let implementations
>     being debugged, UA discussing interoperable features and align the
>     Web Crypto API accordingly (we will have to find a way in W3C to
>     adapt the spec timeline, super-limit-chartering aspects, but I am
>     confident we will find a way). In that case we make developer
>     waiting but deliver a wider range of features.
>
>      
>
>     I would like to hear from the WG members preferred **strategy**
>     asap, so that we can analyze with W3C the best way to move forward.
>
>
> Virginie,
>
> I believe that regardless of the direction the WG takes (and I think
> Two is what we'd be supportive of, but I don't think there'd be
> support for One at all), I unfortunately need to step down as editor.
> Given far more pressing responsibilities, I simply don't have the
> time, or, unfortunately, the professional energy, to continue on as
> editor for the spec. That said, both I and the Chrome team remain
> committed to progressing on WebCrypto in implementation and within the
> working group, and are hoping to see other UAs take a more proactive
> role in helping find an interoperable, robust solution for users.
>
> While I think the spec is largely in a good place, there's definitely
> signs of interoperability issues and spec-compliance issues. While I
> think these issues are entirely surmountable, I think any proposal
> which requires excising entire features from the spec - as has been
> requested of KeyFormat and as suggested in One - means there are
> significant editorial commitments needed. Worse, if that's accepted as
> the standard for publication - minor misalignment causing major
> removals - then I think we'd find a similar large number of core
> features needing to be removed. The proposed resolution of that -
> creating two versions of the spec, one of which represents only the
> subset that is wholly implemented, and one of which represents both
> aspirational and mostly-implemented features - is just way, way too
> much work, and without other UAs to collaborate on this list and on
> the spec, is simply not a worthwhile use of time. Worse, with just a
> small amount of collaboration and work from other UAs, almost all of
> those changes would be made unnecessary.
>
> While I think Option Two is ideal, I don't know if it's realistically
> achievable without greater involvement by members and UAs. If that's
> the path the WG takes, we simply need greater involvement, as well as
> a focus on 'spec compliance' and not just 'rough interoperability,'
> which I do believe we have today. Do I think every UA needs to fully
> adhere to the spec in all of its nuance for us to ship to PR? No, of
> course not. But I think we at least need other UAs making commitments
> to either implement what the spec says (treating it as browser bugs),
> or clarifying if they object to the spec language or requirements, so
> that we can actively resolve these issues. Do I think everything in
> the spec is either necessary or correct? Probably not. But that's why
> feedback from other implementors is needed - given the diversity of
> approaches and goals, that sort of feedback is key. We need that
> consensus to be active - I don't think a "silence is assent," as has
> been proposed and executed for KeyFormat, really represents the best
> outcome, and seems rather arbitrary.
>
> But regardless of these positions, as I mentioned, I think the time
> commitment necessary for either position is, unfortunately, far
> greater than I can honestly make, and as such, need to step down as
> editor. Either option will require more hours-per-week of editorial
> work than I'm able to commit to, and I would rather not be the one
> holding the WG back from progressing. :)