A few observations here. I generally agree that a signature-based scheme has superior privacy properties to something like OAuth, though the details really matter here. For example, if the system requires having a TXT record at the leaf node (e.g., ekr.<something>.gmail.com) then the end result is similar because the DNS server will get a query from the relying party for your specific identity, allowing the server to track you [0]
>From a technical perspective, I think the bigger picture question is whether TLS is the right layer for this. As you know, TLS supports certificate-based client authentication, but that has largely been deprecated, even for cryptographic authentication, in favor of application layer solutions like WebAuthn or Passkeys. There are are a number of reasons for this, including: * Allowing the site to control the timing of the authentication (e.g., offering you connect unauthenticated and then upgrading). * Allowing the site to offer multiple authentication options. * Allowing the site to control the look and feel of the interaction. I'm aware that there are mechanisms to make this work inside of TLS but they require close coordination between the application, HTTP, and TLS, whereas solutions like WebAuthn do not. >From a deployment perspective, we have very wide deployment of OAuth based authentication and both IdPs and RPs are comfortable with that. Deploying something like this would require them all to change as well as a fair amount of work by the browser vendors. Previous attempts to deploy other signature-based federated ID systems (e.g., BrowserId/Persona) have foundered due to lack of deployment interest, so I think an important question to ask here is whether there is real interest from a critical mass of the relevant parties. -Ekr [0] I'm leaving for later the question of whether DNS is the right approach here, compared to approaches like having the signing key in /.well-known. On Tue, May 20, 2025 at 7:45 PM Phillip Hallam-Baker <[email protected]> wrote: > I have floated parts of this scheme in OAUTH and DANE. > > As we all know, TLS does Client auth in theory but the implementations are > unusable for two reasons: > > 1) Issue of client side certs is a pain > 2) The user interface asking the user to select a certificate. > > Both problems could potentially be addressed by the emerging DNS handles > infrastructure. At present, the authentication is OAUTH2 based. But TLS > Client Authentication under a certificate validated under the DNS handle > would be cleaner. > > So, I am looking for people interested in a side meeting in Madrid. > > Here is my current sketch: > > User gets handle from DNS Handle provider who (usually) also runs an > OAUTH2 service under the ATprotocol profile and a private CA for the user. > > The root of the private CA is bound to the DNS zone by a TXT or TLSA > record. > > Each device the user wants to use with their DNS handle gets issued its > own client cert. > > Users can have multiple personas and the browser selects the certificate > the user has assigned to the site asking for authentication. > > > Net is that the user gets to authenticate to any site (supporting T2CA) > under the DNS Handle and persona they have selected for their site without > any additional hassle. > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
