This really is case for using OAuth — since it was designed to take care of the "no-browser" use case, which OpenID is limited by.<div><br></div><div>These links might help:</div><div><br></div><div><a href="http://developer.yahoo.com/oauth/guide/openid-oauth-guide.html">http://developer.yahoo.com/oauth/guide/openid-oauth-guide.html</a></div>
<div><a href="http://hueniverse.com/oauth/">http://hueniverse.com/oauth/</a></div><div><br></div><div>Chris<br><br><div class="gmail_quote">On Wed, Feb 3, 2010 at 6:58 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,<br>
I'm developing applications for Bluray players and I would like to add<br>
OpenId compatibility of our applications.<br>
<br>
For who don't know, a Bluray applications is a sort of applet wrote in<br>
Java 1.3 using AWT for the UI.<br>
You don't have a built-in HTML browser.<br>
As far I can see, all the big OPs are assuming that the user-agent is<br>
able to parse HTML.<br>
Maybe this is not in the standard but seems to be the current de-facto<br>
situation.<br>
<br>
I see 3 solutions;<br>
<br>
A) we embed a 100% Java HTML browser on our applications.<br>
We did some tests and existing solutions are far from perfect.<br>
Glitches and issues are common.<br>
Not professional nor reliable.<br>
<br>
B) we use "reverse engineering" to see how the top OP implemented their<br>
forms and forge the POST request by hand in the bluray application.<br>
As example, for myopenid we need to reverse how these URL<br>
<a href="https://www.myopenid.com/signin_submit" target="_blank">https://www.myopenid.com/signin_submit</a> ,<br>
<a href="https://www.myopenid.com/trust_submit" target="_blank">https://www.myopenid.com/trust_submit</a> should be used.<br>
This solution is fragile. Our application will break each time one OP<br>
changes something in the POST "syntax".<br>
This leads to the solution C.<br>
<br>
C) define in the OpenId specification how OP forms use POST to login<br>
and/or change trust lists.<br>
This solution is the best one because it avoids the use of an HTML<br>
browser and is not prone to break suddenly.<br>
Off course this solution would be beneficial for any device can use HTTP<br>
but not HTML.<br>
<br>
How impossible is to have such extension to the standard?<br>
What are the problems?<br>
<br>
BTW, I saw a post in the BOARD ML: "Question on implementation of<br>
OAUTH/OpenID for Set-top-box".<br>
It cover the same problem but the thread stops without any solution.<br>
<br>
Thanks in advance,<br>
Valentino<br>
_______________________________________________<br>
Code mailing list<br>
<a href="mailto:Code@lists.openid.net">Code@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-code" target="_blank">http://lists.openid.net/mailman/listinfo/openid-code</a><br>
</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>