On 16 Jan 2010, at 12:04, Hugh Barnard wrote:
Hi BryanThanks very much for this...yes, fits in with what I currently understand.Another area that I need to look at and haven't been into is the keyarrangements/options for OAuth. It looks like there are symmetric and publickey asymmetric (RSA) options.I don't personally want 'any' symmetric at the back end because this will tie me to key distribution of some kind to deal with some of the process,but I'm not sure whether that's on the table.
There is also a variant called oAuth WRAP that takes place over HTTPS, and doesn't require any additional encryption at the message level.
However, I'm not well enough into OAuth to be completely clear about any ofthis... Best regards Hugh On Fri, Jan 15, 2010 at 5:06 PM, Copeland, Bryan < [email protected]> wrote:Hi Hugh, I think the most important point is they are definitely suited fordifferent parts of the login/secure access process. To simplify, we couldcall it: 1. Authentication 2. Authorization When it comes to initial login AUTHENTICATION (at least in terms ofgrasping at the fleeting promise of true SSO) OpenID probably works best. I definitely support keeping OpenID integrations simple, as in: "I'd ratheruse my passport to get into the countries I visit, not go through theprocess of signing up for each country as a temp. resident, unless of course I want to spend A LOT of time there because I like the people...)". OpenID should do minimal Authorization (just on access of info attached to youractual OpenID provider) and focus on AUTHENTICATION.While OAuth (with the current 1.0 core + OAuth WRAP extension, or, when the new v2.0 comes out later this yr) works best for AUTHORIZATION of access to third party applications and resources (i.e. once logged in, use an OAuth request to grant Read access for 24 hrs to User 1's "Latest Tweets", frominside a Wookie Twitter widget instance with a specific API key).Actually, FriendFeed has already done the dual integration quite well, although in more of an "Activity Stream" content portal sort of way. Detailshere: http://bret.appspot.com/entry/oauth-wrapWookie would go one step further and bring widgetized app functionalityinto the container. Agreed that the two can easily be confused and usedinterchangeably/inefficiently, at the same time, I realize they may haveother uses outside of this simplified view too. Bryan -----Original Message----- From: Hugh Barnard [mailto:[email protected]] Sent: January 15, 2010 12:47 AM To: [email protected] Subject: Re: Wookie with OpenID support? On Thu, Jan 14, 2010 at 6:45 PM, Scott Wilson < [email protected]> wrote:On 14 Jan 2010, at 17:09, Bernhard Hoisl wrote: Hi all,thanks for your replies. As I'm pretty new to these things I am not 100% sure if I understood the pros and cons of OpenID and OAuth and theirimplementation costs correctly. But I will try to figure it out formyselfThis is a summary, (summarised by another!) of my current understanding:in the next days - need some more thinking. Bryan's sequence diagram isreally helpful in this!http://softwareas.com/oauth-openid-youre-barking-up-the-wrong-tree-if-you-think-theyre-the-same-thingOauth has appeal for some of my work because it involves 'gateways'. Best regards Hugh -- http://www.hughbarnard.org http://www.big-wave-heuristics.com/ http://www.hackney-environment-network.org.uk/-- http://www.hughbarnard.org http://www.big-wave-heuristics.com/ http://www.hackney-environment-network.org.uk/
smime.p7s
Description: S/MIME cryptographic signature
