W3C home > Mailing lists > Public > www-tag@w3.org > March 2016

What we were using public key authentication for

From: Tim Berners-Lee <timbl@w3.org>
Date: Wed, 23 Mar 2016 18:08:12 -0400
Message-Id: <63BFCC95-193C-4264-9A8D-E326A06ED24D@w3.org>
Cc: Public TAG List <www-tag@w3.org>
To: GALINDO Virginie <Virginie.Galindo@gemalto.com>
Virginie

You asked at the AC lunch for me to describe what it was that we had been using  public key authentication for.

This is the system we have been using for someone to be able to identify themselves as the owner of a web page, like a blog.

- A user of a web browser runs a web app A
- The web app uses data stored in various different web sites B (Like health data, bank data, calendar, etc)
- The user has a global ID which is an https: URI which points to public info about them (or a persona) like their blog
- The access control on the data stores is set to allow access referring to that ID string
- The user accesses the data from within the webapp by using a private key which is stored securely on the device (or hardware gadget)
- The user’s public key is accessible only though unfakable "browser chrome"
- The cert is NOT signed by anything — it can be self signed. (the trust is from the public key being on the web)
- The public web home page for the user lists the corresponding public key publicly
- The client cert does contain the global ID URL

The essential characteristics of the system which the browser architecture seems to fight against:

- The whole point is to be have a public identity (like your W3C or github id) which can be to show you are the same person on multiple sites
- It isn’t just about logging onto different we sites, it is about accessing the same data you own on many sites B from many different sites A
- The signature on the cert is not part of the system, so the keychain won’t recognize the cert as “trusted”.  This does NOT use the PKI

We have been doing this using client certs, but the UI was unloved, the  keygen API weird and had bugs, browsers have had a war against client certs.  But the system worked!   Until keygen got turned off in Chrome and Firefox  a few days ago.

So can we get this functionality using web crypto in the short term?

Suppose we 
1) generate the keys in a web app using web crypo, store them in ephemal strage, and rejenerate them any time the use clears the key storage. Use them in a custom HTML form based auth session with the server in which we invent our own PK based authentication protocol.

2) genearte the keys using math, possibly web cryto with “exportable” keys, and download a .pem file to the user’s desktop.  Get the user to click on the .pem and go through the process of installing the cert on their site. Hope fingers crossed the browsers don’t just block the use of client certs at all!

3) Switch the while thing over to use openID-connect to connect people to some password-protected site?

If the Fido system will give us all we need by the end of this/next year, that will be great, but we need something now we can improvise say using  web crypto and JS.  

Best

Tim
Received on Wednesday, 23 March 2016 22:08:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 23 March 2016 22:08:15 UTC