OpenID Mobile Profile?

Breno de Medeiros breno at google.com
Fri Jan 30 17:48:33 UTC 2009 

On Fri, Jan 30, 2009 at 9:41 AM, Wil Tan <wil at dready.org> wrote:

>
> On Fri, Jan 30, 2009 at 12:31 PM, Breno de Medeiros <breno at google.com>wrote:
>
>>
>>
>> On Fri, Jan 30, 2009 at 9:25 AM, Wil Tan <wil at dready.org> wrote:
>>
>>>
>>> http://xri.net/=wil
>>>
>>>
>>> On Fri, Jan 30, 2009 at 11:54 AM, Breno de Medeiros <breno at google.com>wrote:
>>>
>>>>
>>>>
>>>> 2009/1/30 Wil Tan <wil at dready.org>
>>>>
>>>>> 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
>>>>>
>>>>
>>>> This step is the easiest to optimize away. The RP could detect that the
>>>> client is of mobile type and the IP address the user is coming from. That
>>>> would immediately disclose a start point for discovery of user's OP
>>>> preferences, namely a location at the mobile carrier.
>>>>
>>>> Unfortunately, the browsers typically do not support javascript.
>>>> Otherwise at this point, it would be sufficient to make an AJAX request to
>>>> the well-known location to obtain the user's OP. Alternatively, the user
>>>> would be redirected to the location and it would then further redirect the
>>>> user to the user's OP. If the mobile carrier is the OP that last step would
>>>> not be necessary.
>>>>
>>>
>>> Agreed, this step can be easily optimized as long as the RP has a way to
>>> identify the user, via cookies or subscriber ID provided by the gateway.
>>> It's at most a click of a button away.
>>>
>>> This part shouldn't need to be in the profile.
>>>
>>>
>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Since OpenID RP requests are not signed, an artifact profile could be
>>>> simply be the URL where you can actually find the OpenID request.
>>>>
>>>>
>>>>
>>>>>  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.
>>>>>
>>>>
>>>> Just a bit latency delay.
>>>>
>>>>
>>>>> 6. Upon successful authentication, the OP needs to again present at
>>>>> least a submit button to POST the results back to the RP.
>>>>>
>>>>
>>>> Adding an artifact here could work very similarly
>>>>
>>>
>>>
>>> Yes, 4 and 6 are candidates for consideration. The exact mechanism will
>>> need to be hashed out.
>>>
>>> The current OpenID protocol doesn't require the RP to accept connections
>>> from the OP, which means that an RP could well be behind the firewall. It's
>>> a nice property to have. Using artifact binding for step 6 is fine, but
>>> doesn't step 4 require the OP to connect to the RP? I'm thinking something
>>> like a reverse artifact resolution:
>>>
>>> 1. Upon discovering the OP endpoint, posts the request there.
>>> 2. OP responds with a URL containing an artifact.
>>> 3. RP redirects user to that URL at the OP
>>> 4. OP resolves the artifact and finds the request in #1.
>>>
>>
>> This does not work so well if the OP is a distributed infrastructure.
>> There will be latency for the state to propagate so it may not be available
>> when the user comes to the OP.
>>
>>
> Doesn't this apply to existing association data that needs to be available
> to all machines serving the same distributed OP?
>
>
>
>> A better alternative would be for the RP to have a standard request
>> format. Then it could register the URL with the OP (essentially same as 1-2,
>> but the artifact could be pre-registed and is re-usable indefinitely, or at
>> least until the RP needs to construct requests differently). This is quite
>> feasible for directed identity flow. Even easier if we are using 'dumb mode'
>> so no association handles/association expiration issues are involved.
>>
>>
>>>
> Sounds interesting, but I don't understand what you mean by a standard
> request format. Could you elaborate? Thanks.
>

Well, if the RP is working in dumb mode, and using directed identity flow,
there are no parameters that are a function of the particular request. To be
fair, there could be several login flows, with different return_to URLs or
different combinations of extension parameters. But as long as they are a
small set of possible combinations, and not a function of the particular
request, then the RP can register these ahead of time with many OPs using
steps 1-2. The first time around it could even be 'on the fly' as the first
user lands from that OP. But if the flow is spec'ed out with a view that
artifacts will be register-once, re-use many, it will be much more likely
that it will provide adequate performance in practice.


>
>
>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> specs mailing list
>>>>> specs at openid.net
>>>>> http://openid.net/mailman/listinfo/specs
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> --Breno
>>>>
>>>> +1 (650) 214-1007 desk
>>>> +1 (408) 212-0135 (Grand Central)
>>>> MTV-41-3 : 383-A
>>>> PST (GMT-8) / PDT(GMT-7)
>>>>
>>>
>>> =wil
>>>
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk
>> +1 (408) 212-0135 (Grand Central)
>> MTV-41-3 : 383-A
>> PST (GMT-8) / PDT(GMT-7)
>>
>
>
> =wil
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090130/8466e533/attachment-0002.htm>

More information about the specs mailing list