OpenID Mobile Profile?

Fri Jan 30 17:41:40 UTC 2009

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.

>
>>
>>
>>>
>>>
>>>>
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090130/d4ce7af3/attachment-0002.htm>