Subject: [oauth] OAuth Charter Finalized

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 1 Mar 2009 15:05:38 +0200

Hi Lisa, Alexey, Chris, 

We have concluded our OAuth charter discussion on the mailing list.  The
charter text can be found below. 

Ciao
Hannes & Blaine

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

Open Authentication Protocol (oauth)

Last Modified: 2009-03-1

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 implementation.
  * 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, 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/sp
ec.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.

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: Dan Brickley <[email-masked]>
Date: Sun, 01 Mar 2009 14:44:27 +0100

On 1/3/09 14:05, Hannes Tschofenig wrote:
> Hannes&  Blaine

For those of us unfamiliar with IETF process, what exactly does this 
mean? Is the group now chartered / active, or this is a charter proposal 
for discussion?

cheers,

Dan

--
http://danbri.org

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 01 Mar 2009 09:50:54 -0800

> mean? Is the group now chartered / active, or this is a charter proposal 

One perspective:

It means that there is a body of people who are willing pursue the work defined 
by the charter text and that they are submitting it to the IETF management group 
(IESG) for approval.

The charter has had substantial involvement by an Area Director -- a member of 
the IESG.  Since the activity heavily involves security technology, it's worth 
noting that charter development also included significant involvement by folk 
with IETF security experience.  The charter has gone through a pretty diligent 
process, adapting to concerns that were expressed.  This shows some ability of 
the group to grapple with issues.

All of this bodes well for approval, IMO.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "J. Trent Adams" <[email-masked]>
Date: Mon, 02 Mar 2009 10:42:12 -0500

Dan -

 From what I understand of the process, this means that the proposed 
OAuth charter is up for a vote for Working Group status at the IETF.  As 
far as I can tell, once it's a ratified WG, the specification is tracked 
within the pipeline of IETF activities.

If my intel is accurate, the vote could take place as early as IETF 74 
the week of March 22nd in San Francisco.

YMMV,
Trent

Dan Brickley wrote:
> mean? Is the group now chartered / active, or this is a charter 
> proposal for discussion?
>
> cheers,
>
> Dan
>
> -- 
> http://danbri.org
>
> _______________________________________________
> oauth mailing list
> [email-masked]

-- 
J. Trent Adams
=jtrentadams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: "J. Trent Adams" <[email-masked]>
Date: Mon, 02 Mar 2009 11:03:11 -0500

Dan -

OK, apparently I'm still learning the IETF nomenclature.

There's no voting in the IETF, per se.  Instead, word on the street is 
that the charter will be up for discussion at the OAuth BoF (on Wed. 
March 25 at 1pm PT).  From there it goes to the IESG for approval by a 
rough consensus.

Whew.  I hope I got it that time, but welcome any more corrections.

- Trent

J. Trent Adams wrote:
> OAuth charter is up for a vote for Working Group status at the IETF.  
> As far as I can tell, once it's a ratified WG, the specification is 
> tracked within the pipeline of IETF activities.
>

-- 
J. Trent Adams
=jtrentadams

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 2 Mar 2009 09:28:07 -0700

This might help:

http://www.ietf.org/internet-drafts/draft-hoffman-tao4677bis-05.txt

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of J. Trent Adams
> Sent: Monday, March 02, 2009 8:03 AM
> To: Dan Brickley
> Cc: 'Alexey Melnikov'; Hannes Tschofenig; [email-masked];
> [email-masked]; 'Lisa Dusseault'
> Subject: Re: [oauth] OAuth Charter Finalized
> 
> Dan -
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 4 Mar 2009 16:58:43 +0200

Hi Alexey, 

I prefer to avoid re-charting unless the scope of the work significantly
changes. 
The reason for this is efficiency. Discussing the new charter (as we can see
with this exercise) takes a lot of time that could be used more
productively. 

See also the document I recently wrote about my impression on how to reduce
delays: 
http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00.
txt
(written with a focus on RAI but to some extend also applicable to other
areas)

Ciao
Hannes

>From: Alexey Melnikov [mailto:[email-masked]] 
>Sent: 04 March, 2009 12:50
>To: Hannes Tschofenig
>Cc: 'Lisa Dusseault'; [email-masked]; 'Blaine Cook'; 
>[email-masked]
>Subject: Re: OAuth Charter Finalized
>
>Hi,
>I have a quick question about the proposed Charter (please 
>excuse me if this was discussed on the mailing list):
>
>Hannes Tschofenig wrote:
>
>>After delivering OAuth, the Working Group may consider defining 
>>additional functions and/or extensions, for example (but not limited
>>to):
>>  
>>
>WG charters typically say that work on such extra work items 
>require WG rechartering.
>What is the intent in this case?
>
>>http://oauth.googlecode.com/svn/spec/ext/language_preference/1
>.0/drafts
>>/2/sp
>>ec.html.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 4 Mar 2009 17:49:39 +0200

Makes sense to me. I will add that text. 

>Sent: 04 March, 2009 17:18
>To: Hannes Tschofenig
>>I prefer to avoid re-charting unless the scope of the work 
>>significantly changes.
>>The reason for this is efficiency. Discussing the new charter (as we 
>>can see with this exercise) takes a lot of time that could be 
>used more 
>>productively.
>>
>Ok. I suggest the Charter text should say so in order to avoid 
>any questions down the road.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Mar 2009 10:49:57 +0000

Hi,
I have a quick question about the proposed Charter (please excuse me if 
this was discussed on the mailing list):

>functions and/or extensions, for example (but not limited
WG charters typically say that work on such extra work items require WG 
rechartering.
What is the intent in this case?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Mar 2009 15:18:22 +0000

>(written with a focus on RAI but to some extend also applicable to other
Ok. I suggest the Charter text should say so in order to avoid any 
questions down the road.