The Data protection directive and interpretations create a set of requirements for the INFORM and CONSENT interactions with the user. This Data protection Code of Conduct proposes a division of responsibility where the INFORM and CONSENT interaction is carried out by the Home Organisation of the user, for instance, in an INFORM/CONSENT Graphical User Interface (GUI) installed to the Identity Provider server.
However, the Data protection regulators and the groups developing and enforcing these regulations recognize that there is a balance between full disclosure to meet the requirements and usability. A poor design of the user interaction screens can actually reduce the likelihood that users will understand what is happening.
For the requirements on informing the end user, see Introduction to Data protection directive, section 8.
For the requirements on user consent, see Introduction to Data protection directive, section 9.
Note: Introduction to Code of Conduct proposes to defer release of optional extra Attributes based on user consent until Phase 2.
Inform dialogues should be short and concise. If not, users will not read them.
"A layered notice usually consists of a short notice plus a longer notice. The short notice contains basic information, such as the identity of the organisation and the way in which the personal information will be used... The short notice contains a link to a second, longer notice which provides much more detailed information." (the UK information commissioner's Privacy Notices Code of Practice, page 18)
The goal here is to provide a human readable form as the primary interface with the ability to click further to see what the 'technical' data is. The AUPs presented by most Internet services do not suffice as they are rarely read nor understood by the users. The basic information should be provided as short accurate "user-friendly" descriptions; detailed information about "exactly what's going on" can be provided as a link.
It is not expected that "normal" users will actually do the latter, but at least they have the ability to inform themselves of what is going on. The Norwegian Feide federation uses this approach; normal people do not follow the links, but there are several persons who over the years where this has been operational have given favorable feedback on this approach. Including the Data Protection Agency.
Layered notices can be particularly useful when describing the attribute values which will be released. In general, LDAP-style attributes are transferred to the SP. However, very few users have any familiarity with the conventions and usage of LDAP attributes. Instead, the Identity Provider could ask the user to release "name"; the link would take the user to a page listing all of the LDAP name attributes and values.
There are other attributes where the values are intentionally opaque (e.g. ePE="urn:mace:rediris.es:entitlement:wiki:tfemc2"). It is NOT reasonable to expect the end user to understand what this value means and to pick up a particular value to be released. Instead, natural language descriptions of the vallues should be provided.
A good way to explain to a user why there is a transfer of information is "your email, name and affiliation will be transfered, as we do for international projects like Zyzzy, VO2 and Tjollabong". Explaining by analogy is human, albeit not necessarily academic in all disciplines.
See SAML 2 Profile for the Data Protection Code of Conduct for details on the related SAML2 metadata elements.
For all attributes (INFORM interaction)
Additionally, for release of optional extra attributes (CONSENT interaction)
The lang attribute of the mdui elements can be used to match the user's preferred language settings.