Shibboleth Developers

1) a JISC-funded project underway at LSE:

https://gabriel.lse.ac.uk/twiki/bin/view/Projects/Flame/WebHome

https://gabriel.lse.ac.uk/twiki/bin/view/Projects/Flame/PublicOutline

> 1. Project FLAME (Federated Local Access Management Environment) 
> will build a production-scale institutional installation of the 
> online shared services and user interfaces at LSE to enable, and 
> then investigate the use of three important functions peripheral to 
> (but arguably essential to) the adoption of Federated Access 
> Management (FAM) by an institution for cross-domain access to online 
> resources. These are:
>
>     * Delegated Authority Management (DAM): the ability for users 
> with appropriate authority to define, via a central shared service, 
> the authorisations of other users to access diverse sources of 
> information, online services, and physical spaces - including the 
> power to delegate such powers in controlled ways to other users;
>     * Attribute Release Policy (ARP): the ability of the institution 
> and each end user to effectively control what personal information 
> about themselves is released to internal and external service 
> providers; and
>     * Virtual Organisation Management (VOM): the ability for LSE 
> users to easily provide 'guest' access to colleagues based at other 
> institutions (ideally but not necessarily institutions participating 
> in the UK Access Management Federation).

2) A growing set of SPs (here in the US, anyway) that will be used by 
students, and where it would be useful to release attribute info to 
the service provider. Brown doesn't even have Shib in QA yet (this 
week, fer sure...), and we've already lined up an outsourced app used 
by Career Development for seniors seeking jobs (Interfase) and an 
outsourced ticketing service for athletics events (discounts for 
community members) that aren't really academically related.

3) In the EU, I'm told, the user's IdP gets to decide on the 
(educational) "necessity" of releasing attribute info in each 
circumstance; if release is necessary, consent is not required. Here 
in the US, we have to deal with FERPA.

4) An emerging consensus best stated by Bob:

> If we restrict the use of university-IdP federation (for students) 
> to only those services strictly needed for instruction I think we'll 
> be missing lots of opportunities.
>
> In the US I don't think the situation regarding FERPA and ePTID and 
> ePSA is clear, though in one case the UW registrar agreed to these 
> being provided to a third-party, in a non-legitimate-use scenario, 
> without requiring consent (where providing email address, which the 
> vendor wanted, would have required consent).  But in any case it's 
> the same story: restricting the identifiers available to only ePTID 
> will make many collaboration scenarios difficult enough that RPs 
> will give up on federation and fall back to plain old accounts. 
> That is, abandoning the capability of federated signon to provide 
> useful data like name and email address eliminates much of the value 
> of the scheme, for some apps at least.
>
> We do have a ways to go to make consent generally available, but I 
> don't think we have any choice but to get there, for students and 
> everyone else.

5) Because of the emerging consensus around the idea that the user 
will have to grant "consent" to the release of attributes beyond 
epTID, there's interest in discussing the requirements, and what such 
a tool might do and look like.

6) There seems to be consensus that this "consent" would only be 
needed with some sites (eg non-academic).

7) No consensus yet on the role of site policy with respect to consent.

8) Steve thinks this use case will have to be addressed:

User uses Shib to access Elseveir. The default site policy releases 
only "this user is authorized to access this resource". However, the 
user also wants to release the optional attribute epTID; the user 
decides to not release their email address at this time. (If they 
did, then elsevier would send them a monthly news letter.)

9) There also seems to be consensus that, initially, the GUI 
supporting this functionality does NOT have to be completely generic 
with respect to attributes.

9) Steve again -- this all somehow seems related to CardSpace...