Wil Tan » Blog Archive » On Mobile OpenID in Japan

On Mobile OpenID in Japan

This presentation by =zigorou (Toru Yamaguchi) titled “Considering OpenID for Mobile” (Thanks =peterd and =nat) is particularly interesting for me due in part to MojiPage as well as my dabblings in various OpenID implementations.

Knowing that mobile usability is an important topic for OpenID implementors and users, and the rest of world probably has a lot to learn from the Japanese mobile ecosystem, I decided to exercise my Japanese skills and extract some points out of the slides (no, I’m not going to, nor qualified enough to do a full translation. Try Google for that). Please note that this is merely a best-effort translation and any error you find is likely to come from my ignorance.

Translated version follows the actual presentation:

Mobile Openid

View SlideShare presentation or Upload your own. (tags: mobile openid)

Considering Mobile OpenID
- Taking into account Japan’s unique mobile scenario, explore the feasibility and methods of implementing mobile OpenID
- Investigate if the protocol needs to be modified
- Look at ways to make use of mobile characteristics to enhance usability
Limitations and Characteristics of Mobile (Devices)
- Technical Limitations
  - maximum URL length
  - Cookies support
  - IP address blocks and individual identification number (are we talking about carrier gateway IPs and identification headers?)
- Device Limitations
  - manual URL entry - no way
  - manual ID/password input seems too difficult
Maximum URL Length — Carrier Restrictions
- DoCoMo
  - According to “NTT DoCoMo’s standard / guide for common device capabilities”…
  - Encoded URL maximum length = 512 bytes
- au
  - From Open Appli (Java)
    - Maximum 256 bytes and ASCII only
    - Since this is only for “Open Appli (Java)” stuff, this source may not be reliable
- SoftBank
  - From Web & Network Technical Information / Development Tool -> HTML Chapter - 2.5.8 URI Restrictions
    - Roughly 1024 bytes
    - Since this is only for “Open Appli (Java)” stuff, this source may not be reliable
- Summary: Assume 256 bytes
  - Surprisingly small - is that ok?
  - As for au, since source code is in Java, should assume at most 512 bytes
URL Length — Practical Observation
- Logging in to pibb using myopenid (with SREG)
  - checkid_setup > 567 bytes
  - id_res > 921 bytes
  - checkid_immediate > 430 bytes
URL Length — Think Harder
- UA is used for Indirect Communication, so we only need to consider checkid_setup/checkid_immediate, id_res/setup_needed/cancel
- checkid_* authentication requests can be done using GET or POST. With POST requests, the URL parameters go into the request body.
- id_res/setup_needed/cancel comes in the form of HTTP redirect, so GET requests only
- Empirically: id_res parameters requires a combined size of 728 bytes + the URL endpoint itself.
Content Body Limitation for POST
- According to ziguzagu: minimum 5KB (for DoCoMo PDC) => should be sufficient
- we still need to solve the problem of indirect communication: id_res requires a lot of parameters
Tackling id_res
- Basics: OP attaches the authentication result as query parameters to the return_to URL and redirects the UA to it. Do we need anything other than the following for signature verification?
  - openid.mode
  - openid.ns
  - openid.response_nonce
  - openid.assoc_handle
  - openid.signed
  - openid.sig
- According to OpenID Authentication 2.0, Section 11 “Verifying Assertion”:
  - The following steps are taken
    1. Verifying return_to URL
    2. Verifying discovered information
    3. Checking the nonce
    4. Verifying Signatures
  - Are the first two steps absolutely necessary?
  - The basic goal is to verify the data from the OP via indirect communication, it might be good enough to verify signature + nonce in this step?
  - If we had the ability to verify signature in check_authentication, that might work?
- Therefore, adding mode, signed, sig, response_nonce to the URL, we get 468 bytes!
- Moreover, if we delegate everything to the OP, we only need response_nonce and op_endpoint => 289 bytes.
- Conclusion
  - Minimize id_res as much as possible
  - If we have a method to ask the OP via direct communication (keying off response_nonce), that would work.
  - We could also obtain parameters like identity and claimed_id from the OP in the same vein
Cookie support in Mobile
- DoCoMo doesn’t support cookies in the first place
- au has separate secure/non-secure characteristics (?), and there’s a pitfall in using cookies in non-secure mode. (Translator’s note: Not quite sure what this means)
- For Softbank, one cannot access cookies in SSL realm in non-SSL pages (much like the secure-characteristic operation)
- Therefore, cookies are not quite useful for us
The way that mobile web security works (Translator’s note: heavily interpreted)
- There are published IP blocks that each mobile carrier uses
- Unique identification number for the device/subscriber can be provided to the sites (via HTTP header). Used with published IP block, this is an effective way to identify a returning user.
- Generally, it’s better to obtain the subscriber ID rather than device ID
  - imode ID
  - EZ-number
  - x-jphone-uid
- Instead of cookies, device/subscriber IDs are used for session management
- The availability of device/subscriber ID also eases the login process considerably at the OP’s end (during checkid_setup/checkid_immediate)
What’s possible with Mobile OpenID
- Unified identity for PC and mobile world
- Possible ways to link the PC and mobile
  - enabling mobile to as your private information store
  - enabling mobile for settling payment
Summary
- There are challenges:
  - Maximum URL length problem
    - First, URL length needs to be shortened
    - Still, without fixing the protocol, we could exceed the URL length limit => counting on =nat for OpenID Authentication 2.1
  - Unique identification + IP — increases the convenience of using OpenID on mobile, but one must always remember to update the IP blocks lists.
- Looking forward to more active discussions on Mobile OpenID next year

Related posts:

This blog is OpenID enabled! One thing led to another. After reading my previous entry on “mod_python OpenID Access Control”, Nate Olson contacted me...
OpenID for Drupal There was a thread on the OpenID list around the subject of OpenID support in Drupal. Previously, I’ve experimented with...
mod_python OpenID Access Control Since XRI is pretty much in bed with OpenID and NeuStar is an XRI shop, I get to play around...
Why be an OpenID Relying Party? Plaxo’s Joseph Smarr presented the following at the OpenID Design Summit at Facebook HQ yesterday: What an "RP" Wants View...
(Lack of) English Word Wrapping in Japan Here’s a pic of the information panel on a train a took in Tokyo while heading towards Shinjuku: Notice how...

Related posts brought to you by Yet Another Related Posts Plugin.

This entry was posted on Friday, January 2nd, 2009 at 4:12 pm and is filed under japan, mobile, openid. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

On FriendFeed, this post was liked by 0 people and commented on 0 times hide

View this post on FriendFeed

Comments to “On Mobile OpenID in Japan”

Martin Atkins Says:
January 3rd, 2009 at 1:55 pm

This is really useful research. I wonder how much of this applies outside the Japanese mobile market, and whether these limitations are on the device or in the network itself.

One thing that should be noted is that OpenID 2.0 *does* allow the responses to be transmitted as POST requests. There is the problem that this is under the control of the OP, but if the OP is modified to support doing authentication with subscriber ID then presumably it can also be modified to respond with a POST request when it does this.

Some libraries will of course need to be modified since currently most do not allow the caller to choose between GET and POST explicitly.

wil Says:
January 5th, 2009 at 10:46 pm

I too wonder if this situation is unique to the Japanese mobile market. Korean mobile carriers come to mind (in terms of how customized the network can be.)

At least for DoCoMo, I believe the restrictions are applied at the imode gateways. However, the distinction of where the limitations live may not be so relevant since Japanese mobile carriers pretty much dictate the design specifications for the device lineups.

Using POST for authentication responses will probably work if implementations are following the spec, i.e. looks in both the query string as well as POST body. It needs to be verified.

I’m going to try it out in the next few days and report back.