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
