[Code] OpenId on no HTML user-agents
Chris Messina
chris.messina at gmail.com
Thu Feb 4 17:20:35 UTC 2010
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>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> 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/20100204/f98135d1/attachment-0001.htm>
More information about the Code
mailing list