Re: Relevant IETF 121 Sessions: OAuth, DNS

Hey Bryan,

Great to see you on the mailing list!

Thanks for the information about the DNSOP WG sessions, I would've missed those otherwise!

Small correction to the OAuth Sessions link: https://datatracker.ietf.org/doc/agenda-121-oauth/

Correct, OAuth Client ID Metadata Documents were designed to address the problem in the Fediverse with requiring OAuth Client Registration ahead of authorization. For instance, one server I have data from has 40,000-ish people using it, but 465,000 registered OAuth applications. Most of these applications are a 1:1 mapping to an access token as well. Obviously managing 465,000 OAuth Applications isn't feasible, and a lot of this comes down to the client needing to  generate a new registration for each install because it needs a Client ID (and in Mastodon, currently a Client Secret, because we don't yet support Public Clients, only Confidential Clients, despite majority of clients actually classifying as Public Clients).

This internet draft came out of a call Aaron and myself had in the middle of May 2024, where we wanted to figure out "what are the blockers to getting FedCM / IndieAuth implemented in Mastodon?". We came to the conclusion that a major problem was the need to pre-register clients with the OAuth Authorization Server, where instead of having a 1 to Many relationship, as is common in OAuth, in the Fediverse we have a Many to Many relationship between Authorization Servers and Clients.

The Solid Project, which I previously worked on, had a similar problem. They solved it with an extension to their OIDC implementation called Solid Client Identifiers / Client ID Documents (https://solidproject.org/TR/oidc#clientids), however we couldn't just use that directly since it required JSON-LD and was in the scope of the Solid specifications. 

We had to lift it up to the scope of the IETF OAuth WG, whilst maintaining backwards compatibility with Solid's specification and implementations (that's why we allow unknown keys in the Client ID Metadata Documents, specifically to allow for @context in Solid's implementation).

You can read more about the history of OAuth Client ID Metadata Documents here: https://medium.com/@thisismissem/introducing-oauth-client-id-metadata-documents-a347b538e21c

— Emelia Smith

> On 31 Oct 2024, at 21:45, Bryan Newbold <bryan@blueskyweb.xyz> wrote:
> 
> Hi Folks!
> 
> I've been a lurker here on the list for a bit, but never introduced myself. I'm Bryan Newbold, I work at Bluesky on the AT Protocol ("atproto"). I previously worked at the Internet Archive, and was involved with the dweb events they have organized over the years, and contributed to the dat protocol. I'm using my work email here for convenience, but can also be reached at my personal email bnewbold@robocracy.org <mailto:bnewbold@robocracy.org>.
> 
> I wanted to cross-pollinate a couple sessions next week at the IETF which might be of interest to folks here, around auth and identity systems. I hope this is appropriate and in the spirit of coordination between standards groups. The complete agenda/schedule is at https://datatracker.ietf.org/meeting/121/agenda
> 
> The first are some OAuth sessions: https://datatracker.ietf.org/meeting/121/materials/agenda-121-dnsop-01
> 
> Aaron Pareki will be presenting updates to the "OAuth Client ID Metadata Document" draft (https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/). Emelia Smith is a co-author and I believe this work originally came out of plans and ideas for client/server OAuth in the ActivityPub ecosystem. We ended up adopting this draft for the atproto OAuth profile.
> 
> There is also a session on "OAuth 2.1" which might be relevant to the overall direction of the OAuth ecosystem.
> 
> The second are some sessions in the DNSOP working group: https://datatracker.ietf.org/meeting/121/materials/agenda-121-dnsop-01
> 
> My co-authors and I will be presenting on "Integration of DNS Domain Names into Application Environments" (https://datatracker.ietf.org/doc/draft-sheth-dns-integration/). This touches on using domain names as "handles" in social applications. We also had a session at the recent W3C TPAC on this topic (https://www.w3.org/events/meetings/4063788d-6e26-4d19-8898-d7ceb448fca9/), which I probably should have mentioned on this list ahead of time.
> 
> There is also a related draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/) around the mechanics of how to verify associations between a domain and account or service.
> 
> --bryan
> https://social.coop/@bnewbold