Page Comparison

Scalable Attribute Release w/ User Consent

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

• This clearly isn't scaleable to a large number of SPs. 
• There is no user involvement. There is a growing amount of interest in giving the user direct control over the release of attribute information that describes them.

These changes, taken together, are an attempt to address these issues. The proposed solution includes:

...

• SPs cannot always be grouped 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 cannot opt-out of this release.

The proposed solution is:

1. Use the SWITCH ArpViewer to allows users to participate in the release process. This extension to Shibboleth 1.3 and 2.0 has several functions, and can be configured to operate in several different modes. In its most basic mode, however, the first time a user visits a new SP the IdP will present the user with a web form listing the attributes that are being released and asking the user to "approve" the release. If the user clicks YES, the ArpViewer remembers the choice and redirects the user to the SP. If the user clicks NO, the process stops. Note that the user cannot individually control attributes and values for release; they can only approve or reject the entire transaction.The proposed new AFP matching function.
2. Create a new AFP policy rule, described below, that uses a service provider's metadata to influence what is released.

We think this will make use of the SWITCH ArpViewer highly

...

scalable. A site will

...

decide which of the attributes listed in an SPs metadata can be released without further rules. The ArpViewer can 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.

 Here is some additional detail describing how this would work:

...

New AFP Rule

For the sake of this discussion lets we will call this new function AttributeInMetadata. This function would take the attribute on which it is defined and When this function is specified on a PermitValueRule element, it would check to see if he the enclosing attribute was listed in the requesting SPs 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).

Given the above, currently fictitious, proposed matching function a site would do the following to use it.1.

1. Ensure that Service Providers list, in their metadata

...

1. , 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 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 those in a certain group, specific SPs, etc.
3. Install and configure the SWITCH ArpViewer.

...

1. 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.

Here is an example config configuration snippet that release ePPA to any SP in InCommon that lists that as a required attribute:

<AttributeFilterPolicy id="releaseRequiredToInCommon">

...

    <PolicyRequirementRule xsi:type="saml:

...

AttributeRequesterInEntityGroup"

...

 groupID="urn:mace:incommon" />

...

    <AttributeRule attributeID="eduPersonPrimaryAffiliation">

...

        <PermitValueRule xsi:type="saml:AttributeInMetadata" />

...

    </AttributeRule>

...

</AttributeFilterPolicy>