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
