Date: Fri, 29 Mar 2024 04:52:21 +0000 (UTC) Message-ID: <1801679139.1.1711687941987@wiki-prod.refeds.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_0_1011273057.1711687941934" ------=_Part_0_1011273057.1711687941934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The Data protection directive and interpretations create a set of requir= ements for the INFORM and CONSENT interactions with the user. This Da= ta protection Code of Conduct proposes a division of responsibility where t= he INFORM and CONSENT interaction is carried out by the Home Organisation o= f the user, for instance, in an INFORM/CONSENT Graphical User Interface (GU= I) installed to the Identity Provider server.
However, the Data protection regulators and the groups developing and&nb= sp; enforcing these regulations recognize that there is a balan= ce between full disclosure to meet the requirements= and usability. A poor design of the user interacti= on screens can actually reduce the likelihood that users will underst= and what is happening.
For the requirements on informing the end user, see Introduction to Data protec= tion directive, section 8.
For the requirements on user consent, see Introduction to Data protection direc= tive, section 9.
Note: Introduc= tion to Code of Conduct proposes to defer release of optional extra Att= ributes based on user consent until Phase 2.
Inform dialogues should be short and concise. If not, users will not rea= d them.
The UK information commissioner proposes a "layered approach"; the basic= information is on the main page, and there is a hyperlink for detail. = ; Merely having a clickable link labelled "privacy policy here" proba= bly wouldn't be enough.
"A layered notice usually consists of a short notice plus a longer n= otice. The short notice contains basic information, such as the identity of= the organisation and the way in which the personal information will be use= d... The short notice contains a link to a second, longer notice which prov= ides much more detailed information."
(the UK information commissioner's Privacy Notices Code of Pra= ctice, "physical" page 18, PDF page 17)
The goal here is to provide a human readable form as the primary interfa= ce 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 basi= c information should be provided as short accurate "user-friendly" descript= ions; detailed information about "exactly what's going on" can be provided = as a link.
Consequently, this profile recommends displaying the Service Pro= vider's name, description, logo and requested attributes on the main = page. If a user wants to learn more, he/she can click a link resol= ving to the Service Provider's Privacy policy.
It is not expected that "normal" users will actually do the latter= , but at least they have the ability to inform themselves of what&nbs= p; is going on. The Norwegian Feide federation uses this approa= ch; normal people do not follow the links, but there are = several persons who over the years where this has been op= erational have given favorable feedback on this approach. Including the Dat= a Protection Agency.
Layered notices can be particularly useful when describing the attribute= values which will be released. In general, LDAP-style attributes are trans= ferred to the SP. However, very few users have any familiarity with the con= ventions and usage of LDAP attributes. Instead, the Identity Provider could= ask the user to release "name"; the link would take the user to a pa= ge listing all of the LDAP name attributes and values.
There are other attributes where the values are intentionally opaque (e.= g. ePE=3D"urn:mace:rediris.es:entitlement:wiki:tfemc2"). It is NOT reasonab= le to expect the end user to understand what this value means and to pick u= p 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 i= nformation is "your email, name and affiliation will be transfered, as = ; we do for international projects like Zyzzy, VO2 and Tjollabong".&n= bsp; 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.