Re: [OAUTH-WG] Oauth Server to Server

Antonio Sanso <asanso@adobe.com> Fri, 27 September 2013 08:35 UTC

Return-Path: <asanso@adobe.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF0821F9ADD for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2013 01:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.78
X-Spam-Level:
X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+oB90xL3V0m for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2013 01:35:23 -0700 (PDT)
Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFE011E8131 for <oauth@ietf.org>; Fri, 27 Sep 2013 01:35:20 -0700 (PDT)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUkVDSHAo52GiInI9Npp1FrzU3/F/9Ea3@postini.com; Fri, 27 Sep 2013 01:35:21 PDT
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8ZI49005368; Fri, 27 Sep 2013 01:35:18 -0700 (PDT)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R8ZH6A017521; Fri, 27 Sep 2013 01:35:17 -0700 (PDT)
Received: from SJ1GWM332.corp.adobe.com (10.5.79.97) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 27 Sep 2013 01:35:17 -0700
Received: from eurcas01.eur.adobe.com (10.128.4.27) by SJ1GWM332.corp.adobe.com (10.5.79.97) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 01:35:17 -0700
Received: from [10.132.1.66] (10.132.1.66) by eurcas01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.327.1; Fri, 27 Sep 2013 09:35:13 +0100
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Antonio Sanso <asanso@adobe.com>
In-Reply-To: <52443944.6040308@mitre.org>
Date: Fri, 27 Sep 2013 10:35:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <C1A22668-F953-4A7A-AB8C-6BEF5CE119F8@adobe.com>
References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <52443944.6040308@mitre.org>
To: Justin Richer <jricher@mitre.org>
X-Mailer: Apple Mail (2.1510)
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Oauth Server to Server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 27 Sep 2013 08:35:28 -0000

On Sep 26, 2013, at 3:40 PM, Justin Richer <jricher@mitre.org> wrote:

> From what I read, it sounds like you want either the assertion flow 
> (which is defined in extensions)

I do agree the assertion flow + JWT bearer token will suffice

> or the client credentials flow

not too sure about this though since it requires human interaction on input username/password

regards

antonio

> (not the 
> resource owner password flow). In either of these, the client 
> authenticates on its own behalf and gets a token directly with no user 
> involved, and both are fully specified.
> 
>  -- Justin
> 
> On 09/24/2013 08:08 AM, Antonio Sanso wrote:
>> Hi *,
>> 
>> apologis to be back to this argument :).
>> 
>> Let me try to better explain one use case that IMHO would be really good to have in the OAuth specification family :)
>> 
>> At the moment the only "OAuth standard" way I know to do OAuth server to server is to use [0] namely Resource Owner Password Credentials Grant.
>> 
>> Let me tell I am not a big fun of this particular flow :) (but this is another story).
>> 
>> An arguable better way to solve this scenario is to user (and why not to standardise :S?) the method used by Google (or a variant of it) see [1].
>> 
>> Couple of more things:
>> 
>> - I do not know if Google would be interested to put some effort to standardise it (is anybody from Google lurking :) e.g.Tim Bray :D )
>> - I am not too familiar with IETF process. Would the OAuth WG take in consideration such proposal draft??
>> 
>> Thanks and regards
>> 
>> Antonio
>> 
>> [0] http://tools.ietf.org/html/rfc6749#section-4.3
>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>