Re: [OAUTH-WG] OAuth Milestone Update and Rechartering

Prateek Mishra <prateek.mishra@oracle.com> Thu, 15 May 2014 00:37 UTC

Return-Path: <prateek.mishra@oracle.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 4E1361A0393 for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 17:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 FRhgy-Bm9Eim for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 17:37:48 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42931A038B for <oauth@ietf.org>; Wed, 14 May 2014 17:37:47 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4F0bdxa019304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 May 2014 00:37:40 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F0bdYO007240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2014 00:37:39 GMT
Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4F0bd5t007230; Thu, 15 May 2014 00:37:39 GMT
Received: from [130.35.50.173] (/130.35.50.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 17:37:38 -0700
Message-ID: <53740C51.1080009@oracle.com>
Date: Wed, 14 May 2014 17:37:37 -0700
From: Prateek Mishra <prateek.mishra@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Anil Saldhana <Anil.Saldhana@redhat.com>, oauth@ietf.org
References: <536BF140.5070106@gmx.net> <CA+k3eCQN5TGSpQxEbO0n83+8JDVJrTHziVmkjzLUyXtgMQPG1A@mail.gmail.com> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <a004992672a54c32a2237112dab67050@BLUPR03MB309.namprd03.prod.outlook.com> <5373A8FA.9030601@redhat.com>
In-Reply-To: <5373A8FA.9030601@redhat.com>
Content-Type: multipart/alternative; boundary="------------000307010400020209080808"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/jaQKlo_CZN-yZO2WCYZYvJllQec
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
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: <http://www.ietf.org/mail-archive/web/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, 15 May 2014 00:37:52 -0000

Anil,

the challenge is that OIDC is a rather large set of specifications, and 
to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about 
boutique toolkits or startups, I am talking about the folks
who have 100s of millions of users. And, BTW, implementing a few 
arbitrarily selected features from OIDC is not the same as implementing 
OIDC.

As we all know, the core problem is that of adding an authenticator 
token to OAuth flows, which is a rather modest extension to OAuth.

I had personally requested the OIDC community about six months ago to 
describe some minimal subset which we could all reasonably implement. I 
was told that  the specification was "locked down" and fully debugged 
and so on, so no changes could be made. Imagine my surprise to find that 
in the final drafts there was a whole new flow - the hybrid flow - that 
had been added at the last minute. I had never heard of the hybrid flow 
in the OAuth context - have you? So now you have an even larger 
specification!

The value of draft-hunt-oauth-v2-user-a4c-01 is that it describes 
precisely a minimal extension to OAuth flows to support an authenticator 
token.  In my experience, this is the subset that most customers and 
implementors are looking for.


- prateek




> Tony/Phil,
>   any chance you can have this work done at OIDC?
>
> The reason is that it is commonly understood/accepted now that OAuth 
> provides authorization related specs while authentication/profile
> related specs are coming from OIDC (which builds on top of OAuth2).
>
> Regards,
> Anil
>
> On 05/14/2014 10:47 AM, Anthony Nadalin wrote:
>>
>> I agree with Phil on this one, there are implementations of this 
>> already and much interest
>>
>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Phil Hunt
>> *Sent:* Wednesday, May 14, 2014 8:32 AM
>> *To:* Brian Campbell
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
>>
>> On the contrary. I and others are interested.
>>
>> We are waiting for the charter to pick up the work.
>>
>> Regardless there will be a new draft shortly.
>>
>>
>> Phil
>>
>>
>> On May 14, 2014, at 5:24, Brian Campbell <bcampbell@pingidentity.com 
>> <mailto:bcampbell@pingidentity.com>> wrote:
>>
>>     I would object to 'OAuth Authentication' being picked up by the
>>     WG as a work item. The starting point draft has expired and it
>>     hasn't really been discusses since Berlin nearly a year ago.  As
>>     I recall, there was only very limited interest in it even then. I
>>     also don't believe it fits well with the WG charter.
>>
>>     I would suggest the WG consider picking up 'OAuth Symmetric Proof
>>     of Possession for Code Extension' for which there is an excellent
>>     starting point of
>>     http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 - it's a
>>     relativity simple security enhancement which addresses problems
>>     currently being encountered in deployments of native clients.
>>
>>     On Thu, May 8, 2014 at 3:04 PM, Hannes Tschofenig
>>     <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>>
>>         Hi all,
>>
>>         you might have seen that we pushed the assertion documents
>>         and the JWT
>>         documents to the IESG today. We have also updated the
>>         milestones on the
>>         OAuth WG page.
>>
>>         This means that we can plan to pick up new work in the group.
>>         We have sent a request to Kathleen to change the milestone
>>         for the OAuth
>>         security mechanisms to use the proof-of-possession terminology.
>>
>>         We also expect an updated version of the dynamic client
>>         registration
>>         spec incorporating last call feedback within about 2 weeks.
>>
>>         We would like you to think about adding the following
>>         milestones to the
>>         charter as part of the re-chartering effort:
>>
>>         -----
>>
>>         Nov 2014 Submit 'Token introspection' to the IESG for
>>         consideration as a
>>         Proposed Standard
>>         Starting point: <draft-richer-oauth-introspection-04>
>>
>>         Jan 2015 Submit 'OAuth Authentication' to the IESG for
>>         consideration as
>>         a Proposed Standard
>>         Starting point: <draft-hunt-oauth-v2-user-a4c-01>
>>
>>         Jan 2015 Submit 'Token Exchange' to the IESG for
>>         consideration as a
>>         Proposed Standard
>>         Starting point: <draft-jones-oauth-token-exchange-00>
>>
>>         -----
>>
>>         We also updated the charter text to reflect the current
>>         situation. Here
>>         is the proposed text:
>>
>>         -----
>>
>>         Charter for Working Group
>>
>>
>>         The Web Authorization (OAuth) protocol allows a user to grant a
>>         third-party Web site or application access to the user's
>>         protected
>>         resources, without necessarily revealing their long-term
>>         credentials,
>>         or even their identity. For example, a photo-sharing site that
>>         supports OAuth could allow its users to use a third-party
>>         printing Web
>>         site to print their private pictures, without allowing the
>>         printing
>>         site to gain full control of the user's account and without
>>         having the
>>         user share his or her photo-sharing sites' long-term
>>         credential with
>>         the printing site.
>>
>>         The OAuth 2.0 protocol suite encompasses
>>
>>         * a protocol for obtaining access tokens from an authorization
>>         server with the resource owner's consent,
>>         * protocols for presenting these access tokens to resource server
>>         for access to a protected resource,
>>         * guidance for securely using OAuth 2.0,
>>         * the ability to revoke access tokens,
>>         * standardized format for security tokens encoded in a JSON
>>         format
>>           (JSON Web Token, JWT),
>>         * ways of using assertions with OAuth, and
>>         * a dynamic client registration protocol.
>>
>>         The working group also developed security schemes for presenting
>>         authorization tokens to access a protected resource. This led
>>         to the
>>         publication of the bearer token, as well as work that remains
>>         to be
>>         completed on proof-of-possession and token exchange.
>>
>>         The ongoing standardization effort within the OAuth working
>>         group will
>>         focus on enhancing interoperability and functionality of OAuth
>>         deployments, such as a standard for a token introspection
>>         service and
>>         standards for additional security of OAuth requests.
>>
>>         -----
>>
>>         Feedback appreciated.
>>
>>         Ciao
>>         Hannes & Derek
>>
>>
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org <mailto:OAuth@ietf.org>
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>>     -- 
>>
>>     Ping Identity logo <https://www.pingidentity.com/>
>>
>>     	
>>
>>     *Brian Campbell*
>>     Portfolio Architect
>>
>>     *@*
>>
>>     	
>>
>>     bcampbell@pingidentity.com <mailto:bcampbell@pingidentity.com>
>>
>>     phone
>>
>>     	
>>
>>     +1 720.317.2061
>>
>>     Connect with us...
>>
>>     twitter logo <https://twitter.com/pingidentity>youtube logo
>>     <https://www.youtube.com/user/PingIdentityTV>LinkedIn logo
>>     <https://www.linkedin.com/company/21870>Facebook logo
>>     <https://www.facebook.com/pingidentitypage>Google+ logo
>>     <https://plus.google.com/u/0/114266977739397708540>slideshare
>>     logo <http://www.slideshare.net/PingIdentity>flipboard logo
>>     <http://flip.it/vjBF7>rss feed icon
>>     <https://www.pingidentity.com/blogs/>
>>
>>     Register for Cloud Identity Summit 2014 | Modern Identity
>>     Revolution | 19--23 July, 2014 | Monterey, CA
>>     <https://www.cloudidentitysummit.com/>
>>
>>     _______________________________________________
>>     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