[Bug 25985] WebCrypto should be inter-operable

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

Harry Halpin <hhalpin@w3.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hhalpin@w3.org

--- Comment #32 from Harry Halpin <hhalpin@w3.org> ---
(In reply to Ryan Sleevi from comment #31)
> (In reply to Web Cryptography Working Group from comment #27)
> > The NIST curves are  widely deployed. Nonetheless, there is also demand for
> > Curve25519. Ultimately, while browsers often do have local policy they have
> > to deal with, the W3C needs to have an test-suite to prove interoperability
> > over the API. We should test every algorithm that is listed as registered. 
> > I see no reason why not to register Curve25519 given the demand and given
> > that it can be specified, and if browsers don't implement it, that will show
> > up in the CR test-suite report. The CR test-suite report for browsers, which
> > will depend on underlying libraries, will then demonstrate from the
> > interopeability that developers can expect and rely on.  
> 
> The support for Curve25519 is a separate bug. Let's keep it that way. If you
> want to talk about lack of interoperability, specification, or maturity,
> that's a great one to focus on exactly why we should not be including it in
> Web Crypto.

The point is that while interoperabiloty is difficult due to dependency on the
OS level, interoperability for WebCrypto will likely be more difficult than
other APIs (due to reasons mentioned by Ryan), and so it's hard to specify a
priori requirements for "just browsers". Nonetheless, the test-suite *should*
test every registered algorithm across browser and OS combinations to determine
what the level of *actual implemented* interoperability actually is. We are
hoping the "suggested for implementation" algorithms will be implemented
uniformly and so deliver interoperability, but again - we won't know till we
get the test-suite. 

So I suggest we revisit this bug in detail after we get into CR, but that we
add some clarifying text to the next Editor's Draft about the relationship of
suggested implementation to interoperability in 18.2, namely that while there
are no strictly required algorithms in this draft, we will report any
interoperable algorithms in the test-suite. 

Curve22519 was used as an example of an algorithm with real use-cases and
actual demand from developers that can be registered (although it does lack a
proper IETF RFC etc.) but may likely not be implemented by browsers, but
nonetheless should likely be registered and tested. That being said, I can't
see the "it's unlikely to be implemented" as a good argument until we actually
register it and then test the interop to provie it isn't implemented. There is
a large class of such algorithms.

We're likely going to have to revisit the whole
registered/suggestion(recommended) distinction after CR and what stays in the
spec and test-suite and what just is listed in a wiki. I'd like concrete
suggestions on how that process should work. 

For example, options could be:

1) Any algorithm which can be specified should be tested. 
2) Any algorithm which has one (or two?) implementation should be in final test
suite.
4) Only algorithms that work across all major implementation/OS combinations
should be "suggested for implementation" in spec.

There's lots of variance possible here. I feel personally we just need to make
progress on test-suite and then revisit these questions of interoperability,
but we do need a good rule on what we are going to test. So far, it seems like
we're going to test everything registered by the time we move to CR. 



[1]
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithms

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 11 June 2014 09:39:05 UTC