Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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.

...

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.