Re: WebCrypto edits on key material (Option 2)

On Mon, Jan 18, 2016 at 11:37 AM, Harry Halpin <hhalpin@w3.org> wrote:

>
> Again, if you are willing to put in this work and give the W3C a timeline,
> we're happy to work with that updated timeline. The preference would be to
> have the spec ready for another PR by end of the current charter (i.e.
> which ends end of March 2016),
>
> How long do you think it will take you?
>
> Again, I think MarkW is willing to help. However, if we aren't hearing
> back from other UA implementers, we just have safely assume they  will not
> change their underlying implementation, so the spec needs to reflect
> features that have two or more vendors support. That does include most of
> the core of the spec and quite a few of algorithms, as listed earlier,
> although not the key import/export/generation outside JOSE.
>

If that is the case, I will not be able to make those edits and will need
to resign as editor.

There is no point wasting my or my employers time on a spec that has zero
traction from other UAs. If this issue can't be resolved, the spec needs to
die - not the W3C try to save face by pushing an immature and
non-interoperable spec to PR in order to satisfy the powers that be.

If we are to restrict it to simply what is interoperable, you will find
that what exists is so minimal as to be pointless, and the spec ambiguities
so large as to be something that we could not, in good faith, support,
precisely because it leaves too many non-interoperable solutions.

Simply waving away and saying "unspecified" doesn't make a spec
interoperable - it just makes a bad spec.


> That is currently how it works, as this point was discussed with the
> Director re WebCrypto in particular.
>

In that case, we cannot count Safari towards an interoperable
implementation, ergo we do not have any, ergo the spec should die.

I hope you can see the very clear logical fallacy that you cannot count
Safari's implementation towards interoperability while simultaneously
dismissing its bugs as not relevant. The two are mutually exclusive for any
logical semblance of operation.