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

John Bradley <ve7jtb@ve7jtb.com> Thu, 15 May 2014 08:27 UTC

Return-Path: <ve7jtb@ve7jtb.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 440A71A0413 for <oauth@ietfa.amsl.com>; Thu, 15 May 2014 01:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fp-9t7mpSxrG for <oauth@ietfa.amsl.com>; Thu, 15 May 2014 01:27:03 -0700 (PDT)
Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E75F1A0407 for <oauth@ietf.org>; Thu, 15 May 2014 01:27:02 -0700 (PDT)
Received: by mail-ee0-f54.google.com with SMTP id b57so384483eek.13 for <oauth@ietf.org>; Thu, 15 May 2014 01:26:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=lYzr9eenVG/c4ELqA47yK+Oi77lLb/9AV7bkfGHYRmw=; b=PxUUcVIJI9A0HLlyxIPCGkbfE0jYKSqB28sTIjjvlbG+u7j5NyaeEQNzC8JvvVM9UV 7UZ+9mTpGncT0CahK0z9ffYdSLSSbvB4gBd+cWartNtq3GU60C5lWoY1/sYajBvT7JhH INjdJgH9j2N+VfAgm6Rn1Hcetw6PcxDpvW/t+ObpmjtlmjsIIJWT+rWay3A3L12sBfdS OXzxs3rNZoThJas50mgV/CrFx+pGBYLffDxeTwEnSX3vjUsd2IEGTKImU2cNG0tho0Tc PYdLQ8y25nTVW81eMBUqpRi/7TKZbk63rE5xk2OAWjiV2f/uVEAme0weZh2bKHGGZmXK FR5w==
X-Gm-Message-State: ALoCoQkeOpTLbf+TJ4h2edRq/8FuOa7p5GD8N63VoUjQClqJ5XXr9YPtNPTtpBG54lWnGzZYCpMx
X-Received: by 10.14.7.72 with SMTP id 48mr847049eeo.114.1400142414565; Thu, 15 May 2014 01:26:54 -0700 (PDT)
Received: from [10.105.255.214] (vlan105-gw1.ush2.tnib.de. [86.110.65.1]) by mx.google.com with ESMTPSA id h49sm10905490eeg.21.2014.05.15.01.26.52 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 01:26:53 -0700 (PDT)
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> <53740C51.1080009@oracle.com> <CA+wnMn9THMdvjUzF87PJ5BC6HGEaVO8NUpQC=jXOX=ZfcTXCeQ@mail.gmail.com> <6E70D680-CCAC-48FC-82BF-B48DEC1FAFDD@oracle.com> <537416A9.5060701@mit.edu> <CCC586A3-7B71-499C-85B1-51FE4E7AC3D7@oracle.com> <53741B2F.4040506@mit.edu> <1F00EAF0-CC8F-469F-84F3-50C534325360@oracle.com> <51BD7E1D-5C8D-4B6F-8F3C-64137CBDA0DA@oracle.com> <53741F27.4010100@mit.edu> <A7090F21-23FF-43CD-A781-8B1C6C5870DD@oracle.com> <DA9B9C2B-8F6A-4E7E-976C-A2C509F54F5F@ve7jtb.com> <bd52fcf7cac04f91922f7c4b8ecabaf8@BLUPR03MB309.namprd03.prod.outlook.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <bd52fcf7cac04f91922f7c4b8ecabaf8@BLUPR03MB309.namprd03.prod.outlook.com>
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-9F72D215-FC80-4CCD-B2F5-4B42610267F2"; protocol="application/pkcs7-signature"
Content-Transfer-Encoding: 7bit
Message-Id: <F6C4D360-25CF-4CC7-A911-515834C86CBC@ve7jtb.com>
X-Mailer: iPhone Mail (11D201)
From: John Bradley <ve7jtb@ve7jtb.com>
Date: Thu, 15 May 2014 10:26:52 +0200
To: Anthony Nadalin <tonynad@microsoft.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/O2eCV96HFg1YeTc9aCQg85LH6ZQ
Cc: OAuth WG <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 08:27:10 -0000

OAuth covers authentication in security consideration 

This was debated in the WG at the time. 

Just say that you want to reopen the RFC. 

Sent from my iPhone

> On May 15, 2014, at 9:03 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
> 
> So Oauth already treads into the authentication space to some extent and enough of an extent to create additional security issues and threats.
>  
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Wednesday, May 14, 2014 10:32 PM
> To: Phil Hunt
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
>  
> No.
>  
> OAuth requires that if you use the code response type, the token endpoint must return an access token.
>  
> Connect dosen't require a user_info endpoint.
>  
> In the response_type "id_token"  only a id_token is returned in the front channel in a manner similar to SAML POST binding but fragment encoded by default.
>  
> So there is a flow in Connect that doesn't deliver an access token.
>  
> I think this discussion is more about what changes you want to the core of OAuth.
>  
> Connect worked around the OAuth spec to be compatible with it.
>  
> Only the OAuth WG can change OAuth and that seems to be what you want.  
> a4c is a justification for making those changes.
>  
> We should probably focus on the core issue of what changes to RFC 6749 you are after, to determine if the WG wants to change the charter.
>  
> I think focusing on a4c is a read herring.
>  
> John B.
>  
> On May 15, 2014, at 6:55 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> 
> I think those are things to discuss if the authen is on the charter. 
>  
> So we have now clarified that the basic connect profile doesn't do just authen and requires identity profile services. 
> 
> Phil
> 
> On May 14, 2014, at 18:57, Justin Richer <jricher@mit.edu> wrote:
> 
> Right, so instead of being able to use my authorization endpoint, which already authenticates the user and can gather consent, I need to implement a new endpoint that's not-quite-OAuth but is almost like it. But it's enough to be confusing because sometimes I go to this new endpoint endpoint and also get an access token anyway, to use somewhere that I'm not sure where. And I'm not sure I can collapse the two endpoints and re-use my OAuth infrastructure. After all, I still need to use the token endpoint, and by that point my server needs to know which endpoint the user went to in the first place to make that switch. As a developer, this all sounds horribly convoluted and complicated to track. Do I get to re-use any of the components from an authorization endpoint? How do I know whether or not to issue the access token if the user goes to the authentication endpoint? And then there are the optimizations for existing well-known and well-understood use cases: what if my client is sitting in the same browser session and just wants to get the user assertion directly instead of going through a round trip? Do I need to make two round trips if I'm getting a protected API at the same time as authn data? Can I use the same response_type functionality and other extensions on the authentication endpoint? 
> 
> In the end, the a4c draft isn't OAuth, it's only OAuth-like, which is dangerous and confusing and not something I think the OAuth WG should be a part of. And I really just don't see the point of it, unless the goal is to pollute the standards space which Connect currently occupies. Is Connect perfect? Heck no. But it's far and away the best thing we've had in a long time, and it already does every single thing you are asking for from this new draft.
> 
>  -- Justin
> 
> On 5/14/2014 9:43 PM, Phil Hunt wrote:
> Sorry I meant to say this is why it has the /authenticate endpoint to indicate the client only wants the users session information.
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>  
>  
>  
> On May 14, 2014, at 6:42 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> 
> Right.  This is why it has a different point because the client does NOT want a resource token.
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>  
>  
>  
> On May 14, 2014, at 6:41 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> 
> Actually, it's about OAuth compatibility. With OAuth, you get an access token to be used at a protected resource. That's what it's for, that's what clients do the OAuth dance(s) for. Connect defines that protected resource as the userinfo endpoint (ie, "tells the client what to do with it"). Connect also defines the id token that comes in along side of the bog-standard OAuth token, and Connect is turned on and off through the use of bog-standard OAuth scopes. So that makes it very, very, very easy to take an OAuth server and turn it into a Connect server. I know, I've done just that, and I've walked others through the process as well. 
> 
> But the a4c draft is using something that's almost-but-not-quite-OAuth: You might not get an access token, which is going to confuse the heck out of most OAuth clients that I know since that's what they're trying to get at in the first place, and there's no real way for a client to distinguish its request for something with an id_token vs. without. Additionally, in practice, that access token is hugely useful. Just look at all of the weird OpenID2 and OAuth1 hybrid stuff that people were trying to do back a few years ago on top of all the OpenID2 extensions -- this is exactly because OpenID2 was built for "authentication only" because that's what people thought developers wanted, but it turned out that developers wanted a whole lot more than that. This is one main reason the Facebook Connect and Twitter's OAuth-based login came along and ate everyone's lunch: they gave you authentication, but also something useful about the end user.
> 
> All said, it sounds like you want Connect but without the UserInfo Endpoint. You'll be glad to know that you can already do that as per the MTI definitions of the server:
> 
>   http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI
> 
> You are free to implement a SCIM endpoint (which, by the way, you'll probably need that access_token to access) or no endpoint at all, and a compliant client ought to be able to deal with that. In fact, there's a way to get just the id_token in Connect if that's all you care about, but instead of hiding it inside of an existing flow that might return something different depending on (currently-undefined) special circumstances, it puts this mode into a separate response_type entirely to enforce the point that it is different from regular OAuth. 
> 
>  -- Justin
> 
> On 5/14/2014 9:24 PM, Phil Hunt wrote:
> It isn’t required (or should not be).  This issue is OIDC compatibility.
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>  
>  
>  
> On May 14, 2014, at 6:21 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> 
> How is this functionally different from the a4c draft that also allows the return of both an id_token and an access token? 
> 
>  -- Justin
> 
> On 5/14/2014 9:18 PM, Phil Hunt wrote:
> That’s not a minimalistic authn only profile.
>  
> If you return both an access token AND an id token than the service provide has to implement both and the client has to figure out what to do with it.
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>  
>  
>  
> On May 14, 2014, at 5:44 PM, Chuck Mortimore <cmortimore@salesforce.com> wrote:
> 
> 
> "I had personally requested the OIDC community about six months ago to describe some minimal subset which we could all reasonably implement."
>  
> I believe you're looking for this: http://openid.net/specs/openid-connect-basic-1_0.html
>  
> -cmort
>  
>  
>  
> On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra <prateek.mishra@oracle.com> wrote:
> 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> 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
> 
> 
> 
> _______________________________________________
> 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
> 
>  
> _______________________________________________
> 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
>  
>  
>  
>  
>  
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>