[Code] OpenId on no HTML user-agents
Allen Tom
atom at yahoo-inc.com
Sat Feb 13 00:10:44 UTC 2010
[+specs at 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:
http://groups.google.com/group/oauth-wrap-wg
Hope that helps,
Allen
On 2/11/10 10:04 AM, "valentino miazzo" <valentino.miazzo at blu-labs.com>
wrote:
> 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:
>> 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="https://www.myopenid.com/signin_submit"/>
>>
>> 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="https://www.myopenid.com/trust_submit"/>
>>
>> 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 <valentino.miazzo at blu-labs.com>:
>>
>>> 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/00111
>>> 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
>>> 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>
>>> 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
>>>
>>>
>>
>>
>>
More information about the Code
mailing list