Not sure I totally like this idea. Seems almost like double authentication to me. The user has to still sign in via the web to replicate the app and then we have to fetch an access token again by asking for their credentials?? So its like doing a 3-legged dance + the xAuth.
I really question the security benefits of not disclosing consumer key/secrets in the context of desktop/phone based applications. First the xAuth step should be forced to use https which prevents man in the middle attacks. Further all other communication can use https as well. I think the only real security gain from oAuth secrets is for 3-legged authentication. It acts as a cheap verification method that you know this website actually represents this particular application. With desktop/phone applications this is already known since you have downloaded it. When I download client X I know already I am only giving out my credentials to this application, not some attacker spoofing the site. I do appreciate Twitter taking the time to help address these oAuth issues, but before we over complicate the issue lets make sure there are actual gains to be had. Josh On Sat, Jun 12, 2010 at 9:12 AM, Cameron Kaiser <spec...@floodgap.com>wrote: > > @taylor > > So key exchange is done based on consumer key only.(No need to verify the > > signature?.Makes sense as this is distributed )So any abuse by the end > user > > will only lead to the ban of child app ? (assuming the final auth > requests > > are signed by the generated secrets (chid app secret and user secret > only) ) > > IDSOWFT, but that is the way I understand it. > > -- > ------------------------------------ personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- Roger Waters, public health officer: "Careful with that pox, Eugene!" > ------ >
