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

Chuck Mortimore <cmortimore@salesforce.com> Thu, 15 May 2014 00:31 UTC

Return-Path: <cmortimore@salesforce.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 78EE91A0207 for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 17:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WYQICWzdzLLA for <oauth@ietfa.amsl.com>; Wed, 14 May 2014 17:31:53 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C038A1A037D for <oauth@ietf.org>; Wed, 14 May 2014 17:31:52 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id o6so394853oag.17 for <oauth@ietf.org>; Wed, 14 May 2014 17:31:45 -0700 (PDT)
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:date :message-id:subject:from:to:cc:content-type; bh=0I/z4x4CKhfsoS3mCZm0/qYA8YvRX4FevoBBecRsf5c=; b=J/50aw8khgLt7XeLdhV9b5Kb42ijkZcxYrk2viXIAjV+3ll/XeGXA3UPiJxG0L9V8d 61mcTutEAzufxV1xxSmZXyRmfaEj4wkHEQ5lXDqe8qcnLeernH+vQwsusE6x8zgwtmPp 3svryjq8g2dEQK3dRdJZLIHodC4diRQuj6D5lS6fmzq2bnZ32OvwGmxPKpRyzWR12mxf BEXFlQ9wQJv1ES9PzCnqi8GxxMR1co8ivF0yYpXC3BYuOluzNgvgvr6ZXGSrRaGju9DX UZtVU/E7ICYfHwtRzxnOwXKFXFYLy085WX7HRXUMbhZDET3KSdk9cfurxzhcZEEFQnme R0iA==
X-Gm-Message-State: ALoCoQma9lng6XUvTqSooW0z9WqZ5eurvKvucQJAOUmQTLQn1dTFgfTvbYHWmPgJgwI86MC3AefL
MIME-Version: 1.0
X-Received: by 10.60.145.144 with SMTP id su16mr6700884oeb.64.1400113905522; Wed, 14 May 2014 17:31:45 -0700 (PDT)
Received: by 10.76.75.169 with HTTP; Wed, 14 May 2014 17:31:45 -0700 (PDT)
In-Reply-To: <da25696baeb74aa8ae8b57730fdb1b06@BLUPR03MB309.namprd03.prod.outlook.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> <da25696baeb74aa8ae8b57730fdb1b06@BLUPR03MB309.namprd03.prod.outlook.com>
Date: Wed, 14 May 2014 17:31:45 -0700
Message-ID: <CA+wnMn9bfj0h+rYi7tU0BsLaPK6e5k8Rt3F-uaeP0ZJRC83Lkw@mail.gmail.com>
From: Chuck Mortimore <cmortimore@salesforce.com>
To: Anthony Nadalin <tonynad@microsoft.com>
Content-Type: multipart/alternative; boundary="047d7b5d428cfbf3b304f9656b47"
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/SFjplCub3T6U8E4WuL14qn4iNBU
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: Thu, 15 May 2014 00:31:57 -0000

a4c is connect.    For example here's the sample requests:

draft-hunt-oauth-v2-user-a4c-01, section 2.1:

    GET /authenticate?
    response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
    &state=af0ifjsldkj
    &prompt=login
    Host: server.example.com

OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section
2.1.2:

  GET /authorize?
    response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
    &scope=openid%20profile
    &state=af0ifjsldkj HTTP/1.1
  Host: server.example.com


The primary contribution of a4c in this case seems to be malformed HTTP,
and implying that implementors should deploy a redundant authenticate
endpoint.

Sample Responses:

draft-hunt-oauth-v2-user-a4c-01, section 2.4:


     HTTP/1.1 200 OK
       Content-Type: application/json;charset=UTF-8
       Cache-Control: no-store
       Pragma: no-cache
       {
         "access_token":"2YotnFZFEjr1zCsicMWpAA",
         "token_type":"example",
         "expires_in":3600,
         "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
         "id_token":"eyJhbGciOiJub25lIn0.
  eyAic3ViIjoiNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlmIiwicHJvZmlsZSI6Imh0
  dHBzOi8vZXhhbXBsZS5jb20vVXNlcnMvNWRlZGNjOGItNzM1Yy00MDVmLWUwMjlm
  IiwiYXV0aF90aW1lIjoiMTM2Nzk1NjA5NiIsImV4cCI6IjEzNjgwNDI0OTYiLCJh
  bHYiOiIyIiwiaWF0IjoiMTM2Nzk1NjA5OCIsImlzcyI6Imh0dHBzOi8vc2VydmVy
  LmV4YW1wbGUuY29tIiwiYXVkIjoiczZCaGRSa3F0MyIsImV4YW1wbGVfc2Vzc2lv
  bl9wYXJhbWV0ZXIiOiJleGFtcGxlX3ZhbHVlIn0=."
       }



OpenID Connect Basic Client Implementer's Guide 1.0 - draft 33, section
2.1.6.2:


   HTTP/1.1 200 OK
   Content-Type: application/json
   Cache-Control: no-store
   Pragma: no-cache
   {
    "access_token":"SlAV32hkKG",
    "token_type":"Bearer",
    "expires_in":3600,
    "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
    "id_token":"eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso"
   }



a4c seems to toss in a little confusion with an arbitrary example token
type.

We're still dealing with ws-federation passive profile in saml dominated
world.  The oauth working group shouldn't repeat that sin.

-cmort


On Wed, May 14, 2014 at 2:40 PM, Anthony Nadalin <tonynad@microsoft.com>wrote:

>  There are folks that are not implementing connect for various reasons
> (i.e. security reasons, complexity reasons, etc.). thus this is compatible
> with connect if folks want to move on to connect,  we surely don’t use
> connect everwhere as it’s over kill where we only need a the functionality
> of a4c.
>
>
>
> *From:* Chuck Mortimore [mailto:cmortimore@salesforce.com]
> *Sent:* Wednesday, May 14, 2014 9:39 AM
> *To:* Anthony Nadalin
> *Cc:* Phil Hunt; Brian Campbell; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
>
>
>
> 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
>
>
>
>
> --
>
> [image: Ping Identity logo] <https://www.pingidentity.com/>
>
> *Brian Campbell*
> Portfolio Architect
>
> *@*
>
> bcampbell@pingidentity.com
>
> [image: phone]
>
> +1 720.317.2061
>
> Connect with us…
>
> [image: twitter logo] <https://twitter.com/pingidentity>[image: youtube
> logo] <https://www.youtube.com/user/PingIdentityTV>[image: LinkedIn logo]<https://www.linkedin.com/company/21870>[image:
> Facebook logo] <https://www.facebook.com/pingidentitypage>[image: Google+
> logo] <https://plus.google.com/u/0/114266977739397708540>[image:
> slideshare logo] <http://www.slideshare.net/PingIdentity>[image:
> flipboard logo] <http://flip.it/vjBF7>[image: rss feed icon]<https://www.pingidentity.com/blogs/>
>
> [image: 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
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>