[Code] OpenId on no HTML user-agents
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?
PS: Added Allen Tom and Hitoshi Uchida. They were discussing something
similar in openid-user-experience ML.
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
> 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,
> 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.
>> 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
>> 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...
More information about the Code