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

Anil Saldhana <Anil.Saldhana@redhat.com> Wed, 14 May 2014 17:34 UTC

Return-Path: <Anil.Saldhana@redhat.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 93DDB1A013E for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 10:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.552
X-Spam-Level:
X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 MNuRdhDP-eqH for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 10:33:55 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id CDFE31A0102 for <oauth@ietf.org>; Wed, 14 May 2014 10:33:55 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4EHXm6R001751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <oauth@ietf.org>; Wed, 14 May 2014 13:33:49 -0400
Received: from localhost.localdomain (vpn-54-146.rdu2.redhat.com [10.10.54.146]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4EHXkFp016680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <oauth@ietf.org>; Wed, 14 May 2014 13:33:47 -0400
Message-ID: <5373A8FA.9030601@redhat.com>
Date: Wed, 14 May 2014 12:33:46 -0500
From: Anil Saldhana <Anil.Saldhana@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: 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>
In-Reply-To: <a004992672a54c32a2237112dab67050@BLUPR03MB309.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------000605030607020103070504"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/in5ITcmyNbQ9amz5hmWykoUyiY0
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 17:34:02 -0000

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