Re: [OAUTH-WG] PAR error for redirect URI?

[Vladimir Dzhuvinov <[e-mail]>]

If people have articulated a need to have an invalid_redirect_uri error
for the PAR endpoint, then let's register it properly. Rifaat says
there's still time to do this.

I'm also okay with using the general invalid_request code for this. In
this case a sentence, next to the current example, spelling out what the
PAR endpoint must do on a invalid redirect URI will help.

Vladimir

On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote:
> Torsten, Filip,
>
> You can absolutely make this change, as we are still very early in the
> process. 
> So feel free to continue this effort and try to get WG agreement on
> this, and update the document as needed. 
>
> Regards,
>  Rifaat
>
>
> On Thursday, December 3, 2020, Filip Skokan <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     To be clear, I'm not advocating to skip the registration, just
>     wanted to mention a potential concern. If the process allows it
>     and it will not introduce more delay to publication, I think we
>     should go ahead and register the error code.
>
>     Best,
>     *Filip*
>
>
>     On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt
>     <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>         > Am 03.12.2020 um 09:56 schrieb Filip Skokan
>         <[e-mail] <mailto:[e-mail]>>:
>         >
>         > There are several documents already mentioning
>         "invalid_redirect_uri" as an error code, specifically RFC7519
>         and OpenID Connect Dynamic Client Registration 1.0. But these
>         don't register it in the IANA OAuth Extensions Error Registry,
>         presumably because they're neither for the authorization or
>         token endpoints.
>         >
>         > While I think it'd be great if we had this error code
>         registered, I also worry that its registration could confuse
>         implementers to think it's okay to return it from the
>         authorization endpoint.
>
>         I understand your concern. On the other hand, registering the
>         error code is in my opinion the proper way forward. The
>         registration is scoped to a usage location, should be pushed
>         authorization endpoint then, and RFC6749 gives clear guidance
>         on how to treat errors related to the redirect URI at the
>         authorization endpoint.
>
>         "If the request fails due to a missing, invalid, or mismatching
>            redirection URI, … authorization server ... MUST NOT
>         automatically redirect the user-agent to the
>            invalid redirection URI."
>
>         I think if an implementor ignores this, it will ignore any advise.
>
>         best regards,
>         Torsten.
>
>         >
>         > Best,
>         > Filip
>         >
>         >
>         > On Thu, 3 Dec 2020 at 00:29, Brian Campbell
>         <bcampbell=[e-mail]
>         <mailto:[e-mail]>> wrote:
>         > During the course of a recent OIDF FAPI WG discussion (the
>         FAPI profiles use PAR for authz requests) on this issue it was
>         noted that there's no specific error code for problems with
>         the redirect_uri (the example in
>         https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3
>         <https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3>
>         even shows a general error code with mention of the
>         redirect_uri not being valid in the error description). Some
>         folks on that call thought it would be worthwhile to have a
>         more specific error code for an invalid redirect_uri and I
>         reluctantly took an action item to raise the issue here. At
>         the time I'd forgotten that PAR had already passed WGLC. But
>         it's been sitting idle while awaiting the shepherd writeup
>         since mid September so it's maybe realistic to think the
>         window for a small change is still open.
>         >
>         > Presumably nothing like an "invalid_redirect_uri" error code
>         was defined in RFC 6749 because that class of errors could not
>         be returned to the client via redirection. But the data flow
>         in PAR would allow for a "invalid_redirect_uri" so it's not an
>         unreasonable thing to do.
>         >
>         > As I write this message, however, I'm not personally
>         convinced that it's worth making a change to PAR at this
>         point. But I did say I'd bring the question up in the WG list
>         and I'm just trying to be true to my word. So here it is.
>         Please weigh in, if you have opinions on the matter.
>         >
>         >
>         >
>         > CONFIDENTIALITY NOTICE: This email may contain confidential
>         and privileged material for the sole use of the intended
>         recipient(s). Any review, use, distribution or disclosure by
>         others is strictly prohibited.  If you have received this
>         communication in error, please notify the sender immediately
>         by e-mail and delete the message and any file attachments from
>         your computer. Thank
>         you._______________________________________________
>         > OAuth mailing list
>         > [e-mail] <mailto:[e-mail]>
>         > https://www.ietf.org/mailman/listinfo/oauth
>         <https://www.ietf.org/mailman/listinfo/oauth>
>         > _______________________________________________
>         > OAuth mailing list
>         > [e-mail] <mailto:[e-mail]>
>         >
>         https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A
>         <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A>
>
>