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

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 1 Sep 2020 20:48:13 +0200

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 <[email-masked]> 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 <[email-masked]> 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”?
>> 
>>> 
>> 
>

---

From: Takahiko Kawasaki <[email-masked]>
Date: Wed, 2 Sep 2020 12:05:49 +0900

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

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 2 Sep 2020 10:09:21 -0400

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 <[email-masked]> 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 <torsten=[email-masked] <mailto:[email-masked]>> wrote:
> > On 29. Aug 2020, at 17:22, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> 
> >>> 
> >>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Sep 2020 13:41:35 -0600

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 <[email-masked]> 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:
>
> 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
> 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
>
> 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.)
>> > 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
>> >>>   ¶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.
>> >>>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Justin Richer <[email-masked]>
Date: Thu, 3 Sep 2020 00:29:25 +0000

Nice work, Brian. Looks good to me! 
________________________________________
From: Brian Campbell [[email-masked]]
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

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.

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

 — Justin

On Sep 1, 2020, at 11:05 PM, Takahiko Kawasaki <[email-masked]<mailto:[email-masked]>> wrote:

Best Regards,
Takahiko Kawasaki

On Wed, Sep 2, 2020 at 3:48 AM Torsten Lodderstedt <torsten=[email-masked]<mailto:[email-masked]>> wrote:
Here is my proposal for the new section:

> On 29. Aug 2020, at 17:22, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>>
>>>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 3 Sep 2020 08:11:12 +0200

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

---

From: Brian Campbell <[email-masked]>
Date: Thu, 3 Sep 2020 05:33:37 -0600

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

On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt <[email-masked]>
wrote:

> > 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.
> >
> > 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
> > 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
> > 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 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".
> >
> > 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.
> >
> [email-masked]<mailto:[email-masked]>>
> wrote:
> >>>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt <
> [email-masked]<mailto:[email-masked]>> wrote:
> >>>
> >>>
> >>>>
> >>>>
> > CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.
>

---

From: Dave Tonge <[email-masked]>
Date: Thu, 3 Sep 2020 14:14:25 +0200

Looks really good to me, thanks Brian.

On Wed, 2 Sep 2020 at 21:42, Brian Campbell <bcampbell=
[email-masked]> wrote:

>>> [email-masked]> wrote:
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> >> 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
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]

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

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

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

-- 

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

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 3 Sep 2020 14:25:25 +0200

yes.

> On 3. Sep 2020, at 13:33, Brian Campbell <[email-masked]> wrote:
> 
> On Thu, Sep 3, 2020 at 12:11 AM Torsten Lodderstedt <[email-masked]> wrote:
> Thanks Brian!
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 3 Sep 2020 16:28:54 +0200

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

> On 3. Sep 2020, at 14:14, Dave Tonge <[email-masked]> wrote:
> 
> On Wed, 2 Sep 2020 at 21:42, Brian Campbell <bcampbell=[email-masked]> wrote:
>> On Wed, Sep 2, 2020 at 3:48 AM Torsten Lodderstedt <torsten=[email-masked]> wrote:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
>