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

John Bradley <> Fri, 12 February 2016 15:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6FD901A1DBD for <>; Fri, 12 Feb 2016 07:59:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vkJrhlCd51FF for <>; Fri, 12 Feb 2016 07:59:05 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5ADCE1A1EF5 for <>; Fri, 12 Feb 2016 07:59:05 -0800 (PST)
Received: by with SMTP id y9so65660061qgd.3 for <>; Fri, 12 Feb 2016 07:59:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OO5kKSD0VsWejGEC81bk4JWOEU6H0Zt/B/JZEGcOhac=; b=YKoR27i6CbdlDHstwO1a8SM9OfQJlZ3Tm89RmxYMuxtraS0uAQrD/N8D6aXH4NNxfD 88mGraWBt4WEzFF7UuJmyedEz5K2C3Pfp/bnhOKo8JtZWjYGBHj63M3uLhil99EYNdzC BxPRcOuU6sYJLoh9A0ULbOaoiVy2l58V0DiXgd1vFrwZBwvwYnAhLsWMhnFSwN17WLBf +zMoSElGNQiZzceAJEJCbR4gur63e/havlzvaXcyJrzGNfIS07KEwyGGc2VVRDBTm189 XBpJYlBD5SP/8ekc7VutUxSZpaF2TkAxo4dP8hk0RDKzJTB44kYm4jpGwo7+3rQ4girL Cl7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=OO5kKSD0VsWejGEC81bk4JWOEU6H0Zt/B/JZEGcOhac=; b=fZUh1WT4424X/Tzee1wvZPbpBUz2zown+kr9arZUCdr+axdB7c6x46rBf4vsYU5ODL OIjYcts1xVqb2ANlSJ+0IrJ5JO40ktsc+95TdPujTz4IlQF3AKy0vjUGIlEFSIHiKAzW K8naQN6+iSAq+pw4BCDM5lmPitpGpwzrf2OGsEWnpLE3P75yNYyCrAz6JKqn7ddU0A8s L8EwkednlknpSSYA8yNLy1KdioW2WlYyzlhBoGCTljCw36GJ0+vOH1mZD5D2N0x71Hqu 8Z+7Ie0QxGptS4z7h7b1gB/sCUYJ24RGwypc5CMW5LeXtyHOBG+Ej/PeZiCyqoI0z6rD iHCQ==
X-Gm-Message-State: AG10YORjEb082SXEVo7CEHFdPmQKxa9yVWWnUurBvqRlJXT7rsJke/GPWlhYO4iBOtHolg==
X-Received: by with SMTP id r206mr3047397qhr.51.1455292744368; Fri, 12 Feb 2016 07:59:04 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 188sm4911726qhi.1.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Feb 2016 07:59:02 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_9185DA86-B162-4C5A-98FD-0E20D0138FE1"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley <>
In-Reply-To: <>
Date: Fri, 12 Feb 2016 12:58:59 -0300
Message-Id: <>
References: <>
To: Michael Jones <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2016 15:59:08 -0000

+1 to adopt this draft.

> On Feb 12, 2016, at 3:07 AM, Mike Jones <> wrote:
> Draft -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 [] On Behalf Of Hannes Tschofenig
> Sent: Thursday, February 4, 2016 11:23 AM
> To:
> 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 <>
> 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
> <> 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:
> <>
> 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
> <> 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: <>
> 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 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