Emelia,
> On Oct 11, 2025, at 6:39 PM, Emelia S.
> <[email protected]> wrote:
>
> 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
>
OK, let's see how things go but if the same-origin restrictions are "popular"
wouldn't it be good to have some sort of metadata to let a client know what
kind of restrictions are being enforced? (for example,
"client_id_metadata_redirect_uris_supported" string with "any", "same-origin",
"same-native"?)
>> 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.
There is that, of course, but when the AS supports Client ID Metadata Documents
we also have:
1. The client ID URL isn't accessible (host down, expired cert, or some other
issue that prevents the AS from accessing the metadata); "server_error" or
"temporarily_unavailable" seem appropriate.
2. The metadata contains something that the AS doesn't like, say the
redirect_uris values, or is missing required values; maybe
"unauthorized_client" or "access_denied", but there are errors that could be
borrowed from Dynamic Client Registration ("invalid_client_metadata" in
particular) to make this more clear?
3. The AS admin or the user authorizing access has decided they don't want to
allow that client; again maybe "unauthorized_client" or "access_denied"?
I'm asking both from a "generic OAuth client" implementor perspective (CUPS)
and as an OAuth Authorization Server implementor (mOAuth) who it trying to give
printer vendors a more modern way to authorize access vs. Kerberos or
Basic/Digest authentication that also isn't tied to a single vendor...
________________________
Michael Sweet
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
