<div class="gmail_quote">2009/1/31 Nat Sakimura <span dir="ltr"><<a href="mailto:sakimura@gmail.com">sakimura@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
:-)<br><br>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: <br>
<br>--------<br>Hi.<br>
<br>
I'm Toru Yamaguchi (=zigorou).<br>
I'm interested in OpenID for Mobile.<br>
<br>
My presentation of OpenID for Mobile(Jp) was translated by wil(=wil).<br>
<a href="http://dready.org/blog/2009/01/02/mobile-openid-in-japan/" target="_blank">http://dready.org/blog/2009/01/02/mobile-openid-in-japan/</a><br>
<br>----------<br><br>Now, as to the mobile/artifact mode, I kind of feel that it probably is better to establish a second channel. <br><br>So, the flow is like: <br><br>1. RP constract a request string as usual (including ones for the various extensions -- means it could be fairly long.) <br>
2. RP posts this to the OP's artifact mode endpoint published in OP's XRD. <br>3. OP issues a nonce as an "artifact" or "ticket". <br>4. RP redirects the browser with this artifact. <br>5. OP, receiving this artifact, reconstructs the OpenID message from the <br>
post received in step 2 above. <br>6. Credentail presentation etc. happens as usual, and OP verifies the user's identity. <br>7. OP creates a positive response and stores it with the artifact as the key. <br>8. OP redirects the browser with the artifact to the RP. <br>
9. RP fetches the response created in 7. and examines it to authorize the access. <br><br>
Nice thing about this is that it probalby is going to be a very little code addition to the current libraries. <br><br>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. <br>
<font color="#888888">
<br></font></blockquote><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">=nat</font><div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">
On Sat, Jan 31, 2009 at 3:21 AM, Johannes Ernst <span dir="ltr"><jernst+<a href="http://openid.net" target="_blank">openid.net</a>@<a href="http://netmesh.us" target="_blank">netmesh.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div><div>In which case, back to your original question:</div><div><div>
<br></div><div><blockquote type="cite"><blockquote type="cite">Are there poeple who are interested in discussing OpenID Mobile profile sort of thing? <br></blockquote></blockquote></div><div><br></div></div><div>My answer would be "Yes".</div>
<div><div></div><div><div><br></div><div><br></div><br><div><div>On Jan 29, 2009, at 22:14, Nat Sakimura wrote:</div><br><blockquote type="cite">There are two issues involved. <br><br>1) URL length etc. limitations<br>
2) User interface<br><br>1) has impact on 2). <br><br>For instance, we want to avoid the users pressing buttons when redirecting. <br>And, in many cases, we do not have javascript. <br> This means we are left with GET and this URL length limitation becomes an issue. <br>
<br>2) cannot be solved globally because it could very well be somewhat dependent on <br>the carrier implementation and handset capability. <br> For most of the phones in Japan, we can get unique <br>id for each handset at http level fairly securely so we can depend on it to <br>
avoid any typing (not even username etc.). This was one of the factor why <br>m-commerce got so popular in Japan. <br> <br>In many other markets, e.g., the U.S., this is not granted. Thus, some other means <br>are required. I know, WIl Tan of Maleysia is working something on iPhone in this regard. <br>
Essentially, it needs to be solved per carrier or per handset class <br> (e.g., mid-p enabled phones, etc.), I think. <br><br>=nat<br><br><div class="gmail_quote">On Fri, Jan 30, 2009 at 2:56 PM, Johannes Ernst <span dir="ltr"><jernst+<a href="http://openid.net" target="_blank">openid.net</a>@<a href="http://netmesh.us" target="_blank">netmesh.us</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><div>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?<div>
<br></div><div>IMHO the most important question to ask for mobile devices is: can we do without "typing" anything?</div><div><br></div><div><div><div><div></div><div><div>On Jan 29, 2009, at 16:56, Nat Sakimura wrote:</div>
<br></div></div><blockquote type="cite"><div><div></div><div>Hi. <br><br>Are there poeple who are interested in discussing OpenID Mobile profile sort of thing? <br>Mobile phones has unique challenges of being restricted in URL length etc. <br>
OpenID as it stands now has very lengthy URLs in both requests and responses and it sometimes does not fit into the restrictions. <br> SAML world has defined artifact binding to cope with it. IMHO, OpenID should define something like that also. <br>
<br>In Japan, there are bunch of people (including mobile carriers) who wants to do it. <br><br>Are there interest here as well? <br clear="all"> <br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
</div></div><div> _______________________________________________<br>specs mailing list<br><a href="mailto:specs@openid.net" target="_blank">specs@openid.net</a><br><a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
</div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br></blockquote></div>
<br></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br>
</div></div><br>_______________________________________________<br>
specs mailing list<br>
<a href="mailto:specs@openid.net">specs@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/specs" target="_blank">http://openid.net/mailman/listinfo/specs</a><br>
<br></blockquote></div><br><div>=wil</div>