<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Oct 23, 2017, at 11:41 AM, Cantor, Scott <<a href="mailto:cantor.2@OSU.EDU" class="">cantor.2@OSU.EDU</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">What do you think? Does the Shib team want to define one or more entity<br class="">attribute names that could potentially be leveraged as one option to control<br class="">attribute release?<br class=""></blockquote><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I think we should ship defaults, but we would not own the names because by definition the attribute names aren't ours.</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Would you prefer the value set of such an entity attribute<br class="">to be the urn:oid form of the names, rather than the FriendlyNames? Have<br class="">you had some different model for such tagging in mind?<br class=""></blockquote><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">The filter doesn't operate on SAML names so it would be awkward to try and do that, but that's the only way we could do this that would be independent of any particular configuration.</span><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I suppose what we could do is implement a new variant that sort of mapped a particular entity attribute into the equivalent form of RequestedAttribute, which is something we do support, though not all that cleanly. I'd have to think about that.</span></div></blockquote></div><div class=""><br class=""></div>That's an idea. Thinking of the UI, I've been shying away so far from thinking about RequestedAttribute config, since that seems a bit less "controllable" (used in metadata today, not necessarily accurate, etc.). But support for that at some point makes sense, and if you think that mapping everything back to that makes the most sense even in the shorter-term, that could be considered.<div class=""><br class=""></div><div class="">As to the "names/IDs" of the attributes that a given deployment generates in their resolver, the simple initial assumption is go with the standard names in the delivered "example resolver files". But I suppose one could make it more flexible by having yet another property file, where the properties are something like "attributeId1, attributeId2, ..." and you set those properties to the IDs your resolver generates. And the embedded filter config references those properties, and the UI reads in that property file (maybe, eventually, but not in the short term, lets you manage it) and uses it to present the IDs you can "check" that you want to release. The properties file would then, though, probably need 2 properties per attribute, with the 2nd being a description of what that ID represents (for help in a UI).</div><div class=""><br class=""></div><div class="">But I'm kind of for simplifying assumptions to start with, and allow for 10 - 12 commonly used IDs, the IDs that you'd find in the distribute example resolvers, and if you want to change from those, you go in by hand and do so. At least for a first stab at this.</div><div class=""><br class=""></div><div class="">Another thing I've wondered, but so far have shied away from, is an embedded filter config that would be a "Not/deny". But there is no distributed example of a resolver ID for a "suppress" attribute. So that would have to be a property or just make up a value and say "if you want to leverage the standard config, use that ID, even if it means just sourcing it from the ID you are already creating".</div><div class=""><br class=""></div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">--<br class="">Michael A. Grady<br class="">IAM Architect, Unicon, Inc.</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>