Skip to Content.
Sympa Menu

shibboleth-dev - RE: A Case for Shibboleth and PKI (again)

Subject: Shibboleth Developers

List archive

RE: A Case for Shibboleth and PKI (again)


Chronological Thread 
  • From: Scott Cantor <>
  • To: 'Tom Barton' <>, "'David L. Wasley'" <>
  • Cc: 'Shibboleth Developers' <>, "'David H. Walker'" <>
  • Subject: RE: A Case for Shibboleth and PKI (again)
  • Date: Sat, 01 May 2004 16:21:22 -0400
  • Organization: The Ohio State University

> Does this problem really need shib? It's a real and common
> circumstance, but (1) there must be an alternative to federated
> solutions to guest network access, because many guests do not
> and will not originate from shibbolized environments (or a common
> federation, regardless of its architecture),

Problem with that argument: it applies to about 95% of the use cases for
federated identity already. It argues that anything less than a 100%
identity solution has no value, and I don't think that's true. The point is
to reduce the exceptions, not eliminate them (which is impossible).

> and (2), given (1), building 2 solutions to 1 problem, in which one of
> the solutions always works and
> the other does only sometimes, likely means that the solution that
> always works will be the only one much used and supported.

If there's a solution to authenticating people that's better than "let their
existing identity provider do it", then it should replace federated
identity, period. I think the alternative is to one-off them, and that
doesn't scale, but is completely necessary to deal with the exceptions.

> . How would a user get or maintain a "portable handle object"? Doesn't
> this require planning ahead, ie, be not all that different than
> pre-registration from the perspective of peoples' busy lives and
> changing travel requirements? The alternative would seem to be that
> fresh ones are somehow maintained in users' browsers by origin
> infrastructure automagically.

I think he's arguing for authentication with X.509 certificates. I think
using the word "handle" is a bad idea, and confuses the issue and brings
Shibboleth into the discussion prematurely. We have many different use cases
that are looking at authentication using some existing technology and SAML
as an attribute exchange mechanism. The Shibboleth AA supports this use case
today, no real changes required.

That said, I agree with you, it's not clear people can handle X.509 certs,
and I'll continue to believe it until I see evidence otherwise. This seems
like a proposal somewhere in between the longer term use of a key and the
short term kx509 CA. The latter works pretty well for some things, I guess
the question is how far you can push it.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page