Well, OAuth WRAP partially solves the problem because the protocol actually has a profile that doesn't require a web browser. It requires that the client app collect the username+password of the user, which it then forwards to the service provider in exchange for the WRAP token. <div>
<br></div><div>The downsides of this approach is that it depends on the user having a username+password to begin with (which if it's a pure OpenID account, or Infocard, etc. there won't be one) and it requires the user to disclose the password to a third party.</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 Thu, Feb 4, 2010 at 6:10 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;">
Andrew Arnott said the following on 04/02/2010 14.48:<br>
<div class="im">> You're correct, Valentino. In OAuth, a device without a web browser on<br>
> it must indicate to the user to find a web browser [on another device]<br>
> to authorize the token.<br>
><br>
</div>Ask to a user in the sofa (watching a bluray movie) to find a web<br>
browser to login and then go back is not an option. Nobody will do it.<br>
So, it seems Oauth has the same limits of OpenId from this point of view.<br>
<br>
Returning to solution C ... in the opinion of you, experts and founders<br>
of OpenId and Oauth, there is any chance that a some point OpenId<br>
Providers will converge on a common "submit API" ?<br>
I have already the name: Embedded OpenId<br>
:)<br>
<br>
Thanks.<br>
<font color="#888888">Valentino<br>
<br>
<br>
</font></blockquote></div><br></div>