openid.ui.mode for embedded devices
hitoshi.uchida at gmail.com
Tue Feb 16 09:23:47 UTC 2010
Thank you very much for your advice.
After signing up to the contribution agreement as individual,
is it right that I should discuss the topic in below mailing list ?
2010/2/16 Nat Sakimura <sakimura at gmail.com>:
> Hi Hitoshi,
> This is a very interesting and important topic.
> I actually advise you to join ui WG by signing up to the contribution
> There, you can discuss in more detail than here.
> Since we must not allow IPR contamination, any "really" technical
> needs to happen in the WG.
> On Tue, Feb 16, 2010 at 12:18 AM, Hitoshi Uchida <hitoshi.uchida at gmail.com>
>> 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;
>> 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,
>> 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.
>> Hitoshi Uchida <hitoshi.uchida at gmail.com>
>> user-experience mailing list
>> user-experience at lists.openid.net
> Nat Sakimura (=nat)
> user-experience mailing list
> user-experience at lists.openid.net
Hitoshi Uchida <hitoshi.uchida at gmail.com>
More information about the user-experience