Re: [oauth] Updated Charter Text

Blaine Cook <romeda@gmail.com> Wed, 18 February 2009 14:01 UTC

Return-Path: <romeda@gmail.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 DAB9C3A6D26 for <oauth@core3.amsl.com>; Wed, 18 Feb 2009 06:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 F82Zr4lSaciB for <oauth@core3.amsl.com>; Wed, 18 Feb 2009 06:01:36 -0800 (PST)
Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id AE6863A6CC3 for <oauth@ietf.org>; Wed, 18 Feb 2009 06:01:35 -0800 (PST)
Received: by ewy14 with SMTP id 14so2709958ewy.13 for <oauth@ietf.org>; Wed, 18 Feb 2009 06:01:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UdVpaI9oD80c9W6lLP8HWPGV97p/RWKAhhLuIwzXTbQ=; b=drUMXJysV65VmtPQc6wgLXfj6LrIC7dvGdkEwP7hNKO0qvx+nqo0KZs0hIeWVEFkMX kl/Y3ArrP7ED543D/higFcHuisYZTtFL9MuFijSnNoxlqeQF1bsOAJt2Fj5fYI/00ggk Fh1duJD1n3pMyEWI0yGfOZohNS54F79db0WfM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BaQ5601PYTGN+56nAFvlpk035F6V6dXOiNuAEEvF2xisfwrh8eZqNVuJzouo2tJwNA nq0IEdaoGrNt/qgh93+1WtkrhOS9sIbKb16wn5gAquA6Dyzc2uVpJtOgACWQE4cM3dE6 7TmQBpafOjXfl1vKnJDym+xzQg4Rxw9SvBhEI=
MIME-Version: 1.0
Received: by 10.210.53.5 with SMTP id b5mr2486229eba.131.1234965706261; Wed, 18 Feb 2009 06:01:46 -0800 (PST)
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net>
References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> <499BEC9E.10704@cs.tcd.ie> <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net>
Date: Wed, 18 Feb 2009 14:01:46 +0000
Message-ID: <d37b4b430902180601g16d44196n33d599a817041677@mail.gmail.com>
From: Blaine Cook <romeda@gmail.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [oauth] Updated Charter Text
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Oauth bof discussion <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, 18 Feb 2009 14:01:36 -0000

On Wed, Feb 18, 2009 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo)
<hannes.tschofenig@nsn.com> wrote:
> Hi Stephen,
>
> you are a tough negotiator :-)
>
> I think Blaine tried to capture it with the following bullet:
> "
> * Alternate token exchange profiles.
> "

Correct ;-) There are a few other approaches to exchanging tokens that
may be useful in different contexts, and I don't want to close the
door on those if people care about them. I absolutely consider the
mobile/challenged device use case as critical to address either in the
core spec or, if that's not possible, as an alternate token exchange
profile.

> Would adding something like the sentence below make you happier?
>
> "
> For example, profiles that take challenged devices and aggregators into
> account allowing for the client to directly acquire an access token from
> a set of credentials.
> "

I'm weary about being too specific. I appreciate that there is an I-D,
but there are also several OAuth extension specs that are well
documented and in active use in the wild, but do not have specific
attention in the charter. I also worry that we haven't properly
evaluated the case history nor have we attempted to outline what other
approaches are possible and discuss the various trade-offs. Committing
to a single profile and use case without a proper discussion and clear
consensus seems backwards to me.

My current feeling on the matter is that we have a charter which
provides ample room for discussion and implementation of the
accesstoken-creds I-D, without explicitly committing to it (which is
something I'm personally not prepared to do, and my impression is that
few are or will be until we have the core OAuth work complete).

b.