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

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Dec 2020 16:28:08 -0700

During the course of a recent OIDF FAPI WG discussion (the FAPI profiles
use PAR for authz requests) on this issue
<https://bitbucket.org/openid/fapi/issues/343/what-is-authenticity-and-integrity-of-the>
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._

---

From: Filip Skokan <[email-masked]>
Date: Thu, 3 Dec 2020 09:56:24 +0100

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.

Best,
*Filip*

On Thu, 3 Dec 2020 at 00:29, Brian Campbell <bcampbell=
[email-masked]> wrote:

> 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
> *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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 3 Dec 2020 11:06:36 +0100

> Am 03.12.2020 um 09:56 schrieb Filip Skokan <[email-masked]>:
> 
> 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=[email-masked]> 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
> [email-masked]
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A

---

From: Filip Skokan <[email-masked]>
Date: Thu, 3 Dec 2020 11:16:29 +0100

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 <[email-masked]>
wrote:

> > There are several documents already mentioning "invalid_redirect_uri" as
> an error code, specifically RFC7519 and OpenID Connect Dynamic Client
> 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.
>
> 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
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> your computer. Thank you._______________________________________________
> > OAuth mailing list
> > [email-masked]

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Thu, 3 Dec 2020 06:49:24 -0500

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 <[email-masked]> wrote:

>> > There are several documents already mentioning "invalid_redirect_uri"
>> as an error code, specifically RFC7519 and OpenID Connect Dynamic Client
>> > 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.
>>
>> > 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
>> > 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.
>> >
>> >
>> >
>> > https://www.google.com/url?q=https://www.ietf.org/mailman/li
>> stinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvV
>> aw3aW1gdv4EEiLmNYzlsJj-A
>>
>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 4 Dec 2020 09:29:45 +0200

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:
> 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 <[email-masked]
> <mailto:[email-masked]>> 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
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>         > Am 03.12.2020 um 09:56 schrieb Filip Skokan
>         <[email-masked] <mailto:[email-masked]>>:
>         >
>         > 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.
>
>            redirection URI, … authorization server ... MUST NOT
>         automatically redirect the user-agent to the
>         > On Thu, 3 Dec 2020 at 00:29, Brian Campbell
>         <bcampbell=[email-masked]
>         <mailto:[email-masked]>> 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
>         > [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/oauth>
>         > [email-masked] <mailto:[email-masked]>
>         >
>         <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A>
>
>

---

From: Neil Madden <[email-masked]>
Date: Fri, 4 Dec 2020 08:13:44 +0000

Making it a specific error code rather than just an error message suggests that the client can do something with that information. That doesn’t seem likely to me. It’s most likely caused by a misconfiguration that somebody needs to manually sort out rather than something that can be automatically corrected, so I don’t see a reason for this to get its own error code. 

— Neil

> On 2 Dec 2020, at 23:28, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> 

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Dec 2020 08:52:23 -0700

That's a good point. The context of the original discussion that led to
this thread wasn't about a client programmatically acting on the
information. Rather that banks (and similar entities) can be reluctant to
include additional info in descriptive error messages so having a specific
error code might help with the manual troubleshooting situation of problems
with the presented redirect URI. That rationale seems rather dubious.

On Fri, Dec 4, 2020 at 1:13 AM Neil Madden <[email-masked]>
wrote:

> Making it a specific error code rather than just an error message suggests
> that the client can do something with that information. That doesn’t seem
> likely to me. It’s most likely caused by a misconfiguration that somebody
> needs to manually sort out rather than something that can be automatically
> corrected, so I don’t see a reason for this to get its own error code.
>
> — Neil
>
> On 2 Dec 2020, at 23:28, Brian Campbell <bcampbell=

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Dec 2020 09:08:52 -0700

On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> 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/

> 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?

>>> example in

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 14 Dec 2020 10:33:39 +0200

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
> <[email-masked] <mailto:[email-masked]>> 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.
>
>
>     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
>
>>     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
>>
>>
>>         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*
>>
>>
>>             "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.
>>             >
>>             registered, I also worry that its registration could
>>             confuse implementers to think it's okay to return it from
>>             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.
>>
>>             > 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
>>             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
>>             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
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> 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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 14 Dec 2020 06:45:46 -0700

Thanks Vladimir, that seems quite reasonable. Barring any objections, I'll
add that to a -04.

On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov <[email-masked]>
wrote:

> 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.*
>
> On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov <
> [email-masked]> wrote:
>
>>> On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt <
>>> [email-masked]> wrote:
>>>
>>>>
>>>>
>>>> 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
> your computer. Thank you.*
>
> --
> Vladimir Dzhuvinov
>
>

---

From: Dave Tonge <[email-masked]>
Date: Mon, 14 Dec 2020 14:47:44 +0100

I agree with the proposed text

On Mon, 14 Dec 2020 at 14:46, Brian Campbell <bcampbell=
[email-masked]> wrote:

> On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov <
>> as is specified for error responses from the token endpoint in Section 5.2
>>>> 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
>>>>> "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.
>>>>> >

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 14 Dec 2020 06:54:18 -0700

er, I mean an -05

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 14 Dec 2020 16:41:15 +0100

+1 for following Vladimir’s proposal

> Am 14.12.2020 um 14:54 schrieb Brian Campbell <bcampbell=[email-masked]>:
> 
> er, I mean an -05 
> 
> On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell <[email-masked]> wrote:
> Thanks Vladimir, that seems quite reasonable. Barring any objections, I'll add that to a -04. 
> 
> On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov <[email-masked]> wrote:
> Hi Brian,
> 
> I'd like to propose the sentence in bold to be inserted into the current section 2.3 of PAR -04:
> 
> 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.
> 
>> On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov <[email-masked]> 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
>> 
>>> 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
>>> 
>>> 
>>> 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 <[email-masked]> wrote:
>>> 
>>> 
>> 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
> 
> 
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1608558896000000&usg=AOvVaw1OfSvPLJHvFwCsMayd7e4U

---

From: Brian Campbell <[email-masked]>
Date: Mon, 14 Dec 2020 09:39:01 -0700

And that's done:
https://mailarchive.ietf.org/arch/msg/oauth/W0eq4HUiiLVS5F5qyXXY6Gdw7vs/

On Mon, Dec 14, 2020 at 8:42 AM Torsten Lodderstedt <torsten=
[email-masked]> wrote:

> 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]
> “invalid_request” error code can be used as the default error code.
> >
> your computer. Thank you.
> > --
> > Vladimir Dzhuvinov
> >
> >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 14 Dec 2020 18:03:53 +0100

👍

> Am 14.12.2020 um 17:39 schrieb Brian Campbell <bcampbell=[email-masked]>:
> 
> 
> And that's done: https://mailarchive.ietf.org/arch/msg/oauth/W0eq4HUiiLVS5F5qyXXY6Gdw7vs/
> 
>> On Mon, Dec 14, 2020 at 8:42 AM Torsten Lodderstedt <torsten=[email-masked]> wrote: