<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Peter,<div><br></div><div><div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div><font face="Arial">For the user, this comes down to a first hand experience of: 1) choose an SP target, 2) select an IDP, 3) be "fowarded" towards the authentication service of that IDP. As a proprietary extension of SAML1.1 facilitatin the (non-standard) SP-initiated websso flow, it makes sense.</font></div></span></blockquote><div><br></div><div>This is the most common deployment strategy, yes. However, there's nothing in Shibboleth or SAML that constrains it to this model; it can be IdP-first, or IdP selection can be done at the resource by use of buttons or a text field, etc. etc. Any SP can decide through its configuration how to do this.</div><div><br></div><div>I think this is the essential point to stress: Shibboleth discovery is completely optional and entirely unrelated to the security model.</div></div></div><div><br></div><div><blockquote type="cite"><span class="Apple-style-span" style="color: rgb(0, 0, 0); "><font face="Arial">To help make the distinction clearer, let me encourage us to adopt some terminology for what seems to be two, quite different, communication patterns: "chaining" vs "referals". </font><font face="Arial">To be intellectually safe, I'm stealing these terms from the well worn LDAP/X.500 (distributed) directory service protocol -- standardized by the highly formal ISO/ITU-T process, as augmented by additional IETF and MACE profiling work. Because of Drummond's ultra clearly described model for abstract/concrete identifiers (persistent URNs, in webspeak) - where he implied that understanding these construct are essential to comprehension of the OpenID2 model -- I want to note in particular that the LDAP/X.500 directory model subsumes the (really old) X.650 Recommentation - whose naming/addressing/registration model also concerns those names/identifiers/addresses which are specifically "persistent".</font></span></blockquote><div><font class="Apple-style-span" face="Arial"><br></font></div><div><font class="Apple-style-span" face="Arial">These aren't analogous to discovery in Shibboleth, and we don't have either in Shibboleth today.</font></div><div><font class="Apple-style-span" face="Arial"><br></font></div><div><font class="Apple-style-span" face="Arial">To go on a brief tangent, where they will arise is in attribute aggregation, which is the process of pulling identity information from multiple providers and collating it. This problem will become very real in our federations as community members increasingly have their primary account outside the organization, but there are attributes, licenses, and trust models for which the organization itself will always be the only authority.</font></div><div><font class="Apple-style-span" face="Arial"><br></font></div><div><font class="Apple-style-span" face="Arial">The three most likely solutions to the attribute aggregation problem are:</font></div><div><font class="Apple-style-span" face="Arial"><br></font></div><div><font class="Apple-style-span" face="Arial">1) Proxying, e.g. chaining, of requests and attributes. Today there are quite a few deployers experimenting with this process simply by setting up an IdP -> SP -> IdP + more attributes -> SP chain, which effectively destroys all information about the initial IdP and is a chaining model.</font></div><div><font class="Apple-style-span" face="Arial">2) Referrals through sending a unique identifier for a second IdP and a second unique identifier for the user inside an assertion from one IdP. The SP could then chase the referral by making a query to the second IdP using the second identifier. The use of separate identifiers maintains the user's privacy and allows for some cool techniques, like the Liberty Alliance's early work, but it's not strictly necessary. Those core ideas were good, if a little complex and ahead of their time.</font></div><div><font class="Apple-style-span" face="Arial">3) Smart clients that can grab and present multiple claims/assertions at once.</font></div><div><font class="Apple-style-span" face="Arial"><br></font></div><div><font class="Apple-style-span" face="Arial">#3 is my preferred choice by far, the simplest, and the least likely to succeed. None has been widely attempted outside of the laboratory to date.</font></div><div><font class="Apple-style-span" face="Arial"><br></font></div><div><font class="Apple-style-span" face="Arial">Thanks for your insights,</font></div><div><font class="Apple-style-span" face="Arial">Nate.</font></div></div></body></html>