Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

THIS IS DRAFT ! 

Assessment As part of the GN4-2 project, an assessment of the GDPR implications on the eduGAIN constituency was conducted and the results are presented in the Assessment of DP legislation implications document

Based on this assessment, the following action points can be have been attributed to eduGAIN central function operational team (in table only eduGAIN), REFEDS, Identity Federation Operators, Service Providers (SP) and Identity Providers (IdP).

We recognise that there are differences in legal requirements for Identity Federations within the European Union (EU) / European Economic Area (EEA) and in the rest of the world, but believe this advisory represents best current practice for all Identity Federations so have not distinguished our advice to different regions. 


Action TopicWhoDescription
How
AdvisoryStatus
Publishing contacts in metadataeduGAIN

Operational contact information for individual administrators IdPs, SPs, AAs and Identity Federations is collected in the metadata published by Identity Federation Operators. In this case, eduGAIN

is

is  data processor

of

for this information. The information is held and published in the eduGAIN database and in the eduGAIN metadata.

Advise identity federations to register contact informations that are not personal but rather to functions.

The current eduGAIN Metadata Profile says: that if present, <md:EmailAddress> SHOULD not
be a personal address but a role address to get in contact with the entity's responsible persons.

Identity Federations should register functional role contact information intended for publication in metadata. Publication of personal data in metadata for publication is not recommended. eduGAIN will publish guidelines and recommendations to the eduGAIN Steering Group (SG).

eduGAIN will update

Update

the wiki.edugain.org with such examples and practices, and in future Best Current Practice (BCP) guidelines.

Since

there is no such advisory or practice that is active

at the moment, there are no strict requirements regarding contact information in metadata, and substantial number of entities are publishing personal contacts, eduGAIN will adapt the (new) eduGAIN

privacy notice accordingly, to embrace both behaviors.

Published contacts in metadata should not be personal but rather to functions.

Advise identity federation operators.

If personal information is unavoidable, Article 15 on the Rights of Access by the data subject applies.

**ANC: true that Art15 applies, but I'm not sure how saying helps? If you want that to be an actionable statement, you need to at least say whether individuals should send their Art15 requests to eduGAIN or their FedOp? I'd suggest the latter

**MA: cant we specify that contacts related to functions are to be used. Then we can consider that no personal data collected, and if somebody still sends it, well its their own "problem".

Privacy Notice accordingly.

Where personal data does exists, all the usual rights of the user under GDPR will apply. 

Best Current Practice for eduGAIN will be developed from March 2018 - December 2018.   Areas impacted by GDPR will be prioritised.
**PAx: I would say "strongly recommend not to use personal contact addresses in metadata due to GDPR" is a good way to indicate what we're after. Right to Access is available per entity through https://technical.edugain.org/entities. To get a list of all they need to contact the issuing federation. That is also the answer for Article 15 on Right to Rectification and Article 17 on Right to Erasure.
Identity Federations

Operational contact information is registered for administrative purposes and published in metadata for administrators of IdPs, SPs and AAs

is collected in the process of registering their metadata. Identity federations are collecting and processing that data, and IdPs, SPs or AAs are controllers. !? are they

Adapt the entity metadata registration practices, advising or requesting from entity administrators to publish contacts in metadata that are not personal but rather to functions. In this case, identity federation can claim that no personal data is collected or processed.

Published contacts in metadata  should not be personal but rather to functions

Recommend their IdPs, SPs and AAs to use non-personal contact information in the metadata. If personal information is unavoidable, Article 15 on the Rights of Access by the data subject applies.

**ANC: as above

**MA: as above

** PAx: as above

REFEDSUpdate the MDRPS BCP, so that registered contacts are not personal bur rather to functions.
** NH: at the moment the MRPS only covers registration and not publication.  This advice would fall under publication.  Whether MRPS should be extended to include publication has been discussed with FOs several times but always gets pushback.

. Different contact details will be held for internal authorisation purposes and as contact points for public consumption.

For metadata that is published, Identity Federations should adapt its entity metadata registration practice to request functional role contacts rather than personal contacts. For internal administration processes, Identity Federations will need to manage personal data for authorisation processes and should adapt Privacy Notices accordingly.


REFEDS

When registering entities, Identity Federations will gather several different types of contact data. Some of this will be for internal administrative purposes and some will be to publish in metadata. 

The REFEDS Metadata Registration Practice Statement should be updated to include guidance on what type of contacts should be gathered for each role. 


SG members contactseduGAINContact information for the eduGAIN Steering Group delegate and deputy of all member federations
are
is collected and published on the technical website.
eduGAIN is processor and controller ?Consult with the SG if keeping this information publicly is necessary.

Inform member federations that information about their SG delegate and deputy is collected. This information should be added in the (new) eduGAIN

privacy notice

Privacy Notice.

Inform member federations that information about their SG delegate and deputy is published on the technical website. Processes in eduGAIN should ensure that the individuals mentioned have the appropriate ability to ensure this information is accurate and to understand how it is used (as described in Article 15 Rights of access by the data subject).

**MA: Is it necessary to keep the SG delegates list public? IMHO technical contacts yes, but those are not necesserly the same as SG. Should we consult this with SG on this?

**PAx: No I don't think we need to have that list public. It's always possible to ask eduGAIN OT or eduGAIN SG flywheel for the information when you need it.

Consult with the SG if keeping this information publicly is needed.

Consultation started with the eduGAIN Steering Group
NH: on agenda for next eduGAIN SG
.
Data Processor Agreements - DPAIdPs, SPsGDPR regulates the release of personal information from an IdP/AA to SP. Scalable minimal attribute assertions should be addressed with the use of entity categories. However, where scalable models do not apply, the contracting parties can make bilateral DPA agreements
.

Consider making bilateral DPAs where scalable models do not apply.

Can make bilateral DPAs where scalable models do not apply.

**ANC: I agree that having a bi-lateral agreement is an option, but it seems unlikely that the SP would be a data processor in this case? If the IdP is handing over more data than necessary, this feels much more likely to be for a purpose set by the SP, in which case the SP is a data controller. I'd also expect it to be much more common for clauses to be incorporated into an existing contract between the parties (e.g. a site licence) rather than a stand-alone agreement?

, such as those embedded in site licenses.

IdPs and SPs have the option to use a bilateral agreement where more specific agreements (not supported by entity categories) are needed or in place - such as via a specific procurement or other agreement. Other approaches that are more scalable will typically be preferred but will not always fit

** PAx: The federation is used both for traditional procurement services and for the more interesting access by user based on need. I think we need to keep bilateral but add something about that it doesn't work in most cases due to the structure of research collaborations

.


Identity FederationsSupport the IdPs and SPs, and help them identify where scalable models do not apply.
eduGAIN /REFEDS

Consider

to develop

developing a sample bilateral Data Processor Agreement in the BCP package, with the caveat that implementation must be at the risk of the contracting parties

**MA: Are we still planning to do this. If yes, who and what is ETA?

**PAx: I think we should drop it!

**MA: Given the time frame, i think so too

.

It seams unrealistic. Nicole Harris what do you think?

NH: we have a draft DPA from

GÉANT
that is very generic but could be used.  I think we would have to position very carefully so people don't think they HAVE to coordinate DPA with everyone.
GÉANT
Data Protection Code of Conduct 
-
(CoCo)eduGAINThe current version of the CoCo describes an approach to meet the requirements of the EU DPD via the "Code of Conduct" function. It defines behavioural rules for SPs that want to receive user attributes from IdPs/AAs
about the user that logs in to the service
.

Update GÉANT CoCo

to

to reflect the changes between the new GDPR and the old DPD.

After completion, the new CoCo v2.0 should be submitted to the EU GDPR competent supervisory authority of approved codes of conduct as described in GDPR Article 40. After the submission of CoCo v2.0. GÉANT shall work together with the competent supervisory authority to get CoCo v2.0 approved as an official GDPR Code of Conduct, effective after 25 May 2018.

In parallel with the approval process, adoption and use of CoCo v2.0 within eduGAIN will be formalised as Best Practice for both SPs and IdPs.

The work on a new version of CoCo

commenced

is being led by a small team of identity federation specialists with support from DLA Piper. The draft version has been substantially completed and has been sent out to consultation within the international identity federation community.The interim working draft was published in June 2017 and an explanatory memorandum is being prepared in parallel.

Second

The second draft was published in January 2018 and the consultation period

is finished

will finish in February 2018.

Identity Federations

Prepare the tooling and processes to enable adoption of GÉANT CoCo v2 by IdPs and SPs.

Promote usage of CoCo

as ...add please ?

v2 when it's approved.


IdPs, SPs
Use CoCo to ... add please ?

Given the lack of maturity of approaches under Article 40 of the GDPR (Codes of Conduct), the demonstrable application of safeguards and privacy via CoCo and the high-risk impact of other solutions by the user (using commercial logins) there is a strong case to continue using the existing CoCo v1 until CoCo v2 is approved.


REFEDS Research and Scholarship Entity Category -REFEDS R&SREFEDS

REFEDS R&S is designed to allow data to flow to research and

scholarship interaction

scholarship  SPs, that have a legitimate interest in the data.The attributes supported in REFEDS R&S are chosen to represent a privacy baseline such that further minimisation achieves

no particular

no  benefit.

The impact of the GDPR is low due to the fact that REFEDS R&S is based on

necessary use of the service and utilises the minimal Attribute Assertion

legitimate interests and requires minimal attribute release (shared user identifier, person name, email address and the optional organisational affiliation).

Perform an assessment of the GDPR on

Guidance on the use of REFEDS R&S

: use of consent, use outside EU/EEA and the applicability as certification mechanism. Explore the potential of certifying the REFEDS R&S as Certification bodies emerge.

**ANC: do you really want to involve certification bodies/processes/etc. in R&S? The whole point of it was to be lightweight, and certification would almost certainly make that impossible

** PAx: I agree with ANC,

NH: discussing this with Kantara but it is very tentative at the moment. 

and GDPR has been developed by REFEDS and published. REFEDS is considering the potential of making R&S a Certification but this will be a long process.

REFEDS should develop a lightweight audit process for SPs asserting R&S entity category, to be used by Identity Federations before asserting

eduGAINIncorporate  REFEDS R&S as BCP -where, how ?Identity FederationsImplement a lightweight audit for before applying

the REFEDS R&S tag for the SP to ensure that

the 

the data in the attribute bundle is legitimately required

by SP

. This

is

should be supported by a risk management toolkit to help organisations make effective decisions when supporting REFEDS R&S.

  - is it ? where, can we concretise this


https://wiki.refeds.org/display/ENT/Guidance+on+justification+for+attribute+release+for+RandS
eduGAINIncorporate REFEDS R&S as BCP within eduGAIN.
Identity Federations

Implement and use the lightweight audit process for SPs asserting R&S entity category that will be developed by REFEDS.


IdPs

As REFEDS R&S is based on

necessary use by

legitimate

interest

interests, the IdPs

can remove the consent question. Transparent privacy notice

should not use consent dialogues in the workflow. A transparent Privacy Notice in which the IdP explains to the end user which attributes are released and why, can be used instead

.

**ANC: fully agree with this statement, so a bit puzzled why you're mentioning "consent" as something REFEDs should be reviewing in the R&S context above?

** PAx: Consent CAN ONLY be used with R&S for export outside EU/EEA due to the legal basis legitimate interest

.

But how to do decide when to do a consent request or not?


Security Incident Response Trust Framework for Federated Identity – SIRTFIeduGAIN, Identity Federations, IdPs, SPs

SIRTFI aims to enable the coordination of incident response across federated organisations. This assurance framework comprises a list of assertions which an organisation can attest in order to be declared SIRTFI compliant.

In GDPR Chapter IV Section 2 the security practices for data breach of personal data are defined. Security incidents involving breach of personal data are in scope for SIRTFI.

The SIRTFI framework is the recommended way to meet

the requirement of the

GDPR requirements with regard to handling communications around data breaches within

the federated environment is to use the SIRTFI framework

federations.

SIRTFI

Best Practice

will therefore be positioned formally within eduGAIN

as recommended practice,

as  Best Current Practice (BCP) and supported by the central eduGAIN function for data breaches.

**ANC: note that the Article 29 draft guidance on breach notification makes their strongest statement yet that all data controllers should have an effective process to detect and deal with security incidents (smile)

End-user personal data that is necessary for resolving a security incident should only be shared between end points ie. IdP and SP affected. Identity federations and eduGAIN have a role in supporting, escalation and reporting only.

The SIRTFI framework was finalised in late 2016, and adoption of SIRTFI throughout the eduGAIN membership is underway.

SIRTFI has also been included in the GÉANT CoCo v2.0 specification to address GDPR requirements on incident response. SIRTFI states that the use of the Traffic Light Protocol (TLP) must be used to facilitate such information sharing.

Use of ConsentIdPs

Where consent is applicable, all consent should always be given freely, and be specific, informed and unambiguous.When

Attribute Assertion When one of the entity categories CoCo or REFEDS R&S is used for Attribute Assertion

attribute release is based on one of the defined necessary processing models in Chapter II Article 6, consent is not considered applicable.

Negative consent cannot be used, i.e IdP cannot ask the user to uncheck a box in order to stop information being shared.

Consent should only be used when the Attribute Assertion is not necessary.

When attributes are required for operation of a service, IdPs should not ask for consent for passing this information.

Consent mechanisms may be adapted to support the requirement for transparent privacy notices rather than explicit consent. Do not use an accept button but a continue button.


Identity Federations, eduGAIN, REFEDS

Further, specific investigation of the relationship between use of consent and other attribute release mechanisms is recommended, including seeking specific legal opinion when preparing

Best Common Practice (

BCP

)

.

**ANC: whenever I've raised this the problem seems to be that protocols don't provide an SP with a way to say "I can use this attribute but I don't need it". As far as I can see it's only those kinds of attributes where consent might be a valid legal ground. I agree a further investigation would be useful (though I think it's a technical one, not a legal one) to conclude and document either the BCP for how to express that kind of attribute or to say that it can't be done with current protocols

** PAx: Or strategy up til today has been to only work with "simple" releases of either a small standard bundle or using strict neccesariy attributes.


Interoperability with Jurisdictions outside the EU and EEASPs outside of EU/EEA

The increased territorial scope in the GDPR makes all SP that supply services to end users within the EU/EEA affected by the GDPR.

SPs outside the EU/EEA

must comply with the GDPR for their European users and if they cannot fulfil this requirement they

should

not offer the services to federated users from within the EU/EEA.**ANC: I disagree. It's up to the IdP to decide whether or not the benefit of providing a service to its users justifies the risk. And it's also up to the SP to decide whether the risk of offering services to EEA users is justified. So "SPs outside the EU/EEA SHOULD

comply with the GDPR, and EEA IdPs

SHOULD

should assess the risks of releasing attributes to

them". But, since no one actually knows what a "compliant" non-EEA SP looks like (and the status of any SP could easily change, for example if Privacy Shield is cancelled), by saying this MUST you're giving the perfect excuse to universities who are already saying "unless you can guarantee compliance then we're turning eduGAIN off"; to user communities who would rather use GoogleAuth; and to service management who are nervous about offering services through eduGAIN. "Google isn't saying this scary stuff, so clearly it's safer to use Google" (sad)

these services.

The entity categories REFEDS R&S and the upcoming CoCo v2

** PAx: I would right this as an recommendation, not a must. Is always a risc based descision.

The entity categories CoCo and REFEDS R&S

should be used to handle

Attribute Assertions

attribute release from IdPs within the EU/EEA to SPs outside.


Rights of the Data SubjectSPs, Identity Federations, eduGAINThe rights of the data subject are fundamental to the GDPR and therefore it is important for organisations to fully understand and respect these rights.

Create a

privacy policy

Privacy Notice that describes what and how personal data is used in the service. It is recommended that appropriate

privacy policies

Privacy Notices are published for all levels of identity federation services, from eduGAIN centrally, to federations, to IdPs and SPs to demonstrate transparency of compliance to the GDPR. These notices should include guidance on which level of the service users should contact in given scenarios. 

The upcoming

version 2 of the

CoCo v2 will contain information on how to uphold the rights of the

End User

end-user that can be adapted to provide a framework for such

privacy policies

Privacy Notices.

**ANC: a lot of GDPR is about individuals being able to exercise their rights. If you're drafting template policies at the different levels, I think it would also be helpful to map out which level individuals should contact to exercise each of their rights.

An example of how to write a Privacy Notice can be found on the InAcademia website

The Current GÉANT Code of Conduct has a template Privacy Notice as part of its document set. 

Support requests to edugain-supporteduGAIN

Contact information for individuals will be received by edugain-support. This will typically only cover email address and any contact information in email signatures, but there is a risk that individuals may share sensitive data regarding the issues they face (e.g. passwords or usernames that are not working, sensitive incident information). 

Tickets are managed by the GÉANT OTRS system and only accessible by authorised members of the edugain-support team.

Guidance should be given where the edugain-support address is publicised encouraging users not to send personal data to the edugain-support list and describing the incident response role of eduGAIN. 
** PAx: Very true. For all templatet we do, policies, notices and others, we should add information where the users should excersive their rights.