Hi Allen, <div><br></div><div><div>That can be done, but there are a few things to be considered as well. </div><div><br></div><div>1) Association is a rather expensive operation. We might not want to do it with </div><div>
every authentication request. </div><div>2) Breno wanted to have something like 400 bytes or so to achieve statelessness in 255bytes restriction may be too short for him. </div><div>3) Breno (and you I think) wanted to have the request artifact and response artifact different. </div>
<div>3) This would probably mean that we need to touch the core library in many case and arguably has larger impact - which means that we may end up with more adoption friction. (BTW, we actually wrote test code in Java, Python, PHP, and Ruby to see if the draft can be implemented without touching the core library.) </div>
<div>4) In the longer term, I am suspecting that association might be disappearing (like it did in Wrap) so depending on it might not be a good idea. </div><div><br></div><div>In fact, initially, I was thinking the same with you half a year ago, but after a while, I have abandoned the idea. Assuming that association happens once in every hundreds of authentication request, it just buys me 0.01 round trip per authentication request or less. It is going to be even less for a large provider. I could probably trade that round trip with the benefit gained from the above reasons. That's why I did not piggy back on the association. </div>
<div><br></div><div>=nat</div><div> </div><br><div class="gmail_quote">On Sat, Feb 13, 2010 at 1:39 PM, Allen Tom <span dir="ltr"><<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">Hi Nat -<br>
<br>
As an optimization, can we combine the association request with the artifact request? In fact, why can’t the association handle <b>be</b> the artifact?</span></font></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">
<br>
For example, when the RP requests association, it can pass along all the request parameters that it normally would pass via the browser in the authentication request. The OP can then return the association handle/artifact along with the shared secret.<br>
<br>
The RP then redirects the user’s browser to the OP with the association handle. After the user authenticates, the OP redirects the browser back to the RP with the association handle.<br>
<br>
The RP then makes a direct server call back to the OP with the handle (and probably also the shared secret) to fetch the assertion.<br>
<br>
I think this scheme will save a couple round trips.<br><font color="#888888">
<br>
Allen</font><div class="im"><br>
<br>
<br>
<br>
<br>
On 2/11/10 9:55 PM, "Nat Sakimura" <<a href="http://sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
<br>
</div></span></font><div class="im"><blockquote><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">If you look at my manuscript of the Artifact Binding (<a href="http://www.sakimura.org/specs/ab/1.0" target="_blank">http://www.sakimura.org/specs/ab/1.0</a> ) </span></font></blockquote>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>