[OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 04 February 2016 19:22 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 58D1B1ACE0C for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 11:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xCvqdZJ1Lh3n for <oauth@ietfa.amsl.com>; Thu, 4 Feb 2016 11:22:43 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971E11ACE0B for <oauth@ietf.org>; Thu, 4 Feb 2016 11:22:41 -0800 (PST)
Received: from [] ([]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LvE2c-1a0MNJ2rTO-010Psv for <oauth@ietf.org>; Thu, 04 Feb 2016 20:22:39 +0100
To: "oauth@ietf.org" <oauth@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <56B3A4FE.70700@gmx.net>
Date: Thu, 04 Feb 2016 20:22:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="DbEjXvciFoQKLi6HVI92eiqrrQUpQtW5w"
X-Provags-ID: V03:K0:E70nx9+pUAwQiXB0vnPS9o9cyn+X6TEPoUTWfym1OyPtmyZGZFh bDQZ0fitHEnCOYlq84ZldPiU869CEZez8Q+xazJ+01tnTAPRlqA0lTW8r+t8cj2XnlGpNkv aHpGm5tjJKXjwYAg6XdfQ10DLnfsX9IzzVlaO1BrUm84x3R+6tw9ERAn6ztAUVr9iotRlnq zYqemotj+OYESX6kux1Gg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:aYnYGrB2ZrY=:r+pCAlIGF3dX0wAQcbC6VR 4pRydyiNsmg9ADXkK/GX5z/42k4N9Sv/Z2CDwss/hIibEyRvjK4Zbch+UfyvdTnyPqkcXC76b iEAgJ/NoBH/9dxZaBmxAZXJni2DnSKa8Plgq4rqx4yaGVm5oEcVSwRS/9+rea2j6ljCTa0XUM D649f4TvdezDbWMzwUCAbfG9pnz2yJ2kZ7T9D6xtH+0DbIqRaBtXw3J9MypyNRa+mkDUQyrvT rTV+GAbDaK7npkHlQ5WzoZiBjZOeYada6mMYUvZV1CCRC51qvpkbNI7VxUUb1SzwjQJcZEN1y j216A1zke2Nd1yMHOUoKYPQPA+Qh+guxhGUv9BAjzs9EeQmjKU+qLOt5SJ+NNj9nS/WlFVBs7 qlMd0Smcn5olsLlyftsRwHk1NUy/PKoXHSgGi7AXUwnx+ElIi5HarpNhej3NSv+zkhQunfnkj 4qByKxntYzaJVAZAy9qgY+ejVT5rGvyH3UloEhc7UtWeoGBEiwe5yYNiwzOKa4plIxpuRchHY wPVm+AgYBFUZ8x3/lXH48KG6Fmy7Qnp3ZtqneOe7k372y+PoeEf1A5NvQC3snJunQ1aPSPnKW 5tlTphkc0H2lo+TKykvsANq26o2QeAfmcEuHkv2QSCIP0btMLx6VGVcG6b/4lbyVxDjEXljiV hbCjAPILNY+JqvsQr726mKqEcjtDulsyFu2vuqJ3+Ih2462DYDtn30G9QKUcoX/sPGRBkXAUv 94A0Pf4kEmbXMcJYaRsx7vW3vTqaH7MzsYnYNGI3hd5H0IOBPgi+uPJjcyE=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Y7IUMzngKE0GXXNloUWw4UPBk1o>
Subject: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 19:22:49 -0000

Hi all,

On January 19th I posted a call for adoption of the Authentication
Method Reference Values specification, see

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

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

William Denniss believes the document is ready for adoption but agrees
with some of the comments from James. Here is his review:

Justin is certainly the reviewer with the strongest opinion. Here is one
of his posts:

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:

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

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.

Hannes & Derek