From nobody Thu Sep 3 05:14:45 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A873A09DE for ; Thu, 3 Sep 2020 05:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihDjHujQJ7Cd for ; Thu, 3 Sep 2020 05:14:39 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22DE3A09BC for ; Thu, 3 Sep 2020 05:14:38 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id l17so2382235edq.12 for ; Thu, 03 Sep 2020 05:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZjH6NEKxMr5gtqJlx3XkMD/GeVOLnSpXkD9nyDpiOTE=; b=Dylq8etVEDk348FKj9uiuHlMjiUTsuHHPOrodHjRtR5C6CAKfjxtq8UvIhGYhjKXJR W48cXuAQ9SIBmO/ZXm84XFlgN95DZQ3in4awefLSe7Q2EiOevDDeUakWyNmlO3norxkl xaTc1Ewq6GVzRb16X6b1AEqMiFjj9vjHSMuDQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZjH6NEKxMr5gtqJlx3XkMD/GeVOLnSpXkD9nyDpiOTE=; b=kcG54pLSZIThaegfY1Jmr1VueGbDMPWF01Mwg51sI0vECrB0TJOy7ojUZXYkzS797I dP5CPzHuyBxTp63yQmh+m/I6CVF7WRNLmTbvJrnUiresPjLvV1ogWU2DOxCxoC48fKTJ hutUm2LH4yjXBZBmTNEkdA0UC8hnhtUxQkjH2mXYCO0Sd7fCLAJJ8Isaj0ciaLFfOtIQ wN0W7QVLnZqGEaclZ2myO97ohIZmBNdpE/7+MkkRwogoPUcnUw0ZqS2LIeWMoBXtiUUh jIzQGRwB3V3LuZ37coJjP3czP4j0uJrJj3075Ihjnz2cvB9LgMEnVhnEuilSvAY7KxDB o6Gw== X-Gm-Message-State: AOAM531FkQe9s89YjjBTmXR0C0Cbz1VrdlGYbhD3uJT2mt/IdlfPPE/x zCU1PYvc0apnWJEeAgjaOO7z4QeBcghTRvyp+nMDERELPF7VGFnOpVTSWQ5E9lDFjawdOEJVLS5 9woFjvZ5wO0kPlNEBky/0JQ== X-Google-Smtp-Source: ABdhPJzlvWAhPuW692gz703FpG7KR2m2hgfvoW/f6GHwh6agonsXdTp5rJ+YV8I8laV78ObtFkGh39UFtb4m+BzyNHs= X-Received: by 2002:a05:6402:1016:: with SMTP id c22mr2815820edu.89.1599135277014; Thu, 03 Sep 2020 05:14:37 -0700 (PDT) MIME-Version: 1.0 References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> <03845E0A-3563-4FF5-A3F9-318A1C928B89@mit.edu> <61CD8CC7-D16F-4D2A-A43E-2C80DC5B565A@lodderstedt.net> <57BB7167-377D-451C-891F-E04B9A10372F@mit.edu> In-Reply-To: From: Dave Tonge Date: Thu, 3 Sep 2020 14:14:25 +0200 Message-ID: To: Brian Campbell Cc: Justin Richer , oauth Content-Type: multipart/alternative; boundary="000000000000227e3505ae67b256" Archived-At: Subject: Re: [OAUTH-WG] WGLC Review of PAR X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2020 12:14:43 -0000 --000000000000227e3505ae67b256 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Looks really good to me, thanks Brian. On Wed, 2 Sep 2020 at 21:42, Brian Campbell 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) an= d > can simplify client management. It is at the discretion of the > authorization server to apply restrictions on supplied redirect_uri value= s, > 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 i= n > situations where client ids and corresponding credentials and policies ar= e > 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 nee= d > for an additional registration step. > > On Wed, Sep 2, 2020 at 8:09 AM Justin Richer 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. T= hat >> said, I think adding some of Taka=E2=80=99s observations to Torsten=E2= =80=99s text wouldn=E2=80=99t >> hurt: >> >> 2.4. Management of redirect_uri >> >> While OAuth 2.0 [RFC6749] allows clients to use unregistered redirect_ur= i >> 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 s= et >> 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 befo= re >> the authorization process starts and that way ensures it interacts with = the >> legit client. The AS MAY allow such clients to specify redirect_uri valu= es >> 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 make= s >> client management much easier. It is at the discretion of the AS to appl= y >> restriction on redirect_uri values, e.g. the AS MAY require a certain UR= I >> prefix or allow only a query parameter to vary at runtime. >> >> I also feel like this paragraph belongs in a different section outside o= f >> here. I=E2=80=99m not sure where, but it doesn=E2=80=99t quite seem to f= it, to me. It=E2=80=99s not >> the end of the world if it stays here though as it=E2=80=99s a decent vi= ew on the >> =E2=80=9Cwhy". >> >> >> 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 containi= ng >> client permissions. Such an externally managed client could interact wit= h >> an AS trusting the respective 3rd party without the need for an addition= al >> registration step. >> >> >> =E2=80=94 Justin >> >> On Sep 1, 2020, at 11:05 PM, Takahiko Kawasaki 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 n= ot >> 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 > 40lodderstedt.net@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 OAut= h >>> 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 imperson= ate >>> a client and prevent token leakage and open redirection. As a downside,= it >>> makes client management more complex since the redirect URI is typicall= y >>> the most volatile part of a client policy. >>> >>> This requirement MAY be relaxed by the AS, if a confidential client use= s >>> pushed authorization requests since the AS authenticates the client bef= ore >>> the authorization process starts and that way ensures it interacts with= the >>> legit client. The AS MAY allow such clients to specify redirect_uri val= ues >>> 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 mak= es >>> client management much easier. It is at the discretion of the AS to app= ly >>> restriction on redirect_uri values, e.g. the AS MAY require a certain U= RI >>> 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 certifiate= s >>> 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 wrote: >>> > >>> > I completely agree with the utility of the function in question here >>> and it needs to be included. I=E2=80=99m in favor of creating a dedicat= ed 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 U= RIs >>> an authenticated client might be able to use. For example, registering = a >>> client with a Redirect URI prefix, or allowing only a query parameter t= o >>> 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 determin= e >>> which policies should apply. >>> > >>> > =E2=80=94 Justin >>> > >>> >> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >> >>> >> >>> >>> >>> >>> >>> >>> =C2=B66: Does the AS really have "the ability to authenticate and >>> authorize clients=E2=80=9D? I think what we mean here is "the ability t= o >>> authenticate clients and validate client requests=E2=80=9D, but I=E2=80= =99m 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 authorizati= on >>> 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 =E2=80=9Cvalidate" is fine. >>> >> >>> >>> >>> >>> >>> >>> >>> >>> =C2=B67: I=E2=80=99m not sure I buy this example. Even if the cli= entID 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 tha= t >>> is. I think this example could lead an AS developer to (erroneously and >>> dangerously) conclude that they don=E2=80=99t have to check any other v= alues in a >>> request, including scope and redirect URI. It=E2=80=99s important that = DynReg >>> doesn=E2=80=99t alleviate that issue, but removal of DynReg doesn=E2=80= =99t 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 d= raft >>> would be better off without it. >>> >>> >>> >> >>> >> In the traditional authorization flow, the redirect_uri serves as wa= y >>> to make sure the AS is really talking to the legit client and the allow= ed >>> 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=E2=80=99s why I don=E2=80=99t see an issue wi= th letting the >>> client set a per transaction redirect_uri. This will give the client mo= re >>> flexibility (mint AS-specific redirect URIs on the fly) and makes clien= t >>> management much easier since redirect URIs are the most volatile part o= f 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 eIDA= S >>> 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=E2=80= =99t contain >>> OAuth policy values. Nevertheless, the regulation requires any financia= l >>> institution in the EU to at runtime, without any registration, to accep= t >>> 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 me= ans >>> 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=E2=80=99t 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 ab= out >>> moving it into a special section "redirect_uri management=E2=80=9D? >>> >> >>> >>> >>> >> >>> > >>> >>> _______________________________________________ >>> 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 sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Dave Tonge CTO [image: Moneyhub Enterprise] 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 =C2=A9 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. --=20 Moneyhub Enterprise is a trading style of Moneyhub Financial Technology=20 Limited which is authorised and regulated by the Financial Conduct=20 Authority ("FCA"). Moneyhub Financial Technology is entered on the=20 Financial Services Register (FRN 809360) at https://register.fca.org.uk/=20 . Moneyhub Financial Technology is registered= =20 in England & Wales, company registration number 06909772. Moneyhub=20 Financial Technology Limited 2020 =C2=A9 Moneyhub Enterprise, Regus Buildin= g,=20 Temple Quay, 1 Friary, Bristol, BS1 6EA.=C2=A0 DISCLAIMER: This email=20 (including any attachments) is subject to copyright, and the information in= =20 it is confidential. Use of this email or of any information in it other=20 than by the addressee is unauthorised and unlawful. Whilst reasonable=20 efforts are made to ensure that any attachments are virus-free, it is the= =20 recipient's sole responsibility to scan all attachments for viruses. All=20 calls and emails to and from this company may be monitored and recorded for= =20 legitimate purposes relating to this company's business. Any opinions=20 expressed in this email (or in any attachments) are those of the author and= =20 do not necessarily represent the opinions of Moneyhub Financial Technology= =20 Limited or of any other group company. --000000000000227e3505ae67b256 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks really good to me, thanks Brian.

On Wed, 2 Sep = 2020 at 21:42, Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
<= div>Thanks Torsten, Taka, and Justin,

I took the r= evised text from Justin and tweaked it with some typo cleanup and minor adj= ustments 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 be= tter location to suggest so am just leaving it.

2.4. Management of Client Redirect URIs
While OAuth 2.0 [RFC6749] allows=20 clients to use unregistered redirect_uri values in certain=20 circumstances, or for the authorization server to apply its own matching se= mantics to the=20 redirect_uri value presented by the client at the authorization=20 endpoint, the OAuth Security BCP [I-D.ietf-oauth-security-topics]=20 as well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an authorization server = exactly=20 match the redirect_uri parameter against the set of redirect URIs=20 previously established for a particular client. This is a means for early detection of client impersonation attempts and prevents token leakage and= =20 open redirection. As a downside, this can make client management more cumbe= rsome since the redirect URI is typically the most volatile part of a client=20 policy.

The exact=20 matching requirement MAY be relaxed by the authorization server for a=20 confidential client using pushed authorization requests since the authoriza= tion server authenticates the client before the authorization process starts and thus e= nsures it is interacting with the legitimate client. The authorization serv= er MAY allow=20 such clients to specify redirect_uri values that were not previously regist= ered=20 with the authorization server. This will give the client more flexibility = (e.g. to mint distinct redirect URI values per authorization server at runt= ime) and can simplify client management. It is at the discretion of the aut= horization server to apply restrictions on supplied redirect_uri values, e.g. the authorization server MAY require a certain UR= I prefix or=20 allow only a query parameter to vary at runtime.

The ability to set up = transaction specific redirect URIs is also useful in situations where clien= t ids and corresponding credentials and policies are managed by a trusted 3= rd party, e.g. via client certificates containing client permissions. Such = an externally managed client could interact with an authorization server tr= usting the respective 3rd party without the need for an additional registra= tion step.

On Wed, Sep 2, 2020 at 8:09 AM Justin Richer <jricher@mit.edu> wrote:
The real con= flict here is with the BCP and 2.1, both of which adopt the stricter matchi= ng semantics for redirect URIs than 6749 does on its own. This section woul= d be needed to clarify how they relate to each other. That said, I think ad= ding some of Taka=E2=80=99s observations to Torsten=E2=80=99s text wouldn= =E2=80=99t hurt:

2.4. Management of=C2=A0redirect_uri<= br>
While OAuth 2.0 [RFC6749] allows clients to use unregistered redirec= t_uri values in certain circumstances, or for the AS to apply its own match= ing semantics to the redirect_uri value presented by the client at the auth= orization 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 est= ablished 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 require= ment MAY be relaxed by the AS if a confidential client uses pushed authoriz= ation requests since the AS authenticates the client before the authorizati= on 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. t= o mint AS-specific redirect URIs on the fly) and makes client management mu= ch easier. It is at the discretion of the AS to apply restriction on redire= ct_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=E2=80= =99m not sure where, but it doesn=E2=80=99t quite seem to fit, to me. It=E2= =80=99s not the end of the world if it stays here though as it=E2=80=99s a = decent view on the =E2=80=9Cwhy".

The aibility to set up= transaction specific redirect URIs is also useful in situations where clie= nt ids and correspoding credentials and policies are managed by a trusted 3= rd party, e.g. via client certifiates containing client permissions. Such a= n externally managed client could interact with an AS trusting the respecti= ve 3rd party without the need for an additional registration step.

=C2=A0=E2=80=94 Justin

On Sep 1, 2020, at 11:05 PM, Takahiko Kawasaki &l= t;taka@authlete.com<= /a>> wrote:

Under existing specifica= tions (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 c= lients register redirect URIs.)
2. The flow is not "implicit= ". (RFC 6749 Section 3.1.2.2 requires that confidential clients utiliz= ing the implicit grant type register redirect URIs.)
3. The autho= rization request is not an OIDC request. (OIDC Core 1.0 Section 3.1.2.1 req= uires that redirect_uri match a pre-registered one.)
4. The autho= rization request is not a FAPI request. (FAPI Part 1 Section 5.2.2 Clause 8= requires that redirect URIs be pre-registered.)

I= n short, under existing specifications, pure RFC-6749 authorization-code-fl= ow 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 conf= lict with existing specifications, it is better to list the conflicts expli= citly in the section.

Best Regards,
Taka= hiko Kawasaki


On Wed, Sep 2, 2020 at 3:48 AM Torsten Lo= dderstedt <torsten=3D40lodderstedt.net@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 pa= rameter against the set of redirect URIs previously established for a parti= cular client. This is a means to early detect attempts to impersonate a cli= ent and prevent token leakage and open redirection. As a downside, it makes= client management more complex since the redirect URI is typically the mos= t volatile part of a client policy.

This requirement MAY be relaxed by the AS, if a confidential client uses pu= shed authorization requests since the AS authenticates the client before th= e authorization process starts and that way ensures it interacts with the l= egit client. The AS MAY allow such clients to specify redirect_uri values n= ot previously registered with the AS. This will give the client more flexib= ility (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 restrict= ion 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 use= ful in situations where client ids and correspoding credentials and policie= s are managed by a trusted 3rd party, e.g. via client certifiates containin= g 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 <jricher@mit.edu> wrote:
>
> I completely agree with the utility of the function in question here a= nd it needs to be included. I=E2=80=99m in favor of creating a dedicated se= ction for redirect_uri management, so that we can explain exactly how and w= hy to relax the requirement from core OAuth. In addition, I think we want t= o discuss that the AS might have its own restrictions on which redirect URI= s 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 va= ry at runtime. All of these can be enforced in PAR because the client is pr= esenting its authentication, as you point out, so the AS can determine whic= h policies should apply.
>
> =E2=80=94 Justin
>
>> On Aug 29, 2020, at 7:52 AM, Torsten Lodderstedt <torsten@lodderstedt.net= > wrote:
>>
>>
>>>
>>>
>>>=C2=A0 =C2=A0=C2=B66: Does the AS really have "the ability= to authenticate and authorize clients=E2=80=9D? I think what we mean here = is "the ability to authenticate clients and validate client requests= =E2=80=9D, but I=E2=80=99m not positive of the intent.
>>>
>>> I think the intent is that the AS can check whether a client i= s authorized to make a particular authorization request (specific scopes, r= esponse 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 th= ink he originally wrote the text in question.
>>
>> that was the original intent. I think =E2=80=9Cvalidate" is f= ine.
>>
>>>
>>>
>>>
>>>=C2=A0 =C2=A0=C2=B67: I=E2=80=99m not sure I buy this example. = Even if the clientID is managed externally, the association with a set or p= attern 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 (err= oneously and dangerously) conclude that they don=E2=80=99t have to check an= y other values in a request, including scope and redirect URI. It=E2=80=99s= important that DynReg doesn=E2=80=99t alleviate that issue, but removal of= DynReg doesn=E2=80=99t really change things in that regard. Suggest removi= ng 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 thi= nking 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 allow= ed redirect_uri values are determined by the legit client at registration t= ime (might be manually).
>>
>> With PAR, we have a much stronger means to ensure the AS is talkin= g to the legit client. That=E2=80=99s why I don=E2=80=99t 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 mak= es 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 OAut= h). A prominent example is open banking in the EU (aka PSD2). The (technica= l) identity of any PSD2-licensed client is asserted by an eIDAS compliant C= A in a special X.509 certificate. Those certificates contain the permission= s (access to account information and/or payment initiation allowed) and the= identity (member state specific). But they don=E2=80=99t contain OAuth pol= icy values. Nevertheless, the regulation requires any financial institution= in the EU to at runtime, without any registration, to accept and process c= alls 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 credenti= al. Unfortunately, RFC 7591 does not support other client authentication me= ans 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 re= commended approach in at least one of the PSD2 specs.
>>
>> PAR is a clean way to solve that problem.
>>
>> I don=E2=80=99t want this text to cause confusing. On the other ha= nd this potential of PAR is way too important to not mention it at all. Wha= t about moving it into a special section "redirect_uri management=E2= =80=9D?
>>
>>>
>>
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Da= ve Tonge
CTO
3D"Moneyhub
Moneyhub Financial Technology, 5th Fl= oor, 10 Temple Back, Bristol, BS1 6FL
t:=C2=A0+44 (0)117 280 512= 0

Moneyhub = Enterprise is a trading style of Moneyhub Financial Technology Limited whic= h is authorised and regulated by the Financial Conduct Authority ("FCA= ").=C2=A0Moneyhub Financial Technology is entered on the Financial Ser= vices Register=C2=A0(FRN=C2=A0809360) at fca.= org.uk/register. Moneyhub=C2=A0Financial Technology is registered in England &= ; Wales, company registration number=C2=A0=C2=A006909772=C2=A0.<= /span>
Moneyhub=C2=A0Financial Technology L= imited 2018=C2=A0=C2=A9<= /div>

DISCLAIMER: This email (including any attachments) is subject to co= pyright, 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 unla= wful. Whilst reasonable efforts are made to ensure that any attachments are= virus-free, it is the recipient's sole responsibility to scan all atta= chments for viruses. All calls and emails to and from this company may be m= onitored and recorded for legitimate purposes relating to this company'= s business. Any opinions expressed in this email (or in any attachments) ar= e those of the author and do not necessarily represent the opinions of Mone= yhub Financial Technology Limited or of any other group company.
<= /div>

Moneyhub Enterprise is a trading style of Moneyhub Financi= al Technology Limited which is authorised and regulated by the Financial Co= nduct 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 Limite= d 2020 =C2=A9 Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, B= ristol, BS1 6EA.=C2=A0

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


--000000000000227e3505ae67b256--