It's unclear what kind of alternative you're proposing, Valentino.<div><br></div><div>At some point, the user must interact with his/her IDP in order to validate the request — without a web browser involved, you'll have to figure out some way to interact with each IDP individually, which would likely require you to pre-register your client device with the IDP so that they can gauge whether to trust the request or not. Even still, that defeats the security model of OpenID.</div>
<div><br></div><div>We've been down this path several times in the past several years and the result was OAuth.</div><div><br></div><div>While it may seem inelegant to have the user interact with a secondary browser-enabled device to authorize access to their account, we've yet to come up with a scalable, universal solution that is also secure.</div>
<div><br></div><div>You may have name for your solution, but how would it work technically? What would the user experience be like? And how would it keep the user safe?</div><div><br></div><div>Curious to hear your proposal.</div>
<div><br></div><div>Chris<br><br><div class="gmail_quote">On Thu, Feb 4, 2010 at 9:18 AM, Andrew Arnott <span dir="ltr"><<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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><div class="im"><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><div><div></div><div class="h5"><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" target="_blank">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>> 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></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Chris Messina<br>Open Web Advocate, Google<br><br>Personal: <a href="http://factoryjoe.com">http://factoryjoe.com</a><br>Follow me on Twitter: <a href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><br>
<br>This email is: [ ] shareable [X] ask first [ ] private<br>
</div>