Re: Relevant IETF 121 Sessions: OAuth, DNS

Thanks nightpool!

The easiest way to speak in support of the spec is to email the OAuth
mailing list with a note along the lines of "I read the spec and this will
solve my problems because ____" and if you are implementing it or have
plans to implement it, that's worth mentioning too.

The more involved option is to join the working group meeting on Tuesday.
Remote participation is very good at the IETF meetings, and you can request
a fee waiver (which will be automatically granted) to avoid paying the
remote attendee fee: https://www.ietf.org/meeting/registration-fee-waivers/
During the meeting, you can ask questions or just make a similar statement
in support of the draft.

Thanks!

Aaron



On Sun, Nov 3, 2024 at 9:31 PM nightpool <eg1290@gmail.com> wrote:

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