Grouper Developers Forum

[Peter Schober <>]

* 

 
<>
 [2009-09-04 20:04]:
> I think Brendan's list is a very good start.....

Brendan certainly mentioned one of the main problems, which is
presenting users with "stuff" they have no idea about (so we can wash
our hands from data protection laws, I might add: If they consent,
we're out of the equasion, if thy don't they can't access the service.)

And requesting freely given, informed consent (which at least is what
95/46/EC demands in EU contries) for administrative data (say,
eduPersonTargetedId values -- try explaining that to your mother) is
certainly a huge challange for most attributes.

> What do others think ?
>
> ... and could uApprove be at all relevant to Chris' original questions ?

One of the limitsations of uApprove was (still is?) that you need to
approve the release of complete SAML assertions (i.e. you can't
consent to the release of one attribute [value], but deny release of
another). This all(attributes)-or-nothing(no service) approach will
certainly limit its usefulness in actually protecting users data:
since they still want access to the service, they will consent to the
release of all data.

But I'm missing another thing: within an organisation we can certainly
move data (like group membership info) around without collecting
consent (as we're doing when provisioning or using "back channel"
protocols). And crossing organisational borders, how useful will our
(internal) values be -- so obiously this is not about federated group
management either.
But if this is purly about intra-institutional use of getting grouper
groups into SAML assertions (for intra-campus use) where does the need
for consent come from? Is anyone really suggesting to let users do the
work of ACLs, i.e. filtering the data, so that only application X can
get the values, application X is entitled to get?
-peter