Re: [oauth] Updated Charter Text

[Blaine Cook <[e-mail]>]

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
<[e-mail]> wrote:
>
>
> Blaine Cook wrote:
>> On Wed, Feb 18, 2009 at 1:47 PM, Tschofenig, Hannes (NSN - FI/Espoo)
>> <[e-mail]> 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.
>>
>