Potential Agenda Item for UCTrust meeting

Hi David,

Sorry for all the last minute-ness... been somewhat swamped with our
first "SIR" cycle since our new IDM system went live.

Something we've been looking at (and I've raised at UC Trust meetings
before) is what criteria we will use locally at UCSC to determine
when it is (or is not) okay to include new applications in our
Authentication service. As we've discussed in the past, there's two
aspects to this:

(1) What level of security is UC Trust intending to offer? E.g., is
the UC Trust authentication service intended to be sufficient for
access to systems with HIPAA data? Are there applications to which we
would say "we're not good enough for your authentication needs"?

(2) What (if any) additional risk of breach is encumbered by each
participating application by the addition of a new application into
the SSO mix? E.g., adding an application whose users are known to
share passwords would probably undermine the security of other UC
Trust applications that strongly expect their users to maintain
confidentiality of their passwords.

So with all that as background, do we have guiding principles that
tell us what "sorts" of applications should be considered appropriate
for UC Trust inclusion and what shouldn't? E.g., a coworker told me
this AM that TAS is interested in exploring using UC Trust to
authenticate students. Is that an appropriate use of UC Trust? How
would we/they make that determination?

I'm not so much interested just because of UC Trust, it's more that
this (how to determine what "can and can't play") is still an issue
that is slowing UCSC in deciding how to move forward with UC Trust,
Shib and other SSO ventures here at UCSC. So I'm looking for
frameworks I can steal.

--- Eric