RE: What we were using public key authentication for

Hello Tim
Virginie suggested me to answer to your request.
I would recommend 3)++
1. Setting up a central OpenID Connect IDP seems to be the good option for this use case (or even SAML2).
2. This IDP may use various methods to authenticate users:
  a) simple username/password
  b) after a successful a) auth, you may add a fancy protocol using webcrypto to skip password (your option 1) if I get it correctly)
  c) TLS client auth (using PKCS#11 + smart-card :) )
  d) FIDO U2F
  e) FIDO 2 in the longer term
  or any other auth method: OTP, SQRL https://www.grc.com/sqrl/sqrl.htm, Mobile ID...
Hope this helps
--
Olivier Potonniée

-----Original Message-----
From: Tim Berners-Lee [mailto:timbl@w3.org]
Sent: mercredi 23 mars 2016 23:08
To: GALINDO Virginie
Cc: Public TAG List
Subject: What we were using public key authentication for

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



________________________________
 This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

Received on Friday, 1 April 2016 13:22:55 UTC