Shibboleth Developers

[Tom Scavo <>]

On Tue, Apr 12, 2011 at 7:22 PM, Bradley Beddoes
<>
 wrote:
>
> Just to add to this thread following on from yesterdays community call.

Very enlightening demo, thanks.

> Here at the AAF we're asking our service providers to provide us through 
> Federation Registry specific, end user consumable reasons for why they are 
> requesting a particular attribute be transferred to their service.
> We'd then like to present this as part of release consent UI so our users 
> not only see a list of attributes but are afforded the opportunity to 
> better understand what this personally identifiable information(PII) will 
> be used for on the SP end.

Alternatively, the InCommon Federation will achieve the same effect as
follows (or at least this is what I will propose to our Technical
Advisory Committee next week). Each SP will be asked to provide a URL
to a Privacy Policy document targeted at end users. This link will be
prominently displayed on the consent UI. (This will be demoed by USC
and Brown next week at the Internet2 Member Meeting.)

Advantages of this approach are:

- The <mdui:UIInfo> element already has an <mdui:PrivacyStatementURL>
child element, so no new specification or schema are required.

- The granularity seems to be Just Right since SPs can reuse Privacy
Policy documents for those applications that have similar attribute
requirements or create distinct Privacy Policy documents for
significantly different services.

- The content of a Privacy Policy document is potentially more
coherent and understandable than a sequence of text fragments entered
into text fields.

- As a matter of UI design, it's better to keep the consent UI
uncluttered and instead refer the interested reader to external
documents if necessary.

Tom