no peer endpoint available to which to send SAML response

[Michael A Grady]

> No, I think it's more along InCommon lines, just a federation somewhat
> orthogonal to actual services.
> 
> -- Scott
> 


I've never been directly involved with UCTrust, but I have interacted with it in working with a UC campus that was joining UCTrust, and I've worked with (on other things) a person who helped establish it. And, from my perspective, Scott is right about at least the original intent of UCTrust:

- to add some UC-specific policy & process as an addition/overlay over InCommon
 - there was no intent to supply UCTrust-specific metadata, but to rely on everyone being a member of InCommon, with InCommon being the source of metadata
 - to define a standard set of UC-specific attributes, in addition to eduPerson attributes, that would enable sharing of various services between and across the UC campuses
- to define a "basic level of assurance" (and an attribute to carry that) that pre-dated InCommon and its Assurance effort
- to help arrange, promote and encourage services of interest to multiple UC campuses to use Shibboleth/SAML/UCTrust attributes for access

The setting up of UCTrust predated any sort of "entity categories" (like Research & Scholarship), and any mechanism in the InCommon metadata for identifying services as such, so there was no notion (at least in the past) of getting UC IdPs to have a "already configured release of a standard set of attributes to a particular group of UCTrust-vetted services." Just the definition of what those attributes should be. And I don't know if it was ever considered that contacting UCTrust could be a communication conduit to each and every UC campus IdM operation running a Shib IdP. Those certainly sound like they could be useful scope additions to UCTrust, depending on the resources provided to coordinate that effort.

--
Michael A. Grady
Senior IAM Consultant, Unicon, Inc.