Thanks to all. I incorporated the text into the upcoming next revision of the draft.
> On 3. Sep 2020, at 14:14, Dave Tonge <dave.to...@momentumft.co.uk> wrote: > > Looks really good to me, thanks Brian. > > On Wed, 2 Sep 2020 at 21:42, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> 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 <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> 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> 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> 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, 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 > > > 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 > > > -- > Dave Tonge > CTO > > 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/. 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. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
