Re: [OAUTH-WG] New OAuth for Browser-Based Apps draft -02

Hi,

A few rewording suggestions;

*section-6.2*
Original:
The Application Server SHOULD use the OAuth 2.0 authorization code grant to
initiate a request *request *for an access token...

Suggestion:
The Application Server SHOULD use the OAuth 2.0 authorization code grant to
initiate a request for an access token.

*section-7*
Original:
Public browser-based apps needing user authorization create an
authorization request URI with the authorization code grant type per
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being
received by the app.

Suggestion:
Public browser-based apps needing user authorization *should *create an
authorization request URI with the authorization code grant type *as *per
Section 4.1 of OAuth 2.0 [RFC6749], using a redirect URI capable of being
received by the app.

*section-8*
Original:
... can potentially continue using the stoken refresh token to obtain new
access without being detectable by the authorization server.

Suggestion:
can potentially continue using the *stolen *refresh token to obtain new
access *tokens *without being detectable by the authorization server.

Also in *section-9.6,* it is a bit hard to understand what is meant by the
below statement.
*If POSTs in particular from unsupported single-page applications* are to
be rejected as errors per authorization server security policy...

Best Regards,
Janak Amarasena

On Tue, Jul 9, 2019 at 6:43 AM Leo Tohill <leotohill@gmail.com> wrote:

> I see now that my arguments for softening the 6.1 language are backed and
> expanded on by the last paragraph of section 5, starting with " By
> redirecting to the authorization server,..."
>
>
> On Mon, Jul 8, 2019 at 8:44 PM Leo Tohill <leotohill@gmail.com> wrote:
>
>>  regarding 6.1. Apps Served from a Common Domain as the Resource Server
>>
>> Isn't this recommendation neglecting some benefits  or use cases of
>> Oauth?
>>
>> * An application that doesn't collect user credentials is an app that
>> doesn't need to be audited for problems such as password leakage into log
>> files.
>> * Applications that offload authentication to a identity server can
>> delegate to that server the complexities of MFA, password recovery,and the
>> like.  Of course these CAN be done in the app, but isn't it sometimes
>> better to centralize those features in a identity server?  Especially if
>> the organization has multiple apps that require these features.
>>
>>
>> I would soften " it is likely a better decision"  to "it may be a better
>> decision".
>>
>> Leo
>>
>>
>> On Mon, Jul 8, 2019 at 7:05 PM Aaron Parecki <aaron@parecki.com> wrote:
>>
>>> Hi all,
>>>
>>> I've just uploaded a new version of oauth-browser-based-apps in
>>> preparation for the meeting in Montreal.
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02
>>>
>>> This draft incorporates much of the feedback I've received over the last
>>> couple months, as well as what we discussed at the last meeting in Prague.
>>>
>>> The primary change is a significant rewrite and addition of Section 6 to
>>> highlight the two common deployment patterns, a SPA with and without a
>>> dynamic backend.
>>>
>>> Please have a look and let me know what you think. I have a slot in the
>>> agenda for Montreal to present on this as well.
>>>
>>> Thanks!
>>>
>>> ----
>>> Aaron Parecki
>>> aaronparecki.com
>>>
>>> _______________________________________________
>>> 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
>