...
For those that do choose to support these use cases, there are essentially two ways outa number of options:
- a model based on user consent
- a relaxed stance to privacy control for some
...
- subset of users
...
- service categories
No matter what path the IdP chooses, a documented policy and process must exist around the release of attributes such that SPs can engage with the IdP in as efficient a manner as possible, and in particular so that privacy-related failures can be reported to users in a useful fashionFailing that, an IdP should at least define and publish a formal process by which users of new services can make requests to initiate a dialog between IdP and SP representatives. The user should not bear the burden of understanding the technical details involved..
The <PrivacyStatementURL> element, an important IdP user interface element in metadata, is a useful place to capture, if not directly, then indirectly on a broader privacy policy page, a link to this information.
The "administrative" contact in metadata is an appropriate way to designate the point of contact for users in referring privacy issues to their IdP for resolution (and for the appropriate staff to ask questions of the SP).
For any these alternatives to work wellNote that for either model to work, SPs need to articulate their Requested Attributes to IdP partners, preferably in metadata. Thus there is overlap between the kinds of SPs for which such definition is possible and useful, and those to which the release of attributes must be streamlined.
| Tip | ||
|---|---|---|
| ||
|
...
Of course, an opt-out mechanism of some kind is an essential component of such an approach.
Document and Facilitate
No matter what path the IdP chooses, a documented policy and process must exist around the release of attributes such that SPs can engage with the IdP in as efficient a manner as possible, and in particular so that privacy-related failures can be reported to users in a useful fashion.
The <PrivacyStatementURL> in metadata is a useful place to capture, if not directly, then indirectly on a broader privacy policy page, a link to this information.
Service Categories
Another approach is to define a service category that IdPs can choose to support or not. A specific example is the Research & Scholarship Category of services, which currently is gaining traction in the international R&E community.
To operationalize a service category, entity attributes are used in IdP attribute release policy configurations in lieu of Entity IDs. The advantage of doing so can not be overstatedThe "administrative" contact in metadata is an appropriate way to designate the point of contact for users in referring privacy issues to their IdP for resolution (and for the appropriate staff to ask questions of the SP).