Subject: [oauth] Updated Charter Text

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 18 Feb 2009 09:53:29 +0200

Based on the feedback I have compiled another version of the charter
text.  

------------------------------------------

Open Authentication Protocol (oauth)

Last Modified: 2009-01-30

Chair(s):

TBD

Applications Area Director(s):

Chris Newman <[email-masked]>
Lisa Dusseault <[email-masked]> 

Applications Area Advisor:

TBD

Mailing Lists:

https://www.ietf.org/mailman/listinfo/oauth

Description of Working Group:

OAuth allows a user to grant a third-party Web site or application
access to their resources, without necessarily revealing their
credentials, or  even their identity. For example, a photo-sharing site
that supports OAuth would allow its users to use a third-party printing
Web site to access  their private pictures, without gaining full control
of the user account.

OAuth consists of:
  * A mechanism for exchanging a user's credentials for a token-secret
pair which can be used by a third party to access resources on their
behalf.
  * A mechanism for signing HTTP requests with the token-secret pair.

The Working Group will produce one or more documents suitable for
consideration as Proposed Standard, based upon
draft-hammer-oauth-00.txt, that  will:
  * Improve the terminology used.
  * Embody good security practice, or document gaps in its capabilities,
and propose a path forward for addressing the gap.
  * Promote interoperability.
  * Provide guidelines for extensibility.

This specifically means that as a starting point for the working group
OAuth 1.0 (draft-hammer-oauth-00.txt) is used and the available
extension  points are going to be utilized. The WG will profile OAuth
1.0 in a way that produces a specification that is a backwards
compatible profile,  i.e. any OAuth 1.0 and the specification produced
by this group must support a basic set of features to guarantee
interoperability. 

Furthermore, OAuth 1.0 defines three signature methods used to protect
requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will work
on new signature methods and will describe the environments where new
security requirements justify their usage. Existing signature methods
will not be modified but may be dropped as part of the backwards
compatible profiling activity. The applicability of existing and new
signature methods to protocols other than HTTP will be investigated.

The Working Group should consider:
  * Implementer experience.
  * The end-user experience, including internationalization
  * Existing uses of OAuth.
  * Ability to achieve broad impementation.
  * Ability to address broader use cases than may be contemplated by the
original authors.

The Working Group is not tasked with defining a generally applicable
HTTP Authentication mechanism (i.e., browser-based "2-leg" scenerio),
and  should consider this work out of scope in its discussions. However,
if the deliverables are able to be factored in such a way that this is a
byproduct, or such a scenario could be addressed by additional future
work, the Working Group may choose to do so.

After delivering OAuth, the Working Group may consider defining
additional functions and/or extensions, for example (but not limited
to):
  * Discovery of OAuth configuration.
  * Comprehensive message integrity.
  * Recommendations regarding the structure of the token.
  * Localization.
  * Session-oriented tokens.
  * Alternate token exchange profiles.

Goals and Milestones:

Apr 2009    Submit 'OAuth: HTTP Authorization Delegation Protocol' as
working group item
            (draft-hammer-oauth will be used as a starting point for
further work.)
Jul 2009    Start of discussion about OAuth extensions the group should
work on
Oct 2009    Start Working Group Last Call on 'OAuth: HTTP Authorization
Delegation Protocol'
Nov 2009    Submit 'OAuth: HTTP Authorization Delegation Protocol' to
the IESG for consideration as a Proposed Standard 
Nov 2009    Prepare milestone update to start new work within the scope
of the charter

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Feb 2009 11:10:22 +0000

Hate to keep banging the same drum, but I don't see how the
mobile use case is included there, so I'd still suggest the
addition below. (Other than that this charter is fine by me.)

While I would like there to be a milestone associated with
that, I'm ok if that's done later, so haven't suggested one.
(If asked, I'd go for WGLC on a mobile draft 3-6 months after
the WGLC starts on the base spec.)

Stephen.

> Based on the feedback I have compiled another version of the charter

After delivering OAuth, the WG will, if necessary, develop an oauth
extension suited for use on challenged devices and by aggregators that
allows for the client to directly acquire an access token from a set of
credentials. One such scheme is defined in
draft-dehora-farrell-oauth-accesstoken-creds.

> _______________________________________________
> oauth mailing list
> [email-masked]

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 18 Feb 2009 15:47:48 +0200

Hi Stephen, 

you are a tough negotiator :-)

I think Blaine tried to capture it with the following bullet:
"
* Alternate token exchange profiles.
"

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.
"

Ciao
Hannes

>-----Original Message-----
>From: ext Stephen Farrell [mailto:[email-masked]] 
>Sent: 18 February, 2009 13:10
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]
>Subject: Re: [oauth] Updated Charter Text
>
>
>> credentials, or  even their identity. For example, a photo-sharing 
>> site that supports OAuth would allow its users to use a third-party 
>> printing Web site to access  their private pictures, without gaining 
>> full control of the user account.
>> 
>> OAuth consists of:
>>   * Embody good security practice, or document gaps in its 
>> capabilities, and propose a path forward for addressing the gap.
>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will 
>> work on new signature methods and will describe the 
>environments where 
>> new security requirements justify their usage. Existing signature 
>> methods will not be modified but may be dropped as part of the 
>> backwards compatible profiling activity. The applicability 
>of existing 
>> and new signature methods to protocols other than HTTP will 
>be investigated.
>> 
>>   * Ability to address broader use cases than may be contemplated by 
>> the original authors.
>> 
>> and  should consider this work out of scope in its discussions. 
>> However, if the deliverables are able to be factored in such a way 
>> that this is a byproduct, or such a scenario could be addressed by 
>> additional future work, the Working Group may choose to do so.
>
>After delivering OAuth, the WG will, if necessary, develop an 
>oauth extension suited for use on challenged devices and by 
>aggregators that allows for the client to directly acquire an 
>access token from a set of credentials. One such scheme is 
>defined in draft-dehora-farrell-oauth-accesstoken-creds.
>
>

---

From: Blaine Cook <[email-masked]>
Date: Wed, 18 Feb 2009 14:01:46 +0000

> * 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.

> account allowing for the client to directly acquire an access token from

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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Feb 2009 14:41:59 +0000

>> * Alternate token exchange profiles.

I didn't get that when I read it.

> core spec or, if that's not possible, as an alternate token exchange

Good. Me too:-)

>> account allowing for the client to directly acquire an access token from

That'd do it for me. If you're both ok with adding that you
can stop reading now:-)

> 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

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.

> few are or will be until we have the core OAuth work complete).

And I wouldn't, and didn't, ask for that.

Stephen.

---

From: Blaine Cook <[email-masked]>
Date: Fri, 20 Feb 2009 01:19:07 +0000

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.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Feb 2009 10:42:58 +0000

Works for me,
Stephen