Re: [OAUTH-WG] OAuth 2.0 / Charter

[Peter Saint-Andre <[e-mail]>]

<hat type='chair'/>

On 11/30/09 10:57 AM, Stephen Farrell wrote:
> While I think the general goal seems ok, and perhaps even better,

I do think it is worthwhile to have a discussion about the proper
"general goal" for this WG, especially given the changing landscape
regarding OAuth[-ish] technologies.

> I do wonder whether its reasonable to re-charter a WG that has
> never formally met face to face, 

The chairs take responsibility for the lack of a meeting, but I can
guarantee you that the group will meet at IETF 77.

> nor met any of its current
> milestones.

Given that the WG was chartered on May 13, it was perhaps a bit
aggressive to "Submit 'OAuth: HTTP Authorization Delegation Protocol' as
working group item" in Apr 2009. :)

Based on list discussion in May and June, we came to consensus to split
draft-hammer-oauth into two specifications, which Eran did in early
July, resulting in draft-ietf-oauth-authentication and
draft-ietf-oauth-web-delegation as WG items. We've had quite a bit of
discussion about those on the list, but it seems to me that the
discussion here and elsewhere has led to a desire for something more
than a simple, backwards-compatible specification of "OAuth 1.1" as
described in the charter. In particular, the scope of "OAuth 1.1"
appears to have been limited to improving terminology, embodying good
security practices, promoting interoperability, and providing guidelines
for extensibility.

> It may be, I'm just not sure, but what's the reason for not
> finishing OAuth 1.1 first? (The fact that you "see no value"
> doesn't explain it to me at least.)

I agree that we need to get the reasons out on the table so that we can
have an open discussion about problems and objectives.

> I also find the following a bit puzzling:
> 
> Eran Hammer-Lahav wrote:
>> Keep in mind that we are not going to include token structure in scope.
>> We are simply proposing a method in which the token is a string, leaving
>> it up to other efforts to give it structure if needed.
> 
> What other efforts? How would the implementer of an RFC achieve
> interoperability? Wouldn't we need to be able to answer that before
> proceeding?

Those are good questions.

> To answer your specific questions:
> 
>> - Is this approach favorable by the group?
> 
> Maybe.
> 
>> - Do we need to adjust the language in the charter to support?
> 
> Definitely IMO. The current charter talks about striving to
> maintain backwards compatibility etc.

The charter also says:

  However, changes that are not backwards
  compatible might be accepted if the group determines that
  the changes are required to meet the group's technical
  objectives and the group clearly documents the reasons for
  making them.

That implies the need to, above all, clarify the group's technical
objectives. IMHO the problem statement is not fully clear in the
existing charter, and furthermore it appears that some people now might
be trying to solve related but somewhat different problems with OAuth
(or something similar enough to OAuth that it can retain the name). That
might be either exciting or worrisome, depending on your perspective.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/