As many of you probably know, we recently lost Kim Cameron, a giant in the identity and access space.
This caused me to rethink the reasons for the failure of Identicard, one of his most promising proposals. Identicard made using public key authentication easy, just pick the persona you want to authenticate under and click on the corresponding card. The main reason I think Identicard failed is that it didn't have an answer for the credential portability problem. Even in the mid '00s, using multiple devices was common. If I can't get to it from my phone AND my desktop AND my laptop AND my tablet, then it isn't going to work for me. But username/password does. So I have built a system that addresses the problem of key portability. Seems like we should maybe revisit TLS Client Auth and see if we can make that work in a 'Zero Effort' configuration. What I mean by that is even less effort than Infocards requires. TLS server auth requires no user input. The only user input required for client auth should be asking the user if they want to authenticate to the site. And that should be like 'accept cookies', one time and done (only giving the user more control on revoking that decision). Thanks to the Microsoft WebView2 team, I have my own experimental browser running so I can testbed an implementation here. What I need a bit of help on is understanding the API affordances of the legacy browser/server infrastructure because that is going to constrain what is practical. In theory, TLS client auth could use a non PKIX credential, in practice, that option closed decades ago. The client is going to have to present credentials to the service that are at least syntactically consistent with PKIX even if the credential itself is simply a wrapper around a SAML or JSON credential. TLS Client Authentication is inevitably going to require services to perform authorization. So we can treat parts of the PKIX spec with contempt bordering on grievous bodily harm. For example, to validate to a DNS issued credential al...@example.com 1) example.com creates a PKIX certificate signing key kp, hash hkp 2) example.com publishes an authorization statement for hkp in a DNS record in zone _hkp.example.com 3) example.com creates a cert signing cert for kp using the private key for 'DNS Trust' published in the specification At this point, example.com has successfully diverted the PKIX trust chain into a DNS trust chain. But even this is rather more than we need for most web applications. For those the questions are * Is this the same user who visited before? * Is this the same user who visited before from that particular device? * Is this the same user who visited from that device in the past 24 hours? For these the Web server can simply bind direct trust to a key. If we need binding to a persistent identity we can do this out of band on a completely different device. The service tells the browser which form of binding it will accept by specifying the pro-forma root certs. For example, Alice wants to check her portfolio from a mafia run coffee shop. The browser creates a new client cert chain for the session, splashes a connection code XYZPDQ on the screen. Alice gets a ping on her watch saying 'allow access by XYZPDQ'. Good enough for read only access but would really hope that any trading requires individual 2FA confirmation. So all in all, I think we can provide a really solid, really transparent user experience without any new protocol work. It will take changes to the browser to make this really work for the end user but a change to one part of the platform is plausible, changes to server and browser together require decades. I would expect initial interest would be limited to enterprise use where they can say 'you will use this browser to do your job'. What I have running is a C# wrapper around a captive copy of Microsoft Edge Canary so it is a (very) full feature browser and all the maintenance cost is offloaded. (Thanks to the Microsoft team).
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
