Re: some sec-tc use-case input

[Anders Rundgren <anders.rundgren@telia.com>]

Hi Bob,
I think I have mentioned Shibboleth a few times already as I think it is
a very interesting project.

Using S2ML v08.a terminolgy:

IMO it looks like a variation of use case #1 where the client actually tries to access
Site B and with the help of user input and lookup mechanisms are put in contact
with Site A's authentication system.  This is much more complex than hitting a fixed
partner link on your home-site but I think that we should support this anyway.

I have some doubts on details like dependency on URLs as credential carriers
as this put too much size constraints.  Cookies increase capacity but are not
always applicable.  And then I don't understand the desire for an ASN.1 X509 style
of credential.  Or did I get that wrong?

/anders

----- Original Message ----- 
From: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
To: "OASIS Security-Use List" <security-use@lists.oasis-open.org>
Sent: Friday, January 19, 2001 18:06
Subject: some sec-tc use-case input


> 
> I have been working for a while on a project within the Internet2
> initiative (http://www.internet2.edu/) that is closely related to the
> sec-TC work.  It's called Shibboleth, see
> http://www.internet2.edu/middleware/shibboleth/.  It's about providing
> inter-institutional web authentication among universities in the US
> (without assuming comprehensive PKI and end-user certs).  We're also
> working with folks from the EU who have similar projects afoot.
> 
> We're close to finishing a requirements doc; a recent version is at
> 
> http://dceweb.brown.edu/~Steven_Carmody/Projects/Shibboleth/Requirements-v2.html
> 
> (though a new rev is to appear shortly).  Section 3 of that document lists
> a number of scenarios of interest to us.  Based on my understanding of the
> S2ML scenarios (and other related stuff like AuthXML) I think our
> interests bring a couple of different concerns to the table.
> 
> A central interest from our community is privacy protection.  A key
> contributor to this is the library community, where a person's ability to
> view library content without personal records being kept (or made
> available) about what they've viewed has always been considered very
> important.  Since one of our first real deployment scenarios is providing
> access to licensed library-style content, this is an early concern for us.
> 
> So the relevant point is that an authentication system that always
> provides a well-known user identifier (eg a classic X.500-style DN) to a
> service provider doesn't meet our privacy requirements.  More subtly, the
> system should provide the capability for end-user and/or user-domain
> control over what user information gets released to a service provider
> when answering an authorization request.  I don't see any obvious reasons
> why S2ML couldn't meet these requirements, but we'd like to make sure.
> 
> The other element we have in mind that may be unusual is that an
> application site would in our scenario should be able to use
> authentication and authorization services from a large number of
> user-providing sites.  As higher ed sites we'd like to be able to tell
> faculty they can protect resources to people across higher ed without
> giving them local accounts at each institution.  Similarly publishers
> would like to offer site contracts to hundreds or thousands of
> universities and rely local a&a from those sites.  Making this work might
> imply some additional navigation capability, at least in some scenarios,
> to let application sites and their users locate a&a services.
> 
>  - RL "Bob"
> 
>