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.
- [oauth] Updated Charter Text Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [oauth] Updated Charter Text Stephen Farrell
- Re: [oauth] Updated Charter Text Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [oauth] Updated Charter Text Blaine Cook
- Re: [oauth] Updated Charter Text Stephen Farrell
- Re: [oauth] Updated Charter Text Blaine Cook
- Re: [oauth] Updated Charter Text Stephen Farrell