openid.ui.mode for embedded devices

Nat Sakimura sakimura at gmail.com
Tue Feb 16 02:54:12 UTC 2010


Hi Hitoshi,

This is a very interesting and important topic.

I actually advise you to join ui WG by signing up to the contribution
agreement.

There, you can discuss in more detail than here.
Since we must not allow IPR contamination, any "really" technical
discussion
needs to happen in the WG.

Cheers,

=nat

On Tue, Feb 16, 2010 at 12: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.
> >
> >
>
>
>
> --
> Regards,
> Hitoshi Uchida <hitoshi.uchida at gmail.com>
> _______________________________________________
> user-experience mailing list
> user-experience at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-user-experience
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20100216/2791283b/attachment.htm>


More information about the user-experience mailing list