+1 to adopt this draft. > On Feb 12, 2016, at 3:07 AM, Mike Jones <michael.jo...@microsoft.com> wrote: > > Draft -05 <http://tools.ietf.org/html/draft-jones-oauth-amr-values-05> > incorporates the feedback described below - deleting the request parameter, > noting that this spec isn't an encouragement to use OAuth 2.0 for > authentication without employing appropriate extensions, and no longer > requiring a specification for IANA registration. I believe that it’s now > ready for working group adoption. > > -- Mike > <> > -----Original Message----- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, February 4, 2016 11:23 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption > Finalized > > Hi all, > > On January 19th I posted a call for adoption of the Authentication Method > Reference Values specification, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html > <http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html> > > What surprised us is that this work is conceptually very simple: we define > new claims and create a registry with new values. Not a big deal but that's > not what the feedback from the Yokohama IETF meeting and the subsequent call > for adoption on the list shows. The feedback lead to mixed feelings and it is > a bit difficult for Derek and myself to judge consensus. > > Let me tell you what we see from the comments on the list. > > In his review at > http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html > <http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html> James > Manger asks for significant changes. Among other things, he wants to remove > one of the claims. He provides a detailed review and actionable items. > > William Denniss believes the document is ready for adoption but agrees with > some of the comments from James. Here is his review: > http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html > <http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html> > > Justin is certainly the reviewer with the strongest opinion. Here is one of > his posts: > http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html > <http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html> > > Among all concerns Justin expressed the following one is actually actionable > IMHO: Justin is worried that reporting how a person authenticated to an > authorization endpoint and encouraging people to use OAuth for authentication > is a fine line. He believes that this document leads readers to believe the > latter. > > John agrees with Justin in > http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html > <http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html> that we > need to make sure that people are not mislead about the intention of the > document. John also provides additional comments in this post to the > list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html > <http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html> > Most of them require more than just editing work. For example, methods listed > are really not useful, > > Phil agrees with the document adoption but has some remarks about the > registry although he does not propose specific text. His review is here: > http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html > <http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html> > > With my co-chair hat on: I just wanted to clarify that registering claims > (and values within those claims) is within the scope of the OAuth working > group. We standardized the JWT in this group and we are also chartered to > standardize claims, as we are currently doing with various drafts. Not > standardizing JWT in the IETF would have lead to reduced interoperability and > less security. I have no doubts that was a wrong decision. > > In its current form, there is not enough support to have this document as a > WG item. > > We believe that the document authors should address some of the easier > comments and submit a new version. This would allow us to reach out to those > who had expressed concerns about the scope of the document to re-evaluate > their decision. A new draft version should at least address the following > issues: > > * Clarify that this document is not an encouragement for using OAuth as an > authentication protocol. I believe that this would address some of the > concerns raised by Justin and John. > > * Change the registry policy, which would address one of the comments from > James, William, and Phil. > > Various other items require discussion since they are more difficult to > address. For example, John noted that he does not like the use of request > parameters. Unfortunately, no alternative is offered. I urge John to provide > an alternative proposal, if there is one. Also, the remark that the values > are meaningless could be countered with an alternative proposal. James wanted > to remove the "amr_values" parameter. > Is this what others want as well? > > After these items have been addressed we believe that more folks in the group > will support the document. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
