Hi David, It is good that folks share their thoughts.
Sometimes it is, however, difficult to pinpoint the real challenge. To me it seems that the different deployment scenarios people have in mind cause most of the problems. Here is an example conversation from the recent virtual interim meeting chat: * Blaine argues that some web developers cannot afford a certificate and hence, for him, OAuth with only TLS based authentication is not enough. This demands token and HTTP message content signing mechanisms. * Brian claims that TLS is sufficient to protect bearer tokens. * Jeff and Eve argue that they have scenarios where you need to have TLS and signed tokens. So, what are the options: 1) You support all three scenarios. The spec will be large and various people will claim it is complex and that there might be an interoperability problem*. 2) You pick only one of the three scenarios. Let's say you pick the scenario Brian has in mind. The specification is simpler than (1) but will obviously not cover the scenario the other folks had in mind. That may or may not matter. Maybe the developer group Blaine has in mind suddenly decides to buy certificates to be more security aware. Who knows. It is a bit hard to predict the future. In any case, Blaine, Jeff and Eve will be unhappy and will likely do what they want anyway, namely to extend OAuth in their favorite way (in the usual forum shopping mentality). Does this make any sense to you? Now, what would you do? Ciao Hannes PS: I am sure that Eran is concerned about the time it will take him to edit the documents back and forth. Regarding (*): There is an interoperability problem but there is already one anyway since many other parts in the specification are not described so that independent implementations will have a hard time to interwork automatically anyway. >-----Original Message----- >From: ext David Recordon [mailto:record...@gmail.com] >Sent: 21 February, 2010 19:42 >To: Tschofenig, Hannes (NSN - FI/Espoo) >Cc: Eran Hammer-Lahav; oauth@ietf.org >Subject: Re: [OAUTH-WG] WG Survey > >Hey Hannes, >Not to be taken the wrong way, but we've already had eight >really informative responses to this survey. It would be >useful to understand what you're interested in solving within >this working group versus just hearing the belief that the >survey is broken. :) > >Cheers, >--David > >On Sun, Feb 21, 2010 at 8:12 AM, Tschofenig, Hannes (NSN - >FI/Espoo) <hannes.tschofe...@nsn.com> wrote: >> Hi Eran, >> >> There are a couple of problems with this survey. See below >> >>>-----Original Message----- >>>From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] >On Behalf >>>Of ext Eran Hammer-Lahav >>>Sent: 18 February, 2010 19:14 >>>To: OAuth WG (oauth@ietf.org) >>>Subject: [OAUTH-WG] WG Survey >>> >>>A few questions we should answer before moving forward. >>>Considering *your* use cases and reasons for being here: >>> >>>1. Why are you here? What are you trying to solve that is >not already >>>addressed by existing specifications (OAuth 1.0a, WRAP, etc)? >> >> During the conference call we figured out that there is no way one >> would easily agree to a single scenario or deployment variant. >> >> This is where some the disagreements come from. Some folks have the >> super-secure governmental application in mind, others want >to support >> the enterprise environment which are able to spend a lot of money on >> security, and then there are others that focus on the web developer >> that does not have even money for the certs. >> >> How do you want to provide a solution that fits everyone? Not really >> possible IMHO (unless you introduce the notion of "profiles"). >> >>> >>>2. Should the WG start by taking WRAP or OAuth 1.0a as its starting >>>point? Something else? >> >> Largely irrelevant as the content will change anyway >> >>> >>>3. If we start from draft-hammer-oauth, what needs to change to turn >>>it into OAuth 2.0? >> >> Depends on the scenarios you want to cover under item (1). >> >>> >>>4. If we start from draft-hardt-oauth, what needs to change >to turn it >>>into OAuth 2.0? >> >> >> Depends on the scenarios you want to cover under item (1). >> >>> >>>5. Do you think the approach of working first on 'how to use >a token' >>>and then on 'how to get a token' is right? >> >> Nope. First, you have to figure out what you want the >specification to >> accomplish. >> >> >>> >>>6. Should we go back to working on a single specification? >> >> Does not matter. This is purely a document management / authorship >> question that would come last. >> >>> >>>7. Do you think the protocol should include a signature-based >>>authentication scheme? >> >> That depends on the scenarios you want to cover. >> >> Ciao >> Hannes >> >>> >>>EHL >>>_______________________________________________ >>>OAuth mailing list >>>OAuth@ietf.org >>>https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
