[Code] OpenId on no HTML user-agents

Andrew Arnott andrewarnott at gmail.com
Wed Feb 17 18:09:35 UTC 2010


Valentino,

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).

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.

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.

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:

   1. User navigates to their PS3 account menu and says they want to hook up
   their Twitter feed (just an example).
   2. PS3 asks the user to enter the code from their authorization device.
   3. 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."
   4. User uses the on-screen keyboard on the TV to enter the code.
   5. Device authorized.

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 *if* 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.

Can anyone improve on this?

--
Andrew Arnott
"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


On Wed, Feb 17, 2010 at 9:55 AM, valentino miazzo <
valentino.miazzo at blu-labs.com> wrote:

> Hi all,
>
> For Russel:
> <<What you seem to have missed is that the trust model of OpenID is
> *explicitly* built upon the assumption that the end user *never*
> provides their credentials to the relying party (your set top box, in
> this case).>>
> Now I can understand why the "OpenID ecosystem" can be reluctant to
> support this use case.
> I can only point out there is a small difference for a user in trusting:
> 1- a web browser built-in in a PS3 (it cannot be substituted with
> another trusted one)
> 2- a Facebook gadget built-in a mobile phone from Sony-Ericsson
> 3- a rich application burned in a blu-ray disc from Sony Pictures
> In any case the user has trust that Sony will not leak the credentials
> typed in those "systems".
> Cases 1 and 2 are already happening, why don't leave to the user the
> freedom to choose if trust or not the company that produced the BD disc?
> Anyway, thank you Russel for the "philosophical" POV.
> Note: I put Sony here just because it was a nice example. It can be any
> other company.
>
> For Allen and Andrew,
> Thanks for the OAuth WRAP hint.
> Just one clarification: It looks something better can be obtained using
> just OpenID, please correct me.
> 1- The rich application is in the OpenID trust list of the user.
> 2 -The user is using the rich application and chooses to login using
> OpenID .
> 3- The rich application requests authentication to the OP
> 4- if the user is already logged in OpenID then the authentication is done
> 5- if the user is not logged in OpenID then the rich application asks
> him to do it via an HTML browser and press "continue" when done (go to 3)
> It seem possible to avoid the typing of the request token in the HTML
> browser.
> Is that correct?
> What are the pro of OAuth WRAP in this case?
>
> Thank you again,
> Valentino
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100217/da97a390/attachment.htm>


More information about the specs mailing list