<HTML>
<HEAD>
<TITLE>Re: [Code] OpenId on no HTML user-agents</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi Valentino -<BR>
<BR>
If you’re trying to get a BD Player to connect to your web services, you’re probably going to need to pass a credential to the device so that it can access your APIs. Unfortunately, OpenID by itself does not solve this use case – you’ll have to use Oauth. However, Oauth requires a browser.<BR>
<BR>
If your device doesn’t have a browser, and you’re expecting your users to authenticate with a username and password, then Oauth-WRAP will probably satisfy your requirements.<BR>
<BR>
See Section 5.5 – Username/Password Profile in the WRAP spec for more details.<BR>
<BR>
More details about OAuth-WRAP are here:<BR>
<a href="http://groups.google.com/group/oauth-wrap-wg">http://groups.google.com/group/oauth-wrap-wg</a><BR>
<BR>
Allen<BR>
<BR>
<BR>
<BR>
On 2/15/10 12:25 AM, "valentino miazzo" <<a href="valentino.miazzo@blu-labs.com">valentino.miazzo@blu-labs.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi Allen,<BR>
maybe you missed my answer to <I>Yang Zhao : </I><a href="http://lists.openid.net/pipermail/openid-code/2010-February/000088.html">http://lists.openid.net/pipermail/openid-code/2010-February/000088.html</a> <BR>
<BR>
> is the use-case that certain browserless devices need a standardized way to authenticate a user? <BR>
Yes<BR>
<BR>
> How is the user expected to authenticate with their identity provider?<BR>
Via a java application burned on a blu-ray disc<BR>
<BR>
> Do you need to support an infinite number of identity providers, or just a few? <BR>
I hoped to use OpenId to support an infinite number of IP.<BR>
<BR>
The main reason to support OpenId is avoid the registration and login steps.<BR>
I assume the user has a pre-existing OpenId account created before via HTML browser.<BR>
<BR>
Thanks,<BR>
Valentino<BR>
<BR>
<BR>
Allen Tom said the following on 13/02/2010 1.10: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
[+specs@openid]<BR>
<BR>
Hi All -<BR>
<BR>
I missed some of the context here - is the use-case that certain browserless<BR>
devices need a standardized way to authenticate a user? How is the user<BR>
expected to authenticate with their identity provider? Do you need to<BR>
support an infinite number of identity providers, or just a few?<BR>
<BR>
At least in my experience, most of these specialized devices only need to<BR>
authenticate with a single identity provider. For example, Yahoo has<BR>
partnered with many HDTV manufacturers to let Yahoo users use their Yahoo<BR>
account on the TV set. In this case, we use a proprietary protocol that is<BR>
nearly identical to the "Username/Password Profile" defined in Section 5.3<BR>
of the WRAP-0.9.7.2 spec.<BR>
<BR>
It's also pretty much equivalent to Google's Client Login interface.<BR>
<BR>
In both cases, the client asks the user for their username/password, and the<BR>
client validates the username/password with the authentication server.<BR>
<BR>
If that's what you want, then I suggest reading the Oauth-WRAP spec.<BR>
More details here:<BR>
<a href="http://groups.google.com/group/oauth-wrap-wg">http://groups.google.com/group/oauth-wrap-wg</a><BR>
<BR>
Hope that helps,<BR>
Allen<BR>
<BR>
<BR>
<BR>
<BR>
On 2/11/10 10:04 AM, "valentino miazzo" <<a href="valentino.miazzo@blu-labs.com">valentino.miazzo@blu-labs.com</a>> <<a href="mailto:valentino.miazzo@blu-labs.com">mailto:valentino.miazzo@blu-labs.com</a>> <BR>
wrote:<BR>
<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
Hi Hitoshi,<BR>
<BR>
I agree.<BR>
More in general, this mechanism can be used to avoid to hard-code in the<BR>
spec of the extension some constants.<BR>
<BR>
There are millions of connected BD players and HDTVs not able to parse HTML.<BR>
The owners of these devices would find in the proposed extension another<BR>
good reason to obtain an OpenID.<BR>
<BR>
Thanks,<BR>
Valentino<BR>
<BR>
Hitoshi Uchida said the following on 11/02/2010 18.42:<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
Hi Valentino,<BR>
<BR>
I'm also would like OpenID/OAuth WG to consider the embedded devices<BR>
usecase which don't have a web browser.<BR>
<BR>
I understand your consideration that definition of POST URLs to be<BR>
used for submit and trust operation is helpful for those embedded<BR>
devices.<BR>
However, I think it wouldn't be good solution to define the path of<BR>
URL like '/signin_submit' or '/trust_submit' as spec.<BR>
<BR>
So my idea is that a below tag should be contained in the HEAD section<BR>
of the HTML loggin page sent by OP like OpenID HTML discovery.<BR>
<link rel="openid2.provider.signin openid.server.signin"<BR>
href="<a href="https://www.myopenid.com/signin_submit">https://www.myopenid.com/signin_submit</a>" <<a href="https://www.myopenid.com/signin_submit">https://www.myopenid.com/signin_submit</a>> /><BR>
<BR>
Then, for instance, 'signin_id' and 'signin_password' parameters<BR>
representing user's account information would be sent against the URL.<BR>
<BR>
And a below tag would be contained in the trust/deny HTML page sent<BR>
after the user's authentication.<BR>
<link rel="openid2.provider.trust openid.server.trust"<BR>
href="<a href="https://www.myopenid.com/trust_submit">https://www.myopenid.com/trust_submit</a>" <<a href="https://www.myopenid.com/trust_submit">https://www.myopenid.com/trust_submit</a>> /><BR>
<BR>
Those simple tag can be parsed easily by embedded devices.<BR>
And also, such an additional link tag of HEAD section can keep<BR>
interoperability.<BR>
<BR>
What do you think ?<BR>
<BR>
Best Regards,<BR>
Hitoshi Uchida<BR>
<BR>
<BR>
<BR>
2010/2/11 valentino miazzo <<a href="valentino.miazzo@blu-labs.com">valentino.miazzo@blu-labs.com</a>> <<a href="mailto:valentino.miazzo@blu-labs.com">mailto:valentino.miazzo@blu-labs.com</a>> :<BR>
<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
Chris, did you have a chance to read my answer?<BR>
Does anyone has something to add?<BR>
<BR>
Thanks<BR>
Valentino<BR>
<BR>
PS: Added Allen Tom and Hitoshi Uchida. They were discussing something<BR>
similar in openid-user-experience ML.<BR>
<a href="http://lists.openid.net/pipermail/openid-user-experience/2010-February/00111">http://lists.openid.net/pipermail/openid-user-experience/2010-February/00111</a><BR>
9.html<BR>
<BR>
valentino miazzo said the following on 05/02/2010 10.34:<BR>
<BR>
Hi Chris,<BR>
with the name proposal I wanted to be funny but maybe I seemed not humble.<BR>
Sorry for this.<BR>
<BR>
I will try to be more clear about my proposal.<BR>
Basically I see a low hanging fruit but, being a newbie with OpenId, maybe I<BR>
overlook something.<BR>
<BR>
As explained to Yang Zhao in another post I assume the user has a valid<BR>
OpenId.<BR>
I just want to be able to use such OpenId from limited devices.<BR>
It's OK that the user used an HTML browser to create his account.<BR>
<BR>
In my understanding of the OpenId user experience, the user interacts with<BR>
OP HTML pages in at least 2 scenarios (as told, I intentionally exclude<BR>
OpenId account creation):<BR>
1) the OpenId session is closed/expired and the user needs to login in his<BR>
OpenId account with a one factor authentication.<BR>
2) a RP not in the trust list requested user authentication and the user is<BR>
asked to trust it or deny. Plus the user can choose to add/remove the RP<BR>
to/from the trust list.<BR>
<BR>
For sure, an OP can add more features (2 factors authentications, Oauth,<BR>
etc...) but this seems the minimal possible interaction with the OP HTML<BR>
pages.<BR>
The involved OP HTML pages eventually send a POST request to an URL that<BR>
actually perform the login and trust management.<BR>
My proposal is add an extension to the specifications that dictates how<BR>
these 2 POST requests must be made.<BR>
As concrete example, if MyOpenId decides to adopt this extension then it<BR>
will change the code handling these 2 URLs<BR>
<a href="https://www.myopenid.com/signin_submit">https://www.myopenid.com/signin_submit</a> ,<BR>
<a href="https://www.myopenid.com/trust_submit">https://www.myopenid.com/trust_submit</a> to cope with the extension<BR>
specifications.<BR>
<BR>
Why do that? Because, in this way, user-agents not supporting HTML could<BR>
just ignore the HTML pages and invoke the POST URLs directly.<BR>
For users using an HTML browser nothing changes. POST syntax changes are<BR>
completely invisible to the user.<BR>
Maybe, OP supplying a richer user experience compared to what I described at<BR>
point 1 and 2 can offer simplified HTML pages and serve them to limited<BR>
devices.<BR>
<BR>
Point 5 of the protocol overview of OpenId 2.0 specs<BR>
(<a href="http://openid.net/specs/openid-authentication-2_0.html#anchor2">http://openid.net/specs/openid-authentication-2_0.html#anchor2</a>) says:<BR>
<<5. The OP establishes whether the end user is authorized to perform OpenID<BR>
Authentication and wishes to do so. The manner in which the end user<BR>
authenticates to their OP and any policies surrounding such authentication<BR>
is out of scope for this document. >><BR>
So, the proposed extension doesn't overlaps in any way with the OpenId specs<BR>
because this part was intentionally not part of the OpenId standard.<BR>
<BR>
I tried, but I'm not able to found how this extension could change the<BR>
existing security model of OpenId.<BR>
<BR>
I'm very interested in knowing your (and others) opinion.<BR>
<BR>
Thank you,<BR>
Valentino<BR>
<BR>
<BR>
<BR>
Chris Messina said the following on 04/02/2010 18.20:<BR>
<BR>
It's unclear what kind of alternative you're proposing, Valentino.<BR>
At some point, the user must interact with his/her IDP in order to validate<BR>
the request ‹ without a web browser involved, you'll have to figure out some<BR>
way to interact with each IDP individually, which would likely require you<BR>
to pre-register your client device with the IDP so that they can gauge<BR>
whether to trust the request or not. Even still, that defeats the security<BR>
model of OpenID.<BR>
We've been down this path several times in the past several years and the<BR>
result was OAuth.<BR>
While it may seem inelegant to have the user interact with a secondary<BR>
browser-enabled device to authorize access to their account, we've yet to<BR>
come up with a scalable, universal solution that is also secure.<BR>
You may have name for your solution, but how would it work technically? What<BR>
would the user experience be like? And how would it keep the user safe?<BR>
Curious to hear your proposal.<BR>
Chris<BR>
<BR>
On Thu, Feb 4, 2010 at 9:18 AM, Andrew Arnott <<a href="andrewarnott@gmail.com">andrewarnott@gmail.com</a>> <<a href="mailto:andrewarnott@gmail.com">mailto:andrewarnott@gmail.com</a>> <BR>
wrote:<BR>
<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
Well, OAuth WRAP partially solves the problem because the protocol<BR>
actually has a profile that doesn't require a web browser. It requires<BR>
that<BR>
the client app collect the username+password of the user, which it then<BR>
forwards to the service provider in exchange for the WRAP token.<BR>
The downsides of this approach is that it depends on the user having a<BR>
username+password to begin with (which if it's a pure OpenID account, or<BR>
Infocard, etc. there won't be one) and it requires the user to disclose the<BR>
password to a third party.<BR>
--<BR>
Andrew Arnott<BR>
"I [may] not agree with what you have to say, but I'll defend to the death<BR>
your right to say it." - S. G. Tallentyre<BR>
<BR>
<BR>
On Thu, Feb 4, 2010 at 6:10 AM, valentino miazzo<BR>
<<a href="valentino.miazzo@blu-labs.com">valentino.miazzo@blu-labs.com</a>> <<a href="mailto:valentino.miazzo@blu-labs.com">mailto:valentino.miazzo@blu-labs.com</a>> wrote:<BR>
<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
Andrew Arnott said the following on 04/02/2010 14.48:<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
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>
<BR>
<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><BLOCKQUOTE><BLOCKQUOTE><BLOCKQUOTE><BLOCKQUOTE><BLOCKQUOTE><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
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>
Valentino<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
<BR>
<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>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>