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

"torsten@lodderstedt.net" <torsten@lodderstedt.net> Sun, 14 February 2016 14:23 UTC

Return-Path: <torsten@lodderstedt.net>
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 390A61ACCFF for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2016 06:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level:
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-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 iAlNyjy5G3_r for <oauth@ietfa.amsl.com>; Sun, 14 Feb 2016 06:23:38 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0BD1ACCFB for <oauth@ietf.org>; Sun, 14 Feb 2016 06:23:37 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.137]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1aUyWM-0007Ia-FA; Sun, 14 Feb 2016 16:23:34 +0100
Date: Sun, 14 Feb 2016 15:23:25 +0100
Message-ID: <wppx5rmo1ea9gg4o7p2n4yt9.1455459805426@com.syntomo.email>
In-Reply-To: <56C0816B.8070005@lodderstedt.net>
References: <56C0816B.8070005@lodderstedt.net>
From: "torsten@lodderstedt.net" <torsten@lodderstedt.net>
To: Michael.Jones@microsoft.com, wdenniss@google.com, wdenniss@google.com, Michael.Jones@microsoft.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.syntomo.email_1610206958705281"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/OVA_KmtzZ-oHnoI6t5dqfs3pmNE>
Cc: 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: Sun, 14 Feb 2016 14:23:44 -0000

I meant William - sorry!

-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized
Von: Torsten Lodderstedt <torsten@lodderstedt.net>
An: William Denniss <wdenniss@google.com>,Mike Jones <Michael.Jones@microsoft.com>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>

>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 <mailto: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 <mailto:jricher@mit.edu>
>>     Sent: ‎2/‎13/‎2016 11:11 AM
>>     To: Phil Hunt <mailto:phil.hunt@oracle.com>
>>
>>     Cc: <oauth@ietf.org> <mailto: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 <mailto:phil.hunt@oracle.com>> wrote:
>>>
>>>     Yes
>>>
>>>     Phil
>>>
>>>     On Feb 13, 2016, at 07:59, "torsten@lodderstedt.net
>>>     <mailto:torsten@lodderstedt.net>" <torsten@lodderstedt.net
>>>     <mailto: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
>>>>     <mailto:Michael.Jones@microsoft.com>>
>>>>     An: torsten@lodderstedt.net
>>>>     <mailto:torsten@lodderstedt.net>,John Bradley <ve7jtb@ve7jtb.com
>>>>     <mailto:ve7jtb@ve7jtb.com>>
>>>>     Cc: oauth@ietf.org <mailto: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 [mailto:oauth-bounces@ietf.org] *On Behalf Of
>>>>     *torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>
>>>>     *Sent:* Saturday, February 13, 2016 6:37 AM
>>>>     *To:* John Bradley <ve7jtb@ve7jtb.com <mailto:ve7jtb@ve7jtb.com>>
>>>>     *Cc:* oauth@ietf.org <mailto: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 <mailto:ve7jtb@ve7jtb.com>>
>>>>     An: torsten@lodderstedt.net <mailto:torsten@lodderstedt.net>
>>>>     Cc: roland.hedberg@umu.se,oauth@ietf.org
>>>>     <mailto: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
>>>>         <mailto: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
>>>>         <mailto:roland.hedberg@umu.se>>
>>>>         Gesendet: Friday, February 12, 2016 05:45 PM
>>>>         An: oauth@ietf.org <mailto: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 <mailto:ve7jtb@ve7jtb.com>>:
>>>>         >
>>>>         > +1 to adopt this draft.
>>>>         >
>>>>         >> On Feb 12, 2016, at 3:07 AM, Mike Jones
>>>>         <Michael.Jones@microsoft.com
>>>>         <mailto: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 [mailto:oauth-bounces@ietf.org] On Behalf Of
>>>>         Hannes Tschofenig
>>>>         >> Sent: Thursday, February 4, 2016 11:23 AM
>>>>         >> To: oauth@ietf.org <mailto: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 <mailto:OAuth@ietf.org>
>>>>         >> https://www.ietf.org/mailman/listinfo/oauth
>>>>         >
>>>>         > _______________________________________________
>>>>         > OAuth mailing list
>>>>         > OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>         > 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 <mailto:OAuth@ietf.org>
>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>         _______________________________________________
>>>>         OAuth mailing list
>>>>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>     _______________________________________________
>>>>     OAuth mailing list
>>>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org <mailto: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