Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

Thanks to all. I incorporated the text into the upcoming next revision of the 
draft. 

> On 3. Sep 2020, at 14:14, Dave Tonge  wrote:
> 
> Looks really good to me, thanks Brian.
> 
> On Wed, 2 Sep 2020 at 21:42, Brian Campbell 
>  wrote:
> Thanks Torsten, Taka, and Justin,
> 
> I took the revised text from Justin and tweaked it with some typo cleanup and 
> minor adjustments to make what is hopefully a final proposal below. I had a 
> similar feeling about the last paragraph not really fitting but don't have a 
> better location to suggest so am just leaving it. 
> 
> 2.4. Management of Client Redirect URIs
> 
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> values in certain circumstances, or for the authorization server to apply its 
> own matching semantics to the redirect_uri value presented by the client at 
> the authorization endpoint, the OAuth Security BCP 
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> require an authorization server exactly match the redirect_uri parameter 
> against the set of redirect URIs previously established for a particular 
> client. This is a means for early detection of client impersonation attempts 
> and prevents token leakage and open redirection. As a downside, this can make 
> client management more cumbersome since the redirect URI is typically the 
> most volatile part of a client policy.
> 
> The exact matching requirement MAY be relaxed by the authorization server for 
> a confidential client using pushed authorization requests since the 
> authorization server authenticates the client before the authorization 
> process starts and thus ensures it is interacting with the legitimate client. 
> The authorization server MAY allow such clients to specify redirect_uri 
> values that were not previously registered with the authorization server. 
> This will give the client more flexibility (e.g. to mint distinct redirect 
> URI values per authorization server at runtime) and can simplify client 
> management. It is at the discretion of the authorization server to apply 
> restrictions on supplied redirect_uri values, e.g. the authorization server 
> MAY require a certain URI prefix or allow only a query parameter to vary at 
> runtime.
> 
> The ability to set up transaction specific redirect URIs is also useful in 
> situations where client ids and corresponding credentials and policies are 
> managed by a trusted 3rd party, e.g. via client certificates containing 
> client permissions. Such an externally managed client could interact with an 
> authorization server trusting the respective 3rd party without the need for 
> an additional registration step.
> 
> On Wed, Sep 2, 2020 at 8:09 AM Justin Richer  wrote:
> The real conflict here is with the BCP and 2.1, both of which adopt the 
> stricter matching semantics for redirect URIs than 6749 does on its own. This 
> section would be needed to clarify how they relate to each other. That said, 
> I think adding some of Taka’s observations to Torsten’s text wouldn’t hurt:
> 
> 2.4. Management of redirect_uri
> 
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> values in certain circumstances, or for the AS to apply its own matching 
> semantics to the redirect_uri value presented by the client at the 
> authorization endpoint, the OAuth Security BCP 
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> require an AS to excactly match the redirect_uri parameter against the set of 
> redirect URIs previously established for a particular client. This is a means 
> to early detect attempts to impersonate a client and prevent token leakage 
> and open redirection. As a downside, it makes client management more complex 
> since the redirect URI is typically the most volatile part of a client policy.
> 
> This requirement MAY be relaxed by the AS if a confidential client uses 
> pushed authorization requests since the AS authenticates the client before 
> the authorization process starts and that way ensures it interacts with the 
> legit client. The AS MAY allow such clients to specify redirect_uri values 
> not previously registered with the AS. This will give the client more 
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes 
> client management much easier. It is at the discretion of the AS to apply 
> restriction on redirect_uri values, e.g. the AS MAY require a certain URI 
> prefix or allow only a query parameter to vary at runtime.
> 
> I also feel like this paragraph belongs in a different section outside of 
> here. I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not 
> the end of the world if it stays here though as it’s a decent view on the 
> “why".
> 
> The aibility to set up transaction specific redirect URIs is also useful in 
> situations where client ids and correspoding credentials and policies are 
> managed by a trusted 3rd party, e.g. via 

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

yes.

> On 3. Sep 2020, at 13:33, Brian Campbell  wrote:
> 
> Do you mean just putting the "Note:" back in front of it? WFM. 
> 
> 
> 
> On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt  
> wrote:
> Thanks Brian!
> 
> I suggest to put a Note: in front of the last paragraph to indicate it is 
> additional infomercial.
> 
> WDYT?
> 
> > Am 03.09.2020 um 02:29 schrieb Justin Richer :
> > 
> > Nice work, Brian. Looks good to me! 
> > 
> > From: Brian Campbell [bcampb...@pingidentity.com]
> > Sent: Wednesday, September 2, 2020 3:41 PM
> > To: Justin Richer
> > Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth
> > Subject: Re: [OAUTH-WG] WGLC Review of PAR
> > 
> > Thanks Torsten, Taka, and Justin,
> > 
> > I took the revised text from Justin and tweaked it with some typo cleanup 
> > and minor adjustments to make what is hopefully a final proposal below. I 
> > had a similar feeling about the last paragraph not really fitting but don't 
> > have a better location to suggest so am just leaving it.
> > 
> > 2.4. Management of Client Redirect URIs
> > 
> > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> > values in certain circumstances, or for the authorization server to apply 
> > its own matching semantics to the redirect_uri value presented by the 
> > client at the authorization endpoint, the OAuth Security BCP 
> > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> > require an authorization server exactly match the redirect_uri parameter 
> > against the set of redirect URIs previously established for a particular 
> > client. This is a means for early detection of client impersonation 
> > attempts and prevents token leakage and open redirection. As a downside, 
> > this can make client management more cumbersome since the redirect URI is 
> > typically the most volatile part of a client policy.
> > 
> > The exact matching requirement MAY be relaxed by the authorization server 
> > for a confidential client using pushed authorization requests since the 
> > authorization server authenticates the client before the authorization 
> > process starts and thus ensures it is interacting with the legitimate 
> > client. The authorization server MAY allow such clients to specify 
> > redirect_uri values that were not previously registered with the 
> > authorization server. This will give the client more flexibility (e.g. to 
> > mint distinct redirect URI values per authorization server at runtime) and 
> > can simplify client management. It is at the discretion of the 
> > authorization server to apply restrictions on supplied redirect_uri values, 
> > e.g. the authorization server MAY require a certain URI prefix or allow 
> > only a query parameter to vary at runtime.
> > 
> > The ability to set up transaction specific redirect URIs is also useful in 
> > situations where client ids and corresponding credentials and policies are 
> > managed by a trusted 3rd party, e.g. via client certificates containing 
> > client permissions. Such an externally managed client could interact with 
> > an authorization server trusting the respective 3rd party without the need 
> > for an additional registration step.
> > 
> > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer 
> > mailto:jric...@mit.edu>> wrote:
> > The real conflict here is with the BCP and 2.1, both of which adopt the 
> > stricter matching semantics for redirect URIs than 6749 does on its own. 
> > This section would be needed to clarify how they relate to each other. That 
> > said, I think adding some of Taka’s observations to Torsten’s text wouldn’t 
> > hurt:
> > 
> > 2.4. Management of redirect_uri
> > 
> > While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> > values in certain circumstances, or for the AS to apply its own matching 
> > semantics to the redirect_uri value presented by the client at the 
> > authorization endpoint, the OAuth Security BCP 
> > [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> > require an AS to excactly match the redirect_uri parameter against the set 
> > of redirect URIs previously established for a particular client. This is a 
> > means to early detect attempts to impersonate a client and prevent token 
> > leakage and open redirection. As a downside, it makes client management 
> > more complex since the redirect URI is typically the most volatile part of 
> > a client policy.
> 

Re: [OAUTH-WG] WGLC Review of PAR

[Dave Tonge]

Looks really good to me, thanks Brian.

On Wed, 2 Sep 2020 at 21:42, Brian Campbell  wrote:

> Thanks Torsten, Taka, and Justin,
>
> I took the revised text from Justin and tweaked it with some typo cleanup
> and minor adjustments to make what is hopefully a final proposal below. I
> had a similar feeling about the last paragraph not really fitting but don't
> have a better location to suggest so am just leaving it.
>
> 2.4. Management of Client Redirect URIs
>
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri
> values in certain circumstances, or for the authorization server to apply
> its own matching semantics to the redirect_uri value presented by the
> client at the authorization endpoint, the OAuth Security BCP
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1]
> require an authorization server exactly match the redirect_uri parameter
> against the set of redirect URIs previously established for a particular
> client. This is a means for early detection of client impersonation
> attempts and prevents token leakage and open redirection. As a downside,
> this can make client management more cumbersome since the redirect URI is
> typically the most volatile part of a client policy.
>
> The exact matching requirement MAY be relaxed by the authorization server
> for a confidential client using pushed authorization requests since the
> authorization server authenticates the client before the authorization
> process starts and thus ensures it is interacting with the legitimate
> client. The authorization server MAY allow such clients to specify
> redirect_uri values that were not previously registered with the
> authorization server. This will give the client more flexibility (e.g. to
> mint distinct redirect URI values per authorization server at runtime) and
> can simplify client management. It is at the discretion of the
> authorization server to apply restrictions on supplied redirect_uri values,
> e.g. the authorization server MAY require a certain URI prefix or allow
> only a query parameter to vary at runtime.
>
> The ability to set up transaction specific redirect URIs is also useful in
> situations where client ids and corresponding credentials and policies are
> managed by a trusted 3rd party, e.g. via client certificates containing
> client permissions. Such an externally managed client could interact with
> an authorization server trusting the respective 3rd party without the need
> for an additional registration step.
>
> On Wed, Sep 2, 2020 at 8:09 AM Justin Richer  wrote:
>
>> The real conflict here is with the BCP and 2.1, both of which adopt the
>> stricter matching semantics for redirect URIs than 6749 does on its own.
>> This section would be needed to clarify how they relate to each other. That
>> said, I think adding some of Taka’s observations to Torsten’s text wouldn’t
>> hurt:
>>
>> 2.4. Management of redirect_uri
>>
>> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri
>> values in certain circumstances, or for the AS to apply its own matching
>> semantics to the redirect_uri value presented by the client at the
>> authorization endpoint, the OAuth Security BCP
>> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1]
>> require an AS to excactly match the redirect_uri parameter against the set
>> of redirect URIs previously established for a particular client. This is a
>> means to early detect attempts to impersonate a client and prevent token
>> leakage and open redirection. As a downside, it makes client management
>> more complex since the redirect URI is typically the most volatile part of
>> a client policy.
>>
>> This requirement MAY be relaxed by the AS if a confidential client uses
>> pushed authorization requests since the AS authenticates the client before
>> the authorization process starts and that way ensures it interacts with the
>> legit client. The AS MAY allow such clients to specify redirect_uri values
>> not previously registered with the AS. This will give the client more
>> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes
>> client management much easier. It is at the discretion of the AS to apply
>> restriction on redirect_uri values, e.g. the AS MAY require a certain URI
>> prefix or allow only a query parameter to vary at runtime.
>>
>> I also feel like this paragraph belongs in a different section outside of
>> here. I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not
>> the end of the world if it stays here though as it’s a decent view on the
>> “why".
>>
>>
>> The aibility to set up transaction specific redirect URIs is also useful
>> in situations where client ids and correspoding credentials and policies
>> are managed by a trusted 3rd party, e.g. via client certifiates containing
>> client permissions. Such an externally managed client could interact with
>> an AS trusting the respective 3rd party without the 

Re: [OAUTH-WG] WGLC Review of PAR

[Brian Campbell]

Do you mean just putting the "Note:" back in front of it? WFM.



On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt 
wrote:

> Thanks Brian!
>
> I suggest to put a Note: in front of the last paragraph to indicate it is
> additional infomercial.
>
> WDYT?
>
> > Am 03.09.2020 um 02:29 schrieb Justin Richer :
> >
> > Nice work, Brian. Looks good to me!
> > 
> > From: Brian Campbell [bcampb...@pingidentity.com]
> > Sent: Wednesday, September 2, 2020 3:41 PM
> > To: Justin Richer
> > Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth
> > Subject: Re: [OAUTH-WG] WGLC Review of PAR
> >
> > Thanks Torsten, Taka, and Justin,
> >
> > I took the revised text from Justin and tweaked it with some typo
> cleanup and minor adjustments to make what is hopefully a final proposal
> below. I had a similar feeling about the last paragraph not really fitting
> but don't have a better location to suggest so am just leaving it.
> >
> > 2.4. Management of Client Redirect URIs
> >
> > While OAuth 2.0 [RFC6749] allows clients to use unregistered
> redirect_uri values in certain circumstances, or for the authorization
> server to apply its own matching semantics to the redirect_uri value
> presented by the client at the authorization endpoint, the OAuth Security
> BCP [I-D.ietf-oauth-security-topics] as well as OAuth 2.1
> [I-D.ietf-oauth-v2-1] require an authorization server exactly match the
> redirect_uri parameter against the set of redirect URIs previously
> established for a particular client. This is a means for early detection of
> client impersonation attempts and prevents token leakage and open
> redirection. As a downside, this can make client management more cumbersome
> since the redirect URI is typically the most volatile part of a client
> policy.
> >
> > The exact matching requirement MAY be relaxed by the authorization
> server for a confidential client using pushed authorization requests since
> the authorization server authenticates the client before the authorization
> process starts and thus ensures it is interacting with the legitimate
> client. The authorization server MAY allow such clients to specify
> redirect_uri values that were not previously registered with the
> authorization server. This will give the client more flexibility (e.g. to
> mint distinct redirect URI values per authorization server at runtime) and
> can simplify client management. It is at the discretion of the
> authorization server to apply restrictions on supplied redirect_uri values,
> e.g. the authorization server MAY require a certain URI prefix or allow
> only a query parameter to vary at runtime.
> >
> > The ability to set up transaction specific redirect URIs is also useful
> in situations where client ids and corresponding credentials and policies
> are managed by a trusted 3rd party, e.g. via client certificates containing
> client permissions. Such an externally managed client could interact with
> an authorization server trusting the respective 3rd party without the need
> for an additional registration step.
> >
> > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer  jric...@mit.edu>> wrote:
> > The real conflict here is with the BCP and 2.1, both of which adopt the
> stricter matching semantics for redirect URIs than 6749 does on its own.
> This section would be needed to clarify how they relate to each other. That
> said, I think adding some of Taka’s observations to Torsten’s text wouldn’t
> hurt:
> >
> > 2.4. Management of redirect_uri
> >
> > While OAuth 2.0 [RFC6749] allows clients to use unregistered
> redirect_uri values in certain circumstances, or for the AS to apply its
> own matching semantics to the redirect_uri value presented by the client at
> the authorization endpoint, the OAuth Security BCP
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1]
> require an AS to excactly match the redirect_uri parameter against the set
> of redirect URIs previously established for a particular client. This is a
> means to early detect attempts to impersonate a client and prevent token
> leakage and open redirection. As a downside, it makes client management
> more complex since the redirect URI is typically the most volatile part of
> a client policy.
> >
> > This requirement MAY be relaxed by the AS if a confidential client uses
> pushed authorization requests since the AS authenticates the client before
> the authorization process starts and that way ensures it interacts with the
> legit client. The AS MAY allow such clients to specify redirect_uri values
> not previously registered with the AS. This w

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

Thanks Brian!

I suggest to put a Note: in front of the last paragraph to indicate it is 
additional infomercial.

WDYT?

> Am 03.09.2020 um 02:29 schrieb Justin Richer :
> 
> Nice work, Brian. Looks good to me! 
> 
> From: Brian Campbell [bcampb...@pingidentity.com]
> Sent: Wednesday, September 2, 2020 3:41 PM
> To: Justin Richer
> Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth
> Subject: Re: [OAUTH-WG] WGLC Review of PAR
> 
> Thanks Torsten, Taka, and Justin,
> 
> I took the revised text from Justin and tweaked it with some typo cleanup and 
> minor adjustments to make what is hopefully a final proposal below. I had a 
> similar feeling about the last paragraph not really fitting but don't have a 
> better location to suggest so am just leaving it.
> 
> 2.4. Management of Client Redirect URIs
> 
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> values in certain circumstances, or for the authorization server to apply its 
> own matching semantics to the redirect_uri value presented by the client at 
> the authorization endpoint, the OAuth Security BCP 
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> require an authorization server exactly match the redirect_uri parameter 
> against the set of redirect URIs previously established for a particular 
> client. This is a means for early detection of client impersonation attempts 
> and prevents token leakage and open redirection. As a downside, this can make 
> client management more cumbersome since the redirect URI is typically the 
> most volatile part of a client policy.
> 
> The exact matching requirement MAY be relaxed by the authorization server for 
> a confidential client using pushed authorization requests since the 
> authorization server authenticates the client before the authorization 
> process starts and thus ensures it is interacting with the legitimate client. 
> The authorization server MAY allow such clients to specify redirect_uri 
> values that were not previously registered with the authorization server. 
> This will give the client more flexibility (e.g. to mint distinct redirect 
> URI values per authorization server at runtime) and can simplify client 
> management. It is at the discretion of the authorization server to apply 
> restrictions on supplied redirect_uri values, e.g. the authorization server 
> MAY require a certain URI prefix or allow only a query parameter to vary at 
> runtime.
> 
> The ability to set up transaction specific redirect URIs is also useful in 
> situations where client ids and corresponding credentials and policies are 
> managed by a trusted 3rd party, e.g. via client certificates containing 
> client permissions. Such an externally managed client could interact with an 
> authorization server trusting the respective 3rd party without the need for 
> an additional registration step.
> 
> On Wed, Sep 2, 2020 at 8:09 AM Justin Richer 
> mailto:jric...@mit.edu>> wrote:
> The real conflict here is with the BCP and 2.1, both of which adopt the 
> stricter matching semantics for redirect URIs than 6749 does on its own. This 
> section would be needed to clarify how they relate to each other. That said, 
> I think adding some of Taka’s observations to Torsten’s text wouldn’t hurt:
> 
> 2.4. Management of redirect_uri
> 
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
> values in certain circumstances, or for the AS to apply its own matching 
> semantics to the redirect_uri value presented by the client at the 
> authorization endpoint, the OAuth Security BCP 
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] 
> require an AS to excactly match the redirect_uri parameter against the set of 
> redirect URIs previously established for a particular client. This is a means 
> to early detect attempts to impersonate a client and prevent token leakage 
> and open redirection. As a downside, it makes client management more complex 
> since the redirect URI is typically the most volatile part of a client policy.
> 
> This requirement MAY be relaxed by the AS if a confidential client uses 
> pushed authorization requests since the AS authenticates the client before 
> the authorization process starts and that way ensures it interacts with the 
> legit client. The AS MAY allow such clients to specify redirect_uri values 
> not previously registered with the AS. This will give the client more 
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes 
> client management much easier. It is at the discretion of the AS to apply 
> restriction on redirect_uri values, e.g. the AS MAY require a certain URI 

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

Nice work, Brian. Looks good to me! 

From: Brian Campbell [bcampb...@pingidentity.com]
Sent: Wednesday, September 2, 2020 3:41 PM
To: Justin Richer
Cc: Takahiko Kawasaki; Torsten Lodderstedt; oauth
Subject: Re: [OAUTH-WG] WGLC Review of PAR

Thanks Torsten, Taka, and Justin,

I took the revised text from Justin and tweaked it with some typo cleanup and 
minor adjustments to make what is hopefully a final proposal below. I had a 
similar feeling about the last paragraph not really fitting but don't have a 
better location to suggest so am just leaving it.

2.4. Management of Client Redirect URIs

While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
values in certain circumstances, or for the authorization server to apply its 
own matching semantics to the redirect_uri value presented by the client at the 
authorization endpoint, the OAuth Security BCP [I-D.ietf-oauth-security-topics] 
as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an authorization server 
exactly match the redirect_uri parameter against the set of redirect URIs 
previously established for a particular client. This is a means for early 
detection of client impersonation attempts and prevents token leakage and open 
redirection. As a downside, this can make client management more cumbersome 
since the redirect URI is typically the most volatile part of a client policy.

The exact matching requirement MAY be relaxed by the authorization server for a 
confidential client using pushed authorization requests since the authorization 
server authenticates the client before the authorization process starts and 
thus ensures it is interacting with the legitimate client. The authorization 
server MAY allow such clients to specify redirect_uri values that were not 
previously registered with the authorization server. This will give the client 
more flexibility (e.g. to mint distinct redirect URI values per authorization 
server at runtime) and can simplify client management. It is at the discretion 
of the authorization server to apply restrictions on supplied redirect_uri 
values, e.g. the authorization server MAY require a certain URI prefix or allow 
only a query parameter to vary at runtime.

The ability to set up transaction specific redirect URIs is also useful in 
situations where client ids and corresponding credentials and policies are 
managed by a trusted 3rd party, e.g. via client certificates containing client 
permissions. Such an externally managed client could interact with an 
authorization server trusting the respective 3rd party without the need for an 
additional registration step.

On Wed, Sep 2, 2020 at 8:09 AM Justin Richer 
mailto:jric...@mit.edu>> wrote:
The real conflict here is with the BCP and 2.1, both of which adopt the 
stricter matching semantics for redirect URIs than 6749 does on its own. This 
section would be needed to clarify how they relate to each other. That said, I 
think adding some of Taka’s observations to Torsten’s text wouldn’t hurt:

2.4. Management of redirect_uri

While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
values in certain circumstances, or for the AS to apply its own matching 
semantics to the redirect_uri value presented by the client at the 
authorization endpoint, the OAuth Security BCP [I-D.ietf-oauth-security-topics] 
as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an AS to excactly match the 
redirect_uri parameter against the set of redirect URIs previously established 
for a particular client. This is a means to early detect attempts to 
impersonate a client and prevent token leakage and open redirection. As a 
downside, it makes client management more complex since the redirect URI is 
typically the most volatile part of a client policy.

This requirement MAY be relaxed by the AS if a confidential client uses pushed 
authorization requests since the AS authenticates the client before the 
authorization process starts and that way ensures it interacts with the legit 
client. The AS MAY allow such clients to specify redirect_uri values not 
previously registered with the AS. This will give the client more flexibility 
(e.g. to mint AS-specific redirect URIs on the fly) and makes client management 
much easier. It is at the discretion of the AS to apply restriction on 
redirect_uri values, e.g. the AS MAY require a certain URI prefix or allow only 
a query parameter to vary at runtime.

I also feel like this paragraph belongs in a different section outside of here. 
I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not the end 
of the world if it stays here though as it’s a decent view on the “why".

The aibility to set up transaction specific redirect URIs is also useful in 
situations where client ids and correspoding credentials and policies are 
managed by a trusted 3rd party, e.g. via client certifiates containing client 
permissions. Such an externally managed c

Re: [OAUTH-WG] WGLC Review of PAR

[Brian Campbell]

Thanks Torsten, Taka, and Justin,

I took the revised text from Justin and tweaked it with some typo cleanup
and minor adjustments to make what is hopefully a final proposal below. I
had a similar feeling about the last paragraph not really fitting but don't
have a better location to suggest so am just leaving it.

2.4. Management of Client Redirect URIs

While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri
values in certain circumstances, or for the authorization server to apply
its own matching semantics to the redirect_uri value presented by the
client at the authorization endpoint, the OAuth Security BCP
[I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1]
require an authorization server exactly match the redirect_uri parameter
against the set of redirect URIs previously established for a particular
client. This is a means for early detection of client impersonation
attempts and prevents token leakage and open redirection. As a downside,
this can make client management more cumbersome since the redirect URI is
typically the most volatile part of a client policy.

The exact matching requirement MAY be relaxed by the authorization server
for a confidential client using pushed authorization requests since the
authorization server authenticates the client before the authorization
process starts and thus ensures it is interacting with the legitimate
client. The authorization server MAY allow such clients to specify
redirect_uri values that were not previously registered with the
authorization server. This will give the client more flexibility (e.g. to
mint distinct redirect URI values per authorization server at runtime) and
can simplify client management. It is at the discretion of the
authorization server to apply restrictions on supplied redirect_uri values,
e.g. the authorization server MAY require a certain URI prefix or allow
only a query parameter to vary at runtime.

The ability to set up transaction specific redirect URIs is also useful in
situations where client ids and corresponding credentials and policies are
managed by a trusted 3rd party, e.g. via client certificates containing
client permissions. Such an externally managed client could interact with
an authorization server trusting the respective 3rd party without the need
for an additional registration step.

On Wed, Sep 2, 2020 at 8:09 AM Justin Richer  wrote:

> The real conflict here is with the BCP and 2.1, both of which adopt the
> stricter matching semantics for redirect URIs than 6749 does on its own.
> This section would be needed to clarify how they relate to each other. That
> said, I think adding some of Taka’s observations to Torsten’s text wouldn’t
> hurt:
>
> 2.4. Management of redirect_uri
>
> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri
> values in certain circumstances, or for the AS to apply its own matching
> semantics to the redirect_uri value presented by the client at the
> authorization endpoint, the OAuth Security BCP
> [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 [I-D.ietf-oauth-v2-1]
> require an AS to excactly match the redirect_uri parameter against the set
> of redirect URIs previously established for a particular client. This is a
> means to early detect attempts to impersonate a client and prevent token
> leakage and open redirection. As a downside, it makes client management
> more complex since the redirect URI is typically the most volatile part of
> a client policy.
>
> This requirement MAY be relaxed by the AS if a confidential client uses
> pushed authorization requests since the AS authenticates the client before
> the authorization process starts and that way ensures it interacts with the
> legit client. The AS MAY allow such clients to specify redirect_uri values
> not previously registered with the AS. This will give the client more
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes
> client management much easier. It is at the discretion of the AS to apply
> restriction on redirect_uri values, e.g. the AS MAY require a certain URI
> prefix or allow only a query parameter to vary at runtime.
>
> I also feel like this paragraph belongs in a different section outside of
> here. I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not
> the end of the world if it stays here though as it’s a decent view on the
> “why".
>
>
> The aibility to set up transaction specific redirect URIs is also useful
> in situations where client ids and correspoding credentials and policies
> are managed by a trusted 3rd party, e.g. via client certifiates containing
> client permissions. Such an externally managed client could interact with
> an AS trusting the respective 3rd party without the need for an additional
> registration step.
>
>
>  — Justin
>
> On Sep 1, 2020, at 11:05 PM, Takahiko Kawasaki  wrote:
>
> Under existing specifications (RFC 6749, OIDC Core 1.0 and FAPI), a client
> can choose an 

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

The real conflict here is with the BCP and 2.1, both of which adopt the 
stricter matching semantics for redirect URIs than 6749 does on its own. This 
section would be needed to clarify how they relate to each other. That said, I 
think adding some of Taka’s observations to Torsten’s text wouldn’t hurt:

2.4. Management of redirect_uri

While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_uri 
values in certain circumstances, or for the AS to apply its own matching 
semantics to the redirect_uri value presented by the client at the 
authorization endpoint, the OAuth Security BCP [I-D.ietf-oauth-security-topics] 
as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an AS to excactly match the 
redirect_uri parameter against the set of redirect URIs previously established 
for a particular client. This is a means to early detect attempts to 
impersonate a client and prevent token leakage and open redirection. As a 
downside, it makes client management more complex since the redirect URI is 
typically the most volatile part of a client policy.

This requirement MAY be relaxed by the AS if a confidential client uses pushed 
authorization requests since the AS authenticates the client before the 
authorization process starts and that way ensures it interacts with the legit 
client. The AS MAY allow such clients to specify redirect_uri values not 
previously registered with the AS. This will give the client more flexibility 
(e.g. to mint AS-specific redirect URIs on the fly) and makes client management 
much easier. It is at the discretion of the AS to apply restriction on 
redirect_uri values, e.g. the AS MAY require a certain URI prefix or allow only 
a query parameter to vary at runtime.

I also feel like this paragraph belongs in a different section outside of here. 
I’m not sure where, but it doesn’t quite seem to fit, to me. It’s not the end 
of the world if it stays here though as it’s a decent view on the “why".

The aibility to set up transaction specific redirect URIs is also useful in 
situations where client ids and correspoding credentials and policies are 
managed by a trusted 3rd party, e.g. via client certifiates containing client 
permissions. Such an externally managed client could interact with an AS 
trusting the respective 3rd party without the need for an additional 
registration step.

 — Justin

> On Sep 1, 2020, at 11:05 PM, Takahiko Kawasaki  wrote:
> 
> Under existing specifications (RFC 6749, OIDC Core 1.0 and FAPI), a client 
> can choose an arbitrary redirect_uri without registering it only when all the 
> following conditions are satisfied.
> 
> 1. The client type of the client is "confidential". (RFC 6749 Section 3.1.2.2 
> requires that public clients register redirect URIs.)
> 2. The flow is not "implicit". (RFC 6749 Section 3.1.2.2 requires that 
> confidential clients utilizing the implicit grant type register redirect 
> URIs.)
> 3. The authorization request is not an OIDC request. (OIDC Core 1.0 Section 
> 3.1.2.1 requires that redirect_uri match a pre-registered one.)
> 4. The authorization request is not a FAPI request. (FAPI Part 1 Section 
> 5.2.2 Clause 8 requires that redirect URIs be pre-registered.)
> 
> In short, under existing specifications, pure RFC-6749 
> authorization-code-flow requests from confidential clients can choose an 
> arbitrary redirect_uri without registering it. Once OIDC or FAPI is used, 
> existing specifications require pre-registration of redirect URIs. I'm not 
> sure but if PAR's "redirect_uri Management" is going to introduce rules that 
> conflict with existing specifications, it is better to list the conflicts 
> explicitly in the section.
> 
> Best Regards,
> Takahiko Kawasaki
> 
> 
> On Wed, Sep 2, 2020 at 3:48 AM Torsten Lodderstedt 
>  > wrote:
> Here is my proposal for the new section:
> 
> 2.4. redirect_uri Management
> 
> The OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 
> [I-D.ietf-oauth-v2-1] require an AS to excactly match the redirect_uri 
> parameter against the set of redirect URIs previously established for a 
> particular client. This is a means to early detect attempts to impersonate a 
> client and prevent token leakage and open redirection. As a downside, it 
> makes client management more complex since the redirect URI is typically the 
> most volatile part of a client policy.
> 
> This requirement MAY be relaxed by the AS, if a confidential client uses 
> pushed authorization requests since the AS authenticates the client before 
> the authorization process starts and that way ensures it interacts with the 
> legit client. The AS MAY allow such clients to specify redirect_uri values 
> not previously registered with the AS. This will give the client more 
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes 
> client management much easier. It is at the discretion of the AS to apply 
> restriction on 

Re: [OAUTH-WG] WGLC Review of PAR

[Takahiko Kawasaki]

Under existing specifications (RFC 6749, OIDC Core 1.0 and FAPI), a client
can choose an arbitrary redirect_uri without registering it only when all
the following conditions are satisfied.

1. The client type of the client is "confidential". (RFC 6749 Section
3.1.2.2 requires that public clients register redirect URIs.)
2. The flow is not "implicit". (RFC 6749 Section 3.1.2.2 requires that
confidential clients utilizing the implicit grant type register redirect
URIs.)
3. The authorization request is not an OIDC request. (OIDC Core 1.0 Section
3.1.2.1 requires that redirect_uri match a pre-registered one.)
4. The authorization request is not a FAPI request. (FAPI Part 1 Section
5.2.2 Clause 8 requires that redirect URIs be pre-registered.)

In short, under existing specifications, pure RFC-6749
authorization-code-flow requests from confidential clients can choose an
arbitrary redirect_uri without registering it. Once OIDC or FAPI is used,
existing specifications require pre-registration of redirect URIs. I'm not
sure but if PAR's "redirect_uri Management" is going to introduce rules
that conflict with existing specifications, it is better to list the
conflicts explicitly in the section.

Best Regards,
Takahiko Kawasaki


On Wed, Sep 2, 2020 at 3:48 AM Torsten Lodderstedt  wrote:

> Here is my proposal for the new section:
>
> 2.4. redirect_uri Management
>
> The OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth
> 2.1 [I-D.ietf-oauth-v2-1] require an AS to excactly match the redirect_uri
> parameter against the set of redirect URIs previously established for a
> particular client. This is a means to early detect attempts to impersonate
> a client and prevent token leakage and open redirection. As a downside, it
> makes client management more complex since the redirect URI is typically
> the most volatile part of a client policy.
>
> This requirement MAY be relaxed by the AS, if a confidential client uses
> pushed authorization requests since the AS authenticates the client before
> the authorization process starts and that way ensures it interacts with the
> legit client. The AS MAY allow such clients to specify redirect_uri values
> not previously registered with the AS. This will give the client more
> flexibility (e.g. to mint AS-specific redirect URIs on the fly) and makes
> client management much easier. It is at the discretion of the AS to apply
> restriction on redirect_uri values, e.g. the AS MAY require a certain URI
> prefix or allow only a query parameter to vary at runtime.
>
> Note: The aibility to set up transaction specific redirect URIs is also
> useful in situations where client ids and correspoding credentials and
> policies are managed by a trusted 3rd party, e.g. via client certifiates
> containing client permissions. Such an externally managed client could
> interact with an AS trusting the respective 3rd party without the need for
> an additional registration step.
>
> > On 29. Aug 2020, at 17:22, Justin Richer  wrote:
> >
> > I completely agree with the utility of the function in question here and
> it needs to be included. I’m in favor of creating a dedicated section for
> redirect_uri management, so that we can explain exactly how and why to
> relax the requirement from core OAuth. In addition, I think we want to
> discuss that the AS might have its own restrictions on which redirect URIs
> an authenticated client might be able to use. For example, registering a
> client with a Redirect URI prefix, or allowing only a query parameter to
> vary at runtime. All of these can be enforced in PAR because the client is
> presenting its authentication, as you point out, so the AS can determine
> which policies should apply.
> >
> > — Justin
> >
> >> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> >>
> >>
> >>>
> >>>
> >>>   ¶6: Does the AS really have "the ability to authenticate and
> authorize clients”? I think what we mean here is "the ability to
> authenticate clients and validate client requests”, but I’m not positive of
> the intent.
> >>>
> >>> I think the intent is that the AS can check whether a client is
> authorized to make a particular authorization request (specific scopes,
> response type, etc.). But checking authorization to request authorization
> is confusing wording. I think your working is less confusing and still
> allows for the intent.
> >>>
> >>> I'll let Torsten interject if he feels differently as I think he
> originally wrote the text in question.
> >>
> >> that was the original intent. I think “validate" is fine.
> >>
> >>>
> >>>
> >>>
> >>>   ¶7: I’m not sure I buy this example. Even if the clientID is managed
> externally, the association with a set or pattern of allowed redirect URIs
> is still important, and the AS will need to know what that is. I think this
> example could lead an AS developer to (erroneously and dangerously)
> conclude that they don’t have to check any other values in a request,
> 

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

Here is my proposal for the new section:

2.4. redirect_uri Management

The OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth 2.1 
[I-D.ietf-oauth-v2-1] require an AS to excactly match the redirect_uri 
parameter against the set of redirect URIs previously established for a 
particular client. This is a means to early detect attempts to impersonate a 
client and prevent token leakage and open redirection. As a downside, it makes 
client management more complex since the redirect URI is typically the most 
volatile part of a client policy.

This requirement MAY be relaxed by the AS, if a confidential client uses pushed 
authorization requests since the AS authenticates the client before the 
authorization process starts and that way ensures it interacts with the legit 
client. The AS MAY allow such clients to specify redirect_uri values not 
previously registered with the AS. This will give the client more flexibility 
(e.g. to mint AS-specific redirect URIs on the fly) and makes client management 
much easier. It is at the discretion of the AS to apply restriction on 
redirect_uri values, e.g. the AS MAY require a certain URI prefix or allow only 
a query parameter to vary at runtime.

Note: The aibility to set up transaction specific redirect URIs is also useful 
in situations where client ids and correspoding credentials and policies are 
managed by a trusted 3rd party, e.g. via client certifiates containing client 
permissions. Such an externally managed client could interact with an AS 
trusting the respective 3rd party without the need for an additional 
registration step.

> On 29. Aug 2020, at 17:22, Justin Richer  wrote:
> 
> I completely agree with the utility of the function in question here and it 
> needs to be included. I’m in favor of creating a dedicated section for 
> redirect_uri management, so that we can explain exactly how and why to relax 
> the requirement from core OAuth. In addition, I think we want to discuss that 
> the AS might have its own restrictions on which redirect URIs an 
> authenticated client might be able to use. For example, registering a client 
> with a Redirect URI prefix, or allowing only a query parameter to vary at 
> runtime. All of these can be enforced in PAR because the client is presenting 
> its authentication, as you point out, so the AS can determine which policies 
> should apply.
> 
> — Justin
> 
>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
>> wrote:
>> 
>> 
>>> 
>>> 
>>>   ¶6: Does the AS really have "the ability to authenticate and authorize 
>>> clients”? I think what we mean here is "the ability to authenticate clients 
>>> and validate client requests”, but I’m not positive of the intent. 
>>> 
>>> I think the intent is that the AS can check whether a client is authorized 
>>> to make a particular authorization request (specific scopes, response type, 
>>> etc.). But checking authorization to request authorization is confusing 
>>> wording. I think your working is less confusing and still allows for the 
>>> intent. 
>>> 
>>> I'll let Torsten interject if he feels differently as I think he originally 
>>> wrote the text in question. 
>> 
>> that was the original intent. I think “validate" is fine. 
>> 
>>> 
>>> 
>>> 
>>>   ¶7: I’m not sure I buy this example. Even if the clientID is managed 
>>> externally, the association with a set or pattern of allowed redirect URIs 
>>> is still important, and the AS will need to know what that is. I think this 
>>> example could lead an AS developer to (erroneously and dangerously) 
>>> conclude that they don’t have to check any other values in a request, 
>>> including scope and redirect URI. It’s important that DynReg doesn’t 
>>> alleviate that issue, but removal of DynReg doesn’t really change things in 
>>> that regard. Suggest removing example or reworking paragraph.
>>> 
>>> I'm going to have to defer to Torsten on this because, to be honest, I'm 
>>> not too sure about it myself. I tend to lean towards thinking the draft 
>>> would be better off without it. 
>>> 
>> 
>> In the traditional authorization flow, the redirect_uri serves as way to 
>> make sure the AS is really talking to the legit client and the allowed 
>> redirect_uri values are determined by the legit client at registration time 
>> (might be manually).
>> 
>> With PAR, we have a much stronger means to ensure the AS is talking to the 
>> legit client. That’s why I don’t see an issue with letting the client set a 
>> per transaction redirect_uri. This will give the client more flexibility 
>> (mint AS-specific redirect URIs on the fly) and makes client management much 
>> easier since redirect URIs are the most volatile part of a client policy. 
>> 
>> It also makes use of OAuth much easier in deployments where client 
>> identities are managed by external entities (even without any idea of 
>> OAuth). A prominent example is open banking in the EU (aka PSD2). The 
>> (technical) identity of any PSD2-licensed 

Re: [OAUTH-WG] WGLC Review of PAR

[Brian Campbell]

I'm not sure how to word it exactly but I think Dick has landed on what we
ultimately want this to say. Basically that the "request_uri" is intended
to be used only once, the client MUST not use it more than once, and that
the AS should also treat it as one-time use but may make reasonable
accommodations to more gracefully handle redundant authorization requests
due to browser reload or similar.

On Sun, Aug 30, 2020 at 4:48 PM Dick Hardt  wrote:

> I don't have the context of the text to respond to the exact wording, but
> I think we can state that the client MUST use the "request_uri" only once,
> and then explain that the AS may receive duplicate requests if the browser
> is reloaded.
>
>
> On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> You are making a good point here. The reason we added the one time use
>> constraint was the fact the client will include parameters supposed to be
>> used only once, e.g. the PKCE code_challenge. For a traditional
>> authorisation request, we would recommend the client to use a per
>> transaction (== one time use) code_challenge, but PKCE does not require the
>> AS to enforce it. Mapping this to PAR means, we SHOULD recommend the client
>> to use the request_uri only once but not require the AS to enforce it.
>>
>> Would the following text work for you?
>>
>> Since parts of the request content, e.g. the "code_challenge"
>>parameter value, is unique to a certain authorization request,
>> the client SHOULD use the "request_uri" only once.
>>
>> I also would move this text to section 4.
>>
>> > On 27. Aug 2020, at 18:11, Dick Hardt  wrote:
>> >
>> > That is not correct.
>> >
>> > The authorization code one-time-use is directly between the client and
>> the AS. The client has a number of mechanisms to ensure it only presents
>> the authorization code to the AS once, such as a session that was set when
>> the user started at the client.
>> >
>> > In contrast, in a redirect from the client to the AS, the client loses
>> control on how many times the user-agent loads the URL at the AS.
>> Additionally, there is unlikely to be an active browser session at the AS,
>> so the AS can not easily differentiate between a URL load from the same
>> user, or different users. If one-time-use, one of them MUST fail. If the
>> two requests happen to be from the same user (because of a reload, which
>> the user did because the AS was slow to respond), there is no way for the
>> AS to know which of the requests is the one that is current in front of the
>> user. While the AS can internally ensure processing of the request once,
>> one-time-use would dictate that it provides a failure message to one of the
>> requests.
>> >
>> > /Dick
>> >
>> >
>> > ᐧ
>> >
>> > On Thu, Aug 27, 2020 at 7:17 AM Justin Richer  wrote:
>> > We already have this same property with authorization codes, and it’s
>> managed today reasonably well (in my opinion). If you submit the same
>> request URI twice in the same browser (the refresh you’re talking about),
>> it shouldn’t start two separate authorization requests, but it would be
>> reasonable to detect that the same session attached to the same request URI
>> value showed up twice and continue the session as appropriate.
>> >
>> > None of this is in conflict with “one time use”, in my view, since
>> you’re actively detecting the session and source of the value.
>> >
>> >  — Justin
>> >
>> >> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
>> >>
>> >> I think one-time use may be overly restrictive, and I don't think it
>> is the property that we actually want.
>> >>
>> >> Give the request URI is in a redirect from the browser, there is a
>> good chance of a race condition where the same browser request is made more
>> than once, for example, while the browser is loading the authorization URL
>> at the AS, the user could refresh the page causing the authorization URL to
>> be reloaded. Would the reload count as a second use? One could argue it
>> either way.
>> >>
>> >> What I think we want from what I understand, is the request URI MUST
>> be unique so that there is no confusion on which request is being
>> referenced.
>> >>
>> >> I did not see anything about the expiry time of the request URI (but I
>> did not look super hard). If that is not there, then I think the request
>> URI MUST expire in a "short" period of time.
>> >>
>> >>
>> >>
>> >> ᐧ
>> >>
>> >> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell > 40pingidentity@dmarc.ietf.org> wrote:
>> >> Thanks Justin. Just a couple more responses to responses inline below
>> (but with lots of content that needs no further discussion removed).
>> >>
>> >> A TL;DR for the WG is that I'd like to get some wider feedback on the
>> question of changing the one-time-use condition on the request_uri from a
>> SHOULD to a MUST.
>> >>
>> >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:
>> >> Hi Brian, just a couple responses inline where it seemed fitting.
>> Thanks 

Re: [OAUTH-WG] WGLC Review of PAR

[Dick Hardt]

I don't have the context of the text to respond to the exact wording, but I
think we can state that the client MUST use the "request_uri" only once,
and then explain that the AS may receive duplicate requests if the browser
is reloaded.


On Sat, Aug 29, 2020 at 4:24 AM Torsten Lodderstedt 
wrote:

> You are making a good point here. The reason we added the one time use
> constraint was the fact the client will include parameters supposed to be
> used only once, e.g. the PKCE code_challenge. For a traditional
> authorisation request, we would recommend the client to use a per
> transaction (== one time use) code_challenge, but PKCE does not require the
> AS to enforce it. Mapping this to PAR means, we SHOULD recommend the client
> to use the request_uri only once but not require the AS to enforce it.
>
> Would the following text work for you?
>
> Since parts of the request content, e.g. the "code_challenge"
>parameter value, is unique to a certain authorization request,
> the client SHOULD use the "request_uri" only once.
>
> I also would move this text to section 4.
>
> > On 27. Aug 2020, at 18:11, Dick Hardt  wrote:
> >
> > That is not correct.
> >
> > The authorization code one-time-use is directly between the client and
> the AS. The client has a number of mechanisms to ensure it only presents
> the authorization code to the AS once, such as a session that was set when
> the user started at the client.
> >
> > In contrast, in a redirect from the client to the AS, the client loses
> control on how many times the user-agent loads the URL at the AS.
> Additionally, there is unlikely to be an active browser session at the AS,
> so the AS can not easily differentiate between a URL load from the same
> user, or different users. If one-time-use, one of them MUST fail. If the
> two requests happen to be from the same user (because of a reload, which
> the user did because the AS was slow to respond), there is no way for the
> AS to know which of the requests is the one that is current in front of the
> user. While the AS can internally ensure processing of the request once,
> one-time-use would dictate that it provides a failure message to one of the
> requests.
> >
> > /Dick
> >
> >
> > ᐧ
> >
> > On Thu, Aug 27, 2020 at 7:17 AM Justin Richer  wrote:
> > We already have this same property with authorization codes, and it’s
> managed today reasonably well (in my opinion). If you submit the same
> request URI twice in the same browser (the refresh you’re talking about),
> it shouldn’t start two separate authorization requests, but it would be
> reasonable to detect that the same session attached to the same request URI
> value showed up twice and continue the session as appropriate.
> >
> > None of this is in conflict with “one time use”, in my view, since
> you’re actively detecting the session and source of the value.
> >
> >  — Justin
> >
> >> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
> >>
> >> I think one-time use may be overly restrictive, and I don't think it is
> the property that we actually want.
> >>
> >> Give the request URI is in a redirect from the browser, there is a good
> chance of a race condition where the same browser request is made more than
> once, for example, while the browser is loading the authorization URL at
> the AS, the user could refresh the page causing the authorization URL to be
> reloaded. Would the reload count as a second use? One could argue it either
> way.
> >>
> >> What I think we want from what I understand, is the request URI MUST be
> unique so that there is no confusion on which request is being referenced.
> >>
> >> I did not see anything about the expiry time of the request URI (but I
> did not look super hard). If that is not there, then I think the request
> URI MUST expire in a "short" period of time.
> >>
> >>
> >>
> >> ᐧ
> >>
> >> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
> >> Thanks Justin. Just a couple more responses to responses inline below
> (but with lots of content that needs no further discussion removed).
> >>
> >> A TL;DR for the WG is that I'd like to get some wider feedback on the
> question of changing the one-time-use condition on the request_uri from a
> SHOULD to a MUST.
> >>
> >> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:
> >> Hi Brian, just a couple responses inline where it seemed fitting.
> Thanks for going through everything!
> >>  — Justin
> >>
> >>> On Aug 25, 2020, at 6:01 PM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
> >>>
> >>> Thanks for the review and comments Justin. Replies (or attempts
> thereat) are inline below.
> >>>
> >>>
> >>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:
> >>> I’ve done a full read through of the PAR specification, and here are
> my notes on it.
> >>>
> >>>
> >>> ¶2: Of necessity, this spec mixes parameters in the authorization
> endpoint and token endpoint registries into a single request. Is there any
> danger of 

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

I gone draft this section.

> Am 29.08.2020 um 17:22 schrieb Justin Richer :
> 
> I completely agree with the utility of the function in question here and it 
> needs to be included. I’m in favor of creating a dedicated section for 
> redirect_uri management, so that we can explain exactly how and why to relax 
> the requirement from core OAuth. In addition, I think we want to discuss that 
> the AS might have its own restrictions on which redirect URIs an 
> authenticated client might be able to use. For example, registering a client 
> with a Redirect URI prefix, or allowing only a query parameter to vary at 
> runtime. All of these can be enforced in PAR because the client is presenting 
> its authentication, as you point out, so the AS can determine which policies 
> should apply.
> 
> — Justin
> 
>>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
>>> wrote:
>>> 
>>> 
>>> 
>>> 
>>>   ¶6: Does the AS really have "the ability to authenticate and authorize 
>>> clients”? I think what we mean here is "the ability to authenticate clients 
>>> and validate client requests”, but I’m not positive of the intent. 
>>> 
>>> I think the intent is that the AS can check whether a client is authorized 
>>> to make a particular authorization request (specific scopes, response type, 
>>> etc.). But checking authorization to request authorization is confusing 
>>> wording. I think your working is less confusing and still allows for the 
>>> intent. 
>>> 
>>> I'll let Torsten interject if he feels differently as I think he originally 
>>> wrote the text in question. 
>> 
>> that was the original intent. I think “validate" is fine. 
>> 
>>> 
>>> 
>>> 
>>>   ¶7: I’m not sure I buy this example. Even if the clientID is managed 
>>> externally, the association with a set or pattern of allowed redirect URIs 
>>> is still important, and the AS will need to know what that is. I think this 
>>> example could lead an AS developer to (erroneously and dangerously) 
>>> conclude that they don’t have to check any other values in a request, 
>>> including scope and redirect URI. It’s important that DynReg doesn’t 
>>> alleviate that issue, but removal of DynReg doesn’t really change things in 
>>> that regard. Suggest removing example or reworking paragraph.
>>> 
>>> I'm going to have to defer to Torsten on this because, to be honest, I'm 
>>> not too sure about it myself. I tend to lean towards thinking the draft 
>>> would be better off without it.
>>> 
>> 
>> In the traditional authorization flow, the redirect_uri serves as way to 
>> make sure the AS is really talking to the legit client and the allowed 
>> redirect_uri values are determined by the legit client at registration time 
>> (might be manually).
>> 
>> With PAR, we have a much stronger means to ensure the AS is talking to the 
>> legit client. That’s why I don’t see an issue with letting the client set a 
>> per transaction redirect_uri. This will give the client more flexibility 
>> (mint AS-specific redirect URIs on the fly) and makes client management much 
>> easier since redirect URIs are the most volatile part of a client policy. 
>> 
>> It also makes use of OAuth much easier in deployments where client 
>> identities are managed by external entities (even without any idea of 
>> OAuth). A prominent example is open banking in the EU (aka PSD2). The 
>> (technical) identity of any PSD2-licensed client is asserted by an eIDAS 
>> compliant CA in a special X.509 certificate. Those certificates contain the 
>> permissions (access to account information and/or payment initiation 
>> allowed) and the identity (member state specific). But they don’t contain 
>> OAuth policy values. Nevertheless, the regulation requires any financial 
>> institution in the EU to at runtime, without any registration, to accept and 
>> process calls from any licensed PSD2 clients.
>> 
>> There are two ways to cope with it in OAuth context:
>> a) use dynamic client registration with the X.509 cert as credential. 
>> Unfortunately, RFC 7591 does not support other client authentication means 
>> then an initial access token. Beside that, it would violate the text of the 
>> regulation. 
>> b) establish a redirect URL with every transaction. This is the recommended 
>> approach in at least one of the PSD2 specs.
>> 
>> PAR is a clean way to solve that problem. 
>> 
>> I don’t want this text to cause confusing. On the other hand this potential 
>> of PAR is way too important to not mention it at all. What about moving it 
>> into a special section "redirect_uri management”?
>> 
>>> 
>> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

I completely agree with the utility of the function in question here and it 
needs to be included. I’m in favor of creating a dedicated section for 
redirect_uri management, so that we can explain exactly how and why to relax 
the requirement from core OAuth. In addition, I think we want to discuss that 
the AS might have its own restrictions on which redirect URIs an authenticated 
client might be able to use. For example, registering a client with a Redirect 
URI prefix, or allowing only a query parameter to vary at runtime. All of these 
can be enforced in PAR because the client is presenting its authentication, as 
you point out, so the AS can determine which policies should apply.

 — Justin

> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt  
> wrote:
> 
> 
>> 
>> 
>>¶6: Does the AS really have "the ability to authenticate and authorize 
>> clients”? I think what we mean here is "the ability to authenticate clients 
>> and validate client requests”, but I’m not positive of the intent. 
>> 
>> I think the intent is that the AS can check whether a client is authorized 
>> to make a particular authorization request (specific scopes, response type, 
>> etc.). But checking authorization to request authorization is confusing 
>> wording. I think your working is less confusing and still allows for the 
>> intent. 
>> 
>> I'll let Torsten interject if he feels differently as I think he originally 
>> wrote the text in question. 
> 
> that was the original intent. I think “validate" is fine. 
> 
>> 
>> 
>> 
>>¶7: I’m not sure I buy this example. Even if the clientID is managed 
>> externally, the association with a set or pattern of allowed redirect URIs 
>> is still important, and the AS will need to know what that is. I think this 
>> example could lead an AS developer to (erroneously and dangerously) conclude 
>> that they don’t have to check any other values in a request, including scope 
>> and redirect URI. It’s important that DynReg doesn’t alleviate that issue, 
>> but removal of DynReg doesn’t really change things in that regard. Suggest 
>> removing example or reworking paragraph.
>> 
>> I'm going to have to defer to Torsten on this because, to be honest, I'm not 
>> too sure about it myself. I tend to lean towards thinking the draft would be 
>> better off without it. 
>> 
> 
> In the traditional authorization flow, the redirect_uri serves as way to make 
> sure the AS is really talking to the legit client and the allowed 
> redirect_uri values are determined by the legit client at registration time 
> (might be manually).
> 
> With PAR, we have a much stronger means to ensure the AS is talking to the 
> legit client. That’s why I don’t see an issue with letting the client set a 
> per transaction redirect_uri. This will give the client more flexibility 
> (mint AS-specific redirect URIs on the fly) and makes client management much 
> easier since redirect URIs are the most volatile part of a client policy. 
> 
> It also makes use of OAuth much easier in deployments where client identities 
> are managed by external entities (even without any idea of OAuth). A 
> prominent example is open banking in the EU (aka PSD2). The (technical) 
> identity of any PSD2-licensed client is asserted by an eIDAS compliant CA in 
> a special X.509 certificate. Those certificates contain the permissions 
> (access to account information and/or payment initiation allowed) and the 
> identity (member state specific). But they don’t contain OAuth policy values. 
> Nevertheless, the regulation requires any financial institution in the EU to 
> at runtime, without any registration, to accept and process calls from any 
> licensed PSD2 clients.
> 
> There are two ways to cope with it in OAuth context:
> a) use dynamic client registration with the X.509 cert as credential. 
> Unfortunately, RFC 7591 does not support other client authentication means 
> then an initial access token. Beside that, it would violate the text of the 
> regulation. 
> b) establish a redirect URL with every transaction. This is the recommended 
> approach in at least one of the PSD2 specs.
> 
> PAR is a clean way to solve that problem. 
> 
> I don’t want this text to cause confusing. On the other hand this potential 
> of PAR is way too important to not mention it at all. What about moving it 
> into a special section "redirect_uri management”?
> 
>> 
> 

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

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

> 
> 
> ¶6: Does the AS really have "the ability to authenticate and authorize 
> clients”? I think what we mean here is "the ability to authenticate clients 
> and validate client requests”, but I’m not positive of the intent. 
> 
> I think the intent is that the AS can check whether a client is authorized to 
> make a particular authorization request (specific scopes, response type, 
> etc.). But checking authorization to request authorization is confusing 
> wording. I think your working is less confusing and still allows for the 
> intent. 
> 
> I'll let Torsten interject if he feels differently as I think he originally 
> wrote the text in question. 

that was the original intent. I think “validate" is fine. 

> 
>  
> 
> ¶7: I’m not sure I buy this example. Even if the clientID is managed 
> externally, the association with a set or pattern of allowed redirect URIs is 
> still important, and the AS will need to know what that is. I think this 
> example could lead an AS developer to (erroneously and dangerously) conclude 
> that they don’t have to check any other values in a request, including scope 
> and redirect URI. It’s important that DynReg doesn’t alleviate that issue, 
> but removal of DynReg doesn’t really change things in that regard. Suggest 
> removing example or reworking paragraph.
> 
> I'm going to have to defer to Torsten on this because, to be honest, I'm not 
> too sure about it myself. I tend to lean towards thinking the draft would be 
> better off without it. 
> 

In the traditional authorization flow, the redirect_uri serves as way to make 
sure the AS is really talking to the legit client and the allowed redirect_uri 
values are determined by the legit client at registration time (might be 
manually).

With PAR, we have a much stronger means to ensure the AS is talking to the 
legit client. That’s why I don’t see an issue with letting the client set a per 
transaction redirect_uri. This will give the client more flexibility (mint 
AS-specific redirect URIs on the fly) and makes client management much easier 
since redirect URIs are the most volatile part of a client policy. 

It also makes use of OAuth much easier in deployments where client identities 
are managed by external entities (even without any idea of OAuth). A prominent 
example is open banking in the EU (aka PSD2). The (technical) identity of any 
PSD2-licensed client is asserted by an eIDAS compliant CA in a special X.509 
certificate. Those certificates contain the permissions (access to account 
information and/or payment initiation allowed) and the identity (member state 
specific). But they don’t contain OAuth policy values. Nevertheless, the 
regulation requires any financial institution in the EU to at runtime, without 
any registration, to accept and process calls from any licensed PSD2 clients.

There are two ways to cope with it in OAuth context:
a) use dynamic client registration with the X.509 cert as credential. 
Unfortunately, RFC 7591 does not support other client authentication means then 
an initial access token. Beside that, it would violate the text of the 
regulation. 
b) establish a redirect URL with every transaction. This is the recommended 
approach in at least one of the PSD2 specs.

PAR is a clean way to solve that problem. 

I don’t want this text to cause confusing. On the other hand this potential of 
PAR is way too important to not mention it at all. What about moving it into a 
special section "redirect_uri management”?

> 

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

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

You are making a good point here. The reason we added the one time use 
constraint was the fact the client will include parameters supposed to be used 
only once, e.g. the PKCE code_challenge. For a traditional authorisation 
request, we would recommend the client to use a per transaction (== one time 
use) code_challenge, but PKCE does not require the AS to enforce it. Mapping 
this to PAR means, we SHOULD recommend the client to use the request_uri only 
once but not require the AS to enforce it. 

Would the following text work for you?

Since parts of the request content, e.g. the "code_challenge"
   parameter value, is unique to a certain authorization request, 
the client SHOULD use the "request_uri" only once.

I also would move this text to section 4.

> On 27. Aug 2020, at 18:11, Dick Hardt  wrote:
> 
> That is not correct.
> 
> The authorization code one-time-use is directly between the client and the 
> AS. The client has a number of mechanisms to ensure it only presents the 
> authorization code to the AS once, such as a session that was set when the 
> user started at the client.
> 
> In contrast, in a redirect from the client to the AS, the client loses 
> control on how many times the user-agent loads the URL at the AS. 
> Additionally, there is unlikely to be an active browser session at the AS, so 
> the AS can not easily differentiate between a URL load from the same user, or 
> different users. If one-time-use, one of them MUST fail. If the two requests 
> happen to be from the same user (because of a reload, which the user did 
> because the AS was slow to respond), there is no way for the AS to know which 
> of the requests is the one that is current in front of the user. While the AS 
> can internally ensure processing of the request once, one-time-use would 
> dictate that it provides a failure message to one of the requests.
> 
> /Dick
> 
> 
> ᐧ
> 
> On Thu, Aug 27, 2020 at 7:17 AM Justin Richer  wrote:
> We already have this same property with authorization codes, and it’s managed 
> today reasonably well (in my opinion). If you submit the same request URI 
> twice in the same browser (the refresh you’re talking about), it shouldn’t 
> start two separate authorization requests, but it would be reasonable to 
> detect that the same session attached to the same request URI value showed up 
> twice and continue the session as appropriate. 
> 
> None of this is in conflict with “one time use”, in my view, since you’re 
> actively detecting the session and source of the value.
> 
>  — Justin
> 
>> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
>> 
>> I think one-time use may be overly restrictive, and I don't think it is the 
>> property that we actually want.
>> 
>> Give the request URI is in a redirect from the browser, there is a good 
>> chance of a race condition where the same browser request is made more than 
>> once, for example, while the browser is loading the authorization URL at the 
>> AS, the user could refresh the page causing the authorization URL to be 
>> reloaded. Would the reload count as a second use? One could argue it either 
>> way.
>> 
>> What I think we want from what I understand, is the request URI MUST be 
>> unique so that there is no confusion on which request is being referenced. 
>> 
>> I did not see anything about the expiry time of the request URI (but I did 
>> not look super hard). If that is not there, then I think the request URI 
>> MUST expire in a "short" period of time.
>> 
>> 
>> 
>> ᐧ
>> 
>> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 
>>  wrote:
>> Thanks Justin. Just a couple more responses to responses inline below (but 
>> with lots of content that needs no further discussion removed). 
>> 
>> A TL;DR for the WG is that I'd like to get some wider feedback on the 
>> question of changing the one-time-use condition on the request_uri from a 
>> SHOULD to a MUST. 
>> 
>> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:
>> Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
>> going through everything!
>>  — Justin
>> 
>>> On Aug 25, 2020, at 6:01 PM, Brian Campbell  
>>> wrote:
>>> 
>>> Thanks for the review and comments Justin. Replies (or attempts thereat) 
>>> are inline below.
>>> 
>>> 
>>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:
>>> I’ve done a full read through of the PAR specification, and here are my 
>>> notes on it.
>>> 
>>> 
>>> ¶2: Of necessity, this spec mixes parameters in the authorization 
>>> endpoint and token endpoint registries into a single request. Is there any 
>>> danger of conflict between them? The registry holds them in one list but 
>>> they could possibly have different semantics in both places..
>>> 
>>> I think that technically such danger does exist but that it's highly 
>>> unlikely in practice. Especially because the only token endpoint parameters 
>>> that are relevant to PAR are those that deal with client authentication 
>>> (currently client_secret, 

Re: [OAUTH-WG] WGLC Review of PAR

[Mike Jones]

I agree with Dick that it would be a mistake to make the URL one-time use.  
It’s unenforceable and unnecessarily gets in the way of valuable deployment 
patterns.

From: OAuth  On Behalf Of Dick Hardt
Sent: Thursday, August 27, 2020 9:12 AM
To: Justin Richer 
Cc: Brian Campbell ; oauth 

Subject: Re: [OAUTH-WG] WGLC Review of PAR

That is not correct.

The authorization code one-time-use is directly between the client and the AS. 
The client has a number of mechanisms to ensure it only presents the 
authorization code to the AS once, such as a session that was set when the user 
started at the client.

In contrast, in a redirect from the client to the AS, the client loses control 
on how many times the user-agent loads the URL at the AS. Additionally, there 
is unlikely to be an active browser session at the AS, so the AS can not easily 
differentiate between a URL load from the same user, or different users. If 
one-time-use, one of them MUST fail. If the two requests happen to be from the 
same user (because of a reload, which the user did because the AS was slow to 
respond), there is no way for the AS to know which of the requests is the one 
that is current in front of the user. While the AS can internally ensure 
processing of the request once, one-time-use would dictate that it provides a 
failure message to one of the requests.

/Dick


ᐧ

On Thu, Aug 27, 2020 at 7:17 AM Justin Richer 
mailto:jric...@mit.edu>> wrote:
We already have this same property with authorization codes, and it’s managed 
today reasonably well (in my opinion). If you submit the same request URI twice 
in the same browser (the refresh you’re talking about), it shouldn’t start two 
separate authorization requests, but it would be reasonable to detect that the 
same session attached to the same request URI value showed up twice and 
continue the session as appropriate.

None of this is in conflict with “one time use”, in my view, since you’re 
actively detecting the session and source of the value.

 — Justin


On Aug 26, 2020, at 6:16 PM, Dick Hardt 
mailto:dick.ha...@gmail.com>> wrote:

I think one-time use may be overly restrictive, and I don't think it is the 
property that we actually want.

Give the request URI is in a redirect from the browser, there is a good chance 
of a race condition where the same browser request is made more than once, for 
example, while the browser is loading the authorization URL at the AS, the user 
could refresh the page causing the authorization URL to be reloaded. Would the 
reload count as a second use? One could argue it either way.

What I think we want from what I understand, is the request URI MUST be unique 
so that there is no confusion on which request is being referenced.

I did not see anything about the expiry time of the request URI (but I did not 
look super hard). If that is not there, then I think the request URI MUST 
expire in a "short" period of time.



ᐧ

On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 
mailto:40pingidentity@dmarc.ietf.org>>
 wrote:
Thanks Justin. Just a couple more responses to responses inline below (but with 
lots of content that needs no further discussion removed).

A TL;DR for the WG is that I'd like to get some wider feedback on the question 
of changing the one-time-use condition on the request_uri from a SHOULD to a 
MUST.

On Tue, Aug 25, 2020 at 4:57 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
going through everything!
 — Justin


On Aug 25, 2020, at 6:01 PM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:

Thanks for the review and comments Justin. Replies (or attempts thereat) are 
inline below.


On Wed, Aug 19, 2020 at 2:06 PM Justin Richer 
mailto:jric...@mit.edu>> wrote:
I’ve done a full read through of the PAR specification, and here are my notes 
on it.


¶2: Of necessity, this spec mixes parameters in the authorization endpoint 
and token endpoint registries into a single request. Is there any danger of 
conflict between them? The registry holds them in one list but they could 
possibly have different semantics in both places..

I think that technically such danger does exist but that it's highly unlikely 
in practice. Especially because the only token endpoint parameters that are 
relevant to PAR are those that deal with client authentication (currently 
client_secret, client_assertion, and client_assertion_type). I'm also not sure 
what can reasonably be done about it given the way the registries are. I guess 
PAR could update the registration for those three (client_secret, 
client_assertion, and client_assertion_type) to also indicate authorization 
request as a usage location with some commentary that it's only for avoiding 
name collisions. And offer some guidance about doing the same for any future 
client auth methods being defined. But honestly I'm not sure what, if anything,

Re: [OAUTH-WG] WGLC review of PAR

[Neil Madden]

Thanks for the response Brian, I agree with your comments. I’ve been scratching 
my head for a non-OIDC example for the URI swapping issue, but can’t think of 
one that isn’t very contrived at the moment.

— Neil

> On 26 Aug 2020, at 21:04, Brian Campbell  wrote:
> 
> Thanks Neil. Appreciate the review and feedback. My attempts at responses are 
> inline below. 
> 
> 
> On Thu, Aug 20, 2020 at 5:30 AM Neil Madden  > wrote:
> As promised in the last interim meeting, I’ve reviewed the current (03) 
> draft-ietf-oauth-par document. Overall it looks close to ready to me, with 
> mostly minor comments and one security-relevant comment on section 2.1 that 
> should be discussed further, and one additional proposed security 
> consideration:
> 
> Abstract:
> The wording here could be improved - “allows clients to push an authorization 
> request […] used as a reference to the data in a subsequent authorization 
> request.” Both the pushed data and the call to the authorization endpoint are 
> referred to as an “authorization request”. Maybe change the second usage to 
> “in a subsequent call to the authorization endpoint”.
> 
> Makes sense. 
>  
> 
> Section 1:
> The introductory part here is quite long. Maybe adding a new sub-heading 
> before the example would make it flow better.
> 
> Will look at breaking it up. 
>  
> 
> The end of the introduction uses the acronym “PAR” for the first time, but 
> never explicitly defines it.
> 
> Will fix. 
>  
> 
> I agree with Justin that ACR is not the best example to lead with. If it 
> stays there should be a reference to OIDC to explain what this means.
> 
> Yup. 
>  
> 
> The paragraph that begins “It also allows clients to push the form encoded …” 
> is confusing because the use of “also” suggests this is different from the 
> previous paragraph, but it seems to actually be saying the same thing?
> 
> Yeah, that is rather awkward because it is the same thing. Will fix. 
>  
> 
> “[…] but it also allows clients requiring
>an even higher security level, especially cryptographically confirmed
>non-repudiation, to explicitly adopt JWT-based request objects”
> 
> The “but” should be an “and” in this paragraph. It’s also not clear what is 
> being said here - isn’t JAR what provides JWT-based request objects? 
> 
> Yeah, JAR defines JWT-based request objects and PAR allows for their use by 
> sending the 'request' parameter to the PAR endpoint.  Will try and make that 
> more clear.
>  
> 
> The paragraph beginning “As a further benefit, …” is a little bit of a 
> Columbo moment (“Just one more thing…”) at the end of the introduction. Maybe 
> move this as another bullet point at the start of the section. The following 
> paragraph can then be rewritten as “The increased confidence in the identity 
> of the client during the authorization process allows confidential clients to 
> provide a different redirect_uri on every request. […]”
> 
>  Agree with the sentiment here and will endeavor to rework things along the 
> lines of the suggestion. 
> 
>  
> Section 2:
> The 3rd paragraph contains statements like 
> The endpoint also supports sending all authorization
>request parameters as request object according to
>[I-D.ietf-oauth-jwsreq 
> ].
> presumably this is not a normative requirement that any PAR implementation 
> has to also support JAR, or is it? Maybe change the wording to “MAY also 
> support …”.
> 
> Interesting question. PAR has a normative reference to JAR for the 
> request_uri parameter at the authz endpoint. But does that necessitate that 
> every PAR implementation also has to support all of JAR? I'm thinking 
> probably not. I mean, different but related, an AS PAR implementation might 
> legitimately support the request_uri parameter with URI values that it 
> creates but not support the more general retrieval of arbitrary URIs. In the 
> same vein, it seems legit and still useful to support PAR without also 
> supporting request object JWTs. So yeah, I think changing this to MAY or 
> something similar would be appropriate. 
>  
> 
> The first mention of “token_endpoint_auth_method” and client metadata should 
> have a reference to RFC 7591 - currently it’s only referenced later in 
> section 2.1.
> 
> Will fix. 
> 
> 2.1:
> I’m a little bit wary of the relaxing of the redirect_uri processing rules, 
> because this removes a layer of defence in depth. With the current 
> requirement for pre-registered URIs an attacker needs to compromise the 
> redirect endpoint *and* the client credentials in order to steal an 
> authorization code and use it. With this change, compromising the client 
> credentials alone would be enough. If the use-case is specifically in a PKI 
> environment, could the redirect_uri be baked into the cert? Maybe this 
> use-case could be better addressed in a separate draft.
> 
>  I agree that the 

Re: [OAUTH-WG] WGLC Review of PAR

[Dick Hardt]

That is not correct.

The authorization code one-time-use is directly between the client and the
AS. The client has a number of mechanisms to ensure it only presents the
authorization code to the AS once, such as a session that was set when the
user started at the client.

In contrast, in a redirect from the client to the AS, the client loses
control on how many times the user-agent loads the URL at the AS.
Additionally, there is unlikely to be an active browser session at the AS,
so the AS can not easily differentiate between a URL load from the same
user, or different users. If one-time-use, one of them MUST fail. If the
two requests happen to be from the same user (because of a reload, which
the user did because the AS was slow to respond), there is no way for the
AS to know which of the requests is the one that is current in front of the
user. While the AS can internally ensure processing of the request once,
one-time-use would dictate that it provides a failure message to one of the
requests.

/Dick


ᐧ

On Thu, Aug 27, 2020 at 7:17 AM Justin Richer  wrote:

> We already have this same property with authorization codes, and it’s
> managed today reasonably well (in my opinion). If you submit the same
> request URI twice in the same browser (the refresh you’re talking about),
> it shouldn’t start two separate authorization requests, but it would be
> reasonable to detect that the same session attached to the same request URI
> value showed up twice and continue the session as appropriate.
>
> None of this is in conflict with “one time use”, in my view, since you’re
> actively detecting the session and source of the value.
>
>  — Justin
>
> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
>
> I think one-time use may be overly restrictive, and I don't think it is
> the property that we actually want.
>
> Give the request URI is in a redirect from the browser, there is a good
> chance of a race condition where the same browser request is made more than
> once, for example, while the browser is loading the authorization URL at
> the AS, the user could refresh the page causing the authorization URL to be
> reloaded. Would the reload count as a second use? One could argue it
> either way.
>
> What I think we want from what I understand, is the request URI MUST be
> unique so that there is no confusion on which request is being referenced..
>
> I did not see anything about the expiry time of the request URI (but I did
> not look super hard). If that is not there, then I think the request URI
> MUST expire in a "short" period of time.
>
>
>
> ᐧ
>
> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell  40pingidentity@dmarc.ietf.org> wrote:
>
>> Thanks Justin. Just a couple more responses to responses inline below
>> (but with lots of content that needs no further discussion removed).
>>
>> A TL;DR for the WG is that I'd like to get some wider feedback on the
>> question of changing the one-time-use condition on the request_uri from a
>> SHOULD to a MUST.
>>
>> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:
>>
>>> Hi Brian, just a couple responses inline where it seemed fitting. Thanks
>>> for going through everything!
>>>  — Justin
>>>
>>> On Aug 25, 2020, at 6:01 PM, Brian Campbell 
>>> wrote:
>>>
>>> Thanks for the review and comments Justin. Replies (or attempts thereat)
>>> are inline below.
>>>
>>>
>>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:
>>>
 I’ve done a full read through of the PAR specification, and here are my
 notes on it.


> ¶2: Of necessity, this spec mixes parameters in the authorization
> endpoint and token endpoint registries into a single request. Is there any
> danger of conflict between them? The registry holds them in one list but
> they could possibly have different semantics in both places.
>

 I think that technically such danger does exist but that it's highly
 unlikely in practice. Especially because the only token endpoint parameters
 that are relevant to PAR are those that deal with client authentication
 (currently client_secret, client_assertion, and client_assertion_type).. 
 I'm
 also not sure what can reasonably be done about it given the way the
 registries are. I guess PAR could update the registration for those three
 (client_secret, client_assertion, and client_assertion_type) to also
 indicate authorization request as a usage location with some commentary
 that it's only for avoiding name collisions. And offer some guidance about
 doing the same for any future client auth methods being defined. But
 honestly I'm not sure what, if anything, to do here?

 And yes it is super unfortunate that client auth and protocol
 parameters got mixed together in the HTTP body. I didn't cause that
 situation but I've certainly contributed to it and for that I apologize.

>>>
>>> I think the only perfect solution is to go back in time and fix the
>>> 

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

We already have this same property with authorization codes, and it’s managed 
today reasonably well (in my opinion). If you submit the same request URI twice 
in the same browser (the refresh you’re talking about), it shouldn’t start two 
separate authorization requests, but it would be reasonable to detect that the 
same session attached to the same request URI value showed up twice and 
continue the session as appropriate. 

None of this is in conflict with “one time use”, in my view, since you’re 
actively detecting the session and source of the value.

 — Justin

> On Aug 26, 2020, at 6:16 PM, Dick Hardt  wrote:
> 
> I think one-time use may be overly restrictive, and I don't think it is the 
> property that we actually want.
> 
> Give the request URI is in a redirect from the browser, there is a good 
> chance of a race condition where the same browser request is made more than 
> once, for example, while the browser is loading the authorization URL at the 
> AS, the user could refresh the page causing the authorization URL to be 
> reloaded. Would the reload count as a second use? One could argue it either 
> way.
> 
> What I think we want from what I understand, is the request URI MUST be 
> unique so that there is no confusion on which request is being referenced. 
> 
> I did not see anything about the expiry time of the request URI (but I did 
> not look super hard). If that is not there, then I think the request URI MUST 
> expire in a "short" period of time.
> 
> 
> 
> ᐧ
> 
> On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell 
>  > wrote:
> Thanks Justin. Just a couple more responses to responses inline below (but 
> with lots of content that needs no further discussion removed). 
> 
> A TL;DR for the WG is that I'd like to get some wider feedback on the 
> question of changing the one-time-use condition on the request_uri from a 
> SHOULD to a MUST. 
> 
> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  > wrote:
> Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
> going through everything!
>  — Justin
> 
>> On Aug 25, 2020, at 6:01 PM, Brian Campbell > > wrote:
>> 
>> Thanks for the review and comments Justin. Replies (or attempts thereat) are 
>> inline below.
>> 
>> 
>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer > > wrote:
>> I’ve done a full read through of the PAR specification, and here are my 
>> notes on it.
>> 
>> 
>> ¶2: Of necessity, this spec mixes parameters in the authorization 
>> endpoint and token endpoint registries into a single request. Is there any 
>> danger of conflict between them? The registry holds them in one list but 
>> they could possibly have different semantics in both places.
>> 
>> I think that technically such danger does exist but that it's highly 
>> unlikely in practice. Especially because the only token endpoint parameters 
>> that are relevant to PAR are those that deal with client authentication 
>> (currently client_secret, client_assertion, and client_assertion_type). I'm 
>> also not sure what can reasonably be done about it given the way the 
>> registries are. I guess PAR could update the registration for those three 
>> (client_secret, client_assertion, and client_assertion_type) to also 
>> indicate authorization request as a usage location with some commentary that 
>> it's only for avoiding name collisions. And offer some guidance about doing 
>> the same for any future client auth methods being defined. But honestly I'm 
>> not sure what, if anything, to do here?  
>> 
>> And yes it is super unfortunate that client auth and protocol parameters got 
>> mixed together in the HTTP body. I didn't cause that situation but I've 
>> certainly contributed to it and for that I apologize. 
> 
> I think the only perfect solution is to go back in time and fix the 
> registries with based on the last decade of knowledge in using them. :P 
> 
> For this, I think maybe being very prescriptive about the fact that the only 
> parameters from the token endpoint that are allowed here are those used for 
> client authentication and that when they show up, they’re interpreted as in 
> the token endpoint request not the authorization endpoint request. Does that 
> work?
> 
> I think so, yes. And will work on incorporating some text towards that end. 
> 
> 
>  
>> I don’t see why a request URI with unguessable values isn’t a MUST for 
>> one-time-use, is there a reason?
>> 
>> The reason AFAIK was to not be overly prescriptive and allow for eventually 
>> consistent or not atomic storage of the data by not strictly requiring the 
>> AS to enforce one-time-use. Do you think that's too loose or could be 
>> worded/explained differently or better? 
> 
> I do think it’s too loose and it should be a MUST, and the methods for 
> enforcing that “MUST” are going to vary based on the deployments and 
> implementations 

Re: [OAUTH-WG] WGLC Review of PAR

[Dick Hardt]

I think one-time use may be overly restrictive, and I don't think it is the
property that we actually want.

Give the request URI is in a redirect from the browser, there is a good
chance of a race condition where the same browser request is made more than
once, for example, while the browser is loading the authorization URL at
the AS, the user could refresh the page causing the authorization URL to be
reloaded. Would the reload count as a second use? One could argue it
either way.

What I think we want from what I understand, is the request URI MUST be
unique so that there is no confusion on which request is being referenced.

I did not see anything about the expiry time of the request URI (but I did
not look super hard). If that is not there, then I think the request URI
MUST expire in a "short" period of time.



ᐧ

On Wed, Aug 26, 2020 at 1:45 PM Brian Campbell  wrote:

> Thanks Justin. Just a couple more responses to responses inline below (but
> with lots of content that needs no further discussion removed).
>
> A TL;DR for the WG is that I'd like to get some wider feedback on the
> question of changing the one-time-use condition on the request_uri from a
> SHOULD to a MUST.
>
> On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:
>
>> Hi Brian, just a couple responses inline where it seemed fitting. Thanks
>> for going through everything!
>>  — Justin
>>
>> On Aug 25, 2020, at 6:01 PM, Brian Campbell 
>> wrote:
>>
>> Thanks for the review and comments Justin. Replies (or attempts thereat)
>> are inline below.
>>
>>
>> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:
>>
>>> I’ve done a full read through of the PAR specification, and here are my
>>> notes on it.
>>>
>>>
 ¶2: Of necessity, this spec mixes parameters in the authorization
 endpoint and token endpoint registries into a single request. Is there any
 danger of conflict between them? The registry holds them in one list but
 they could possibly have different semantics in both places.

>>>
>>> I think that technically such danger does exist but that it's highly
>>> unlikely in practice. Especially because the only token endpoint parameters
>>> that are relevant to PAR are those that deal with client authentication
>>> (currently client_secret, client_assertion, and client_assertion_type). I'm
>>> also not sure what can reasonably be done about it given the way the
>>> registries are. I guess PAR could update the registration for those three
>>> (client_secret, client_assertion, and client_assertion_type) to also
>>> indicate authorization request as a usage location with some commentary
>>> that it's only for avoiding name collisions. And offer some guidance about
>>> doing the same for any future client auth methods being defined. But
>>> honestly I'm not sure what, if anything, to do here?
>>>
>>> And yes it is super unfortunate that client auth and protocol parameters
>>> got mixed together in the HTTP body. I didn't cause that situation but I've
>>> certainly contributed to it and for that I apologize.
>>>
>>
>> I think the only perfect solution is to go back in time and fix the
>> registries with based on the last decade of knowledge in using them. :P
>>
>> For this, I think maybe being very prescriptive about the fact that the
>> only parameters from the token endpoint that are allowed here are those
>> used for client authentication and that when they show up, they’re
>> interpreted as in the token endpoint request not the authorization endpoint
>> request. Does that work?
>>
>
> I think so, yes. And will work on incorporating some text towards that
> end.
>
>
>
>
>> I don’t see why a request URI with unguessable values isn’t a MUST
>>> for one-time-use, is there a reason?
>>>
>>
>> The reason AFAIK was to not be overly prescriptive and allow for
>> eventually consistent or not atomic storage of the data by not strictly
>> requiring the AS to enforce one-time-use. Do you think that's too loose or
>> could be worded/explained differently or better?
>>
>>
>> I do think it’s too loose and it should be a MUST, and the methods for
>> enforcing that “MUST” are going to vary based on the deployments and
>> implementations out there.
>>
>>
> I'd be okay with making it a MUST but think maybe it'd be good to hear
> from a few more people in the WG before committing to that change.
>
> Can I ask some folks to weigh in on this one? I'm leaning towards making
> the change barring objections.
>
>
> *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
> OAuth@ietf.org
> 

Re: [OAUTH-WG] WGLC Review of PAR

[Brian Campbell]

Thanks Justin. Just a couple more responses to responses inline below (but
with lots of content that needs no further discussion removed).

A TL;DR for the WG is that I'd like to get some wider feedback on the
question of changing the one-time-use condition on the request_uri from a
SHOULD to a MUST.

On Tue, Aug 25, 2020 at 4:57 PM Justin Richer  wrote:

> Hi Brian, just a couple responses inline where it seemed fitting. Thanks
> for going through everything!
>  — Justin
>
> On Aug 25, 2020, at 6:01 PM, Brian Campbell 
> wrote:
>
> Thanks for the review and comments Justin. Replies (or attempts thereat)
> are inline below.
>
>
> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:
>
>> I’ve done a full read through of the PAR specification, and here are my
>> notes on it.
>>
>>
>>> ¶2: Of necessity, this spec mixes parameters in the authorization
>>> endpoint and token endpoint registries into a single request. Is there any
>>> danger of conflict between them? The registry holds them in one list but
>>> they could possibly have different semantics in both places.
>>>
>>
>> I think that technically such danger does exist but that it's highly
>> unlikely in practice. Especially because the only token endpoint parameters
>> that are relevant to PAR are those that deal with client authentication
>> (currently client_secret, client_assertion, and client_assertion_type). I'm
>> also not sure what can reasonably be done about it given the way the
>> registries are. I guess PAR could update the registration for those three
>> (client_secret, client_assertion, and client_assertion_type) to also
>> indicate authorization request as a usage location with some commentary
>> that it's only for avoiding name collisions. And offer some guidance about
>> doing the same for any future client auth methods being defined. But
>> honestly I'm not sure what, if anything, to do here?
>>
>> And yes it is super unfortunate that client auth and protocol parameters
>> got mixed together in the HTTP body. I didn't cause that situation but I've
>> certainly contributed to it and for that I apologize.
>>
>
> I think the only perfect solution is to go back in time and fix the
> registries with based on the last decade of knowledge in using them. :P
>
> For this, I think maybe being very prescriptive about the fact that the
> only parameters from the token endpoint that are allowed here are those
> used for client authentication and that when they show up, they’re
> interpreted as in the token endpoint request not the authorization endpoint
> request. Does that work?
>

I think so, yes. And will work on incorporating some text towards that end.




> I don’t see why a request URI with unguessable values isn’t a MUST for
>> one-time-use, is there a reason?
>>
>
> The reason AFAIK was to not be overly prescriptive and allow for
> eventually consistent or not atomic storage of the data by not strictly
> requiring the AS to enforce one-time-use. Do you think that's too loose or
> could be worded/explained differently or better?
>
>
> I do think it’s too loose and it should be a MUST, and the methods for
> enforcing that “MUST” are going to vary based on the deployments and
> implementations out there.
>
>
I'd be okay with making it a MUST but think maybe it'd be good to hear from
a few more people in the WG before committing to that change.

Can I ask some folks to weigh in on this one? I'm leaning towards making
the change barring objections.

-- 
_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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] WGLC review of PAR

[Brian Campbell]

Thanks Neil. Appreciate the review and feedback. My attempts at responses
are inline below.


On Thu, Aug 20, 2020 at 5:30 AM Neil Madden 
wrote:

> As promised in the last interim meeting, I’ve reviewed the current (03)
> draft-ietf-oauth-par document. Overall it looks close to ready to me, with
> mostly minor comments and one security-relevant comment on section 2.1 that
> should be discussed further, and one additional proposed security
> consideration:
>
> Abstract:
> The wording here could be improved - “allows clients to push an
> authorization request […] used as a reference to the data in a subsequent
> authorization request.” Both the pushed data and the call to the
> authorization endpoint are referred to as an “authorization request”. Maybe
> change the second usage to “in a subsequent call to the authorization
> endpoint”.
>

Makes sense.


>
> Section 1:
> The introductory part here is quite long. Maybe adding a new sub-heading
> before the example would make it flow better.
>

Will look at breaking it up.


>
> The end of the introduction uses the acronym “PAR” for the first time, but
> never explicitly defines it.
>

Will fix.


>
> I agree with Justin that ACR is not the best example to lead with. If it
> stays there should be a reference to OIDC to explain what this means.
>

Yup.


>
> The paragraph that begins “It also allows clients to push the form encoded
> …” is confusing because the use of “also” suggests this is different from
> the previous paragraph, but it seems to actually be saying the same thing?
>

Yeah, that is rather awkward because it is the same thing. Will fix.


>
> “[…] but it also allows clients requiring
>
>an even higher security level, especially cryptographically confirmed
>non-repudiation, to explicitly adopt JWT-based request objects”
>
>
> The “but” should be an “and” in this paragraph. It’s also not clear what is 
> being said here - isn’t JAR what provides JWT-based request objects?
>
>
Yeah, JAR defines JWT-based request objects and PAR allows for their use by
sending the 'request' parameter to the PAR endpoint.  Will try and make
that more clear.


>
> The paragraph beginning “As a further benefit, …” is a little bit of a 
> Columbo moment (“Just one more thing…”) at the end of the introduction. Maybe 
> move this as another bullet point at the start of the section. The following 
> paragraph can then be rewritten as “The increased confidence in the identity 
> of the client during the authorization process allows confidential clients to 
> provide a different redirect_uri on every request. […]”
>
>
 Agree with the sentiment here and will endeavor to rework things along the
lines of the suggestion.



> Section 2:
>
> The 3rd paragraph contains statements like
>
> The endpoint also supports sending all authorization
>
>request parameters as request object according to
>[I-D.ietf-oauth-jwsreq 
> ].
>
> presumably this is not a normative requirement that any PAR implementation
> has to also support JAR, or is it? Maybe change the wording to “MAY also
> support …”.
>

Interesting question. PAR has a normative reference to JAR for the
request_uri parameter at the authz endpoint. But does that necessitate that
every PAR implementation also has to support all of JAR? I'm thinking
probably not. I mean, different but related, an AS PAR implementation might
legitimately support the request_uri parameter with URI values that it
creates but not support the more general retrieval of arbitrary URIs. In
the same vein, it seems legit and still useful to support PAR without also
supporting request object JWTs. So yeah, I think changing this to MAY or
something similar would be appropriate.


>
> The first mention of “token_endpoint_auth_method” and client metadata
> should have a reference to RFC 7591 - currently it’s only referenced later
> in section 2.1.
>

Will fix.

2.1:
> I’m a little bit wary of the relaxing of the redirect_uri processing
> rules, because this removes a layer of defence in depth. With the current
> requirement for pre-registered URIs an attacker needs to compromise the
> redirect endpoint *and* the client credentials in order to steal an
> authorization code and use it. With this change, compromising the client
> credentials alone would be enough. If the use-case is specifically in a PKI
> environment, could the redirect_uri be baked into the cert? Maybe this
> use-case could be better addressed in a separate draft.
>

 I agree that the specifics of a PKI type environment use-case would be
better in a separate draft or profile somewhere. And do plan to add some
more considerations around the possibility of relaxed redirect_uri
validation.


2.2:
> The definition of “expires_in” as a "JSON number" suggests that
> fractional/floating-point values are allowed. Presumably this is intended
> to be an integer?
>

Yes and I need to clarify that it's a positive 

Re: [OAUTH-WG] WGLC Review of PAR

[Justin Richer]

Hi Brian, just a couple responses inline where it seemed fitting. Thanks for 
going through everything!
 — Justin

> On Aug 25, 2020, at 6:01 PM, Brian Campbell  
> wrote:
> 
> Thanks for the review and comments Justin. Replies (or attempts thereat) are 
> inline below.
> 
> 
> On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  > wrote:
> I’ve done a full read through of the PAR specification, and here are my notes 
> on it.
> 
> For additional context, I’ve implemented this specification for both a client 
> and a server in a couple of languages. Overall, I think it’s in good shape 
> and it makes sense from a developer’s perspective. I’ve got a few comments, 
> some small and some that might need more conversation within the WG,
> 
> Always nice to get feedback from implementation experience. Especially when 
> the overall is that it's "in good shape".
> 
> 
> Throughout: Suggest using “credentialed” instead of “confidential” client, as 
> introduced in OAuth 2.1 draft.
> 
> I'm hesitant to use *new* terminology from the 2.1 draft, which was just 
> recently adopted by the WG, in this document that is written as an extension 
> of OAuth 2.0 and is further along in the process going through WGLC. There's 
> a temporal dependency problem including potential risk of change after the 
> fact. 
> 
> Perhaps this draft could avoid use of the terms and be more explicit and 
> wordy with something like "clients having established authentication 
> credentials with the AS"? 

Fair point about the terminology, and while it’s verbose I think the more 
precise wording might be warranted here so as not to extend the problems and 
confusion with “confidential” clients as a term.

> 
>  
> §1: Suggest the problems list start with changing scopes or swapping client 
> IDs as scenarios in the first bullet, ACR is an esoteric use case for many 
> and not in OAuth 2 core, either remove it or put it at the end of the bullet.
> 
> Fair suggestion. Will look at reworking it a bit. 
>  
> 
>Suggest the second bullet note who the information needs to be protected 
> from, at least in passing. It’s not clear from this setup why the parameters 
> should be confidential, and this is a major motivation for this work.
> 
> Also a fair suggestion. Although there are some subtleties and complexities 
> that I think make this a little tricky to write. Will try though. 
> 
>  
>Avoid use of phrase “so-called” and just give the name “Request Object”.
> 
> Okay, yeah. I think a moment of terminology frustration slipped into the text 
> there. 
>  
> 
> 
>¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a 
> request_uri value usable at the authorization server”. 
> 
> I like the pedanticness. 
>  
> 
>¶4/5: Alternatively, suggest combining these paragraphs: “This document 
> complements JAR by providing an interoperable way for the client to push its 
> authorization request parameters to the authorization server in exchange for 
> a request_uri usable at the authorization server. The document further allows 
> the client to push request objects as specified in JAR in exchange for a 
> request_uri usable at the authorization server.”
> 
>  Yeah, I think that working works better. 
> 
>  
> ¶12: “This is directly utilized” is a little ambiguous into what it’s 
> referring to. Would suggest rewording the start as: “This early stage client 
> authentication is used by this draft to allow confidential clients…” or 
> something of that sort.
> 
> Makes sense to be less ambiguous there. 
>  
> 
> ¶13: Not only is POST much harder to use, it’s also optional for the AS 
> to implement so it can’t be counted on by a client to be available generally. 
> (To be honest in retrospect we shouldn’t have included it in OAuth 2.)
> 
> Connect says the AS/OP must support both get and post. But your point on 
> optionality stands with respect to pure OAuth only ASs. Will add something 
> about that to the paragraph. 
>  
> 
> §2: Please provide a reference to JWT client assertion auth here (either the 
> assertion RFC or OIDC’s definition of the client auth methods mentioned). I 
> would also phrase this as direct guidance instead of a note/aside.
> 
> Will do. 
>  
> 
> §2.1: There’s some potential weirdness about client_id here. Since the authz 
> request was designed around not having client authentication, that request 
> requires client_id. However, here the client is authenticating, and the 
> client_id might be included elsewhere like the Basic header. A developer 
> might be curious about whether they need to include them twice.
> 
> Fair point about the weirdness. Suggestions on some text to preempt curiosity 
> or confusion? My thinking is that the client_id parameter should always be 
> sent so as to conform to the syntax of a regular authz request. But I'll 
> admit that, due to reusing client auth logic, my server implementation won't 
> strictly require client_id when it's 

Re: [OAUTH-WG] WGLC Review of PAR

[Brian Campbell]

Thanks for the review and comments Justin. Replies (or attempts thereat)
are inline below.


On Wed, Aug 19, 2020 at 2:06 PM Justin Richer  wrote:

> I’ve done a full read through of the PAR specification, and here are my
> notes on it.
>
> For additional context, I’ve implemented this specification for both a
> client and a server in a couple of languages. Overall, I think it’s in good
> shape and it makes sense from a developer’s perspective. I’ve got a few
> comments, some small and some that might need more conversation within the
> WG,
>

Always nice to get feedback from implementation experience. Especially when
the overall is that it's "in good shape".


Throughout: Suggest using “credentialed” instead of “confidential” client,
> as introduced in OAuth 2.1 draft.
>

I'm hesitant to use *new* terminology from the 2.1 draft, which was just
recently adopted by the WG, in this document that is written as an
extension of OAuth 2.0 and is further along in the process going through
WGLC. There's a temporal dependency problem including potential risk of
change after the fact.

Perhaps this draft could avoid use of the terms and be more explicit and
wordy with something like "clients having established authentication
credentials with the AS"?



> §1: Suggest the problems list start with changing scopes or swapping
> client IDs as scenarios in the first bullet, ACR is an esoteric use case
> for many and not in OAuth 2 core, either remove it or put it at the end of
> the bullet.
>

Fair suggestion. Will look at reworking it a bit.


   Suggest the second bullet note who the information needs to be protected
> from, at least in passing. It’s not clear from this setup why the
> parameters should be confidential, and this is a major motivation for this
> work.
>

Also a fair suggestion. Although there are some subtleties and complexities
that I think make this a little tricky to write. Will try though.



>Avoid use of phrase “so-called” and just give the name “Request Object”.
>

Okay, yeah. I think a moment of terminology frustration slipped into the
text there.



>¶4: Perhaps overly pedantic but I suggest extending: “in exchange for a
> request_uri value usable at the authorization server”.
>

I like the pedanticness.


>
>¶4/5: Alternatively, suggest combining these paragraphs: “This document
> complements JAR by providing an interoperable way for the client to push
> its authorization request parameters to the authorization server in
> exchange for a request_uri usable at the authorization server. The document
> further allows the client to push request objects as specified in JAR in
> exchange for a request_uri usable at the authorization server.”
>

 Yeah, I think that working works better.



> ¶12: “This is directly utilized” is a little ambiguous into what it’s
> referring to. Would suggest rewording the start as: “This early stage
> client authentication is used by this draft to allow confidential clients…”
> or something of that sort.
>

Makes sense to be less ambiguous there.


>
> ¶13: Not only is POST much harder to use, it’s also optional for the
> AS to implement so it can’t be counted on by a client to be available
> generally. (To be honest in retrospect we shouldn’t have included it in
> OAuth 2.)
>

Connect says the AS/OP must support both get and post. But your point on
optionality stands with respect to pure OAuth only ASs. Will add something
about that to the paragraph.


>
> §2: Please provide a reference to JWT client assertion auth here (either
> the assertion RFC or OIDC’s definition of the client auth methods
> mentioned). I would also phrase this as direct guidance instead of a
> note/aside.
>

Will do.


>
> §2.1: There’s some potential weirdness about client_id here. Since the
> authz request was designed around not having client authentication, that
> request requires client_id. However, here the client is authenticating, and
> the client_id might be included elsewhere like the Basic header. A
> developer might be curious about whether they need to include them twice.
>

Fair point about the weirdness. Suggestions on some text to preempt
curiosity or confusion? My thinking is that the client_id parameter should
always be sent so as to conform to the syntax of a regular authz request.
But I'll admit that, due to reusing client auth logic, my server
implementation won't strictly require client_id when it's included
elsewhere like the Basic header.


>
> ¶2: Of necessity, this spec mixes parameters in the authorization
> endpoint and token endpoint registries into a single request. Is there any
> danger of conflict between them? The registry holds them in one list but
> they could possibly have different semantics in both places.
>

I think that technically such danger does exist but that it's highly
unlikely in practice. Especially because the only token endpoint parameters
that are relevant to PAR are those that deal with client authentication
(currently