<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Allen,<br>
maybe you missed my answer to <i>Yang Zhao
: </i><a class="moz-txt-link-freetext" 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:
<blockquote cite="mid:C79B2E04.2383F%25atom@yahoo-inc.com" type="cite">
<pre wrap="">[+specs@openid]
Hi All -
I missed some of the context here - is the use-case that certain browserless
devices need a standardized way to authenticate a user? How is the user
expected to authenticate with their identity provider? Do you need to
support an infinite number of identity providers, or just a few?
At least in my experience, most of these specialized devices only need to
authenticate with a single identity provider. For example, Yahoo has
partnered with many HDTV manufacturers to let Yahoo users use their Yahoo
account on the TV set. In this case, we use a proprietary protocol that is
nearly identical to the "Username/Password Profile" defined in Section 5.3
of the WRAP-0.9.7.2 spec.
It's also pretty much equivalent to Google's Client Login interface.
In both cases, the client asks the user for their username/password, and the
client validates the username/password with the authentication server.
If that's what you want, then I suggest reading the Oauth-WRAP spec.
More details here:
<a class="moz-txt-link-freetext" href="http://groups.google.com/group/oauth-wrap-wg">http://groups.google.com/group/oauth-wrap-wg</a>
Hope that helps,
Allen
On 2/11/10 10:04 AM, "valentino miazzo" <a class="moz-txt-link-rfc2396E" href="mailto:valentino.miazzo@blu-labs.com"><valentino.miazzo@blu-labs.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Hitoshi,
I agree.
More in general, this mechanism can be used to avoid to hard-code in the
spec of the extension some constants.
There are millions of connected BD players and HDTVs not able to parse HTML.
The owners of these devices would find in the proposed extension another
good reason to obtain an OpenID.
Thanks,
Valentino
Hitoshi Uchida said the following on 11/02/2010 18.42:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Valentino,
I'm also would like OpenID/OAuth WG to consider the embedded devices
usecase which don't have a web browser.
I understand your consideration that definition of POST URLs to be
used for submit and trust operation is helpful for those embedded
devices.
However, I think it wouldn't be good solution to define the path of
URL like '/signin_submit' or '/trust_submit' as spec.
So my idea is that a below tag should be contained in the HEAD section
of the HTML loggin page sent by OP like OpenID HTML discovery.
<link rel="openid2.provider.signin openid.server.signin"
href=<a class="moz-txt-link-rfc2396E" href="https://www.myopenid.com/signin_submit">"https://www.myopenid.com/signin_submit"</a>/>
Then, for instance, 'signin_id' and 'signin_password' parameters
representing user's account information would be sent against the URL.
And a below tag would be contained in the trust/deny HTML page sent
after the user's authentication.
<link rel="openid2.provider.trust openid.server.trust"
href=<a class="moz-txt-link-rfc2396E" href="https://www.myopenid.com/trust_submit">"https://www.myopenid.com/trust_submit"</a>/>
Those simple tag can be parsed easily by embedded devices.
And also, such an additional link tag of HEAD section can keep
interoperability.
What do you think ?
Best Regards,
Hitoshi Uchida
2010/2/11 valentino miazzo <a class="moz-txt-link-rfc2396E" href="mailto:valentino.miazzo@blu-labs.com"><valentino.miazzo@blu-labs.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Chris, did you have a chance to read my answer?
Does anyone has something to add?
Thanks
Valentino
PS: Added Allen Tom and Hitoshi Uchida. They were discussing something
similar in openid-user-experience ML.
<a class="moz-txt-link-freetext" href="http://lists.openid.net/pipermail/openid-user-experience/2010-February/00111">http://lists.openid.net/pipermail/openid-user-experience/2010-February/00111</a>
9.html
valentino miazzo said the following on 05/02/2010 10.34:
Hi Chris,
with the name proposal I wanted to be funny but maybe I seemed not humble.
Sorry for this.
I will try to be more clear about my proposal.
Basically I see a low hanging fruit but, being a newbie with OpenId, maybe I
overlook something.
As explained to Yang Zhao in another post I assume the user has a valid
OpenId.
I just want to be able to use such OpenId from limited devices.
It's OK that the user used an HTML browser to create his account.
In my understanding of the OpenId user experience, the user interacts with
OP HTML pages in at least 2 scenarios (as told, I intentionally exclude
OpenId account creation):
1) the OpenId session is closed/expired and the user needs to login in his
OpenId account with a one factor authentication.
2) a RP not in the trust list requested user authentication and the user is
asked to trust it or deny. Plus the user can choose to add/remove the RP
to/from the trust list.
For sure, an OP can add more features (2 factors authentications, Oauth,
etc...) but this seems the minimal possible interaction with the OP HTML
pages.
The involved OP HTML pages eventually send a POST request to an URL that
actually perform the login and trust management.
My proposal is add an extension to the specifications that dictates how
these 2 POST requests must be made.
As concrete example, if MyOpenId decides to adopt this extension then it
will change the code handling these 2 URLs
<a class="moz-txt-link-freetext" href="https://www.myopenid.com/signin_submit">https://www.myopenid.com/signin_submit</a> ,
<a class="moz-txt-link-freetext" href="https://www.myopenid.com/trust_submit">https://www.myopenid.com/trust_submit</a> to cope with the extension
specifications.
Why do that? Because, in this way, user-agents not supporting HTML could
just ignore the HTML pages and invoke the POST URLs directly.
For users using an HTML browser nothing changes. POST syntax changes are
completely invisible to the user.
Maybe, OP supplying a richer user experience compared to what I described at
point 1 and 2 can offer simplified HTML pages and serve them to limited
devices.
Point 5 of the protocol overview of OpenId 2.0 specs
(<a class="moz-txt-link-freetext" href="http://openid.net/specs/openid-authentication-2_0.html#anchor2">http://openid.net/specs/openid-authentication-2_0.html#anchor2</a>) says:
<<5. The OP establishes whether the end user is authorized to perform OpenID
Authentication and wishes to do so. The manner in which the end user
authenticates to their OP and any policies surrounding such authentication
is out of scope for this document. >>
So, the proposed extension doesn't overlaps in any way with the OpenId specs
because this part was intentionally not part of the OpenId standard.
I tried, but I'm not able to found how this extension could change the
existing security model of OpenId.
I'm very interested in knowing your (and others) opinion.
Thank you,
Valentino
Chris Messina said the following on 04/02/2010 18.20:
It's unclear what kind of alternative you're proposing, Valentino.
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.
We've been down this path several times in the past several years and the
result was OAuth.
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.
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?
Curious to hear your proposal.
Chris
On Thu, Feb 4, 2010 at 9:18 AM, Andrew Arnott <a class="moz-txt-link-rfc2396E" href="mailto:andrewarnott@gmail.com"><andrewarnott@gmail.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
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.
--
Andrew Arnott
"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
On Thu, Feb 4, 2010 at 6:10 AM, valentino miazzo
<a class="moz-txt-link-rfc2396E" href="mailto:valentino.miazzo@blu-labs.com"><valentino.miazzo@blu-labs.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Andrew Arnott said the following on 04/02/2010 14.48:
</pre>
<blockquote type="cite">
<pre wrap="">You're correct, Valentino. In OAuth, a device without a web browser on
it must indicate to the user to find a web browser [on another device]
to authorize the token.
</pre>
</blockquote>
<pre wrap="">Ask to a user in the sofa (watching a bluray movie) to find a web
browser to login and then go back is not an option. Nobody will do it.
So, it seems Oauth has the same limits of OpenId from this point of view.
Returning to solution C ... in the opinion of you, experts and founders
of OpenId and Oauth, there is any chance that a some point OpenId
Providers will converge on a common "submit API" ?
I have already the name: Embedded OpenId
:)
Thanks.
Valentino
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
--
Chris Messina
Open Web Advocate, Google
Personal: <a class="moz-txt-link-freetext" href="http://factoryjoe.com">http://factoryjoe.com</a>
Follow me on Twitter: <a class="moz-txt-link-freetext" href="http://twitter.com/chrismessina">http://twitter.com/chrismessina</a>
This email is: [ ] shareable [X] ask first [ ] private
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</body>
</html>