Skip to Content.
Sympa Menu

shibboleth-dev - RE: Fwd: More detailed Grid scenarios

Subject: Shibboleth Developers

List archive

RE: Fwd: More detailed Grid scenarios


Chronological Thread 
  • From: "David L. Wasley" <>
  • To: Scott Cantor <>, "'Von Welch'" <>
  • Cc:
  • Subject: RE: Fwd: More detailed Grid scenarios
  • Date: Tue, 20 Jan 2004 09:58:38 -0800

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




Archive powered by MHonArc 2.6.16.

Top of Page