Shibboleth Developers

["David L. Wasley" <>]

I have a problem with this.  I assume the EPPN is supposed to be 
unique within the domain supported by the directory.  It is not 
obvious to me that one can make the assumption that removing 
something from it results in a substring that continues to be unique 
within that same domain.  Rather, I assume there is some reason for 
the "@<RHS>" component being in the directory in conjunction with the 
<LHS>.

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

(I'm trying to use general terminology)

Therefore I think Scott's proposal, that the the EPPN be considered 
an opaque string regardless of whether it has an '@' or not, is the 
proper one.

But then maybe I'm missing something...

        David
-----
At 3:54 PM -0500 on 1/19/02, Scott Cantor wrote:

>  > PROPOSAL
> >  Create a new dynamic attribute, supported by Shibboleth, and called
> >  SHIB_EPPN. If an ARP instructed an AA to provide this attribute, the
> >  AA would obtain the user's EPPN attribute from their directory
> >  object, would strip the RHS and the @, and provide the LHS as the
> >  value of SHIB_EPPN.  This attribute would be scoped, like any other
> >  Shibboleth attribute, by the value of the SecurityDomain element.
>
> Is this appropriate for current (if any) deployments of EPPN who embed
> security realm information that is needed to insure uniqueness?
>
> Maybe the answer is to just ignore EPPN and mandate a new username
> attribute that is unique within a security domain as defined by
> Shibboleth (as opposed to one defined by eduPerson or a directory). For
> most deployments it may be equal to EPPN, and when it's not, leave that
> to the site to resolve.
>
> >  The SHAR, using its default AAP, would, as usual, ensure that this
> >  particular AA can make assertions about this SecurityDomain. And,
> >  probably, that the scope equals the org name. (It might also check to
> >  ensure that the SHIB_EPPN does NOT contain a @.)
>
> As a general rule, I want the XML parser to enforce the syntax of
> attributes. If you want to ban @, then we'll write a schema to define
> the username string with the appropriate regexp.
>
> -- Scott

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

   http://archives.internet2.edu/

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