Hi Adrian,
I agree with Brian that the proposed document directly relates to
ongoing work in the OAuth working group. Establishing a completely
different mechanism for supporting Single Page Apps other than what is
being proposed by the working group will lead to bifurcated
implementations and potential confusion across the industry. I'd much
prefer to see the work proposed to be considered for adoption by the
OAuth working group such that it can go through the normal
standardization process. This will also ensure that the security best
practices document will cover any additional mechanisms and keep all
that work together.
Thanks,
George
On 2/19/21 4:09 PM, Brian Campbell wrote:
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/
<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-...@rfc-editor.org <mailto:rfc-...@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-...@rfc-editor.org <mailto:rfc-...@rfc-editor.org>
[1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/
<https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/>
[2] https://www.rfc-editor.org/about/independent/
<https://www.rfc-editor.org/about/independent/>
>
>
--
Adrian Farrel (ISE),
rfc-...@rfc-editor.org <mailto:rfc-...@rfc-editor.org>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<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./
_______________________________________________
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
