Re: What we were using public key authentication for

On 2016-03-24 06:58, Martin Thomson wrote:
> On 24 March 2016 at 09:08, Tim Berners-Lee <timbl@w3.org> wrote:
>> So can we get this functionality using web crypto in the short term?
>
> The answer is yes, though it requires some work on the part of the
> entity hosting the "user's public ID".  Other origins would have to
> ask it for permission to read the identity (the public key), probably
> using CORS, and they would also have to ask it (or a JS proxy it runs,
> probably in a service worker, maybe with foreign fetch) to sign things
> with that key to prove that the "user" really wants to authenticate.

Luckily for us users, both the payment industry and the eID networks have
found a faster a more user-friendly way to get things going which is using
mobile "Apps".


> UX here is the interesting part.  You could use notifications from the
> SW to get users to interact with the ID-provider origin in order to
> grant permission to authenticate and that sort of thing.  This looks a
> like like OAuth, which isn't a coincidence.
>
> And the browser is not involved.  Not fundamentally.  That the keys
> are on the browser, and the browser only, is something between the
> user and the ID-provider.  You might argue that's a bad thing, but
> that's how I understand modern web identity to work.  Take away all
> the fancy new stuff and fancy interfaces and you essentially have the
> systems that all the big identity providers have been using for years.

Yes, unfortunately this only works satisfactory if the number of IdPs for the
actual use case is very small which is not how things were envisioned during
the OpenID heydays.

Anyway, this is as I have written an already "solved" issue.  What's worse is
that there are new things on the W3C agenda that haven't been dealt with in a
constructive manner which most likely will cause major headaches in the future:
https://github.com/w3c/browser-payment-api/issues/50

Anders

Received on Thursday, 24 March 2016 07:03:24 UTC