[OpenID] An OpenID "mobile" Hint?
Tan, William
William.Tan at neustar.biz
Mon Jun 16 17:57:55 UTC 2008
+1
Requiring the RP to perform special processing is only going to work for
a small percentage of RPs out there, leaving the user desiring more.
Having an OP-selector intermediate screen is worse in terms of mobile
experience as page-loading is expensive (I'm not willing to wait 3
seconds to get to an intermediate screen, select the OP, then get
redirected to yet another site.)
Mobile-friendly OP is the way to go. Ultimately, it is the OP that is
presenting the sign-in UI, and therefore it should be the one detecting
UA and presenting an appropriate auth mechanism for the device. Most
existing OPs don't cut it mainly because it's hard to navigate to the
actionable UI components (login form, buttons, etc.) due to various
non-relevant elements like logo, navigation menus, etc. Using a
media="handheld" stylesheet might work in some cases, but still there
are many devices out there that don't support CSS, and the page is
generally still too large to be downloaded snappily. Also, bear in mind
that some WAP gateways (notably DoCoMo) don't even support cookies.
As Nat said, it would be great if OPs could incorporate the subscriber
credentials presented in the HTTP headers by WAP gateways, but not all
carriers support it and it depends on the "browsing profile" that the
user is using. If user is using straight TCP connections, such headers
are not going to be there.
=wil
Martin Atkins wrote:
> David Recordon wrote:
>
>> Agreed, in a perfect world you'd have lots of OPs with mobile
>> experiences. I guess part of what I'm thinking about is far less
>> around the technology and more around a forcing function to make it
>> very clear about which OPs support mobile and which don't. In the end
>> hopefully getting us to that perfect world.
>>
>>
>
> I assume having read the various responses that what we're discussing
> here is selecting the RP selecting different provider if the the RP is
> an explicitly-mobile site, such as http://m.facebook.com/.
>
> Now that I understand what you're trying to achieve, I can get behind it
> a bit more. I'm still not completely convinced that it's going to be
> that useful in practice, though: I know I generally use the main
> "desktop" version of most sites I visit on my phone, just because they
> tend to be more complete. I'd still prefer to see the a mobile-friendly
> OP UI, though.
>
> Also, some sites will have their main site simultaneously be the mobile
> site by simply providing a mobile stylesheet and doing capability
> determinations in script on the client-side. Such sites would have no
> reliable way to determine whether to set this flag or not, and would
> presumably therefore always use the non-mobile version.
>
> Finally, I'd be curious to hear which OpenID providers you percieve to
> have poor mobile experiences and what in particular makes them poor.
>
> I think I'd prefer something that requires less disruptive changes to
> what an RP is expected to do, such as something similar to the language
> preference proposal where the RP sets a flag saying that it's a mobile
> site in the request which allows the OP to select a mobile-friendly UI
> if available. This gives the OP an opportunity to make the switch if
> necessary, and can be implemented as a standard OpenID Auth extension.
>
> If a provider depends on some specific hardware to do authentication,
> then it's the responsibility of that provider to come up with an
> acceptable solution for situations where the user is unable to use that
> hardware for whatever reason.
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
More information about the general
mailing list