This document contains DRAFT material intended for discussion and comment by the InCommon participant community. Comments and questions should be sent to the InCommon participants mailing list.
The default privacy stance of most software, and indeed most organizational (as opposed to consumer) IdPs, is one of minimal, if any, information released to SPs for which special arrangements have not been made. This creates a serious barrier to adoption for SPs that need only basic/common identity attributes, but are not designed around heavy-weight contractual vehicles.
It can be argued (and may be by some) that these are not appropriate uses of organizational IdPs, and contracts are necessary to ensure appropriate data use and regulatory compliance. Such IdPs will simply not be usable for the vast majority of "long tail" services expected to emerge.
For those that do choose to support these use cases, there are essentially two ways out:
- a model based on user consent
- a relaxed stance to privacy control for some set of users and services
Failing 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.
Best Practice
- IdPs make common identity attributes (identifiers, displayName, mail) available to educationally-useful/non-commercial SPs for significant user populations, either subject to opt-in user consent, or with an opt-out process.
- IdPs document and publish their policies and procedures for the release of attributes. The
<PrivacyPolicyURL>in IdPUIElements should link directly or indirectly to this information. - An "administrative" contact is documented for each IdP and SP identifying a point of contact for attribute release issues.