I gone draft this section.
> Am 29.08.2020 um 17:22 schrieb Justin Richer <jric...@mit.edu>: > > 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”? >> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
