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

Phil Hunt <phil.hunt@oracle.com> Wed, 14 May 2014 16:55 UTC

Return-Path: <phil.hunt@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 09C1C1A0316 for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 09:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.841
X-Spam-Level:
X-Spam-Status: No, score=-4.841 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, T_REMOTE_IMAGE=0.01] 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 HCwFdpRPbs9J for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 09:55:48 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5871A0318 for <oauth@ietf.org>; Wed, 14 May 2014 09:55:48 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s4EGteQY025459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 May 2014 16:55:41 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 s4EGtdq5029684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2014 16:55:40 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s4EGtdpP029672; Wed, 14 May 2014 16:55:39 GMT
Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 14 May 2014 09:55:39 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E1FB1AB-1C0C-47C1-A608-DF0D5904B291"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <CA+wnMn98XJt=ri8DeH8Y+VOYUzHx1-FxbvDMy2YTjjySqgx2SQ@mail.gmail.com>
Date: Wed, 14 May 2014 09:55:37 -0700
Message-Id: <0E7371D4-510A-49A6-8096-8DF5210D5AB6@oracle.com>
References: <536BF140.5070106@gmx.net> <CA+k3eCQN5TGSpQxEbO0n83+8JDVJrTHziVmkjzLUyXtgMQPG1A@mail.gmail.com> <29B83890-91B4-4682-B82F-2B11913CCE6A@oracle.com> <a004992672a54c32a2237112dab67050@BLUPR03MB309.namprd03.prod.outlook.com> <CA+wnMn98XJt=ri8DeH8Y+VOYUzHx1-FxbvDMy2YTjjySqgx2SQ@mail.gmail.com>
To: Chuck & Mara Mortimore <cmortimore@salesforce.com>
X-Mailer: Apple Mail (2.1874)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/WaUpCiuXlFLg7MHJENWoz57mpCM
Cc: "oauth@ietf.org" <oauth@ietf.org>
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: Wed, 14 May 2014 16:55:53 -0000

For the record, we adjusted draft 01 to make it more compatible with OIDC at the request of the Connect community.  I agreed to change it because I can agree that it is a good stepping stone for adoption of Connect. Others may prefer to have a cleanly separate method. I leave that for the group to decide.

The IETF needs a draft that enables and provides user authentication information to clients. 

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com



On May 14, 2014, at 9:39 AM, Chuck Mortimore <cmortimore@salesforce.com> wrote:

> Can you point to one publicly available or publicly documented implementation of a4c?    I've never seen one.
> 
> I will say the a4c spec is almost 100% overlapped with OpenID Connect.   Some minor variations in claim names, but it adds 0 incremental value over what we have in Connect.    
> 
> Connect is being successfully deployed at large scale.  It would be irresponsible for this working group to confuse developers and the industry with duplicate work, especially given this feels more like an argument over signing IPR agreements.
> 
> -cmort
> 
> 
> On Wed, May 14, 2014 at 8:47 AM, Anthony Nadalin <tonynad@microsoft.com> 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> 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> 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
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> 
> --
> 
> 
> 
> Brian Campbell
> Portfolio Architect
> 
> @
> 
> bcampbell@pingidentity.com
> 
> 
> 
> +1 720.317.2061
> 
> Connect with us…
> 
> 
> 
> 
> 
>  
> 
> _______________________________________________
> 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
> 
>