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

Thu Jan 8 17:04:04 UTC 2009

Peter,

There are actually several actors at play.
The user which would provide his own Openid and therefore decides on  
the OP to use.
The AC developer could (in my model) register his application to  
another OP (and provide a public key)

The SP receives a transaction from the AC on behalf of the user.
1. SP acts as an RP and checks out the AC to get access to its public  
key to verify the OAuth signature
2. SP acts as an RP and checks out the user identification and  
credentials (AX).  It would also ask via the user's OP if user is ok  
about delegating its authority to the AC.  User would manage the  
grant(s) from his OP profile (along with the other OpenID grants).

Would love to discuss this scenario before Google or Yahoo dictate to  
us the protocol of their choosing given their own implementations and  
preferences.

I would hope that this is the right forum to discuss.

Pat.

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

> Is there a forum where the issues are being argued in the manner the  
> openid community is used to?
>
> I don’t mind vendors advocating and initiating – or using forums  
> like the Foundation to orchestrate the world they view as applicable  
> to their business (e.g. address patent face-offs). But, in a UCI  
> culture there needs to be a forum where the user can be involved  
> too, before its all “sewn up”.
>
> I like UCI as a dogma, if only because its generic in its definition  
> and puts an constantly redefinable limit on the power of the OP.
>
> Its seems obvious that is an OAUTH AC happens to be an openid RP,  
> the RP can expect to  leverage its security context with an OP to  
> securely communicate with the SP.
>
> The question is, does the governance control of the OP over the RP  
> project to the SP?
>
> That’s where I start to question. In a UCI environment, I would say  
> that the user MUST decide that issue. A user May decide that OP1 is  
> replaced by OP2, once Op1 has bootstrapped a secure channel between  
> RP and OAUTH-SP.
>
>
> From: Pat Cappelaere [mailto:pat at cappelaere.com]
> Sent: Thursday, January 08, 2009 8:32 AM
> To: Peter Williams
> Cc: Steven Livingstone-Perez; general at openid.net
> Subject: Re: [OpenID] The OpenID and OAuth Flow: Playing with UX
>
> 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/ff545e9b/attachment-0002.htm>