Re: Relevant IETF 121 Sessions: OAuth, DNS

I'm a big fan of the client ID metadata document spec and the way it solves
many to many OAuth in a very simple and practical way that makes server
administration easier. Are there any ways to speak in support of the spec
remotely?

On Sun, Nov 3, 2024, 11:07 AM Bryan Newbold <bryan@blueskyweb.xyz> wrote:

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