Re: [OAUTH-WG] Your opinion about draft-ideskog-assisted-token

Hi Adrian,

I believe this work was presented briefly to the WG in London during IETF
101. As far as I can recall, the general reaction/thinking at that time was
that the WG really should be working on a document about OAuth and single
page applications (that may or may not include something like the
functionality in draft-ideskog-assisted-token). Since that time the WG
adopted and is actively working on 'OAuth 2.0 for Browser-Based Apps'
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ which
is intended as a BCP for single page applications acting as OAuth clients.
The prospective BCP details security considerations and best practices
around leveraging existing features of OAuth for single page apps. Whereas
draft-ideskog-assisted-token introduces a new grant, new authorization
server endpoint, and really a whole new interaction model between client
and authorization server. Publishing an independent stream RFC that runs
contrary to the BCP coming out of the WG does seem potentially harmful.

On Mon, Feb 15, 2021 at 11:59 AM RFC ISE (Adrian Farrel) <
rfc-ise@rfc-editor.org> wrote:

> Hi OAuth,
>
> The authors of draft-ideskog-assisted-token [1] have approached me
> requesting that the draft be published as an Informational RFC in the
> Independent Submission Stream [2].
>
> The draft extends the OAuth 2.0 framework to include an additional
> authorization flow for single page applications called the assisted token
> flow. It is intended to enable OAuth clients that are written in
> scripting languages (such as JavaScript) to request user authorization
> using a simplified method. Communication leverages HTML's iframe element,
> child windows, and the postMessage interface. This communication is done
> using an additional endpoint, the assisted token endpoint.
>
> It is clear to me that this work could be in scope for OAuth and I want to
> be sure that both:
> - there is no interest within the WG in pursuing this approach
> - there is no perceived harm to existing OAuth work if this goes ahead
>
> I'd appreciate any opinions.
>
> Many thanks,
> Adrian
> --
> Adrian Farrel (Independent Submissions Editor),
> rfc-ise@rfc-editor.org
>
> [1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/
> [2] https://www.rfc-editor.org/about/independent/
> >
> >
>
>
> --
> Adrian Farrel (ISE),
> rfc-ise@rfc-editor.org
>
> _______________________________________________
> OAuth mailing list
> 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._