InC-Lib-Vendor

["Kent Percival" <>]

David Kennedy wrote:
> It doesn't make sense to me to have our identity provider release multiple
> entitlement values for the same set of users for the same service
> provider.  And I am fairly certain that our identity provider wouldn't
> agree to do this.  ...

Obviously it makes sense to work on business relationship details to avoid
technical complexity.  However, from an implementation perspective, one should
expect that those business relationships aren't always going to resolve to the
simplest implementation.  There are lots of reasons why multiple entitlement
values may apply to the same set of users, including the potential that two
highly overlapping community groups are actually being targeted.  There are 
also
more technical reasons for this situation, including transition to newer
entitlement values because of technical improvements or overlapping contracts.

In general, I would not want the IdP owner to make these decisions solely on
service policy.  IdP's need to be more flexible but also engaged in 
discussions
influencing implementation details of the business contracts.   The reality is
that often a compromise is necessary!

However, this team's current effort is also on finding Best Practices that 
avoid
a plethora of entitlement values unique to user subsets and specific vendor
services.  My hope is that business arrangements (contracts) could be better
tailored to identify more generic campus community groups (students, 
undergrads,
alumni, ...) so that vendors could better utilize our existing attributes in
their access control policies.  Transferring access control filtering to the
IdP, resulting in a complex entitlement value problem,  is not in the best
interests of the federated model.  

....Kent
 _

Attachment: smime.p7s
Description: S/MIME cryptographic signature