*The problem:* Yet again, tried to log into GitHub with Passkeys, yet again, can't because the servers aren't talking. And that isn't the only place Passkeys is failing me, point being if Microsoft can't get it working between my devices, I don't expect any other service provider to have a workable solution.
This is not a me problem, if I can't get this stuff to work, you can be sure as heck, I am not the only one. Any replacement for passwords has to be 99.9999999% reliable and this system as experienced by real people isn't fit for prime time. And given the way it is put together with multiple client providers and multiple services all using slightly different profiles, I cannot see this ever working unless the architecture is radically changed. Sure, someone might be able to give me a fix for my problem here, but that isn't the issue, the issue is the millions of people who gave Passkeys exactly one try, find it doesn't work and resolved to never use it again, ever. *The solution:* The core of the solution is to use a modern profile of OAUTH2 that supports a true open service model. So now, instead of having to deploy passkeys across the Web, Passkeys becomes one option the user can use to authenticate to their authentication provider should they choose to use it. [Yeah, I know the 'we only do authorization' theory, OAUTH is both, deal with it.] This gets us to a practical model for eliminating passwords, a model that the smart password vault providers could build on. After all, what they really provide is an easy way to use one account across multiple services. Running an OAUTH server is an incremental change for them. There are two password problems: 1) Using passwords at all 2) Presenting passwords for verification at a hundred sites. OAUTH solves the second. It does not solve the first but it does make it more tractable. Let's say I choose VeraVPN as my authentication provider. Getting Passkeys to work between my watch, phone and the browsers on my three principal browsing devices is a much more tractable problem than getting my six devices to work across a hundred Web sites. My broker is probably not going to rely on VeraVPN as a sole authentication source. They already make use of the biometrics in my iPhone to authenticate important transactions like trading or adding payees. But they might allow it as a means of authenticating to view account details. *The constraint:* There is one very important constraint here which is that the OpenID model of you can use your Google/Facebook/Apple account anywhere isn't acceptable if we are going to tell people the entire Web now belongs to three tech companies. Blue Sky has almost solved that problem with their DNS handles. If VeraVPN is going to be my authentication provider, it can provide me with a DNS handle, or handles even. The notion that I want to isolate my interactions across the Web misses what I really want. I don't want my professional profile and my dalek building profiles to crossover. But I do want my dalek building persona to cover my interactions on Project Dalek and The RPF. So the handles VeraVPN is managing for me might be @phill.hallambaker.com and @salvador.veravpn.com. The first being a very public persona, the second being a private, pseudonymous persona. I'll get back to that. *The essential change* The ATprotocol implementation of DNS Handles has a major flaw as far as this application goes in that it relies on a new PLC registry mapping DIDs to OAUTH providers. This makes the PLC registry a control point for the whole system and that is not acceptable. The solution to this problem is to rewrite the mechanism binding a DNS Handle to the OAUTH server for the account to specify the DNS name of the OAUTH service and a public key fingerprint under which some sort of assertion binding the handle to the service credentials can be validated. The PLC scheme is almost there, just have to rejigger some stuff. *Browser experience.* This approach provides for a potential new browser experience in which the browser is configured with my six personas which for the sake of simplicity are all serviced by the same service provider. The browser world is about to go through some big changes and I can see a business model enabling a change of this type. Each day I log into my accounts exactly once using a strong mechanism built directly into the browser chrome. This might involve using my phone for biometric auth or a callback on my watch. We can do a pretty good 2FA or even a 3FA if it is only once a day. Whenever I visit a site, the browser automatically picks the persona I have assigned to it. LinkedIn will always be @phill.hallambaker.com, Project Dalek will always be @salvador.veravpn.com. And if I am looking for the best possible separation of concerns, the browser might route the important dalek related stuff over a separate VPN (hence the reason for picking that as an example instead of PercyPass). This isn't hard to do with some recourse to Bloom filters. OK, as for the business model. Let's say we get the first part of the project done and there are password providers and VPN providers offering the basic DNS Handle service. If the incumbent browser providers don't offer a browser that meets their needs, they can form a club to finance development of a browser (or browsers) that do meet their needs. They might be built on Chrome or Firefox or even Ladybird. And if that is in place, we can move beyond the silly constraints the browsers put us in in the first place. Forget passkeys, just use TLS client auth to login and present a certificate binding the DNS Handle to the public key that is authenticated under a root key bound to the handle without the awful and unnecessary 'select certificate' dialog.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
