> > It may just be that there are certain environments that one can't do > > OAuth. I'd rather that folks use a different auth mechanism for those > > than further confuse the standard. > > Well said. I've been thinking along the same lines after I met a few > folks at IIW and discussed the same. This impacts registration (as > there is no registration if everyone uses the same key/secret), and > also the database side of things at the provider if the provider is > maintaining database tables cross-referencing a consumer_key against > issued token(s). Installed apps may need to use a really "modified" > OAuth flow to meet the same level of security as the web-app scenario, > but that will end up changing the protocol so much that it may not > resemble the original..
I agree that this is starting to push away from the core functions of OAuth and a new protocol altogether might be the right answer. What worries me, though, is that it's hard enough convincing people to support OAuth as part of their API authentication, and asking for an additional protocol on top of this to support desktop apps specifically might kill it more. I'd prefer to have something that I could throw a single library at; whether this is another protocol that meshes well enough with OAuth that you can easily support them in parallel or a special one-legged application-key mode, I'm a bit ambivalent. But I do think that making more work for the SP's is going to hurt both OAuth and whatever we end up coming up with for the app case in the long run. -- justin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
