<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">I'd be happy to go over what we've done, we don't have much in the way of statistics yet though<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><font face="courier new, monospace">Jeffrey</font><br><br><div><font face="courier new, monospace">Both pilots and IT professionals require training and currency before charging into clouds!<br></font></div><div><font face="courier new, monospace">---------------------------------------</font></div></div></div></div>
<br><div class="gmail_quote">On Thu, Jan 14, 2016 at 12:45 PM, Eric Goodman <span dir="ltr"><<a href="mailto:Eric.Goodman@ucop.edu" target="_blank">Eric.Goodman@ucop.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Jeffrey at UCSC configured his IdP to have something like three levels of data release:<br>
<br>
* Bi-lateral agreement SPs with (essentially) custom data attribute filter settings that don't require consent (normal "must be specifically approved" processes)<br>
* InCommon SPs with <RequestedAttribute> elements in metadata will require consent and will only release the specified attributes<br>
* Other InCommon SPs require consent and will release a (UCSC-selected) default set of attributes<br>
<br>
There may be other variances in his setup; e.g., I'm not sure if R&S is handled under the above use cases (I'm pretty sure they require consent for "random" R&S sites) or as a special case and it's possible they may have "bi-lateral agreement SPs" that still require consent, but they've been in production for a while with the model.<br>
<br>
I was thinking just last week (volunteering someone else to do work here) that this might be an interesting topic (both generally and covering UCSC's specific approach) to discuss in an InCommon webinar. Something like "real-life consent models and campus experiences".<br>
<span class="HOEnZb"><font color="#888888"><br>
--- Eric<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: users [mailto:<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a>] On Behalf Of Cantor, Scott<br>
Sent: Thursday, January 14, 2016 6:29 AM<br>
To: Shib Users<br>
Subject: RE: user consent, which SPs should trigger these screens ?<br>
<br>
> Looking at how to implement this, it seems the deployer would want to<br>
> AND their activationCondition predicate with the default/system<br>
> predicate. But in this case I don’t see an easy way to do that without<br>
> copying the default/system activationCondition, since it is wired as an inner bean.<br>
> Perhaps an improvement would be to remove the inner-ness of the<br>
> default/system activationCondition, so that it could be referred to in<br>
> an AND, and would ’survive' updates.<br>
<br>
Yes, probably true.<br>
<br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a></div></div></blockquote></div><br></div></div>