Re: OpenID Mobile Profile?
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 sakim...@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@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
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. 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 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 sakim...@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@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
http://xri.net/=wil On Fri, Jan 30, 2009 at 11:54 AM, Breno de Medeiros br...@google.comwrote: 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. 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 sakim...@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?
Re: OpenID Mobile Profile?
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.comwrote: 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. 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. 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 sakim...@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
Re: OpenID Mobile Profile?
In which case, back to your original question: Are there poeple who are interested in discussing OpenID Mobile profile sort of thing? My answer would be Yes. On Jan 29, 2009, at 22:14, Nat Sakimura wrote: 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@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@openid.net http://openid.net/mailman/listinfo/specs -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
