<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
thanks Chris for the links but is not clear to me how OAuth can be used
without a HTML browser.<br>
Could you help me?<br>
<br>
I'm a newbie an I'm reading here
<a class="moz-txt-link-freetext" href="http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html">http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html</a> .<br>
<br>
At step 3, the user is asked to browse to
<a class="moz-txt-link-freetext" href="https://api.login.yahoo.com/oauth/v2/request_auth?oauth_token=">https://api.login.yahoo.com/oauth/v2/request_auth?oauth_token=</a><myreqtoken><br>
and the document says <br>
<<If your application does not have access to a browser, it must
provide the User with the Yahoo! authorization page URL and Request
Token, both provided in <a class="link"
href="http://developer.yahoo.com/oauth/guide/oauth-auth-flow.html#oauth-requesttoken"
title="Get a Request Token (get_request_token)">Step 2</a>. Your
application must provide directions for your User to manually browser
to the URL and enter the provided Request Token. >><br>
I imagine that
<a class="moz-txt-link-freetext" href="https://api.login.yahoo.com/oauth/v2/request_auth?oauth_token=">https://api.login.yahoo.com/oauth/v2/request_auth?oauth_token=</a><myreqtoken>
will return an HTML page were the user can permit or deny the
authorization.<br>
<br>
How a device not able to render an HTML page can allow to the user to
perform that choice?<br>
My guess is that such limited device can only suggest to use another
device (a PC) with a HTML browser.<br>
Where I'm wrong?<br>
<br>
Thank you,<br>
Valentino<br>
<br>
<br>
<br>
Chris Messina said the following on 03/02/2010 22.42:
<blockquote
cite="mid:1bc4603e1002031342t6021b14ew2aeac7b2b4b9a856@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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 moz-do-not-send="true" 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 moz-do-not-send="true"
href="mailto:valentino.miazzo@blu-labs.com">valentino.miazzo@blu-labs.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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 moz-do-not-send="true"
href="https://www.myopenid.com/signin_submit" target="_blank">https://www.myopenid.com/signin_submit</a>
,<br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" href="mailto:Code@lists.openid.net">Code@lists.openid.net</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" href="http://factoryjoe.com">http://factoryjoe.com</a><br>
Follow me on Twitter: <a moz-do-not-send="true"
href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a><br>
<br>
This email is: [ ] shareable [X] ask first [ ] private<br>
</div>
</blockquote>
</body>
</html>