OpenID Mobile Profile?

[Wil Tan]

I'm by no means familiar with the mobile market in Japan, but out of
interests I did spend some time researching it. To elaborate on Nat's
points:
As I understand it, a typical user interaction flow for mobile phone usage
in Japan goes like:

1. User browses the carrier deck, finds a site she's interested in, clicks
on the link.
2. She is brought to the site, and can immediately be identified for all
future visits (i.e. logged in.) This is possible because the site knows that
the IP address belongs to the mobile carrier, and that it can trust the
subscriber/device ID in the HTTP headers.

With OpenID comes additional features such as AX, but it is only usable, or
rather considered to be an acceptable user experience, if it doesn't add too
much to the flow above.

In the OpenID scenario, we assume that she uses OpenID to authenticate to
the site (RP), the flow continues:

3. First of all, the user needs to input an OpenID URI
4. Due to the URL length restriction, RP will have to use POST, which means
she will have to wait for the HTML form to be downloaded, then click on a
button to submit it.
5. She'll have to authenticate at the OP site, which we assume is no-op for
the user assuming the OP uses the subscriber/device ID provided by the
carrier.
6. Upon successful authentication, the OP needs to again present at least a
submit button to POST the results back to the RP.

The URL restriction forces the use of POST, which costs 2 additional steps
for the user, not to mention the additional bandwidth, time and attention
overhead.

It all boils down to providing a great mobile experience, which in turn
spurs adoption and innovation.

=wil

2009/1/30 Nat Sakimura <sakimura at gmail.com>

> There are two issues involved.
>
> 1) URL length etc. limitations
> 2) User interface
>
> 1) has impact on 2).
>
> For instance, we want to avoid the users pressing buttons when redirecting.
>
> And, in many cases, we do not have javascript.
> This means we are left with GET and this URL length limitation becomes an
> issue.
>
> 2) cannot be solved globally because it could very well be somewhat
> dependent on
> the carrier implementation and handset capability.
> For most of the phones in Japan, we can get unique
> id for each handset at http level fairly securely so we can depend on it to
>
> avoid any typing (not even username etc.). This was one of the factor why
> m-commerce got so popular in Japan.
>
> In many other markets, e.g., the U.S., this is not granted. Thus, some
> other means
> are required. I know, WIl Tan of Maleysia is working something on iPhone in
> this regard.
> Essentially, it needs to be solved per carrier or per handset class
> (e.g., mid-p enabled phones, etc.), I think.
>
> =nat
>
>
> On Fri, Jan 30, 2009 at 2:56 PM, Johannes Ernst <jernst+openid.net@
> netmesh.us> wrote:
>
>> Are you talking about URL length limitations for the identifiers that
>> users need to enter, or for URLs that are being sent around as part of the
>> protocol?
>> IMHO the most important question to ask for mobile devices is: can we do
>> without "typing" anything?
>>
>> On Jan 29, 2009, at 16:56, Nat Sakimura wrote:
>>
>> Hi.
>>
>> Are there poeple who are interested in discussing OpenID Mobile profile
>> sort of thing?
>> Mobile phones has unique challenges of being restricted in URL length etc.
>>
>> OpenID as it stands now has very lengthy URLs in both requests and
>> responses and it sometimes does not fit into the restrictions.
>> SAML world has defined artifact binding to cope with it. IMHO, OpenID
>> should define something like that also.
>>
>> In Japan, there are bunch of people (including mobile carriers) who wants
>> to do it.
>>
>> Are there interest here as well?
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>  _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090130/dc13fbd4/attachment-0002.htm>