Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

[Brian Campbell]

On Sat, Dec 12, 2020 at 1:22 AM Vladimir Dzhuvinov 
wrote:

> If the current DPoP has code complexity "X", the relative additional
> complexity to include access token hashes doesn't seem like very much. An
> app choosing DPoP means accepting the code complexity that comes with
> dealing with keys, composing the signing inputs for the proofs, signing,
> the necessary changes to the token and RS requests. On the other hand, for
> some people that additional access token hash may become the straw that
> breaks the camel's back, causing them to quit their jobs developing web
> apps and never look back :)
>
Yeah, the relative additional complexity to include an access token hash
maybe isn't too much but it's also not not nothing. It's a different kind
of operation than the other things you listed (yes, I know there's a hash
as part of the signing but it's abstracted away from the developer in most
cases) and something that can be quite difficult to troubleshoot when
different parties arrive at different hash values. Hence my lack of
conviction on this one way or the other.


> Have you thought about letting deployments decide about the access token
> hash? To say look, there is also the option to bind an access token to the
> DPoP proof, the security benefits can be such an such, and this is how it
> can be done.
>
> What I don't like about that proposal:
>
>- It will complicate the spec
>
>- The current spec doesn't require implementers / deployments to make
>any decisions, apart from adopt / not DPoP (okay, also choose a JWS alg) -
>which is actually a great feature to have
>
>
I also don't like it for basically the same reasons. I've definitely aimed
to keep it simple from that perspective of not having a lot of optionality
or switches. It is a nice feature to have, when possible.



> Vladimir
>
>
> On 12/12/2020 01:58, Brian Campbell wrote:
>
> Any type of client could use DPoP and (presumably) benefit from
> sender-constrained access tokens. So yeah, adding complexity specifically
> for browser-based applications (that only mitigates one variation of the
> attacks possible with XSS anyway)  has 'cost' impact to those clients as
> well. And should be considered in the cost/benefit. Including the AT hash
> isn't terribly complicated but it's not trivial either. I'm honestly still
> unsure but am leaning towards it not being worth adding.
>
> On Fri, Dec 11, 2020 at 2:14 AM Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> wrote:
>
>> The scenario you describe here is realistic in browser-based apps with
>> XSS vulnerabilities, but it is pretty complex. Since there are worse
>> problems when XSS happens, it’s hard to say whether DPoP should mitigate
>> this.
>>
>> I’m wondering what other types of clients would benefit from using DPoP
>> for access tokens? Mobile apps? Clients using a Client Credentials grant?
>>
>> How are they impacted by any change made specifically for browser-based
>> applications?
>>
>> Philippe
>>
>>
>> On 9 Dec 2020, at 23:57, Brian Campbell 
>> wrote:
>>
>> Thanks Philippe, I very much concur with your line of reasoning and the
>> important considerations. The scenario I was thinking of is: browser based
>> client where XSS is used to exfiltrate the refresh token along with
>> pre-computed proofs that would allow for the RT to be exchanged for new
>> access tokens and also pre-computed proofs that would work with those
>> access tokens for resource access. With the pre-computed proofs that would
>> allow prolonged (as long as the RT is valid) access to protected resources
>> even when the victim is offline. Is that a concrete attack scenario? I
>> mean, kind of. It's pretty convoluted/complex. And while an access token
>> hash would reign it in somewhat (ATs obtained from the stolen RT wouldn't
>> be usable) it's hard to say if the cost is worth the benefit.
>>
>>
>>
>> On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck <
>> phili...@pragmaticwebsecurity.com> wrote:
>>
>>> Yeah, browser-based apps are pure fun, aren’t they? :)
>>>
>>> The reason I covered a couple of (pessimistic) XSS scenarios is that the
>>> discussion started with an assumption that the attacker already
>>> successfully exploited an XSS vulnerability. I pointed out how, at that
>>> point, finetuning DPoP proof contents will have little to no effect to stop
>>> an attack. I believe it is important to make this very clear, to avoid
>>> people turning to DPoP as a security mechanism for browser-based
>>> applications.
>>>
>>>
>>> Specifically to your question on including the hash in the proof, I
>>> think these considerations are important:
>>>
>>> 1. Does the inclusion of the AT hash stop a concrete attack scenario?
>>> 2. Is the “cost” (implementation, getting it right, …) worth the
>>> benefits?
>>>
>>>
>>> Here’s my view on these considerations (*specifically for browser-based
>>> apps, not for other types of applications*):
>>>
>>> 1. The proof precomputation attack is already quite comple

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

[Torsten Lodderstedt]

👍

> Am 14.12.2020 um 17:39 schrieb Brian Campbell 
> :
> 
> 
> And that's done: 
> https://mailarchive.ietf.org/arch/msg/oauth/W0eq4HUiiLVS5F5qyXXY6Gdw7vs/
> 
>> On Mon, Dec 14, 2020 at 8:42 AM Torsten Lodderstedt 
>>  wrote:
>> +1 for following Vladimir’s proposal
>> 
>> > Am 14.12.2020 um 14:54 schrieb Brian Campbell 
>> > :
>> > 
>> > er, I mean an -05 
>> > 
>> > On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell 
>> >  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 
>> >  wrote:
>> > 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 
>> >>  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  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 
>> >>>  wrote:
>> >>> 
>> >>> 
>> >>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
>> >>> > 
>> >>> > 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 
>> >>> >  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

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

[Brian Campbell]

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

On Mon, Dec 14, 2020 at 8:42 AM Torsten Lodderstedt  wrote:

> +1 for following Vladimir’s proposal
>
> > Am 14.12.2020 um 14:54 schrieb Brian Campbell  40pingidentity@dmarc.ietf.org>:
> >
> > er, I mean an -05
> >
> > On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell <
> bcampb...@pingidentity.com> 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 <
> vladi...@connect2id.com> wrote:
> > 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 <
> vladi...@connect2id.com> 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 
> 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 <
> tors...@lodderstedt.net> wrote:
> >>>
> >>>
> >>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
> >>> >
> >>> > 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  40pingidentity@dmarc.ietf.org> 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 fol

[OAUTH-WG] I-D Action: draft-ietf-oauth-par-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : OAuth 2.0 Pushed Authorization Requests
Authors : Torsten Lodderstedt
  Brian Campbell
  Nat Sakimura
  Dave Tonge
  Filip Skokan
Filename: draft-ietf-oauth-par-05.txt
Pages   : 22
Date: 2020-12-14

Abstract:
   This document defines the pushed authorization request endpoint,
   which allows clients to push the payload of an OAuth 2.0
   authorization request to the authorization server via a direct
   request and provides them with a request URI that is used as
   reference to the data in a subsequent call to the authorization
   endpoint.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-par/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-par-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-par-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Torsten Lodderstedt]

+1 for following Vladimir’s proposal

> Am 14.12.2020 um 14:54 schrieb Brian Campbell 
> :
> 
> er, I mean an -05 
> 
> On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell  
> 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  
> wrote:
> 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  
>> 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  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  
>>> wrote:
>>> 
>>> 
>>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
>>> > 
>>> > 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 
>>> >  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 sin

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

[Brian Campbell]

er, I mean an -05

On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell 
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 <
> vladi...@connect2id.com> wrote:
>
>> 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 <
>> vladi...@connect2id.com> 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  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 <
 tors...@lodderstedt.net> wrote:

>
>
> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
> >
> > 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  40pingidentity@dmarc.ietf.org> 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 pa

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

[Dave Tonge]

I agree with the proposed text

On Mon, 14 Dec 2020 at 14:46, Brian Campbell  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 <
> vladi...@connect2id.com> wrote:
>
>> 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 <
>> vladi...@connect2id.com> 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  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 <
 tors...@lodderstedt.net> wrote:

>
>
> > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
> >
> > 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  40pingidentity@dmarc.ietf.org> 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

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

[Brian Campbell]

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 
wrote:

> 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 <
> vladi...@connect2id.com> 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  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 <
>>> tors...@lodderstedt.net> wrote:
>>>


 > Am 03.12.2020 um 09:56 schrieb Filip Skokan :
 >
 > 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 >>> 40pingidentity@dmarc.ietf.org> 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

Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response

[Dominick Baier]

+1

———
Dominick Baier

On 8. December 2020 at 13:51:04, Rifaat Shekh-Yusef (rifaat.s.i...@gmail.com)
wrote:

All,

This is a call for adoption for the following AS Issuer Identifier in
Authorization Response as a WG document:
https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/

Please, provide your feedback on the mailing list by Dec 22nd.

Regards,
 Rifaat & Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Vladimir Dzhuvinov]

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
> mailto:vladi...@connect2id.com>> 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 > > 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
>> mailto:tors...@lodderstedt.net>> wrote:
>>
>>
>>
>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan
>> mailto:panva...@gmail.com>>:
>> >
>> > 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
>> > > 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 o