Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206391A6FB7 for ; Fri, 12 Feb 2016 08:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2AzOX93OzCj for ; Fri, 12 Feb 2016 08:45:19 -0800 (PST) Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD8A1A6FAE for ; Fri, 12 Feb 2016 08:45:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,436,1449529200"; d="asc'?scan'208";a="86840581" X-IPAS-Result: A2CoBACOC75W/8kN74JeGQEBAQEPAQEBAYJffW0GiFWzIAIFFwqFbAKCBAEBAQEBAYEAC4RBAQEBAQIBAQEBGgZLEAcEAgEIEQQBAQEnAwICJwsUCQgCBBMJBYgECAEDCrJ3jncBAQEBAQEEAQEBAQEBEgiGEYFsCIJChBMBASOCQjgTGIEPBZZ3gTqBSIFkl2WOPmKCMIE0agGGeTQBewEBAQ Received: from umu-ex01.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.201]) by smtp5.umu.se with ESMTP; 12 Feb 2016 17:45:17 +0100 Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX01.ad.umu.se (2002:82ef:dc9::82ef:dc9) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 12 Feb 2016 17:45:17 +0100 Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Fri, 12 Feb 2016 17:45:17 +0100 From: Roland Hedberg To: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized Thread-Index: AQHRZa52NFBVrhv6lEWL98m8SaaO2J8ojV8A Date: Fri, 12 Feb 2016 16:45:17 +0000 Message-ID: References: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> In-Reply-To: <00A79383-9149-439D-95AB-9461EDF8A35F@ve7jtb.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [81.170.242.121] Content-Type: multipart/signed; boundary="Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2016 16:45:23 -0000 --Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > 12 feb 2016 kl. 16:58 skrev John Bradley : >=20 > +1 to adopt this draft. >=20 >> On Feb 12, 2016, at 3:07 AM, Mike Jones = wrote: >>=20 >> 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=E2=80=99s now ready for working group adoption. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@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 >>=20 >> Hi all, >>=20 >> 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 >>=20 >> 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. >>=20 >> Let me tell you what we see from the comments on the list. >>=20 >> 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. >>=20 >> 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 >>=20 >> 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 >>=20 >> 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. >>=20 >> 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, >>=20 >> 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 >>=20 >> 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. >>=20 >> In its current form, there is not enough support to have this = document as a WG item. >>=20 >> 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: >>=20 >> * 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. >>=20 >> * Change the registry policy, which would address one of the comments = from James, William, and Phil. >>=20 >> 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? >>=20 >> After these items have been addressed we believe that more folks in = the group will support the document. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth =E2=80=94 Roland =E2=80=9DEverybody should be quiet near a little stream and listen." =46rom =E2=80=99Open House for Butterflies=E2=80=99 by Ruth Krauss --Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWvgwcAAoJEMHjX+0KUIOoINcQAKUhOaQV9Iswfm3lAT6WEyAJ VxuHUGnMOOv3J2qCrzYO1XnyUH8p2vtqtHvNYf6lM4RrIUessN8M3MWWmgTcHAbA pWrJ3J+K8v9dDObj9J/95bN1s/7pE5/Y6TItHof+S7Mg6bLQBfSmi4seARw0Nkk1 2ol0oNgiJHOERTW1BGWpAXIprc5sogEsI8BQd0N8u21uyxCflh9plLcRg/ouwTot aOn3shlCS77MkHxweTvA0ma3MZWqXCqKvp4zkzNv5L6HB9kHZ+TRMWRhsBQ4/1bU fwjTxxlVfaAUP9rW91K1Cs/z94k3uR+QRZlyib4fM+mJ8gLZNdd9OpZeWyj9eBua 8QFh/qI+ZvRbk2kSIn367bpqDq/4Ph2tcH0f5agKhyproW+vhl0umT8+UddW7SZd EByMTmHEnNrYDaFuQAURl9YiZprW3O5bJe8NDxa2hO7ISgKRZEAAIwZyASNs2GIq SGhavserv6/cfocOOdAOYcxiXDBeMAxfSiWeaxVeAwQtu1k+V+e1tl8O9EYRRo2P CPuLCX2EeZr4I2XMcaHP/BF9hkHSYyhabYLDv3BrgmWJV2K2/TEymc0BC+IIWm+L j2q5sgBmHZLEUFb7xnGfiNKzq2XAHZb6XDufpEIfTFDjhDA49N9mOjpFNhLAXx+Q kY4hq2Y6RZKhnv5221U/ =cF1Y -----END PGP SIGNATURE----- --Apple-Mail=_8DA0AEE3-356C-44B0-9CF4-031FB078E743--