OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [security-services] SAML deployments that use consent step?

> As far as:
> we believe that consent is only infrequently a practical or efficient
> instrument for protecting user privacy. Indeed, it is often too easy  
> for
> IdPs to misuse consent to the detriment of their users' privacy.
> I have heard these arguments but don't understand them, nor,  
> apparently, do other European HE federations agree.  Assuming that  
> IdPs are inherently hostile to user privacy seems an odd starting  
> point.

I don't believe that IdPs are inherently hostile to user privacy.  
Unfortunately, the natural meaning of 'consent' is subtly different  
from the technical legal (EU) sense, and this sometimes leads to well- 
meaning implementations that are inadvertently unlawful (hence  
'misuse' rather than 'abuse'). In particular, users are often led to  
believe that if they don't give consent, they won't get service (in  
effect, a user is inadvertently "intimidated" into giving consent). In  
addition, there is a sometimes a perception that consent is a  
sufficient condition for release of PII. Neither of these are lawful.

Excepting some differences in practice concerning the mapping of the  
data "controller"/"processor" relationship to the SAML IdP/RP model,  
I'm not aware of any controversy about this. "Consent should only be  
used, if at all, for services that are not necessary, or to provide  
optional information to services that are necessary." - http://www.terena.org/activities/refeds/docs/FederatedAccessManagementv0.10.pdf

There's some on-going work in the European HE federations community  
looking at expressing RPs' attribute requirements in SAML metadata, in  
concert with assertions from TTPs attesting to the 'necessity' of  
these attributes, that a user could subsequently consent to. However,  
it's not clear yet if this could be made to work practically.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]