ConsentRelease

Current Thinking

1. Meaning of consent --  user provides a YES/NO to a complete specific set of attributes (however that list is developed). This may include a check box for "Don't ask me again for this site". Does not allow user to create a new policy.
2. Deferred functionality -- user provides a YES/NO to each attribute that potentially can be released. We think that, currently, most SPs requirements are quite simple. Worrying about supporting service levels and optional attributes seems too ambitious at this point, and somewhat disconnected from the current SP reality. Several reasons were listed: at this point users would not understand this functionality; this would be lots of effort to implement;  implementation becomes a negotiation with the IdP; users think they already manage this info at the campus directory.
3. There is a significant scaling problem for sites  to configure "consent required" for some SPs. Manual configuration isn't a long term solution. Sites are likely to have a range of opinions about when consent is required, so having the Federation tag SPs likely won't work. There are some SPs that could/should be done manually (eg the "find an employer" apps used by Career Development depts and seniors). Its the collaboration sites that are expected to appear in large numbers.
4. At this point, so few information providers support epTID that we aren't worried about supporting the "do you -- the individual -- want to release epTID to this SP" use case.
5. An approach...
   1. SPs must publish which attributes they want (via the federaation metadata). Will require a change in how Federations maintain their metadata (and perhaps the UIs they provide for metadata maintenance).
   2. Each IdP can identify a set of attributes whose release requires user consent.
   3. When an SP wants an attribute(s):
      1. Normal ARP processing is triggered
      2. If one of the attributes being released is in the "consent required" set, then user consent is triggered.
      3. User is presented with a browser screen listing the attributes that are going to be released (may need some explanaation to the user)
      4. User can make a YES/NO decision about releasing all of the attributes.
6. For this to be adopted, there MUST be motivation for SPs to adopt this model. Pressure from IdPs seems like a possible/likely incentive.

Notes, Issues and Constraints

1. Within the UK, the epTID attribute value is NOT considered to be "personal information". Some felt that is was an aggressive position, advantageous to the campuses.
2. Within the US, we expect different institutions will adopt a variety of policies on this issue. It might be useful to test this idea with the Dept of Edu.
3. EPPN's reassignability makes it somewhat problematic as a permanent identifier. However, its value seems to be a function of the application. epTID works fine with RefWorks; EPPN works better with a wiki (even with reassignability). What do we preach to developers? EPPN is "collaboration friendly" --friendly to the user, friendly to others.
4. At some institutions, people don't know how to obtain their value for this attribute.

Related Projects

1. (from MAMS) We are pushing it further that the whole federation will support the above
   idea, where SPs are required to set their requirement attributes and IdP
   (through tools such as ShARPE or Autograph) will aid user in filtering them.
   Further to that, each service may have different offerings (that's just our
   term) where the requirement for attributes could very well be different
   sets.

Acceptance of service offering is heavily dependent on whether the involved
attributes are privacy-concerned (the tools have references to these;
federation may mandate some).

The current AAF Operational Document which is open for public comments
(hence your comments are more than welcome) outlines this, avail at
http://federation.org.au/requirements.doc.