Re: [OAUTH-WG] OAuth 2.0 / Charter

[Pelle Braendgaard <[e-mail]>]

I agree completely with these steps as well. While OAuth has had a few
implementation difficulties that I think Eran has done a good job of
fixing in the revised 1.0 spec there is a clear danger for OAuth 2.0
to stray to much from the original ideas.

If we add too many different variations and features into the standard
we risk becoming WS-deathstar 2.0 and no small developers will deal
with it.

Of course our respective companies all have specific use cases we
would like to implement like me wanting to keep some sort of generic
model for asymmetric signing in the standard. It would really help us
by not including those in the base standard and having various
extensions outside.

For example as much as I don't like the OAuth Session Extension for
the additional complexity it adds for developers, I am much happier
with it being an extension where a vendor decides if they are willing
to add a complexity tax for their client developers. It is their
choice.

If for the sake of simplicity it would be better create some kind of
simple optional public key signing into an extension, then I would be
for it.

So as a general approach keep it simple.

Pelle

I think the idea of splitting the standard up in two as suggested
really helps this approach.

On Mon, Nov 30, 2009 at 4: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
>



-- 
http://agree2.com - Reach Agreement!
http://extraeagle.com - Solutions for the electronic Extra Legal world
http://stakeventures.com - Bootstrapping blog