<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jun 28, 2018 at 3:30 PM IAM David Bantz <<a href="mailto:dabantz@alaska.edu">dabantz@alaska.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Marvin or others, could you elaborate on why this is a superior approach?</div></div></blockquote><div><br></div><div>Scott said it's a matter of style, and I suppose that's true to some extent, but the real driver for us is policy. I would characterize Virginia Tech as very conservative with data handling and as such we have a lot of policy around attribute release. Consent is one policy aspect, but approvals and documentation are equally if not more important. Since I'm not a bookkeeper I need as few policy enforcement points as possible, and minimizing the number of attributes and defining named bundles have been two strategies we've adopted to keep things simple. Our clients request a couple bundles, and we release them with signals in the metadata (entity attributes). That keeps my hands out of the configuration as much as possible. Yay!</div><div><br></div><div>I have learned to be very strict about attribute bundles, which precludes adding or subtracting from them in order to meet the unique requirements of poorly implemented SAML in some SPs. Our workaround is to add encoders to existing attribute definitions and enable/disable via activation conditions. That keeps our policy points invariant under the wonky demands of the integrations we get with what seems like increasing regularity.</div><div><br></div><div>Best,</div><div>Marvin</div><div><br></div></div></div>