[OpenID] The OpenID and OAuth Flow: Playing with UX

[Pat Cappelaere]

Peter,

OpenID and OAUTH are completely independent protocols.
OAuth "classic" is a point-to-point solution between an application  
consumer (AC) and a service provider(SP).

There is no OpenID + OAuth specification yet (or best practice).

Google/Yahoo is pushing for a OP/SP integrated hybrid solution spec.

We would like to keep them separate to support federated OP's and  
variety of SP's out there.  Of course, there is no browser in the loop  
requirement when an AC and SP need to communicate.  However, they  
could use RSA-SHAI with the keys they have published at the OP and  
follow OAUTH two-legged protocol.

Pat.



However, there are efforts

On Jan 8, 2009, at 11:11 AM, Peter Williams wrote:

> I’m not sure about this being the “ultimate” solution: but the  
> thread and its links were definitely very valuable to me.
>
> I learned a lot about the doctrine of OAUTH (and “FireEagle”) that  
> was just not apparent in the technical spec. he spec focused on the  
> free and fun world of SPs –data sources supporting OpenID RPs. If  
> these control ideas are part and parcel of OAUTH culture, I think  
> I’m starting to understand why Eran seemed to distraught during the  
> election process. There may well be a cultural disconnect, over the  
> issue of OP control. This disconnect contrasts with the obvious and  
> apparently easy opportunity to harmonize the bits and bytes of the  
> two protocols
>
> To make software,  in the interests of “security and safety of  
> users” (always a dodgy introduction in a control culture) developers  
> used to be commonly subject a distributor’s certification of their  
> PC app’s code. In particular, one may remember that app designers  
> targeting the Apple platform had to ensure the app’s look was  
> consistent with the platform’s goals. (Originally, this used to  
> include even being required to submitting your business plan to  
> Apple).
>
> For OAUTH, this seems to translate: “portals” acting as OPs will not  
> certify third-party apps as consumers of the assertion (i.e. will  
> refuse to issue backchannel passwords or will revoke an existing  
> credential) if the app fails to continually demonstrate that it  
> adopts certain design patterns that promote the browser (vs. the PC  
> or PKI) as the trust system. If a third party site uses an embedded  
> browser control, for example, the app not be certified (as it  
> compromises user identity protection boundary). The argument is that  
> any website design practice that doesn’t advocate using the “browser  
> as a trust platform” fails to counter phishing attacks by fraudulent  
> websites).
>
> Have I correctly captured the social issue? I note the advocacy of  
> certain folks who want the Foundation to promote and certify “UX”,  
> too.
>
>
>
> From: general-bounces at openid.net [mailto:general-bounces at openid.net]  
> On Behalf Of Steven Livingstone-Perez
> Sent: Thursday, January 08, 2009 5:04 AM
> To: general at openid.net
> Subject: [OpenID] The OpenID and OAuth Flow: Playing with UX
>
> This is an excellent piece and discussion OpenID as part of the  
> article. Should be a kick off to design (at least on paper) the  
> “ultimate” solution I’d think.
>
> http://ben-ward.co.uk/blog/oauth-flow/
>
> steven
> http://friendfeed.com/rooms/openidstream
> http://livz.org
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090108/07a2379b/attachment-0002.htm>