On Fri, Jan 30, 2009 at 12:48 PM, Breno de Medeiros <br...@google.com>wrote:
> > > On Fri, Jan 30, 2009 at 9:41 AM, Wil Tan <w...@dready.org> wrote: > >> >> On Fri, Jan 30, 2009 at 12:31 PM, Breno de Medeiros <br...@google.com>wrote: >> >>> >>> >>> On Fri, Jan 30, 2009 at 9:25 AM, Wil Tan <w...@dready.org> wrote: >>> >>>> >>>> http://xri.net/=wil >>>> >>>> >>>> On Fri, Jan 30, 2009 at 11:54 AM, Breno de Medeiros >>>> <br...@google.com>wrote: >>>> >>>>> >>>>> >>>>> 2009/1/30 Wil Tan <w...@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. > Thanks for the clarification. I see, using id_select and dumb mode, the only variable in the request is the return_to URLs, which would presumably be a small set. Therefore, this is a mechanism to minimize the potential problem of propagation delay within the OP's distributed architecture. In the process, it also saves some calls that RP has to make to the OP. What about other use cases, i.e. non- dumb mode and non- directed identity? Just means that 1-2 will have to be repeated for each request right? =wil
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
