Re: [OAUTH-WG] OAuth 2.0 / Charter

[John Panzer <[e-mail]>]

FWIW, I agree with Eran's three point model, and on not re-debating these
core ideas absent some compelling reason.  My take on the strategy that
motivates them: OAuth's intent is to provide a simple, scalable,
interoperable web API auth mechanism that both services and other open
standards will build upon.  It also raises the current bar for interoperable
auth from the current state of the practice.  Non-backwards-compatible
changes are warranted if they are necessary to meet these goals (and of
course detailed technical justifications need to be provided as well.)

--
John Panzer / Google
[e-mail] / abstractioneer.org / @jpanzer



On Mon, Nov 30, 2009 at 1:17 PM, Eran Hammer-Lahav <[e-mail]>wrote:

> During the charter discussions and earlier during the BOF discussions, the
> consensus was that any effort to address the general problem from scratch
> was doomed. The IETF and other bodies have a very poor track record of
> successfully creating new security technologies with wide adoption. OAuth
> represented a rare opportunity of using the community work to bootstrap a
> standards track effort.
>
> Different people take that to mean different things. For some, the goal
> should be to rubber stamp 1.0 or as close to that as possible. To others,
> this means taking whatever they feel is the core component of the protocol
> and reusing it (from the signature methods to the web-redirection flow).
>
> To me, the most useful part of OAuth for the purpose of creating new work
> is the model, not the technical details. This is not to imply that the model
> is better than others, just that we have consensus on that, and it is the
> hardest part to agree on. The OAuth model includes some specific choices:
>
> 1. Resource owner credentials are not shared with third parties. Instead, a
> token is used to represent a specific access scope.
> 2. Tokens are issued by the server, not by the resource owner. OAuth tokens
> are treated as opaque strings, and while structured tokens are possible,
> they are external to the model.
> 3. Token authentication does not require SSL/TLS, but is fully compatible
> with it.
>
> I would strongly caution this working group from reopening these basic
> elements as it is more likely to lead to a forking of this effort than any
> successful specification. OAuth's greatest value is the compromise it
> represents in its design. Give up that and we are back to square one. I have
> no interest in starting from scratch or a different base technology.
>
> The main issue with the current charter is the backward-compatibility
> section, not the 1.1 label. It would be a mockery of process and common
> sense to justify each of the proposed changes as required for security and
> interoperability and worth breaking compatibility. None of this matters once
> we change a single thing, and we already know we are going to.
>
> My proposal doesn't change the core model. It cleans up the authentication
> part by simplifying it and making it more extensible and it proposes to
> extend the set of available methods to obtain a token from a single
> redirection-based process to a few other options.
>
> We can certainly stretch the existing charter by using our mandate to
> create a new authenticate scheme and focus on that, calling it Token
> Authentication. Then we can have this discussion about how much to add to
> the single delegation method provided. I leave this up to the chair to
> decide what is best.
>
> My focus is now on producing a draft for the Token Authentication method
> which is very much in line with the charter and based on WG discussions from
> a couple of months ago.
>
> EHL
>
>
> > -----Original Message-----
> > From: Peter Saint-Andre [mailto:[e-mail]]
> > Sent: Monday, November 30, 2009 11:59 AM
> > To: Stephen Farrell
> > Cc: Eran Hammer-Lahav; OAuth WG ([e-mail])
> > Subject: Re: [OAUTH-WG] OAuth 2.0 / Charter
> >
> > <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/
> >
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>