[OpenID] Discovery and Security

[Nate Klingenstein]

Peter,

> 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.

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.

I think this is the essential point to stress: Shibboleth discovery is  
completely optional and entirely unrelated to the security model.

> 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".  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".

These aren't analogous to discovery in Shibboleth, and we don't have  
either in Shibboleth today.

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.

The three most likely solutions to the attribute aggregation problem  
are:

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.
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.
3)  Smart clients that can grab and present multiple claims/assertions  
at once.

#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.

Thanks for your insights,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080324/3e31ebdc/attachment-0002.htm>