Subject: [OAUTH-WG] (no subject)

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Mon, 15 Feb 2021 10:56:55 -0800

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),
[email-masked]

[1] https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/
[2] https://www.rfc-editor.org/about/independent/

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Mon, 15 Feb 2021 10:59:30 -0800

Hi OAuth,

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.

Many thanks,
Adrian

-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 16 Feb 2021 18:53:33 -0500

Hi Adrian,

This document is definitely in scope for the OAuth WG.
We are planning a series of virtual interim meetings after the coming IETF
conference, and we would be happy to schedule one of these meetings to
discuss this document.

Regards,
 Rifaat

On Mon, Feb 15, 2021 at 1:59 PM RFC ISE (Adrian Farrel) <
[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 19 Feb 2021 14:09:03 -0700

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.

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

---

From: Travis Spencer <[email-masked]>
Date: Sat, 20 Feb 2021 18:28:40 +0100

On Fri, Feb 19, 2021 at 10:09 PM Brian Campbell
<[email-masked]> wrote:
> 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) <[email-masked]> wrote:
>> I want to be sure that ... there is no perceived harm to existing
>> OAuth work if this goes ahead

It is my understanding that the procedure that an informational RFC
goes through is that if "(a) the IESG recommends that the document
be brought within the IETF and progressed within the IETF context,
but the author declines to do so, or (b) the IESG considers that
the document proposes something that conflicts with, or is actually
inimical [i.e., 'harmful'] to, an established IETF effort, the
document may still be published as an Experimental or Informational
RFC," (RFC 2026, section 4.2.3). RFC 5742 updates this with a
"compatible" description that states in section 3 that the IESG
review of an independent submission may recommend not to publish
the draft because the IESG "concluded that publication could
potentially disrupt the IETF work done in WG <X>". My question is
how could this draft disrupt this working group's work?

Is it because it will be unclear to the market what advice they
should follow when implementing single page applications? That could
be a reason, some may argue, to not publish this document by this
working group. This is not justification, in my opinion, however,
for recommending that it not at least be published outside this
working group. I say this because RFC 7221 says in section 5.3 that
"[e]ngineering for interesting topics often produces competing,
interesting proposals... Although it is far more comfortable to
entertain only one proposal, a working group is free to pursue
more than one. Often this is necessary until a clear preference
develops. Sometimes, multiple versions are formally published,
absent consensus among the alternatives."

RFC 7221 goes on to describe how to deal with competing drafts. We
feel that we have followed those guidelines for the betterment of
all. For instance, we have contributed to the BCP that Brian
mentioned[1], and agree that this is a good set of recommendations.
The results proposed in the BCP are ones that our customers will
hopefully follow when applicable. The combined results in the BCP do
not detract from the usefulness of the assisted token protocol we
have defined, in my opinion. This should not surprise us when we
consider that we "IETF participants devise solutions for the global
Internet that meet the needs of diverse technical and operational
environments," (RFC 7153, section 3). This diversity will require
multiple methods to solve a wide array of problems. This need is
reflected in the enthusiasm of reviewers' comments I have received
since draft 4 was published recently wherein one reviewer states,
that they are "looking forward to see the assisted token endpoint
being implemented by clients and IdPs." I have received similar
comments before as well. This leads me to conclude that it isn't
just me that thinks that this protocol is generally useful.

Furthermore, RFC 7221 also says in section 5.2 that "If a working
group drops a draft, then anyone is permitted to pursue it as an
Individual or Independent Submission." While the working group never
adopted this draft, the implication of the statement is that any I-D
that the working group opted not to take up can also be submitted to
the independent stream. One of the reasons for this non-standard
track, as stated in RFC 4846 section 2, is to describe "Documents
considered by IETF Working Groups but not standardized."

Another is to give place to dissenting views, so they can reach the
broader Internet community when consensus cannot be established
within a working group. If a working group has the possibility to
prevent publication outside of its boundaries (e.g., in the
independent stream), this purpose of an alternative publication
venue cannot be achieved. When I read RFC 4846, I am left
with the view that this is one of the primary purposes of the
independent stream. There it says in section 2:

    Independent Submissions are especially important as checks on
    the IETF processes even though such checks are not the only, or
    even a common, reason for them. That role is compromised if IETF-
    related entities are able to block or deprecate such documents to
    a degree beyond that needed to avoid difficulties with the
    standards process....Independent Submissions have become
    important....[because they include] ....Critiques and discussions
    of alternatives to IETF Standards-Track protocols. The potential
    for such critiques provides an important check on the IETF's
    standards processes and should be seen in that light.

For this reason, I think the OAuth working group should either
accept this document (though I'm not sure I'm willing to yield
control of it any longer) or not hinder its publication outside
the group. If the IESG recommends that it not be published as
an independent publication, I would ask for very clear
explanation of the harm it does to this working group's efforts
beyond "we have a BCP for single page apps."

Another purposes of the independent stream, also stated in RFC
4846 section 2, is for the "publication of vendor-specific
protocols". Even if no other vendor or authorization server adopts
the assisted token flow, it is useful to describe it in an open
manner. This allows for open dialog and is our explicit request
for comments on our work.

A final reason to ratify this document as an RFC (in this working
group or the independent stream) that I'll mention here is for the
sake of interoperability. Our product supports this protocol
already. To help with those seeking to interoperate with it, a
ratified RFC would align with the broader Internet community's best
interests, in my view. The fact that this protocol is already
implemented by at least one vendor aligns with the IETF's credo
that we, as an community, value running code.[2] Our adherence to
this aim is further reflected in our publication of multiple open
source client libraries[3] and explanations of the protocol in
various other Internet forums.[4, 5]

Therefore, I firmly believe that this working group cannot
prevent publication of this I-D in the independent stream. I used
to think that it would be better that it was worked on in this
group, but have accepted the consensus opinion the body voiced at
IETF 101 that they would not accept it. For this reason, we have
submitted it outside of this group and expect that work to conclude
without prevention by this working group. If this expectation is set
by an incorrect understanding of the purpose of the independent
stream, I welcome objective facts from cited RFCs, bylaws, etc.
that will clarify how my view is inaccurate. If it is correct but
this group believes this work should not be published independently
because it would disrupt its own, I welcome a clear and complete
explanation of how.

[1] https://github.com/travisspencer/draft-ietf-oauth-security-topics/commit/ef94ccd0784341e4fedb4c6fdc5afb4fea058cd4
[2] https://tools.ietf.org/html/rfc7282#section-1
[3] https://github.com/curityio?q=assisted
[4] https://www.youtube.com/watch?v=h_wT-58L5ZY
[5] https://zisc.ethz.ch/oauth-security-workshop-2017/

---

From: George Fletcher <[email-masked]>
Date: Mon, 22 Feb 2021 12:27:22 -0500

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) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi OAuth,
>
>     [email-masked] <mailto:[email-masked]>
>
>     <https://datatracker.ietf.org/doc/draft-ideskog-assisted-token/>
>     <https://www.rfc-editor.org/about/independent/>
>     >
>     >
>
>
>     -- 
>     Adrian Farrel (ISE),
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>     <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./
>