Hi Michael, Good questions!
> 1. What about PKCE/OpenID "native" authorization with a redirect URI of > "http://127.0.0.1/some/path";? There is discussion of "maybe the AS will > require same-origin URIs" but that would preclude native auth flows. Would be > nice to talk about it and, if optional, have some guidance about what the AS > does. Yeah, restrictions on redirect URIs leads to a lot of interesting problems, this is one of those, that's why we say it's possible to add restrictions, but may not be a good idea. PKCE is required in OAuth 2.1, so we haven't explicitly mentioned it: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html#name-compatibility-with-oauth-20 > 2. What is the error if a client_id using this scheme on the authorization > endpoint isn't acceptable? "unauthorized_client"? As in the AS doesn't support Client ID Metadata Documents? Then yes, the error would be "unauthorized_client" because the Authorization Server would not be able to find the client with the given client_id. This is why it's important to look at the Authorization Server Metadata (RFC 8414), since assumptions about Authorization Servers will lead to broken experiences for people. Yours, Emelia Smith > On 11 Oct 2025, at 21:43, Michael Sweet <[email protected]> > wrote: > > All, > > I finally had a chance to look through this latest (adopted) draft, and I > like the simplicity this brings over dynamic client registration. That said, > I have a couple quick comments/questions: > > 1. What about PKCE/OpenID "native" authorization with a redirect URI of > "http://127.0.0.1/some/path";? There is discussion of "maybe the AS will > require same-origin URIs" but that would preclude native auth flows. Would be > nice to talk about it and, if optional, have some guidance about what the AS > does. > > 2. What is the error if a client_id using this scheme on the authorization > endpoint isn't acceptable? "unauthorized_client"? > > Thanks to the AS metadata, I can see supporting this in the CUPS OAuth client > fairly quickly... > > ________________________ > Michael Sweet > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
