Re: WebCrypto edits on key material (Option 2)

On 01/18/2016 07:33 PM, Ryan Sleevi wrote:
>
>
> On Jan 18, 2016 3:36 PM, "Harry Halpin" <hhalpin@w3.org
> <mailto:hhalpin@w3.org>> wrote:
> >
> >
>
> > New features that need interop that aren't in the CR version of the
> spec just go into WebCrypto 1.1, which I'm happy to recharter - but we
> have to show we have some success with WebCrypto 1.0  I'd like that to
> happen.
>
> And I do not believe for a second we can reasonably argue we have had
> success. Perhaps this is the cause for the disconnect - you are
> unaware of or unwilling to recognize the significance of the issues.
>

I'm not saying success is 100%, but we have run out of time on this
version and need to document interop or lack thereof. However, we also
need to keep a 'living spec' - and my goal is to make sure we both have
a 'living spec' that we can keep updating and fulfil W3C process
requirements. This is not impossible, it's what most WGs do rather than
keep specs in CR forever.
>
> > You need to scope the parts you don't think are interoperable. In
> particular, non-JOSE key formats and Workers have been brought up. Do
> you have anything else in mind?
>
> Harry, since you have repeatedly (and continue to) suggest it is easy
> to spec the interoperable bits, perhaps you should make an effort. You
> will, for example, find the lack of interoperability for ECC. Or
> discover the lack of interoperability forhandling of BigIntegers or
> JWKs, which, by your logic, necessitates removing all key import and
> export for asymmetric keys.
>
> I am not going to engage with you on a point by point matter of
> compatibility issues, because you have consistently refused to
> acknowledge the systemic issues at play here. You cannot reasonably or
> in good faith suggest the WG is in a state to progress to PR, given
> the challenges for the past few months, nor can you argue reasonably
> that the WG should be rechartered given the lack of involvement. This
> should be painfully obvious, and it is somewhat frustrating that you
> consistently ignore these issues and attempt to reduce them into
> something that fits your goals.
>

It's not my goals, it's the W3C charter that we all explicitly agreed to.

The obvious way forward is to open, for each interop problem you mention
and any others that are discovered, a bug. Then we can tackle them and
(cross fingers) UAs can re-engage.  So, why not re-open bugs for these
issues?

 If they can't be tackled, then they features have to be removed.
Hopefully that will motivate UA vendors to fix issues. Indeed, the most
accurate way forward is probably to call out each interop bug and then
document each problem, and if the problem cannot be resolved for
whatever reason (including UAs simply not prioritizing WebCrypto),
remove or call out the problem in the spec.

> >  However, if we continue with the current state of affairs (i.e. no
> further UA progress), then the Working Group will expire at end t arof
> March and we'll be stuck with an out of date spec with features that
> are non-interoperable, and the charter will not be renewed for further
> work. That's probably the worst of all worlds :(
> >
>
> I disagree. That's the most honest and accurate of worlds, and
> reflects what UAs are currently willing to commit to. If what is
> pushed out in PR fails to reflect the status of what is implemented
> (however incompatible) and fails to reflect the direction (if any),
> then it is even worse than no spec.
>
So, you seem to be stating that you want the Working Group to close with
no further progress being made. I hope that is not the case. I also
doubt you are arguing that a spec that is effectively unmaintained and
that doesn't reflect existing implementations is the best for developers. 

I am suggesting that we can get the best of both worlds. We can have a
new charter with a reasonable time-frame of 2-3 years that lets UA
vendors keep working on resolving bugs, and then by end of March
*explicitly* call out each interop bug and if needed, remove features.

Thus, one way forward could be to fork the spec. For example, we could
have a PR->Rec version called WebCrypto 1.0 that calls out the
incompatibilities so at least developers know what parts they can rely
on and which ones and then charter WebCrypto 1.1 that keeps a 'living
spec' for the next few years.  What do you think?

   cheers,
         harry