Page Comparison

...

In all Shibboleth releases up through the current one (2.1), attribute release is solely managed by a site administrator who maintains the Attribute Filtering Policies (AFPs). These policies are generally written so that they apply to a given SP or group of SPs. There are some problems with this approach:

• SPs can not cannot always be grouped but in order to simplify AFP rule management; however, writing a unique policy for each SP is not administratively scalable
• Administrators must be aware of new SPs that come online and make sure that existing policies release only the appropriate data.
• User's are not involved in the process that releases their information. They can not cannot opt-out of this release.

The proposed solution is:

...

We think this will make use of the SWITCH ArpViewer highly scalable. A site will decide which of the attributes , list listed in an SPs metadata , can be released without further rules. The ArpViewer can the then be used to gain user consent for this release. Note that this approach requires a change in how Federations maintain their metadata -- they would have to populate the  AttributeConsumingService element of the SPs in their metadata.

New AFP

...

Rule

For the sake of this discussion we will call this new function AttributeInMetadata. When this function is specified on a PermitValueRule element, it would check to see if the enclosing attribute was listed in the requesting SP's AttributeConsumingService metadata element. If there is a match, then the Rule returns TRUE. This type of match function could also have options specifying whether to release optional attributes and whether to filter on values too (since this is allowed in the metadata, but would be expensive to implement).

...

1. Ensure that Service Providers list, in their metadata, those attributes that are required and optional for proper operation.
2. Create an AFP covering those attributes. Each attribute would list a single PermitValueRule of type AttributeInMetadata. Note, this does not effect affect how the PolicyRequirementRule is specified so this rule could be applied to a requester using the same logic as any other policy. So the rule could be applied to all SPs, only this those in a certain group, specific SPs, etc.
3. Install and configure the SWITCH ArpViewer. Strictly speaking, this is not required. However, taking the above steps without using the ArpViewer creates a situation that is extremely dangerous to the effective management of personal privacy.

...