Shibboleth Developers

["David L. Wasley" <>]

I think the general case of a "portable handle," in spite of reduced 
privacy, has value as an extension to the basic model of 
"authenticate locally; authorize globally".  I think there may be a 
number of cases where the user may not be able to communicate with 
their local authN system but the target server could.

The reason I referred to the cert subject name as a "handle" is to 
reinforce the notion that it serves approximately the same function 
as the Shib handle.  I think this may have some implications for the 
subject name content as well as for the AA API.

I also thought the x.509 object would be rather easier to deal with 
as opposed to almost any other form of portable credential. 
Remember, it needs to be a digitally signed object for authenticity, 
and there needs to be some way to ensure that the person offering it 
"owns it."

I was also hoping that this would become another carrot (business 
driver in current-speak) to get schools to install or contract for a 
CA.  I have an explicit request from our faculty that they want this 
type of access across all UC campuses (it's ironic that our PKI 
project lost funding).  The faculty request is really why this issue 
came up recently.

And no, it isn't the same as pre-registration because it is 
independent of the location of use.  Also, a school could choose to 
make them good for 15 days if stored in a software cache or 2 years 
if they're on a smartUSB device.  Etc.

Finally, I do agree with Scott that sometimes we need to put 
something out there and see if it takes off.  Who knows, it might 
become the preferred method (at least until something better comes 
along).

Thanks,
        David

-----
At 4:21 PM -0400 on 5/1/04, Scott Cantor wrote:

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