Re: Relevant IETF 121 Sessions: OAuth, DNS

Thanks for the additional context Emilia! There's one more piece of
relevant background.

We've had essentially client ID metadata documents since at least 2018, as
described in the W3C IndieAuth Note published by the social web working
group:

https://www.w3.org/TR/indieauth/#client-information-discovery

This mechanism provided the metadata in HTML, where consumers could get a
JSON version by parsing the page with a Microformats parser. This has been
in use since at least 2018. But one of the things that has become apparent
in recent years is that more and more of this client metadata is actually
for machine consumption rather than human consumption, so would be better
off published in a machine-readable-first format like JSON.

The latest version of IndieAuth now references the IETF draft:
https://indieauth.spec.indieweb.org/#client-information-discovery

This change was driven by a combination of wanting to standardize this
discovery method across all the systems that have the same relationships
(IndieWeb apps, ATProto apps, Mastodon/ActivityPub, etc), as well as
wanting to use these OAuth extensions with FedCM to get a better user
experience.

Looking forward to talking with whoever is in Dublin for the IETF meetings
this week!

Aaron



On Sun, Nov 3, 2024 at 6:30 PM Emelia S. <emelia@brandedcode.com> wrote:

> 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.
>
> 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
>
>
>