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
