Re: [OAUTH-WG] First Draft of OAuth 2.1

[George Fletcher <[e-mail]>]

I also am in favor of not requiring "sender constraint" as a MUST. 
SHOULD or RECOMMENDED is fine. Many websites are NOT Single-Page-Apps 
and as such DPOP doesn't work for those environments. Converting all web 
based environments to SPAs so not viable.

Thanks,
George

On 3/12/20 2:28 PM, Vittorio Bertocci wrote:
> damnit, i hit enter too soon.
>    Hey guys,
> thanks for putting this together.
> I am concerned with the real world impact of imposing sender constraint |
> rotation as a MUST on refresh tokens in every scenario.
> Sender constraint isn't immediately actionable - we just had the discussion
> for dPOP, hence I won't go in the details here.
> Rotation isn't something that can be added without significant impact on
> development and runtime experiences:
>
>     - on distributed scenarios, it introduces the need to serialize access
>     to shared caches
>     - network failures can lead to impact on experience- stranding clients
>     which fail to receive RTn+1 during RTn redemption in a limbo where user
>     interaction might become necessary, disrupting experience or functionality
>     for scenarios where the user isn't available to respond.
>     - remediations currently in the wild for this are either clunky (grace
>     periods) or downright cumbersome (waiting for the AT refreshed via RTn to
>     be used by the client to invalidate RTn, which locks RS and AS in a
>     transaction that is both expensive and itself subject to network failure)
>
> I think it's fine to recommend using those mechanisms with a SHOULD, but
> imposing those complexities to everyone in the core is asking too much IMO.
> Thanks
> V.
>
> On Thu, Mar 12, 2020 at 11:24 AM Vittorio Bertocci <[e-mail]>
> wrote:
>
>> Hey guys,
>> thanks for putting this together.
>> I am concerned with the real world impact of imposing sender constraint |
>> rotation as a MUST on refresh tokens in every scenario.
>> Sender constraint isn't immediately actionable - we just had the
>> discussion for dPOP, hence I won't go in the details here.
>> Rotation isn't something that can be added without significant impact on
>> development and runtime experiences:
>>
>>     - on distributed scenarios, it introduces the need to serialize access
>>     to shared caches
>>     - network failures can lead to impact on experience- stranding clients
>>     which fail to receive RTn+1 during RTn redemption in a limbo where user
>>     interaction might become necessary, disrupting experience or functionality
>>     for scenarios where the user isn't available to respond.
>>     -
>>
>>
>>
>> On Wed, Mar 11, 2020 at 5:28 PM Aaron Parecki <[e-mail]> wrote:
>>
>>> I'm happy to share that Dick and Torsten and I have published a first
>>> draft of OAuth 2.1. We've taken the feedback from the discussions on
>>> the list and incorporated that into the draft.
>>>
>>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01
>>>
>>> A summary of the differences between this draft and OAuth 2.0 can be
>>> found in section 12, and I've copied them here below.
>>>
>>>> This draft consolidates the functionality in OAuth 2.0 (RFC6749),
>>>> OAuth 2.0 for Native Apps (RFC8252), Proof Key for Code Exchange
>>>> (RFC7636), OAuth 2.0 for Browser-Based Apps
>>>> (I-D.ietf-oauth-browser-based-apps), OAuth Security Best Current
>>>> Practice (I-D.ietf-oauth-security-topics), and Bearer Token Usage
>>>> (RFC6750).
>>>>
>>>>    Where a later draft updates or obsoletes functionality found in the
>>>>    original [RFC6749], that functionality in this draft is updated with
>>>>    the normative changes described in a later draft, or removed
>>>>    entirely.
>>>>
>>>>    A non-normative list of changes from OAuth 2.0 is listed below:
>>>>
>>>>    *  The authorization code grant is extended with the functionality
>>>>       from PKCE ([RFC7636]) such that the only method of using the
>>>>       authorization code grant according to this specification requires
>>>>       the addition of the PKCE mechanism
>>>>
>>>>    *  Redirect URIs must be compared using exact string matching as per
>>>>       Section 4.1.3 of [I-D.ietf-oauth-security-topics]
>>>>
>>>>    *  The Implicit grant ("response_type=token") is omitted from this
>>>>       specification as per Section 2.1.2 of
>>>>       [I-D.ietf-oauth-security-topics]
>>>>
>>>>    *  The Resource Owner Password Credentials grant is omitted from this
>>>>       specification as per Section 2.4 of
>>>>       [I-D.ietf-oauth-security-topics]
>>>>
>>>>    *  Bearer token usage omits the use of bearer tokens in the query
>>>>       string of URIs as per Section 4.3.2 of
>>>>       [I-D.ietf-oauth-security-topics]
>>>>
>>>>    *  Refresh tokens must either be sender-constrained or one-time use
>>>>       as per Section 4.12.2 of [I-D.ietf-oauth-security-topics]
>>> https://tools.ietf.org/html/draft-parecki-oauth-v2-1-01#section-12
>>>
>>> I'm excited for the direction this is taking, and it has been a
>>> pleasure working with Dick and Torsten on this so far. My hope is that
>>> this first draft can serve as a good starting point for our future
>>> discussions!
>>>
>>> ----
>>> Aaron Parecki
>>> aaronparecki.com
>>> @aaronpk
>>>
>>> P.S. This notice was also posted at
>>> https://aaronparecki.com/2020/03/11/14/oauth-2-1
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth