Re: OpenID Mobile Profile?
Hi Nat, OpenID has a huge opportunity in the mobile market, because logging in/registering is at least an order of magnitude more painful on a handset than on a standard desktop browser. Even with my iPhone, logging in is terrible, and I can't think of a single time I've bothered to register. At least from my perspective, I'm more interested in discussing UX rather than protocol changes. Although the URLs are getting really long, the URL length is an implementation detail that is mostly hidden from the user. Supporting the equivalent of SAML's artifact binding as an additional OpenID communication mode isn't really going to improve the UX for users of iPhone class devices. Because OpenID and OAuth appear to be converging, I'd prefer to see artifact-type binding implemented using OAuth's Request Token. In OAuth, the RP (aka Consumer) first requests a Request Token using direct communication, and then redirects the browser to the OP (aka SP) with the Request Token to maintain the state. Instead of having the browser pass all the request parameters on the URL, all the parameters are represented by the Request Token, which is intented to be relatively short. Allen 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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
:-) So we shall contiue. =zigorou, who wrote the Japanese presentation that Wil translated also posted a message to this list, but it apparently has gone into a moderation queue for some reason... So, here is his text: Hi. I'm Toru Yamaguchi (=zigorou). I'm interested in OpenID for Mobile. My presentation of OpenID for Mobile(Jp) was translated by wil(=wil). http://dready.org/blog/2009/01/02/mobile-openid-in-japan/ -- Now, as to the mobile/artifact mode, I kind of feel that it probably is better to establish a second channel. So, the flow is like: 1. RP constract a request string as usual (including ones for the various extensions -- means it could be fairly long.) 2. RP posts this to the OP's artifact mode endpoint published in OP's XRD. 3. OP issues a nonce as an artifact or ticket. 4. RP redirects the browser with this artifact. 5. OP, receiving this artifact, reconstructs the OpenID message from the post received in step 2 above. 6. Credentail presentation etc. happens as usual, and OP verifies the user's identity. 7. OP creates a positive response and stores it with the artifact as the key. 8. OP redirects the browser with the artifact to the RP. 9. RP fetches the response created in 7. and examines it to authorize the access. Nice thing about this is that it probalby is going to be a very little code addition to the current libraries. The difference between this flow and the SAML artifact binding is that in case of SAML, the artifact/ticket is created by the RP and OP goes and fetch the request from RP. I chose this design because RP can be inside the firewall when OP is on the internet which is a more likely use case for OpenID. =nat On Sat, Jan 31, 2009 at 3:21 AM, Johannes Ernst jernst+openid.net@ netmesh.us wrote: 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.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/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
2009/1/31 Nat Sakimura sakim...@gmail.com :-) So we shall contiue. =zigorou, who wrote the Japanese presentation that Wil translated also posted a message to this list, but it apparently has gone into a moderation queue for some reason... So, here is his text: Hi. I'm Toru Yamaguchi (=zigorou). I'm interested in OpenID for Mobile. My presentation of OpenID for Mobile(Jp) was translated by wil(=wil). http://dready.org/blog/2009/01/02/mobile-openid-in-japan/ -- Now, as to the mobile/artifact mode, I kind of feel that it probably is better to establish a second channel. So, the flow is like: 1. RP constract a request string as usual (including ones for the various extensions -- means it could be fairly long.) 2. RP posts this to the OP's artifact mode endpoint published in OP's XRD. 3. OP issues a nonce as an artifact or ticket. 4. RP redirects the browser with this artifact. 5. OP, receiving this artifact, reconstructs the OpenID message from the post received in step 2 above. 6. Credentail presentation etc. happens as usual, and OP verifies the user's identity. 7. OP creates a positive response and stores it with the artifact as the key. 8. OP redirects the browser with the artifact to the RP. 9. RP fetches the response created in 7. and examines it to authorize the access. Nice thing about this is that it probalby is going to be a very little code addition to the current libraries. The difference between this flow and the SAML artifact binding is that in case of SAML, the artifact/ticket is created by the RP and OP goes and fetch the request from RP. I chose this design because RP can be inside the firewall when OP is on the internet which is a more likely use case for OpenID. I like it! It's very much in line with what Breno and I have been discussing, but you've taken it a notch higher by reusing the artifact issued by the OP and optimizes it further. As I said earlier, I agree that keeping the ability for RP to stay within firewall is an important property to preserve. In NeuStar, we had a few intranet installation that can work with OPs on the Internet. =nat On Sat, Jan 31, 2009 at 3:21 AM, Johannes Ernst jernst+openid.net@ netmesh.us wrote: 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.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/ -- Nat Sakimura (=nat) http://www.sakimura.org/en/ ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs =wil ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
Thanks =nat to introduce my post. Considering openid mobile profile, I think to provide as openid extension. The extension uses likes artifact or direct communication OP to RP. I'll develop and try using real device. Toru Yamaguchi (=zigorou) 2009/1/31 Nat Sakimura sakim...@gmail.com: :-) So we shall contiue. =zigorou, who wrote the Japanese presentation that Wil translated also posted a message to this list, but it apparently has gone into a moderation queue for some reason... So, here is his text: Hi. I'm Toru Yamaguchi (=zigorou). I'm interested in OpenID for Mobile. My presentation of OpenID for Mobile(Jp) was translated by wil(=wil). http://dready.org/blog/2009/01/02/mobile-openid-in-japan/ -- Now, as to the mobile/artifact mode, I kind of feel that it probably is better to establish a second channel. So, the flow is like: 1. RP constract a request string as usual (including ones for the various extensions -- means it could be fairly long.) 2. RP posts this to the OP's artifact mode endpoint published in OP's XRD. 3. OP issues a nonce as an artifact or ticket. 4. RP redirects the browser with this artifact. 5. OP, receiving this artifact, reconstructs the OpenID message from the post received in step 2 above. 6. Credentail presentation etc. happens as usual, and OP verifies the user's identity. 7. OP creates a positive response and stores it with the artifact as the key. 8. OP redirects the browser with the artifact to the RP. 9. RP fetches the response created in 7. and examines it to authorize the access. Nice thing about this is that it probalby is going to be a very little code addition to the current libraries. The difference between this flow and the SAML artifact binding is that in case of SAML, the artifact/ticket is created by the RP and OP goes and fetch the request from RP. I chose this design because RP can be inside the firewall when OP is on the internet which is a more likely use case for OpenID. =nat On Sat, Jan 31, 2009 at 3:21 AM, Johannes Ernst jernst+openid@netmesh.us wrote: 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/ -- 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?
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?
? 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 -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) =wil ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
.). 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 -- --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) ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
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
OpenID Mobile Profile?
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
Re: OpenID Mobile Profile?
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 ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: OpenID Mobile Profile?
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
