yes.

> On 3. Sep 2020, at 13:33, Brian Campbell <bcampb...@pingidentity.com> 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 <tors...@lodderstedt.net> 
> 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 <jric...@mit.edu>:
> > 
> > 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<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 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 
> > <t...@authlete.com<mailto:t...@authlete.com>> 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=40lodderstedt....@dmarc.ietf.org<mailto:40lodderstedt....@dmarc.ietf.org>>
> >  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 
> >> <jric...@mit.edu<mailto:jric...@mit.edu>> 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<mailto: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, 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<mailto:OAuth@ietf.org>
> > 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.
> 
> 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

Reply via email to