[Code] OpenId on no HTML user-agents

valentino miazzo valentino.miazzo at blu-labs.com
Thu Feb 11 11:59:29 UTC 2010


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.
http://lists.openid.net/pipermail/openid-user-experience/2010-February/001119.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
> https://www.myopenid.com/signin_submit ,
> https://www.myopenid.com/trust_submit 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
> (http://openid.net/specs/openid-authentication-2_0.html#anchor2) 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 <andrewarnott at gmail.com
>> <mailto:andrewarnott at gmail.com>> wrote:
>>
>>     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
>>     <valentino.miazzo at blu-labs.com
>>     <mailto:valentino.miazzo at blu-labs.com>> wrote:
>>
>>         Andrew Arnott said the following on 04/02/2010 14.48:
>>         > 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.
>>         >
>>         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
>>
>>
>>
>>
>>
>>
>> -- 
>> Chris Messina
>> Open Web Advocate, Google
>>
>> Personal: http://factoryjoe.com
>> Follow me on Twitter: http://twitter.com/chrismessina
>>
>> This email is:   [ ] shareable    [X] ask first   [ ] private
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-code/attachments/20100211/275fceb7/attachment.htm>


More information about the Code mailing list