IETF Logo Mail Archive

Re: [OAUTH-WG] Oauth Server to Server

Antonio Sanso <asanso@adobe.com> Fri, 27 September 2013 09:45 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 F41CD21E80F1 for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2013 02:45:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.604
X-Spam-Level:
X-Spam-Status: No, score=-4.604 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 Rb9Y1Oo9zxEy for <oauth@ietfa.amsl.com>; Fri, 27 Sep 2013 02:45:25 -0700 (PDT)
Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id D125021E80E7 for <oauth@ietf.org>; Fri, 27 Sep 2013 02:45:21 -0700 (PDT)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUkVTsNEmkwvXYSzLruL5vBgSOJEql9o4@postini.com; Fri, 27 Sep 2013 02:45:22 PDT
Received: from inner-relay-2.corp.adobe.com (mail-321.eur.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R9jJ49013465; Fri, 27 Sep 2013 02:45:19 -0700 (PDT)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8R9jIOU007372; Fri, 27 Sep 2013 02:45:18 -0700 (PDT)
Received: from SJ1GWM333.corp.adobe.com (10.5.79.98) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.327.1; Fri, 27 Sep 2013 02:45:18 -0700
Received: from eurcas01.eur.adobe.com (10.128.4.27) by SJ1GWM333.corp.adobe.com (10.5.79.98) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 27 Sep 2013 02:45:18 -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 10:45:04 +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: <C1A22668-F953-4A7A-AB8C-6BEF5CE119F8@adobe.com>
Date: Fri, 27 Sep 2013 11:44:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <CC42C2C2-0F2A-4B49-853A-0BD8724F249F@adobe.com>
References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <52443944.6040308@mitre.org> <C1A22668-F953-4A7A-AB8C-6BEF5CE119F8@adobe.com>
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 09:45:34 -0000

On Sep 27, 2013, at 10:35 AM, Antonio Sanso <asanso@adobe.com> wrote:

> 
> 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

ops apologies you are off course right. I wrongly mixed the client credentials flow with the implicit grant (sometime also called client-side... :s)

regards

Antonio
> 
> 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
>> 
>

v2.23.0 | Report a Bug | By Email