By not feasible, what is the technical use case/issue? Phil
Sent from my phone. On 2011-04-01, at 21:52, Skylar Woodward <[email protected]> wrote: > Am I the only one still supporting SHOULD on this case? If someone else > supports this language, please speak up. Otherwise, it seems the group SHOULD > move forward with MUST. > > As a provider, we (Kiva) must deal with the possibility of an ecosystem of > developer apps which can't feasibly serve HTTPS endpoints. However, we're > perfectly capable of securing credential exchange and our ecosystem with our > own API/Network additions without holding up the working group on this point. > Alternatively, if others are interested in supporting developers who can't > or won't establish HTTPS endpoints, I'm happy to continue the discussion to > work toward a solution (in this working group or side thread). > > > > On Apr 1, 2011, at 2:12 PM, Phil Hunt wrote: > >> Unfortunately neither solution suggested so far is acceptable. So a vote >> from my perspective is premature. >> >> I'd like to keep working for a new solution. >> >> Phil >> [email protected] >> >> >> >> >> On 2011-04-01, at 10:51 AM, Oleg Gryb wrote: >> >>> It's a very interesting discussion and I think, I understand both parties >>> well because consider myself belonging to both communities (enterprise and >>> networking). Still, I would vote in favor of MUST. >>> >>> Considering the big size of this mailing list and the big level of >>> engagement of its members, why don't we vote? >>> >>> The results of the vote should be taken into consideration by those who >>> writes the final version. >>> >>> From: Francisco Corella <[email protected]> >>> To: Eran Hammer-Lahav <[email protected]>; Mark Mcgloin >>> <[email protected]> >>> Cc: OAuth WG <[email protected]>; [email protected] >>> Sent: Fri, April 1, 2011 9:22:32 AM >>> Subject: Re: [OAUTH-WG] Authorization code security issue (reframed) >>> >>>> So we have 2 different communities of Oauth developers that >>>> will never agree. >>>> >>>> SHOULD: Typically the social networking sites that need to >>>> cater for tail end developers by not enforcing TLS on >>>> redirect_uri. It is a risk to think that using strong >>>> language in the spec will help them appreciate the issues >>>> MUST: Typically enterprise organisations (I am in this >>>> camp). They can enforce indirectly by only supporting >>>> registered callback urls and ensure those use TLS >>> >>> Security is at least as necessary to social networking sites >>> as to enterprise sites. Think about what this means for >>> Facebook. If you are using Wifi in a cafe and use the >>> Facebook login button to log in to any application, a hacker >>> can easily impersonate you. >>> >>> By the way, is somebody from Facebook reading this? If so, >>> this is a vulnerability that Facebook has right now, and you >>> should do something about it. At the very least you should >>> change the examples of redirect URIs in the developer >>> documentation so that they use https rather than http. >>> >>> Francisco >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
