<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>Typical for us is a 1 year contract for access to all services for a given institution.</span></div><div><br></div> <div style="font-family: arial, helvetica, sans-serif; font-size: 12pt;"> <div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1"> <font size="2" face="Arial"> <b><span style="font-weight:bold;">From:</span></b> "Cantor, Scott" <cantor.2@osu.edu><br> <b><span style="font-weight: bold;">To:</span></b> Shib Users <users@shibboleth.net> <br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, May 14, 2013 10:10 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> RE: School me on hub and spoke federations<br> </font> </div> <div class="y_msg_container"><br>> It is indeed different. We are now re-coding the app to
support this while<br>> remaining backwards compatible with all the existing customers. It would be<br>> VERY cool if there was a single standard attribute for this kind of thing /sigh<br><br>Could you explain why it's not about billing to the contracted instance of a service? I don't think I've seen a case yet that wasn't really about that at the root. Organizations sometimes contract for multiple instances of a service, which is where tying contracts to any kind of organizational ID ends up breaking.<br><br>(For example, university departments here often buy the same service individually, but they all use our single IdP, so it's one entityID.)<br><br>-- Scott<br><br><br>--<br>To unsubscribe from this list send an email to <a ymailto="mailto:users-unsubscribe@shibboleth.net" href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br><br><br></div> </div> </div> </div></body></html>