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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth