Re: [OAUTH-WG] Oauth Server to Server

Antonio Sanso <asanso@adobe.com> Tue, 24 September 2013 12:57 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 E6CEC11E8121 for <oauth@ietfa.amsl.com>; Tue, 24 Sep 2013 05:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.371
X-Spam-Level:
X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, 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 ULRorKz2FdKE for <oauth@ietfa.amsl.com>; Tue, 24 Sep 2013 05:57:29 -0700 (PDT)
Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 96C7821F8FAC for <oauth@ietf.org>; Tue, 24 Sep 2013 05:57:29 -0700 (PDT)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUkGMNnMbhAWFfJ+X/r94t1m9nHww/MeO@postini.com; Tue, 24 Sep 2013 05:57:29 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OCrniH018263; Tue, 24 Sep 2013 05:53:49 -0700 (PDT)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8OCvL6H024919; Tue, 24 Sep 2013 05:57:25 -0700 (PDT)
Received: from eurcas01.eur.adobe.com (10.128.4.27) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 24 Sep 2013 05:57:23 -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; Tue, 24 Sep 2013 13:57:02 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_8084DA08-14E7-4FB0-9113-736999ED950A"
MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Antonio Sanso <asanso@adobe.com>
In-Reply-To: <CA+k3eCSVwT15wBwuCZNy1EuiVOSwVg+TThVvWnbwZ1wHVvfA-A@mail.gmail.com>
Date: Tue, 24 Sep 2013 14:56:56 +0200
Message-ID: <7558541E-3517-4F71-A049-6143D4247738@adobe.com>
References: <832FA2A6-D0DD-45D0-9107-7EE02B6793B7@adobe.com> <CA+k3eCSVwT15wBwuCZNy1EuiVOSwVg+TThVvWnbwZ1wHVvfA-A@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
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: Tue, 24 Sep 2013 12:57:35 -0000

Hi Brian,

thanks a lot for your pointer.

What the custom Google flow provides more than the oauth jwt bearer draft is IMHO an explicit way to build JWT without any 'human interaction' so a server can handle the construction of an expired JWT bearer token on his own.

This can of course be figured out by any implementer (as the Google folks obviously did) but it would be nice to provide this black on white on a spec IMHO

regards

Antonio


On Sep 24, 2013, at 2:35 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

> Might this http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer be what you're looking for?
> 
> 
> On Tue, Sep 24, 2013 at 6:08 AM, Antonio Sanso <asanso@adobe.com> 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
>