Shibboleth Developers

[Tom Barton <>]

Abstracting a bit from the particulars of this use case, it might be 
worth considering a model in which a resource manager can initiate a 
request for attributes about an already-authenticated user. Instead of 
attributes being bound to users by virtue of the authentication process 
employed, as occurs in shibboleth v1 because of its focus on the web 
browser use case, there would need to be a step in which a resource 
manager asks an origin to search for a user identity based upon whatever 
authenitcation artifacts it has in hand ( in Mark's 
example). Attributes could only be transmitted if that search is successful.

In addition to a dav server, perhaps Von's GridFTP use case could be 
addressed in this way.

Tom

Scott Cantor wrote:

> > A final note -- I wonder if for DAV we should focus more on using Shib for
> > authorization and not authentication. That is if I know it's
> >
> >  and unt.edu is in my federation can I call the unt.edu
> > origin server to see data about mewilcox?
>
>
> Well, that's one possibility. The other is to consider writing a file system
> extension for some popular systems that can do a redirect-based SSO. Doesn't
> really solve the client issue, but might help illustrate the concept for
> vendors.
>
> -- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--