Shibboleth Developers

At 1:56 AM -0500 1/23/02, Scott Cantor wrote:
>  > Furthermore, an EPPN from one domain can not be assumed to be unique
> >  across all such domains, i.e. it is not globally unique.  Therefore,
> >  as an application or resource manager, I would always make the
> >  association
> >
> >     unique_user_identifier = concatenation (EPPN, <asserting domain> )
>
> Maybe I'm wrong, but I understood the intent to be that EPPN was
> universally (more or less) unique?
>
> In other words, I thought EPPN alone was supposed to be unique without
> appending anything else to it. Otherwise, why have the right-hand side?

I'd agree -- I think that was the intent. But, I think two things 
have changed substantially since the time we defined EPPN:

1) the shib architecture has changed. To my knowledge, Shib is the 
only use case we've envisioned so far to use EPPN. Remember -- EPPN 
was defined before the Shib conversations got real serious. I *think* 
we were originally imagining that the target web server would 
directly contact the enterprise directory at the origin site, and 
would retrieve the EPPN attribute associated with the user, and would 
compare that string against some local policy rule. (Take a look at 
http://middleware.internet2.edu/shibboleth/shibboleth-project.html to 
see how much our thinking about Shib has evolved....).  Previously, 
things like EPPN had to be complete unto themselves -- thus the idea 
that "EPPN was supposed to be unique all by itself,without appending 
anything to it". Now, we are appending something to it and to all of 
the other attributes (we're appending the scoping information).

2) We're now using SAML Assertions to transport Attributes (along 
with scoping, or domain, information) from the origin to the target. 
And we're transporting lots of different kinds of attributes (eg 
Affiliation, enrolledCourse, OU, etc). Our thinking has also evolved 
on this. We've now got a "standard" way to specify and transport 
scoping information for all of these (and all of them need scoping).

I'm suggesting that we update how we think of EPPN, and how we treat 
it, to reflect the huge evolution of our thinking since the time that 
EPPN was originally defined. That definition of EPPN made sense with 
the original Shib model (see above url). I think we've moved past 
that, to a better place, and its time to update EPPN, to be 
consistent with the rest of our attributes.
--

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--