Phillip,
Can you review the DANCE documents and see if they can satisfy your use
case?
https://datatracker.ietf.org/wg/dance/documents/
You could also start a thread on the DANCE wg mailing list.
At first glance, I can't see why the DANE TLS client auth protocol
described there could not accommodate Bluesky/AT protocol handles, but
perhaps you can do a deeper review. It might also be useful to describe the
use case in the DANCE architecture doc (which describes the set of other
use cases we had originally envisioned). This set of docs is currently in
working group last call.
Shumon.
On Wed, May 21, 2025 at 10:15 AM Phillip Hallam-Baker <[email protected]>
wrote:
> Thanks! I had forgotten about that spinning out. I was coming to this from
> the OAUTH frame and suddenly realized TLS client auth could be a better
> option.
>
> It certainly looks like DNS Handles makes that model look a lot clearer.
> The frame that we were given for Internet accounts is '[email protected]',
> the account being provided by an Internet service. OAUTH originally fit the
> same model only it is an account with an authentication service.
>
> @alice.example.com is a different frame in which Internet accounts are
> represented directly in the DNS. It is a model a lot of people have
> resisted but there are 35 million users already and growing.
>
>
> On Wed, May 21, 2025 at 8:57 AM Ben Schwartz <[email protected]> wrote:
>
>> This sounds a bit like draft-ietf-dance-client-auth.
>>
>> --Ben Schwartz
>> ------------------------------
>> *From:* Phillip Hallam-Baker <[email protected]>
>> *Sent:* Tuesday, May 20, 2025 10:44 PM
>> *To:* tls <[email protected]>
>> *Subject:* [TLS] Transparent TLS Client Auth (t2CA)
>>
>> 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
>> 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]
