Shibboleth Developers

["Bruc Liong" <>]

> We're talking about encouraging SPs to  publish (in their metadata) the
> set of attributes they want, and letting IdPs identify the set of
> attributes that "require user consent". A typical flow would have the
> IdP looking up the set of attributes that the requesting SP desires,
> filtering that thru the current ARP mechanism, and then, if one of the
> "consent" attributes is ticketed for release, triggering something akin
> to the current SWITCH ARPViewer. The user could say YES/NO to the whole
> lot, but not individual attributes.
> 
> I understand that this isn't ideal. Far from it. But, we're trying to
> make it easy for  both SPs and IdPs, while giving users some control and
> flexibility. And keeping it simple enuf that people could understand it.
> 
> I'd love to hear folks' thoughts......

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.

Bruc

Attachment: smime.p7s
Description: S/MIME cryptographic signature