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