[OpenID] OpenID SREG best practice question

[Nate Klingenstein]

Ben,

> Clearly as (if?) more attributes get added into the mix more thought
> will have to go into this aspect.

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":

http://www.switch.ch/de/aai/participants/allresources.html?show=all

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).

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.

1)  It created a surge in help desk calls as well-meaning users  
locked themselves out of apps.
2)  Most users didn't care at all, and the ones who did care, didn't  
care on such fine granularity.

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.

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.

Take care,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081113/d0e21764/attachment-0002.htm>