OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC