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

William Denniss <wdenniss@google.com> Mon, 15 February 2016 22:36 UTC

Return-Path: <wdenniss@google.com>
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 842F11A014C for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2016 14:36:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.384
X-Spam-Level:
X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=no
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 gs6vhoLQj3Gh for <oauth@ietfa.amsl.com>; Mon, 15 Feb 2016 14:36:28 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7794F1A00D8 for <oauth@ietf.org>; Mon, 15 Feb 2016 14:36:28 -0800 (PST)
Received: by mail-ob0-x22b.google.com with SMTP id wb13so232724727obb.1 for <oauth@ietf.org>; Mon, 15 Feb 2016 14:36:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ozSdEB1O4whCc4qyNCMany7hvh6bKb04HtilOIdTP7A=; b=Nx6k9K2rej7rgwaedINdLYjNXOtcmkoIPkON4Fsp3/mzRtohSwPfTyH/MmuopdbD7W 6I1VjzjZwt+Vmjo6XRjlz2mHBvWqpG+FrXh1VfoqAvWL/5iBL2reVCx4s9KaA+Pnzk3p 99rA4sFgNDtoo0ULMforgkqoUQEsymYjY/P0u+kpL/l7Plyy8OHdIA00sTG/+ectGahP kCFBw1ee5MwTM+jcbCZRPUwVKhB074FI2cF2jrU7PRXYJl/VQBRE60Y3LqYXVz6lniTj JA7F/4s27fuenAo3pJLVvnzCpmLryak+kRWyFoPG6ylUgCAzg+YcW/kPFpURklfud3Y/ SJlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ozSdEB1O4whCc4qyNCMany7hvh6bKb04HtilOIdTP7A=; b=cioA+RcR3kJVFIzIiLWPd6oAXV40AKrsLAMh18PZSNg6LlwnrRdD7wychoXYX4rJhA KN6eLlXYXnzVgtb9/UKF2axhKtTM3mG7W9OiClLiKhvEZ2XUwHa9KWvb6JwTXCcHRyN5 ByJrApWsc664lBriOTew5H3tyvCpQoddJoLuZes6CnGRq7tyQKiHC/ZtNyH/rMCXeAFq hQcfbbp3AFj/tzKjsZXBytU3mUujQ6RAEZAcTNjtg5K0mMr6SR/8BfFF6hVyJdx7ZfNM aQ2tn99d9ixY//g+V0suliAS6kM/OgK77aWBR8Q/Cem0FBADUoWWhNZhkjkH85jDZ37S YJpg==
X-Gm-Message-State: AG10YOTQh/zZ3xa7spQx4lqr7tm4jeJkrtZMsysowXBPaFM8f/f3ZpkY9ib8Mzq6gVbY/h84VLYAC6FqsYwFVIHi
X-Received: by 10.60.35.201 with SMTP id k9mr14703194oej.3.1455575787560; Mon, 15 Feb 2016 14:36:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Mon, 15 Feb 2016 14:36:07 -0800 (PST)
In-Reply-To: <56C0816B.8070005@lodderstedt.net>
References: <BL2PR03MB433E8ACD3609AF27BB9315CF5AA0@BL2PR03MB433.namprd03.prod.outlook.com> <rbrketsshbps53oogq7ovmrw.1455379158417@com.syntomo.email> <D1B1293D-2811-466E-8F10-94AA3F55F82F@oracle.com> <95DA4443-B94B-4A99-ADE4-4C238DDAB1AD@mit.edu> <BL2PR03MB433BDBFABB72EE4CFD14925F5AA0@BL2PR03MB433.namprd03.prod.outlook.com> <CAAP42hA=Ja5eaiWKQPzxv2Y38bhVyJt6+KPRSfFkN=VCsCxT_A@mail.gmail.com> <56C0816B.8070005@lodderstedt.net>
From: William Denniss <wdenniss@google.com>
Date: Mon, 15 Feb 2016 14:36:07 -0800
Message-ID: <CAAP42hD_uU=Cu-dVk7G6Cz8FdGNNst2Ohw0_F82MsGM1fij_1w@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=089e011613bcc32660052bd6a542
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/pKmbBIIGkUSgWvIhF_yPZfhWyD0>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
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 <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: Mon, 15 Feb 2016 22:36:33 -0000

We return 'amr' claims in ID Tokens if "max_age" is requested (per OpenID
Connect), e.g.:

https://accounts.google.com/o/oauth2/auth?redirect_uri=https%3A%2F%2Fdevelopers.google.com%2Foauthplayground&response_type=code&client_id=407408718192.apps.googleusercontent.com&scope=openid+profile&approval_prompt=force&access_type=offline&max_age=1

The reason we do this is to be explicit about how we are processing the
"max_age" reauth request, specifically that we don't always prompt the user
to reauthenticate directly (but do perform in-session risk analysis).

I can see us potentially using the more generic amr values like "user", and
"mfa" but we will probably avoid very specific ones like "sms" or "otp" to
avoid brittle relationships with RPs. That said, I don't object to those
being in the registry, perhaps there is value in some tightly coupled
enterprise configurations.


On Sun, Feb 14, 2016 at 5:30 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi Denniss,
>
> out of curiosity: Does Google use amr values?
>
> best regards,
> Torsten.
>
>
> Am 14.02.2016 um 02:40 schrieb William Denniss:
>
>
>
> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones <Michael.Jones@microsoft.com>
> wrote:
>
>> It's an acceptable fallback option if the working group decides it
>> doesn't want to register the values that are already in production use at
>> the time we establish the registry. But add William points out, Google is
>> already using some of these values. Microsoft is using some of them. The
>> OpenID MODRNA specs are using some of them. So it seems more efficient to
>> register them at the same time.
>>
>> That would be my preference.
>>
>
> +1, it is also my preference to register the current values.
>
> I don't see any harm in the spec that establishes the registry also
> seeding it with all known values in use at the time of drafting, regardless
> of the group that originally specified them. Makes the original spec more
> useful, and avoids the need to submit each value for consideration
> separately – they can be all be reviewed at the same time.
>
>
> From: Justin Richer <jricher@mit.edu>
>> Sent: ‎2/‎13/‎2016 11:11 AM
>> To: Phil Hunt <phil.hunt@oracle.com>
>>
>> Cc: <oauth@ietf.org><oauth@ietf.org> <oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for
>> Adoption Finalized
>>
>> Can we just do that, then? Seems to be the easiest way to address various
>> needs and concerns.
>>
>>  — Justin
>>
>> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) <phil.hunt@oracle.com>
>> wrote:
>>
>> Yes
>>
>> Phil
>>
>> On Feb 13, 2016, at 07:59, " <torsten@lodderstedt.net>
>> torsten@lodderstedt.net" <torsten@lodderstedt.net> wrote:
>>
>> So basically, the RFC could also just establish the new registry and oidf
>> could feel in the values?
>>
>> (just trying to understand)
>>
>>
>> -------- Originalnachricht --------
>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for
>> Adoption Finalized
>> Von: Mike Jones < <Michael.Jones@microsoft.com>
>> Michael.Jones@microsoft.com>
>> An: torsten@lodderstedt.net,John Bradley < <ve7jtb@ve7jtb.com>
>> ve7jtb@ve7jtb.com>
>> Cc: oauth@ietf.org
>>
>> The context that most people on this thread probably don’t have is that
>> an IANA registry can only be established by an RFC.  Non-RFC
>> specifications, such as OpenID specifications, can **register** values
>> in a registry, but they cannot **establish** a registry.  The OpenID
>> Foundation inquired about this with the IETF before OpenID Connect was
>> finalized and learned that its specifications could not establish IANA
>> registries.  Otherwise, they would have.
>>
>>
>>
>> Instead, RFCs need to be created to establish registries – even for
>> values first defined in non-RFC specifications.  This specification is one
>> example of doing this.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth [ <oauth-bounces@ietf.org>mailto:oauth-bounces@ietf.org
>> <oauth-bounces@ietf.org>] *On Behalf Of * <torsten@lodderstedt.net>
>> torsten@lodderstedt.net
>> *Sent:* Saturday, February 13, 2016 6:37 AM
>> *To:* John Bradley < <ve7jtb@ve7jtb.com>ve7jtb@ve7jtb.com>
>> *Cc:* <oauth@ietf.org>oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values: Call
>> for Adoption Finalized
>>
>>
>>
>> We clearly have this problem between oauth and oidc. Just take a look at
>> the discovery thread.
>>
>> According to you argument I see two options:
>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg just
>> publishes the registry entries. In this case, the spec should clearly
>> explain this.
>> (2) amr is of any use in oauth (although it has been invented in oidc) -
>> than define it and motivate it's use in oauth in this spec.
>>
>> Right now, I think it creates the impression oauth is for authentication.
>>
>>
>>
>> -------- Originalnachricht --------
>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for
>> Adoption Finalized
>> Von: John Bradley < <ve7jtb@ve7jtb.com>ve7jtb@ve7jtb.com>
>> An: torsten@lodderstedt.net
>> Cc: roland.hedberg@umu.se,oauth@ietf.org
>>
>> This is not a issue between oauth and OIDC.
>>
>>
>>
>> This has to do with the registry for JWT being in OAuth.   Many protocols
>> that use JWT are going to want to register claims.
>>
>> We can’t ask them to all move the parts of there specs that use JWT to
>> OAuth.
>>
>>
>>
>> Perhaps JWT should have been part of JOSE, but that is water under the
>> bridge.
>>
>>
>>
>> The OAuth WG is responsible for JWT and it’s registry, and we will need
>> to deal with registering claims.
>>
>>
>>
>> I guess that we can tell people that they need to publish the specs
>> defining the claims someplace else, and just do the registry part.
>>
>> However doing that will probably not improve interoperability and
>> understanding.
>>
>>
>>
>> This document defines the claim for JWT in general.  We still have almost
>> no documentation in the WG about what a JWT access token would contain
>> other than the POP work.
>>
>>
>>
>> John B.
>>
>> On Feb 13, 2016, at 9:18 AM, <torsten@lodderstedt.net>
>> torsten@lodderstedt.net wrote:
>>
>>
>>
>> I basically support adoption of this document. Asserting authentication
>> methods in access tokens (in this case in JWTS format) is reasonable. We
>> use it to pass information about the authentication performed prior issuing
>> an access token to the _resource_ server.
>>
>> What worries me is the back and forth between oauth and oidc. The amr
>> claim is defined in oidc (which sits on top of oauth) but the oauth wg
>> specifies the registry? Moreover, the current text does not give a
>> rationale for using amr in context of oauth.
>>
>> As a WG we need to find a clear delineation between both protocols,
>> otherwise noone will really understand the difference and when to use what.
>> We create confusion!
>>
>> For this particular draft this means to either move amr to oauth or the
>> registry to oidc.
>>
>> best regards,
>> Torsten.
>>
>>
>>
>> -------- Ursprüngliche Nachricht --------
>> Von: Roland Hedberg < <roland.hedberg@umu.se>roland.hedberg@umu.se>
>> Gesendet: Friday, February 12, 2016 05:45 PM
>> An: <oauth@ietf.org>oauth@ietf.org
>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for
>> Adoption Finalized
>>
>> +1
>>
>> > 12 feb 2016 kl. 16:58 skrev John Bradley < <ve7jtb@ve7jtb.com>
>> ve7jtb@ve7jtb.com>gt;:
>> >
>> > +1 to adopt this draft.
>> >
>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones <
>> <Michael.Jones@microsoft.com>Michael.Jones@microsoft.com> 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 [ <oauth-bounces@ietf.org>mailto:oauth-bounces@ietf.org
>> <oauth-bounces@ietf.org>] On Behalf Of Hannes Tschofenig
>> >> Sent: Thursday, February 4, 2016 11:23 AM
>> >> To: <oauth@ietf.org>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>OAuth@ietf.org
>> >> <https://www.ietf.org/mailman/listinfo/oauth>
>> https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > <OAuth@ietf.org>OAuth@ietf.org
>> > <https://www.ietf.org/mailman/listinfo/oauth>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> — Roland
>>
>> ”Everybody should be quiet near a little stream and listen."
>> >From ’Open House for Butterflies’ by Ruth Krauss
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> <OAuth@ietf.org>OAuth@ietf.org
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> <OAuth@ietf.org>OAuth@ietf.org
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>