[Bug 25985] WebCrypto should be inter-operable

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

--- Comment #22 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Boris Zbarsky from comment #20)
> Alright, let's try this again with crypto.  A user goes to a site to,
> hypothetically, see a movie whose watching involves crypto operations in
> some way (if there other obvious use cases that I should be considering
> here, I'd appreciate a pointer; I'm told the movie use case does exist,
> though). 

For sake of discussion, it might be better to focus on an authentication
service (IdP / RP), whose security goals are a bit less nebulous.

> So the site will instead provide an actionable error message.  Chances are,
> something like "You must be using Microsoft Internet Explorer 10.0 and
> Windows 7" to use this site (with possibly a different browser name/version
> and different OS name/version, and maybe with a short list instead of a
> single entry, but this will be the gist). 

Up until a few weeks ago, this is the same thing that a site that wished to use
WebGL on certain major platforms would do, where, despite being "standard", is
not implemented by a particular UA. And the user can do nothing but switch UAs.

> the other case the user grabs their tablet because it's
> got the blessed operating system and browser version on it. 

A site that wishes to restrict it's users to "the blessed operating system and
browser version" on it has plenty of other ways to do this. If that is your
thread, you should be far more worried about
http://www.w3.org/TR/2013/WD-webcrypto-key-discovery-20130108/ , which embodies
that ability cryptographically.

So let's set aside a moment the 'hostile streaming provider' (which is
certainly reasonable, though hopefully rare).

Your more common case is going to be your site operator that is wishing to use
WebCrypto to offer some extended functionality. It might be handling OpenID
Connect messages (which use JWT) within the UA, using WebCrypto to handle the
JOSE interaction, with multiple iframes and postMessage to handle the identity
provider/relying party communication.

They might allow a system of "sign in with just your email", but only if they
detect the user agent supports their desired cryptographic profile. They might
hide it from the user, or they might allow the user to try, run a check for
support, and then decide that the feature is not accessible.

They can say *whatever* they want when it's not available, and whether it
recommends the user to get a new UA, to file a bug with their existing UA, to
write their congresscritter/representative/MP, it's up to the site.

However, from the point of the output of this WG, they know that every UA
*COULD* implement a given algorithm, and every UA that *DOES* implement an
algorithm will at least implement it to the conforming shape and size. The last
thing you want is your signatures to be unreadable in every UA but the one
you're using - which is a real risk, judging by historical APIs.

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

Received on Thursday, 5 June 2014 16:44:42 UTC