Evolving Attribute Release Policies for campuses

[Wessel, Keith]

Well, I could answer that, but then what reason would you have to join the IAM On-line next week???

What we have in terms of a consent policy is still in flux. I can tell you what Illinois is considering, though. The big draw of enabling consent is so that we can start releasing attributes for our users who have elected FERPA suppression, or more accurately allow those users to make that call. We'll still let the consent page be displayed for all users, even those who aren't FERPA suppressed. It's good to let users know what they're sharing when they log into something, putting them in control of their own identity.

For on-campus services and services that aren't in a federation (one-off federations that we have contracts with), we consider the consent to be implied. So, we don't plan to present a consent screen for those SPs.

For InCommon and eduGAIN, we are leaning toward only displaying a consent screen for services that aren't global R&S. The excellent work that went into global R&S as it relates to data stewardship and storage gives our registrar a lot of confidence in those services.

We currently release the R&S bundle, as many of you have heard me say, to everyone in InCommon and in the eduGAIN aggregate for all users who haven't elected FERPA suppression. The idea is to continue doing this with the users' consent, adding in the FERPA-suppressed users as well.

We also plan to use <md:requestedAttribute> elements when available, limiting the R&S bundle to those which an SP has stated are required or optional. When none are stated, we'll release the whole bundle as we do today. For SPs with incorrect requested attributes in metadata, if a user tries to access their service and can't, this is a great opportunity to contact the service provider and ask them to update their metadata. We'll save manually releasing attributes to that service provider to work around incorrect metadata as a last resort.

As I also mentioned on the list, we'd love to turn on per-attribute consent, but only if we can identify which attributes are optional. An SP admin who contacted me off-list (I'll let that person speak up if they want to) has concerns about this. It might not be enough to tell a user that an attribute is optional; it'd be better to tell them what the SP plans to do with that attribute so they can make an informed decision: is the intended use a feature that the user care about enough to release that piece of their information? That, obviously, involves changes to metadata to allow SPs a place to say what each attribute will be used for. Other registries such as the AAF's federation registry require the SP operator to record the reason for wanting the attribute, but there's currently no place in metadata (that I know of) to pass that text along.

Finally, we've got an interesting, ahem, discussion going right now between our security folks and our usability folks for the global consent checkbox. Our usability folks think that some users would rather trust us to release their data appropriately rather than have to consent to each service that they access. Our security folks think that a checkbox giving permission for us to release all of the user's data to any service is beyond frightening, though. We think, with the right configuration and good wording for that checkbox, we can find a balance on that.

I'd love to hear what others are considering, too, as we make our plans to enable consent, hopefully by the start of classes in the fall.

And now I'm off to figure out what I can share in next week's IAM Online that I didn't already share in this note.

Keith


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Steven Carmody
Sent: Tuesday, April 05, 2016 1:45 PM
To: users at shibboleth.net
Subject: Evolving Attribute Release Policies for campuses

Hi,

Keith Wessel has recently started a couple of interesting threads 
related to implementing various portions of a campus Attribute Release 
Policy. Recent questions had to do with "Determining optional vs. 
required attribute on the consent page?", and "How accurate are the 
<md:RequestedAttribute> elements in InCommon and eduGAIN metadata".

I'd like to ask Keith (who is obviously thinking about this space) and 
any other campus that is also thinking about deploying User Consent on 
Attribute Release to share their current thinking about what their 
"complete" policy looks like. User Consent is clearly just a part of the 
complete policy -- presumably it only gets triggered for certain SPs ? 
How do you combine Consent and R&S ? What is your default release policy 
? to IC, to eduGain ? What other special handling is included in your 
policy ?

I think I remember one of the UC campuses talking about their consent 
implementation during one of those threads. I'm sure other campuses are 
also now trying to develop a policy that covers all the options, and 
does so without confusing or overloading users.

So -- Keith (and anyone else) -- what is your current thinking about 
your "complete" Attribute Release policy?

thanks !
-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net