Re: [OAUTH-WG] WGLC Review of PAR

[Takahiko Kawasaki]

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  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  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,
> 

Re: [OAUTH-WG] third party applications

[Dima Postnikov]

Good point Denis, thanks

The OAuth 2.1 authorization framework enables a*n* *third-party*
application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   *third-party* application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in RFC 6749 .


And an additional section is required to describe scenarios where this
framework works well and scenarios when it doesn't.


On Wed, Sep 2, 2020 at 12:57 AM Denis  wrote:

> Hello Dima,
>
> Not exactly.
>
> Change :
>
> or by allowing the third-party application
>
> into:
>
> or by allowing the application
>
>
> Denis
>
> Thank everyone for your feedback.
>
> So the abstract could look like this:
>
> The OAuth 2.1 authorization framework enables a*n* *third-party*   
> application to obtain limited access to an HTTP service, either on
>behalf of a resource owner by orchestrating an approval interaction
>between the resource owner and the HTTP service, or by allowing the
>third-party application to obtain access on its own behalf.  This
>specification replaces and obsoletes the OAuth 2.0 Authorization
>Framework described in RFC 6749 .
>
>  And an additional section is required to describe scenarios where this 
> framework works well and scenarios when it doesn't.
>
>
> On Sat, Aug 29, 2020 at 2:37 AM Aaron Parecki  wrote:
>
>> I agree. While the original motivations for OAuth were to support
>> third-party apps, it's proven to be useful in many other kinds of
>> situations as well, even when it's a "first-party" app but the OAuth server
>> is operated by a different organization than the APIs. I don't think the
>> abstract needs any qualification on this and would only confuse people
>> further. Any clarifications of which situations are appropriate for using
>> OAuth could be explored in a different section in the spec.
>>
>> Aaron Parecki
>>
>> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt > 40lodderstedt@dmarc.ietf.org> wrote:
>>
>>> I agree. OAuth works for 3rd as well as 1st parties as well.
>>>
>>> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
>>> >
>>> > Hi,
>>> >
>>> > Can "third-party" term be removed from the specification?
>>> >
>>> > The standard and associated best practices apply to other applications
>>> that act on behalf of a resource owner, too (internal, "first-party" and
>>> etc).
>>> >
>>> > Regards,
>>> >
>>> > Dima
>>> >
>>> > The OAuth 2.1 authorization framework enables a third-party
>>> >
>>> >application to obtain limited access to an HTTP service, either on
>>> >behalf of a resource owner by orchestrating an approval interaction
>>> >between the resource owner and the HTTP service, or by allowing the
>>> >third-party application to obtain access on its own behalf.  This
>>> >specification replaces and obsoletes the OAuth 2.0 Authorization
>>> >Framework described in
>>> > RFC 6749.
>>> > ___
>>> > 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
>>>
>>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> 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

Re: [OAUTH-WG] WGLC Review of PAR

[Torsten Lodderstedt]

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  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  
>> 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 

Re: [OAUTH-WG] third party applications

[Denis]

Hello Dima,

Not exactly.

Change :

   or by allowing the third-party application

into:

or by allowing the application


Denis


Thank everyone for your feedback.

So the abstract could look like this:

The OAuth 2.1 authorization framework enables a*n**third-party* application 
to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.  This
specification replaces and obsoletes the OAuth 2.0 Authorization
Framework described inRFC 6749  .
And an additional section is required to describe scenarios where this 
framework works well and scenarios when it doesn't.


On Sat, Aug 29, 2020 at 2:37 AM Aaron Parecki > wrote:


I agree. While the original motivations for OAuth were to support
third-party apps, it's proven to be useful in many other kinds of
situations as well, even when it's a "first-party" app but the
OAuth server is operated by a different organization than the
APIs. I don't think the abstract needs any qualification on this
and would only confuse people further. Any clarifications of which
situations are appropriate for using OAuth could be explored in a
different section in the spec.

Aaron Parecki

On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt
mailto:40lodderstedt@dmarc.ietf.org>> wrote:

I agree. OAuth works for 3rd as well as 1st parties as well.

> On 28. Aug 2020, at 05:26, Dima Postnikov
mailto:d...@postnikov.net>> wrote:
>
> Hi,
>
> Can "third-party" term be removed from the specification?
>
> The standard and associated best practices apply to other
applications that act on behalf of a resource owner, too
(internal, "first-party" and etc).
>
> Regards,
>
> Dima
>
> The OAuth 2.1 authorization framework enables a third-party
>
>    application to obtain limited access to an HTTP service,
either on
>    behalf of a resource owner by orchestrating an approval
interaction
>    between the resource owner and the HTTP service, or by
allowing the
>    third-party application to obtain access on its own
behalf.  This
>    specification replaces and obsoletes the OAuth 2.0
Authorization
>    Framework described in
> RFC 6749.
> ___
> 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


___
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

Re: [OAUTH-WG] third party applications

[Dima Postnikov]

Thank everyone for your feedback.

So the abstract could look like this:

The OAuth 2.1 authorization framework enables a*n* *third-party*
application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in RFC 6749 .


And an additional section is required to describe scenarios where this
framework works well and scenarios when it doesn't.



On Sat, Aug 29, 2020 at 2:37 AM Aaron Parecki  wrote:

> I agree. While the original motivations for OAuth were to support
> third-party apps, it's proven to be useful in many other kinds of
> situations as well, even when it's a "first-party" app but the OAuth server
> is operated by a different organization than the APIs. I don't think the
> abstract needs any qualification on this and would only confuse people
> further. Any clarifications of which situations are appropriate for using
> OAuth could be explored in a different section in the spec.
>
> Aaron Parecki
>
> On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt  40lodderstedt@dmarc.ietf.org> wrote:
>
>> I agree. OAuth works for 3rd as well as 1st parties as well.
>>
>> > On 28. Aug 2020, at 05:26, Dima Postnikov  wrote:
>> >
>> > Hi,
>> >
>> > Can "third-party" term be removed from the specification?
>> >
>> > The standard and associated best practices apply to other applications
>> that act on behalf of a resource owner, too (internal, "first-party" and
>> etc).
>> >
>> > Regards,
>> >
>> > Dima
>> >
>> > The OAuth 2.1 authorization framework enables a third-party
>> >
>> >application to obtain limited access to an HTTP service, either on
>> >behalf of a resource owner by orchestrating an approval interaction
>> >between the resource owner and the HTTP service, or by allowing the
>> >third-party application to obtain access on its own behalf.  This
>> >specification replaces and obsoletes the OAuth 2.0 Authorization
>> >Framework described in
>> > RFC 6749.
>> > ___
>> > 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
>>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth