Potential Agenda Item for UCTrust meeting

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