Shibboleth Developers

[Scott Cantor <>]

>  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