Re: [oauth] Updated Charter Text
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 20 February 2009 10:46 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 8670F3A69D4 for <oauth@core3.amsl.com>; Fri, 20 Feb 2009 02:46:28 -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=[AWL=0.000, 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 bOGMk0tKbN1i for <oauth@core3.amsl.com>; Fri, 20 Feb 2009 02:46:27 -0800 (PST)
Received: from relay.imagine.ie (dns2.dns.imagine.ie [87.232.1.41]) by core3.amsl.com (Postfix) with ESMTP id 1AE503A6AF7 for <oauth@ietf.org>; Fri, 20 Feb 2009 02:46:26 -0800 (PST)
Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id D98E146E0; Fri, 20 Feb 2009 10:46:39 +0000 (GMT)
Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id n1KAkbpo031346; Fri, 20 Feb 2009 10:46:37 GMT
References: <3D3C75174CB95F42AD6BCC56E5555B4501102F3B@FIESEXC015.nsn-intra.net> <499BEC9E.10704@cs.tcd.ie> <3D3C75174CB95F42AD6BCC56E5555B4501103309@FIESEXC015.nsn-intra.net> <d37b4b430902180601g16d44196n33d599a817041677@mail.gmail.com> <499C1E37.6030105@cs.tcd.ie> <d37b4b430902191719q32f94ee2u3e4a213343d0f5ba@mail.gmail.com>
Message-Id: <1FE0F60B-C2B3-4A84-8088-A0C14A313288@cs.tcd.ie>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
To: Blaine Cook <romeda@gmail.com>
In-Reply-To: <d37b4b430902191719q32f94ee2u3e4a213343d0f5ba@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (5G77)
Mime-Version: 1.0 (iPhone Mail 5G77)
Date: Fri, 20 Feb 2009 10:42:58 +0000
X-Bayes-Prob: 0.0001 (Score 0)
X-Canit-Stats-ID: 37492561 - c0021128fa92 (trained as not-spam)
X-CanItPRO-Stream: outgoing
X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53
Cc: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>, "oauth@ietf.org" <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: Fri, 20 Feb 2009 10:46:28 -0000
Works for me, Stephen On 20 Feb 2009, at 01:19, Blaine Cook <romeda@gmail.com> wrote: > Ok, proposed text, disambiguating the sorts of extensions we're > interested in addressing: > > After delivering OAuth, the Working Group may consider defining > additional functions and/or extensions, for example (but not limited > to): > * Discovery of OAuth configuration. e.g., http://oauth.net/discovery/1.0 > * Comprehensive message integrity e.g., > http://oauth.googlecode.com/svn/spec/ext/body_hash/1.0/drafts/1/spec.html > . > * Recommendations regarding the structure of the token. > * Localization e.g., > http://oauth.googlecode.com/svn/spec/ext/language_preference/1.0/drafts/2/spec.html > * Session-oriented tokens e.g., > http://oauth.googlecode.com/svn/spec/ext/session/1.0/drafts/1/ > spec.html > * Alternate token exchange profiles e.g., > draft-dehora-farrell-oauth-accesstoken-creds-00 > > b. > > On Wed, Feb 18, 2009 at 2:41 PM, Stephen Farrell > <stephen.farrell@cs.tcd.ie> wrote: >> >> >> Blaine Cook wrote: >>> 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. >>>> " >> >> I didn't get that when I read it. >> >>> 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. >> >> Good. Me too:-) >> >>>> 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. >>>> " >> >> That'd do it for me. If you're both ok with adding that you >> can stop reading now:-) >> >>> 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. >> >> Sure. OTOH, anyone can write an I-D and that is the IETF >> process, so one shouldn't be penalised for actually doing >> the right thing, right? >> >> I'll be interested in seeing how many of those other >> extensions get pushed into the IETF process. As of now, >> that's zero. So there's a justification for this use >> case (which we agree is critical) to be called out >> up front. (And to be clear, the reason I'm hammering >> on this is so that the WG can choose to adopt an >> I-D on the topic without first rechartering.) >> >>> 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. >> >> I've no problem with that. Even if our I-D is named in >> the charter, there's no guarantee that it gets adopted by >> the WG and the proposed charter text I sent doesn't >> assume that it will be adopted. Its quite common for >> there to be a number of draft-author-foo drafts only >> one of which becomes draft-ietf-wg-foo and that's >> just fine. From my POV the important thing is that the >> WG is chartered to address the use case. Our I-D >> is currently just one approach. >> >>> 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). >> >> And I wouldn't, and didn't, ask for that. >> >> Stephen. >> >>> >>> 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