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

[Vladimir Dzhuvinov <[e-mail]>]

Hi Brian,

I'd like to propose the sentence in bold to be inserted into the current
section 2.3 of PAR -04:

https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-2.3

The authorization server returns an error response with the same format
as is specified for error responses from the token endpoint in
Section 5.2 of [RFC6749] using the appropriate error code from therein
or from Section 4.1.2.1 of [RFC6749]. *In those cases where Section
4.1.2.1 of [RFC6749] prohibits automatic redirection with an error back
to the requesting client and hence doesn’t define an error code, for
example when the request fails due to a missing, invalid, or mismatching
redirection URI, the “invalid_request” error code can be used as the
default error code.*

Hope with this we can close the case.

Vladimir

On 04/12/2020 18:08, Brian Campbell wrote:
>
>
> On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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.
>
>
> Following from the response I recently sent to Neil, I don't think a
> legitimate need has been articulated.
> https://mailarchive.ietf.org/arch/msg/oauth/gMiH1mTr0AKDvWpqO1zikcVUySY/
>  
>
>     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.
>
> I don't know that that's needed either. But do have some text to
> suggest that you think would be helpful?
>
>  
>
>     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
>>             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
>>             > _______________________________________________
>>             > 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
>>
>>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> /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./ 

-- 
Vladimir Dzhuvinov