Date: Thu, 28 Mar 2024 18:05:40 +0000 (UTC)
Message-ID: <1098979171.1912.1711649140707@wiki-prod.refeds.org>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_1911_992459788.1711649140705"
------=_Part_1911_992459788.1711649140705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
1. Background
Service Providers in the identity federations for higher education and r=
esearch are reporting problems in receiving necessary user attributes from =
his/her Home Organisations (see for instance: Federated Identity Management for Resear=
ch Collaborations). Data protection concerns are believed to be a major=
reason for Home Organisations' hesitation to release attributes.
This Data protection Code of Conduct describes an approach to meet the r=
equirements of the EU data protection directive. This Code of Conduct is a =
joint effort by the GN3 project (SA3 task 3 "eduGAIN") and REFEDS.
2. Contents
The Data protection Code o=
f Conduct consists of these normative documents:
- Cod=
e of Conduct for Service Providers. The principles to which a Service P=
rovider commits when it asserts that its processing of personal data is com=
pliant with this Data Protection Code of Conduct.
- Entity category attribute definition: Data protection Code=
of Conduct. This document defines a SAML 2.0 metadata Entity Category =
attribute which is then used in the Data Protection Code of Conduct.
- SAML 2 Profile for the Code of Conduct. This document describ=
es a profile of SAML 2.0 metadata to support the Code of Conduct.
In addition, there are several accompanying informative, non-normative d=
ocuments:
- Int=
roduction to Data protection directive An general introduction to EU Da=
ta protection directive's relevant sections.
- Managing Data Protection Risks Using the Code of Conduct. T=
his document identifies data protection risks and proposes approaches to ma=
nage them.
- Privacy policy guidelines for Service Providers. This document assis=
ts the Service Providers to develop a Privacy Policy document expected in t=
his Code of Conduct.
- What attributes are relevant for a Service Provider. This docume=
nt assists the Service Providers to assess what attributes they can request=
from the Home Organisations.
- Data protection good practice for Home Organisations. This docu=
ment assists the Home Organisations to reduce their attribute release risks=
.
- Operator guidelines. =
This document describes the federation and interfederation operator's role =
in the Code of Conduct.
- Handling non-complian=
ce. This document suggests actions in the case of having doubts that a =
Service Provider is ignoring the Code of Conduct to which it has committed.=
- Notes on Implementa=
tion of INFORM/CONSENT GUI Interfaces. This document supplements the Co=
de of Conduct by suggesting features for the Identity Providers' attribute =
release/consent modules.
3. How Does the Code of Conduct Achieve i=
ts Goals?
The Code of Conduct describes an approach whereby both Home Organisation=
s and Service Providers can acquire confidence that the other party is meet=
ing its data protection requirements:
- Both the Home Organisation and the Service Provider must comply with th=
e requirements specifically imposed on them by the Data protection directiv=
e and by national law.
- The Service Provider commits to the Code of Conduct for Service Provide=
rs.
- If the Service Provider is located within the EU/EEA, the local laws al=
ready bind the Service Provider to most of the requirements presented in th=
is the Code of Conduct. The Code of Conduct can be seen mostly as a divisio=
n of responsibility to ensure the data protection law's requirements are me=
t.
- The use of this Code of Conduct is not encouraged for attribute release=
to non-EU/EEA Service Providers and Service Providers outside countries/ar=
rangements that do not guarantee adequate data protection. Instead, refer t=
o the Model cont=
racts of European Commission.
- The Service Provider asks, via its SAML 2.0 metadata elements, for Attr=
ibutes that are necessary for the legitimate interests of the Service Provi=
der to provide the service to the end user. It indicates this legal grounds=
by labeling these attributes as "isRequired=3Dtrue".
- To inform the end user of processing his/her personal data, the Service=
Provider includes a prominent link to its Privacy Policy e.g. on its front=
page.
- The Service Provider's commitment to the Code of Conduct document may a=
ssist the Home Organisation to achieve confidence that the risk of releasin=
g Attributes to such a Service Provider is acceptable because it can see th=
at the attribute processing done at the Service Provider meets the requirem=
ents of the Directive.
4. Phased Implementation
This section suggests and provides reasoning for a phased implementation=
, where the release of optional extra attributes is deferred to a later pha=
se. See Introduction to Data protection directive for background information.<=
/p>
4.1 Thoughts on the Current Situation
- There are already many Service Providers which require Attributes to be=
asserted by a trusted Identity Provider. There is significant interest in =
encouraging Identity and Service Providers to use Attribute release, when a=
ppropriate and done in a manner consistent with each party's risk appetite.=
- In the short term, deployability is the primary goal. The Code of Condu=
ct should give maximum confidence to both the Home Organisations and the Se=
rvice Provider with minimum cost for both of them.
- There is a need for a scaleable approach to providing Home Organisation=
s with the information they need when deciding whether or not to release at=
tributes to a specific Service Provider.
- Consensus on Phase 1 has to involve both Service Providers and Home Org=
anisations. Both parties must be comfortable with the approach in order for=
it to see broad adoption. It is inevitable that any framework is going to =
be a trade-off between maximising functionality and maximising adoption; a =
dialogue between Service Providers and Home Organisations is required to wo=
rk out where the sweet spots are in that range.
- Experience in some federations seems to indicate that there are very fe=
w (approaching none) use cases that require the use of optional extra Attri=
butes released on user consent. Using necessary Attributes has been suffici=
ent.
- Requiring user consent to the release of optional Attributes would make=
widespread deploy significantly less likely since doing consent properly r=
equires both the Home Organistations and Service Providers to implement new=
systems (so increased cost).
- Service Providers need to be able to identify attributes as "necessary"=
or "optional".
- Identity Providers need to install a consent module which supports the =
concept of releasing optional extra attributes on user consent.
- Identity Providers needs to signal that user consent has been obtained.=
- Service Providers need to be able to verify that user consent has been =
obtained.
4.2 Phase 1 Approach
- Deploy a voluntary participation model for constraining risk. Encourage=
all parties to addess their responsibilities within the Code of Conduct.=
li>
- Home Organisations and Service Providers should rely on the nec=
essary for the legitimate interests legal grounds for requesting a=
nd providing Attribute release.
- This approach would be much simpler than user consent,=
for both Home Organisations and Service Providers.
- This approach seems to match the experience so far.
- Defer release of optional extra Attributes based on us=
er consent until Phase 2.
- Introducing consent, even as an optional possibility for Home Organisat=
ions and Service Providers, would add significant complexity to the framewo=
rk. A unilateral statement by the Service Provider that did not rely on mat=
ching action by the Home Organisation would no longer be sufficient. The ad=
ded burden exceeds the value at this point in time.
- Explaining all of the additional complexity without creating an immense=
amount of confusion for everyone may be too difficult.
- If an Service Provider really wants an optional attribute, it should ob=
tain it directly from the user.
4.3 Specific Phase 1 Steps
The =
Code of Conduct for Service Providers lists the criteria that Service P=
roviders must meet in order to state that they are committed to this Code o=
f Conduct. For Home Organisations aiming at making use of this Code of Cond=
uct, Data protection good practice for Home Organisations provides =
good practices which would help the Home Organisations to meet the requirem=
ents set by the Data protection directive. A Home Organisation can decide t=
o ignore these good practices. However, doing so creates risk for the Home =
Organisation, not the Service Provider.
Federations are proposed to
- Help Service Providers to populate necessary SAML 2.0 metadata =
elements, such as MDUI information
- Help and encourage Service Providers to understand a simple privacy pol=
icy document and its role, and then publish a privacy policy.
- Help Home Organisations understand the Code of Conduct=
model and become comfortable with it.
- Help Home Organisations configure their Identity Provi=
der to use the Code of Conduct model.
5. About the Preparation Process of=
this Code of Conduct
Specifically,
- The eduGAIN project and REFEDS attribute release workgroup have develop=
ed the Code of Conduct as a joint project process.
- The intention has been to keep the process open, including public comme=
nting, workshops and consultations. The goal is to make the Code of Conduct=
generally approved among the community.
- The eduGAIN project is discussing with the Article 29 working party (WP=
29) of EU on the possibilities to submit the Code of Conduct to the working=
party for approval. Approval by WP29 would further legitimize the use of t=
he Code of Conduct in EU.
- The generally approved Code of Conduct would then be made available for=
federations, Home Organisations and Service Providers.
- Adopting the Code of Conduct would be purely optional for federations. =
Service Providers and Home Organisations are always able to use whatever al=
ternative means (e.g. bilateral agreements) to fulfill the obligations impo=
sed by the data protection laws.
- The goal of having the CoC generally approved is to remove obstacles fr=
om wide adoption and to avoid the eduGAIN project and REFEDS attribute rele=
ase workgroup being held liable for the contents of the Code of Conduct. Ob=
taining "general approval" would further legitimize the use of the Code of =
Conduct in EU.
------=_Part_1911_992459788.1711649140705--