Shibboleth Developers

["David L. Wasley" <>]

I agree completely with Scott, of course :-).  Shib is about exchange 
of trustworthy information, not about authN or what that information 
represents.

Since for higher ed (at least) one possible piece of information is a 
persistent identifier, I have been suggesting that the Grid use that 
for it's purposes.

Maybe I should ask: what functionality is the Grid really looking for?

If the Grid issues its own x.509 credentials, then it's clearly not 
looking for authentication.  If Grid apps want to use the identifier 
in those credentials to query a user's HO AA, then I suggest that the 
HO's EPPN for that user be in the Grid cert somewhere.

Is there something else?

        David
-----
At 11:29 AM -0500 on 1/20/04, Scott Cantor wrote:

>  >  There are applications out there that have authentication schemes
> >  other than Handles. Assuming that Shib wants to work with these
> >  applications it seems like one of two things has to happen:
> >
> >   1) The Shib AA has to understand the identities used by these
> >  applications (either in addition to handles/EPPNs or instead of).
> >
> >   2) The applications have to understand handles/EPPNs (I'm not sure
> >  which) so that they can cast their questions in terms the shib AA
> >  understands.
>
> I'd rather there not be any implication about EPPNs being somehow part of
> Shibboleth or in any way related to the notion of a handle. eduPerson is
> really the source of the promulgation of EPPN as a global username for
> principals across higher ed. If we think that's not a good solution, then we
> should use something else, but Shibboleth really doesn't have to be a part
> of that discussion.
>
> Probably it is a decent solution but doesn't replace the existing investment
> some may have in X.500, I would imagine. I can't think of anything else that
> has any real global reach.
>
> As far as handles go, I'd rather focus on the underlying concept here, which
> is representing a unique identity while preserving privacy. SAML 2.0 will
> standardize two ways of doing this: transient identifiers which are
> essentially like our handles and "federated" identifiers which are
> persistent pair-wise aliases for a principal. Both are intended to address
> privacy and work to prevent activity correlation across sites.
>
> Absent either of those considerations, other naming approaches probably make
> more sense, and SAML is agnostic to all of them.
>
> >   In other words, where do you want to put the burden of federating the
> >  identities?
>
> Depending on how you define that, there is no identity federation happening
> if you use a globally unique identifier. I prefer a more relaxed definition,
> but either way, the issues are different if you don't need privacy.
>
> >   #1 seems to have the advantage that applications are kept simpler,
> >  but requires support of extra namespaces by the administrator/deployer
> >  of the shib AA.
>
> It's almost a requirement to really address applications that can't deal
> with and manage an opaque identity though (e.g. storing of aliases). At the
> very least, you have to map right away to something non-opaque, leaving one
> to question the point of that. So I think we want the SAML authorities to
> support flexible policy about supporting different kinds of subject names
> based on the relying party, and that's where we're headed, which just makes
> the subject one among the full set of attributes we're talking about.
>
> >   #2 allows anyone who understands the EPPN/handle namespace to talk to
> >  the shib AA without any special support from it, but obviously is more
> >  work on their part.
>
> The AA really doesn't care at all about the name *until you try and address
> presence as a requirement*, and any persistent name fails at that, so
> probably that's something we need to address more generally than just
> forcing people to use handles.
>
> -- Scott