[Concordia] A wiki page for our IdP Discovery Problem educational materials

[Josh Howlett]

Hi Mikael,

Discovery and trust path establishment are orthogonal. As an analogy, you can use TLS to estalish trust with a peer whose network address you have discovered using insecure DNS.

IIRC, eduGAIN (like the Shibboleth profile) does not consider discovery to be in-scope.

best regards, josh.

> -----Original Message-----
> From: community-bounces at projectconcordia.org 
> [mailto:community-bounces at projectconcordia.org] On Behalf Of 
> Mikaël Ates
> Sent: 22 January 2008 10:03
> To: Eve Maler
> Cc: community at projectconcordia.org
> Subject: Re: [Concordia] A wiki page for our IdP Discovery 
> Problem educational materials
> 
> Hi the Concordia community,
> 
> Eve have posted about the "where are you from" issue. I am 
> also working on this (like everyone I guess...) so I would be 
> pleased if anybody could give me his opinion about something 
> like "Say me something about you, I will say you where you 
> are from" and also if you ever hear something about this? In 
> fact, these works mainly concern trust path establishment.
> 
> I suppose that the SP/RP and the Authority (STS, SAML IdP, 
> etc...) are not directly trust linked. So there is "n" 
> indirect trust links and n+1 nodes. The nodes at the 
> boundaries are the security information (token, assertion, 
> etc...) producer and consumer. The "middle nodes" ensure what
> SAML2 called "IdP proxing", which means for me transitive 
> trust. I called them trusted nodes. The issue is: the user is 
> "on" the SP and want to authn (or else) on an Authority 
> indirectly trusted by the SP (Does it sound like a reallife case?).
> I suppose that the Authority and trusted nodes metadatas are 
> "publicly" 
> avaible which means that all the trust links can be known. So 
> it also means that it is feasable for an SP or a dedicated 
> entity (maybe a "trust router") to construct a complete 
> "trust path table".
> The SP asks the user a "hint", something like a URI or a domain name. 
> The SP presents the user a form or a claim requirement 
> (satisfied by an infocard containing the hint). With this 
> hint the SP is able to match one of the trust paths.
> So the SP redirects the user to the first trusted node of the 
> path, which the SP directly trusts. The SP also gives the 
> hint while the redirection. Hence, the trusted node will 
> perform an other "jump" in the
> path: matching and redirection.
> One of the application I see is for a sort of internationnal 
> confederation. For now, you would have choosen your country 
> on the SP for the first redirection, your organization on the 
> trusted node, and then you would have authenticated on your 
> IdP. There, we only have one trusted node, so it is feasable 
> to require the human intervention to establish the trust 
> path. But it is not if we have n trusted nodes...
> In fact, some confederation project (eduGAIN) rely on a 
> common PKI, so there is a common "metadatas pool" of the 
> confederation which allows to search (also thanks to a hint) 
> the IdP directly in the metadatas, and dynamically establish 
> a direct trust link between the SP and the IdP. 
> Here, I treat another case, in which we don't have a common 
> PKI or whatever secondary common trust architecture which 
> would allow a dynamic direct trust establishment. In the case 
> of a dynamic direct trust establishment, the SAML ECP profile 
> or Infocard tech would be enough to solve the WAYF issue. In 
> fact, there is common trust architecture which would be the 
> (con)federation by itself.
> 
> Regards,
> 
> Mikaël Ates
> DIOM Laboratory - ISTASE School of Engineering University of 
> Saint-Etienne - FRANCE mikael.ates at univ-st-etienne.fr
> +33 4 77 43 50 34
> 
> Eve Maler wrote:
> > I finally created a place to put our IdP discovery thoughts; that 
> > action has been hanging out there for a while.  Please feel free to 
> > edit, correct, flesh out, etc.  Scott and Jeff and George, I'd be 
> > especially grateful for your contributions since we all indicated 
> > interest in carrying this forward.
> >
> > 
> http://projectconcordia.org/index.php/The_Identity_Provider_Discovery_
> > Problem
> >
> > By the way, in some private conversations I've been having, 
> it seems 
> > deployers would find a similar exercise for single logout to be 
> > useful.  It's got some of the same characteristics: sensitive to UI 
> > concerns, decisions get based as much on business as technical 
> > considerations, confusing, no one perfect solution vs. lots of 
> > imperfect solutions that involve tradeoffs...  If you're 
> interested, 
> > please raise your hand (or just start writing a new page!).
> >
> > 	Eve
> >
> > Eve Maler                                         +1 425 947 4522
> > Principal Engineer                            eve.maler @ sun.com
> > CTO Business Alliances group                Sun Microsystems, Inc.
> >
> > _______________________________________________
> > Community mailing list
> > Community at projectconcordia.org
> > http://lists.projectconcordia.org/mailman/listinfo/community
> >
> > Participating in this discussion list does not grant any 
> intellectual property rights or any commitment by the 
> participants of the content discussed to any organization.
> >   
> 
> _______________________________________________
> Community mailing list
> Community at projectconcordia.org
> http://lists.projectconcordia.org/mailman/listinfo/community
> 
> Participating in this discussion list does not grant any 
> intellectual property rights or any commitment by the 
> participants of the content discussed to any organization.
> 

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG