Shibboleth Developers

At 8:08 AM +0200 10/17/03, Aumont - Comite Reseaux des Universites wrote:
> > > > > You can "trust" them, but you have to understand what they mean.  And yes,
> > > > > my point exactly is that in the general case there is no guarantee that an
> > > > > email address listed for a user is under the control of that user.
>  This discussion started because some Shib designer says that users 
> have multiple email addresses and may want to subscribe with 
> "alternate email addresses". Right ?

I think the starting point was "when I create a presence, an 
identity, in sympa, when kind of identifier do I want to give to 
sympa?". Traditionally, because of the nature of mailing list 
managers, this identity has been an email address.

We're suggesting that sympa, when it is shibboleth-enabled, should 
accept a different kind of identity attribute from shibboleth -- the 
so-called eduPersonPrincipalName (EPPN). This value is assigned to 
the person by their origin site, and their origin can state, with a 
high degree of assurance, that this EPPN belongs to this browser 
user. With email address, on the other hand, there is some variation 
from campus to campus in their policies related to who can edit this 
value... and consequently there is a lower level of assurance about 
the correctness of this value.

> A mailling list server should not allow anyone to subscribe to 
> anylist with an email address which corresponding mailbox is not 
> under his control . Right ? Well, if email attributes herited by 
> Sympa from Shib authentication are unverified email addresses , you 
> will just have to configure Sympa in order to ignore these 
> attributes. Sympa already allows alternate email adresses to be 
> declared by the users. On this opposite, if email attributes herited 
> by Sympa from Shib authentication are verified emails addresses, it 
> will be possible to configure Sympa to accept any of those email 
> addresses for subscription, unsubscription etc.

the problem is that policies with respect to editing the email 
attribute are in effect at the origin campus, and the sympa server is 
a target. Consequently, any given sympa server might receive an email 
attribute from campus A (where the campus can assert the value) and 
an email attribute from campus B (where the campus cannot assert the 
value).

Consequently, our suggestion is to NOT use email address as the 
primary identifier for an individual, as the key field. Instead, 
we're suggesting you use EPPN (REMOTE_USER). In a previous note, Bob 
described the U-Wash mailman mods, which included an algorithm that 
tried to take advantage of the email attribute (if it was present), 
while giving the user a choice about what email address sympa should 
use..........

> It's just a matter of Sympa configuration to define what Shib 
> attribute provide a trusted email address.

see above.....