Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

William Mills <wmills@yahoo-inc.com> Wed, 26 January 2011 23:17 UTC

Return-Path: <wmills@yahoo-inc.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2AB3A6A0C for <oauth@core3.amsl.com>; Wed, 26 Jan 2011 15:17:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.533
X-Spam-Level:
X-Spam-Status: No, score=-17.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7-IGaeM-KCI for <oauth@core3.amsl.com>; Wed, 26 Jan 2011 15:17:29 -0800 (PST)
Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 77B0A3A6A08 for <oauth@ietf.org>; Wed, 26 Jan 2011 15:17:29 -0800 (PST)
Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0QNHIkY038686; Wed, 26 Jan 2011 15:17:18 -0800 (PST)
Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Wed, 26 Jan 2011 15:17:18 -0800
From: William Mills <wmills@yahoo-inc.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>, Marius Scurtescu <mscurtescu@google.com>
Date: Wed, 26 Jan 2011 15:17:17 -0800
Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
Thread-Index: Acu9ogeRAwlXT0bpQq61uKkqcPiAygACe9PAAACUY8A=
Message-ID: <FFDFD7371D517847AD71FBB08F9A31563848E7CF15@SP2-EX07VS06.ds.corp.yahoo.com>
References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTimzOErQhT_gjdQrcawVgfsnr_2RVtTOYRoP-fcR@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> <AANLkTi=doUBwOyvZx+GyJSB7N19hpQEE-UqAfQ1F-xSv@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6275A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6275A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 26 Jan 2011 23:17:30 -0000

Actually I was envisioning a situation where you have multiple possibly disparate endpoints that rely on authenticator like Google or Yahoo.  One company decides they want to allow federated login and accept SAML assertions, another accepts bearer, yet a 3rd IMAP server accepts both some form of signed auth and bearer.  I think discovery for a service should allow the service to specify the type(s) of auth accepted and the client can choose one that it supports and pass that on to the token server.  The resource server has to know what auth types are supported by the token server.  I would rather have this explicit in the discovery information and support multiple types in the same SASL mechanism than have to offer N mechanisms (or 2N if channel binding is in play).

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Wednesday, January 26, 2011 2:58 PM
> To: Marius Scurtescu
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> 
> 
> > -----Original Message-----
> > From: Marius Scurtescu [mailto:mscurtescu@google.com]
> > Sent: Wednesday, January 26, 2011 1:43 PM
> > To: Eran Hammer-Lahav
> > Cc: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
> 
> > >> 1. The token_type parameter is required in responses from the
> server.
> > >> If the server supports multiple formats, which one will be used?
> In
> > >> this case, would it make sense to allow the client to request a
> specific
> > format?
> > >>
> > >> For example, if the authorization server supports both MAC and
> > >> BEARER, which one will the server issue?
> > >
> > > It might in some cases, but I suspect most providers are going to
> decide
> > which scheme provides the right level of security for them and just
> use that.
> > If you are going to allow both MAC and BEARER, you are basically
> letting
> > clients decide which level to operate at. Do you have a need or plan
> to
> > support multiple token types?
> >
> > For now we are planning to support only bearer, but I am sure some
> form of
> > signed tokens will follow sooner than later. At which point we would
> have to
> > support both.
> >
> > In most cases I think it is up to the client to decide.
> 
> Interesting. Given that you are not planning on supporting this in the
> near future, I think we should wait until there is more deployment
> experience in allowing the client to negotiate the token type. But of
> course, you are welcome to submit a proposal for inclusion on the WG
> new charter.
> 
> EHL
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth