openid.ui.mode for embedded devices

Allen Tom atom at yahoo-inc.com
Wed Feb 17 07:01:26 UTC 2010


Hi Hitoshi -

Although users generally authenticate with their OpenID Provider using a
username/password, the OpenID spec does not require users to have passwords.
OpenID currently requires users to have browsers so that users can
authenticate using other methods besides a password.

If you do expect to authenticate users with a username/password on a
browserless client, then I suggest looking at Oauth-WRAP's username/password
profile defined in section 5.3 of the WRAP spec.

More info about Oauth-WRAP is here:
http://groups.google.com/group/oauth-wrap-wg

Thanks
Allen


On 2/15/10 7:18 AM, "Hitoshi Uchida" <hitoshi.uchida at gmail.com> wrote:

> Hi Allen,
> 
>> We definitely are interested in defining modes for clients other than
>> desktop web browsers, especially for mobile devices, set-top boxes
>> (Playstation/X-box/DVD Players), and other embedded devices.
> 
>> Is that what you had in mind?
> 
> Those devices you mentioned can have a normal web browser because they
> are allowed to be large size and have rich memory and CPU. The devices
> I mentioned is more small and has more limited resources like audio,
> camera and so on.
> 
> I would like the spec to support an additional mode which enables a
> consumer to request a simple login page to be published to client side
> against IdP.
> For instance, as I mentioned in my prior email about
> 'openid.ui.mode=svg', 'openid.ui.mode=MIME-type' enables the consumer
> to request its desired login page against IdP. Maybe
> 'openid.ui.type=MIME-type' may be better as the query name to
> distinguish from 'openid.ui.mode'.
> 
> Almost of IdP publish a login page representing a rich user interface;
> for examples, based on HTML + JavaScript + CSS. The devices I
> mentioned can't display it against users. If the login pages is simple
> and fixed permanently, it would be easy to convert the page to a
> specific page UA can display. (for instance, html page would be
> converted to SVG. Then, the client side analyzes the HTML page to
> detect the POST endpoint to be used to submit the user id and
> password. And the client generates the SVG login page)
> However, if the login page published by IdP is changed, the conversion
> program of client side wouldn't be available.
> So I think above additional mode is needed by small devices whose
> resources are limited.
> 
> In addition to that, as I posted another mailing list in below,
> http://lists.openid.net/pipermail/openid-code/2010-February/000095.html
> the client side can easily find the POST endpoint to authenticate the
> user by analyzing only the link element of HEAD section.
> 
> Best Regards,
> Hitoshi Uchida
> 
> 
>> At least with regards to mobile devices, it turns out that the 500x500 popup
>> mode seems to work very well for iPhones and similar mobile clients.
>> 
>> 
>> Thanks
>> Allen
>> 
>> 
>> 
>> 
>> On 2/5/10 10:13 AM, "Hitoshi Uchida" <hitoshi.uchida at gmail.com> wrote:
>> 
>>> Dear all,
>>> 
>>> Concerning 'openid.ui.mode', do you have a plan to support more mode ?
>>> 
>>> Though UI extension spec describes 'popup'
>>> and for instance Google Federated Login API also supports currently,
>>> even if embedded devices would like to use OpenID/OAuth,
>>> they need web browser to show the html login page against users.
>>> 
>>> So, if the provider side supports, for instance, 'openid.ui.mode=svg',
>>> embedded devices supporting SVG renderer can use OpenID/OAuth to
>>> access protected resources securely.
>>> In another way, maybe it could be done by sending
>>> 'Accept : image/svg+xml' header from UA.
>>> 
>>> Anyway, if UI extension spec and real provider services supports more mode,
>>> OpenID/OAuth would be used in more various use case;
>>> especially embedded devices.
>>>  So, I would like to discuss about this topic in this mailing list.
>> 
>> 
> 
> 



More information about the user-experience mailing list