<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV>Joaquin</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Here is my clarification between Push and Pull:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Pull:</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>- The user provides the Relying Party with a *user unique* Repository locator. (URL or XRI)</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>- The Relying Party queries a Repository to get user data.</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>- The user may or may not be involved in the transaction.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I consider OpenID, LID and XRI Pull architectures</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Push:</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>- The Relying party advertises what data it wants.</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>- The user "Pushes" the data to the Relying Party</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN>- The repository does not need to be accessible to the Relying Party. This allows the data to reside on the user's machine.</DIV><DIV><SPAN class="Apple-tab-span" style="white-space:pre">        </SPAN></DIV><DIV>I consider Shiboleth, SXIP and WS-* Push architectures</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>....</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>With SXIP, which is a Push architecture, we have a need for protocol discovery, which lead to my interest in Yadis. Unlike the Pull technologies where the identifier is for the user, the identifier was for the user agent so that the Relying Party would know what the user agent was capable of. This is only needed for zero desktop footprint implementations. Rich Clients would be able to negotiate capabilities with the Relying Party.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>The original Yadis mandate was for identity protocol discovery. I was very interested in leveraging existing work, if it did not impose excessive overhead. The current direction of Yadis seems to be exclusively for support of the Pull technologies. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Feel free to ask for any clarifications.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-- Dick</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><DIV><DIV>On 2-Mar-06, at 4:38 PM, Joaquin Miller wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"> <FONT size="3">This might be right (someone who uses the terms might could explain them) <BR><BR> and it is certainly clear, which is very useful. <BR><BR> <BLOCKQUOTE type="cite" class="cite" cite="">Okay, let me see if I have this Push/Pull distinction straight. Please correct me if I'm wrong.<BR><BR> "Pull" protocols are those that put some data out there to be accessible via a URL. The data does not change based on who requests the information. Yadis is such a protocol, since when an Relying Party goes to fetch the data, there is no specified way to change the data based on who is requesting it.<BR><BR> "Push" protocols are those that allow the user to modify the data based on who is requesting it. OpenID is such a protocol: the data is transmitted by redirecting the user between the Relying Party and the Identity Provider, and the user can choose to have the Identity Provider send his or her authentication information or to cancel the transaction.<BR><BR> Is that right, or is there something I'm missing?</BLOCKQUOTE><BR> If this is what 'push' and 'pull' mean, then your examples are certainly right: According to your distinction Yadis is pull and OpenID and LID are push. LID, of course, differs from OpenID; you describe OpenID in your example of push.<BR><BR> Cordially, Joaquin</FONT> </BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>