The default privacy stance of most softwaredeployments, 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 has been argued by some) that these are not appropriate uses of organizational IdPs, and that 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.
...
Note that for either model to work, SPs need to define articulate their Requested Attributes, 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 | ||
|---|---|---|
| ||
|
...
Opt-In
The goal is to facilitate the release of basic identify identity information without the involvement of a manual workflow at the IdP. The most restrictive mechanism for this is to require users to opt-in to the release of data, usually at the time the service is used.
This is supported in software through built-in or add-on modules for "consent management." . Such modules are necessarily a significant part of the effort involved in deploying an IdP, but the flexibility is extensive in terms of recognizing changes to specific attributes and values, tracking consent across client devices, etc.
...
A major advantage to a consent-based model is that universal coverage (even for FERPA-suppressed students) is potentially feasiblepossible.
Opt-Out
If consent is deemed too onerous or undesirable, an alternative is to identify classes of users for whom default release of basic information is acceptable to SPs that meet a commonly-accepted set of criteria (such criteria definitely a work in progress at this stage of discussion).
...
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> 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 typein 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).