On Fri, Feb 19, 2021 at 10:09 PM Brian Campbell
<bcampb...@pingidentity.com> 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)
> <rfc-...@rfc-editor.org> 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/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
