<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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 overlook something.<br>
<br>
As explained to Yang Zhao in another post I assume the user has a valid
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 OP HTML pages in at least 2 scenarios (as told, I intentionally
exclude OpenId account creation):<br>
1) the OpenId session is closed/expired and the user needs to login in
his OpenId account with a one factor authentication.<br>
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.<br>
<br>
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.<br>
The involved OP HTML pages eventually send a POST request to an URL
that actually perform the login and trust management.<br>
My proposal is add an extension to the specifications that dictates how
these 2 POST requests must be made.<br>
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.<br>
<br>
Why do that? Because, in this way, user-agents not supporting HTML
could just ignore the HTML pages and invoke the POST URLs directly.<br>
For users using an HTML browser nothing changes. POST syntax changes
are completely invisible to the user.<br>
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.<br>
<br>
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:<br>
<<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. >><br>
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.<br>
<br>
I tried, but I'm not able to found how this extension could change the
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:
<blockquote
cite="mid:1bc4603e1002040920w2c5e99a1hf844a9dd820a0dd6@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.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;">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 class="h5">
<div class="gmail_quote">On Thu, Feb 4, 2010 at 6:10 AM, valentino
miazzo <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:valentino.miazzo@blu-labs.com" target="_blank">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;">
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 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>