Re: State of the WebCrypto API

> On 12 Oct 2015, at 13:51, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
> On 2015-10-12 13:53, henry.story@bblfish.net wrote:
> <snip>
>> 
>> Anders can you please try to be more positive and constructive about your posts.
> 
> I consider it constructive asking prospective members of pre-announced WGs to provide
> input specifications *before* actually starting in order to not repeat the problems we saw in:
> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop
> 
> I believe Ryan Sleevi have said something similar as well.

That's not exactly what you did in your post which started this thread.
https://lists.w3.org/Archives/Public/public-web-security/2015Oct/0017.html

Now I do agree that WebCrypto has been used in various places as a panacea,
and that it is not the "'final solution' to client-side crypto for the Web".
There are a few of other features needed. But that seems clear to the WebAppSec
WG since they are proposing a lot of other complementary specs there.

Discussions are like chess or Go. You can't make a point or advance
the debate in any way you want. Here you are just making an opening that 
is putting you into check mate position from the get go.

>> 
>> Is it not obvious here that one can use a Shim, and that older browsers never are
>> retrofittted with newer standards?
> 
> IE 11 is Microsoft's most recent browser for their currently largest installed base of Windows.
> Why does it still require a workaround?  Probably because there's limited demand for WebCrypto.

It does not actually matter since there is a shim. WebCrypto as I understand is
just a library. Having it built into the browser would make certain operations 
faster. 

I suppose it could also be used by folks in the server space such
as Node.js . Have you considered that field? 

A lot of standards take a long time before they get used, and often
they get used in ways that are completely different from the intended ones.

>> 
>> I agree with Tony that this looks very much like trolling, much like many
>> of your posts to  the WebID Community Group [1].
> 
> My postings in the WebID CG has only been about HTTPS Client Cert Authentication used by WebID-TLS.
> You need no particular knowledge of linked data and RDF on *that* level.

TLS is only one authentication scheme for WebID. It's the one that has been available in a large number of browsers for some time, and was built into the browser chrome, so it had a 
distinct advantage. 

But the WebID logic does not require TLS. We can do something similar with WebCrypto,
and plain HTTP. I am just implementing this
   https://tools.ietf.org/html/draft-cavage-http-signatures-04
right now to see how far that gets one.

You would understand that WebID-TLS is just one way of doing WebID authentication, if you actually had worked with LinkedData. Otherwise you are missing the most important part
of the picture. And if you continuously miss one part of the picture but 
continue to want to participate in a debate, then it comes across very badly.

> 
> Anyway, as we know, HTTPS Client Certificate Authentication is slowly but surely leaving the browser world
> (Microsoft "Edge" already removed web-enrollment), so these discussions are only of historical interest.

Actually what is being removed is the keygen feature, for the wrong reasons I believe.

But that does not mean that server to server TLS auth is still out... 
It will also be interesting to see how all this pans out with the Quic protocol...

Anyway, I'am programming a demo with WebCrypto, so then I'll be able to have
actual real feedback of problems encountered doing so. 

> 
> Anders

Received on Monday, 12 October 2015 14:43:12 UTC