Skip to Content.
Sympa Menu

shibboleth-dev - Re: [Shib-Dev] [IdPv3] Attribute Filter Work

Subject: Shibboleth Developers

List archive

Re: [Shib-Dev] [IdPv3] Attribute Filter Work


Chronological Thread 
  • From: Adam Lantos <>
  • To:
  • Subject: Re: [Shib-Dev] [IdPv3] Attribute Filter Work
  • Date: Fri, 4 Jun 2010 12:12:54 +0300

On Thu, Jun 3, 2010 at 7:03 PM, Peter Schober
<>
wrote:
> * Scott Cantor
> <>
> [2010-06-03 17:34]:
>> This is the thing Microsoft claims to have done a lot of user research on
>> for Cardspace and concluded it's a bad idea. One reason I think is that
>> users can't get clear indications about what the implications are of
>> blocking the data.
>
> In the Jananese implementation I found it to be quite clear, with
> those attributes that would lead to a loss of access to the service
> (which are therefore marked mandatory in the SP's metadata) being as
> they are in uApprove today (i.e., cannot be opted out individually,
> only by denying the transmission as a whole). Only those that are
> truly optional (i.e., the SP can either operate without those or will
> e.g. ask the user in the application) can be handled individually.

I agree with Peter on this: from a data protection point of view, if
the user had control over the release of the so called 'optional'
attributes, IdP admins wouldn't have to decide whether they should
release them or not.
I think as of today, many IdP admins are afraid to release these
attributes, because of the data protection directives mentioned by
Peter. And after all, the SP has to prompt for these data (eg. display
name or nickname), thus leading to worse user experience.

> This also aligns well with the EU data protection directive (about
> which many could care less, but also many will have to take into
> consideration) which has some text to the effect that withheld consent
> should not lead to the complete loss of service, rather things should
> degrade gracefully, so to speak.


cheers,
Adam



Archive powered by MHonArc 2.6.16.

Top of Page