Re: Relevant IETF 121 Sessions: OAuth, DNS

Thanks for the link correction Emelia!

Relevant to DIDs and DNS, I also just noticed an alternative "all dispatch"
session on DIDs in DNS ("High Assurance DIDs with DNS"). New to me,
recommends DNS URI records, and TLSA certificates:
https://datatracker.ietf.org/meeting/121/materials/agenda-121-alldispatch-04

--bryan

On Sun, Nov 3, 2024 at 10:30 AM 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
>
>
>