<div>Valentino,</div><div><br></div><div>I don't think your OpenID scenario that you just described with the rich app would work as-is. There is no way for the OP to establish that the rich app is 'trusted', especially in light of the fact that rich apps don't get to keep secrets (the client user has the app and can read the secrets, then spoof them, thereby rendering it useless).</div>
<div><br></div><div>But even in the light of a PS3, possibly with an untrusted browser, you can use the off-device browser authorization I described earlier this morning so you can use a trusted browser, and allow an otherwise untrusted device to access a limited set of your private data but never having seen the credentials. </div>
<div><br></div><div>OAuth WRAP doesn't solve the problem IMO -- it merely offers a standard way for the client to collect username+password, which for various reasons should be avoided if possible.</div><div><br></div>
<div>This might be interesting. If the Service Provider (or in WRAP the Authorization Server) had a trusted app on your cell phone, this scenario might work:</div><div><ol><li>User navigates to their PS3 account menu and says they want to hook up their Twitter feed (just an example).</li>
<li>PS3 asks the user to enter the code from their authorization device.</li><li>The user's phone beeps. On the phone is a prompt that says "Your PS3 wants access to your Twitter feed. If this is ok, enter A3VD5 at the PS3 console."</li>
<li>User uses the on-screen keyboard on the TV to enter the code.</li><li>Device authorized.</li></ol><div>This seems to me a secure, reasonable experience, that's even more convenient than entering a whole username+password combo, and doesn't require that you trust the device any more than the specific authorization being granted. And it's all possible with OAuth, or OAuth WRAP. WRAP makes this even more interesting <i>if</i> a common Authorization Server is trusted by multiple Service Providers, such that the user can install just one Authorization Server's smart client app on their cell phone, and have it serve as this authorization point for many services.</div>
<div><br></div><div>Can anyone improve on this?</div></div><div><br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre<br>
<br><br><div class="gmail_quote">On Wed, Feb 17, 2010 at 9:55 AM, valentino miazzo <span dir="ltr"><<a href="mailto:valentino.miazzo@blu-labs.com">valentino.miazzo@blu-labs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi all,<br>
<br>
For Russel:<br>
<div class="im"><<What you seem to have missed is that the trust model of OpenID is<br>
*explicitly* built upon the assumption that the end user *never*<br>
provides their credentials to the relying party (your set top box, in<br>
this case).>><br>
</div>Now I can understand why the "OpenID ecosystem" can be reluctant to<br>
support this use case.<br>
I can only point out there is a small difference for a user in trusting:<br>
1- a web browser built-in in a PS3 (it cannot be substituted with<br>
another trusted one)<br>
2- a Facebook gadget built-in a mobile phone from Sony-Ericsson<br>
3- a rich application burned in a blu-ray disc from Sony Pictures<br>
In any case the user has trust that Sony will not leak the credentials<br>
typed in those "systems".<br>
Cases 1 and 2 are already happening, why don't leave to the user the<br>
freedom to choose if trust or not the company that produced the BD disc?<br>
Anyway, thank you Russel for the "philosophical" POV.<br>
Note: I put Sony here just because it was a nice example. It can be any<br>
other company.<br>
<br>
For Allen and Andrew,<br>
Thanks for the OAuth WRAP hint.<br>
Just one clarification: It looks something better can be obtained using<br>
just OpenID, please correct me.<br>
1- The rich application is in the OpenID trust list of the user.<br>
2 -The user is using the rich application and chooses to login using<br>
OpenID .<br>
3- The rich application requests authentication to the OP<br>
4- if the user is already logged in OpenID then the authentication is done<br>
5- if the user is not logged in OpenID then the rich application asks<br>
him to do it via an HTML browser and press "continue" when done (go to 3)<br>
It seem possible to avoid the typing of the request token in the HTML<br>
browser.<br>
Is that correct?<br>
What are the pro of OAuth WRAP in this case?<br>
<br>
Thank you again,<br>
<font color="#888888">Valentino<br>
<br>
</font></blockquote></div><br></div>