We should talk next time we meet at IETF. This is something I've been working on for a very long time.
Most recently, I've been working on prototyping a similar thing leveraging an experimental feature in FedCM, called "IDP Registration", enabling an RP to use an arbitrary IDP rather than one from a fixed list like "Sign in with Google". FedCM solves the UX problem that has plagued adoption of "bring your own IDP" efforts like OpenID in the past. I have a blog post about this with a demo video and details on how to put together the various OAuth building blocks to make it happen: https://aaronparecki.com/2024/05/12/3/fedcm-for-indieauth There's also a handful of people who have spun up IDPs that support this with their own domain and trying out the FedCM feature, you can see all the details here: https://github.com/w3c-fedid/idp-registration/issues/2 Aaron On Tue, Jan 21, 2025 at 10:19 AM Phillip Hallam-Baker <ph...@hallambaker.com> wrote: > On Tue, Jan 21, 2025 at 12:30 PM Warren Parad <wpa...@rhosys.ch> wrote: > >> If I understand correctly, I don't like this at all. In the OAuth context >> you can already use (nay, must use) your DNS as the Issuer for these tokens >> and specify the appropriate user ID in the *sub *claim of the generated >> identity tokens. Given this is already possible, and realistically up to >> the AS Issue to determine which values to populate into the *sub. *The >> fact that the Subject claim should really be opaque to the resultant OAuth >> compatible application, I'm not really sure what is being requested here. >> >> Based on what you are saying, what existing standard needs to be created >> or changed to support this, because from my perspective, this is already >> the current state of the world, isn't it? >> > > Standards are what people actually use. > > Right now, I cannot go to a Web site and expect them to support use of my > DNS handle, even though almost all the infrastructure required to support > it already exists. > > IETF has been talking about decentralization, here is a mechanism that can > achieve it. And its not just the IETF. There are a lot of governments who > are rather upset at the walled-garden cartels and some have begun the > process of breaking them up. > > > Standards are not just about agreeing ways to do things, it is the process > of getting widespread agreement to use the same approach. > > As for the need for documentation, I am utterly unable to understand what > you are saying about checking the sub field and the > ATprotocol documentation on it is opaque at best. And a really good rule of > thumb in things security is that where the descriptions are unclear, there > are at best non-conforming deployments that have security vulnerabilities. > > I am highly skeptical of Passkeys because the 'documentation' they have > provided is mostly marketecture with pointers to documents that spend more > time defining unhelpful jargon than actually explaining anything. > > If this is to become a widely supported approach, we need a profile to > describe the particular way to go about it. What we have now is a stack of > specifications that have evolved over a period of 20 years designed to > support a slightly different objective. > > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
