<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Ben,<div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"><p style="margin: 0.0px 0.0px 0.0px 0.0px"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">Clearly as (if?) more attributes get added into the mix more thought</span></p> <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">will have to go into this aspect.</font></p> </blockquote></div><br></div><div>We share and utilize a very large number of attributes, and many applications do need much more information than email address. Some need less. In our deployments, each service has the ability to express which attributes it needs. See, for example, this page, and click on "Show requested attributes":</div><div><br></div><div><a href="http://www.switch.ch/de/aai/participants/allresources.html?show=all">http://www.switch.ch/de/aai/participants/allresources.html?show=all</a></div><div><br></div><div>Then, the IdP administrator can choose to alter these defaults for their local userbase. This has worked out great for these apps, but it's not a general solution (and doesn't help in your situation regardless).</div><div><br></div><div>User-managed release of attributes was a key design tenet for us that has seen very little uptake in the real world. We've tried interfaces that allowed users to individually select which attributes, building from a default set, they would like to block or enable the release of.</div><div><br></div><div>1) It created a surge in help desk calls as well-meaning users locked themselves out of apps.</div><div>2) Most users didn't care at all, and the ones who did care, didn't care on such fine granularity.</div><div><br></div><div>We're now toying with interfaces that are opt-in/opt-out, and ones that can give "levels of service" based on how much information you're willing to reveal, e.g. persistent pseudonym = personalized content. It gives the user the ability to do consent-based release for many services, and for services that are absolutely necessary to providing an education for the student, they won't be prompted. We'll see if these are more successful.</div><div><br></div><div>Something certainly has to be done, though. We don't want the IdP administrator to be a gatekeeper for all services. It works very well for the major apps with our large user bases, but it's not scaling down to the small collaborations. I suspect this is why Eric is so keen to have some formal research into the problem.</div><div><br></div><div>Take care,</div><div>Nate.</div></div></body></html>