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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to