Page History

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  data processor for this information. The information is held and published in the eduGAIN database and in the eduGAIN metadata.

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 the wiki.edugain.org with such examples and practices, and in future Best Current Practice (BCP) guidelines.

Since 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.

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

Operational contact information

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

. 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.

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. 

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

.

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

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  benefit.

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

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

Guidance on the use of REFEDS R&S

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

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

the data in the attribute bundle is legitimately required

. This

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

Implement and use the lightweight audit process for SPs asserting R&S

entity category that will be developed by REFEDS.

As REFEDS R&S is based on

legitimate

interests, the IdPs

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.

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

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

.

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.

Further, specific investigation of the relationship between use of consent and other attribute release mechanisms is

recommended, including seeking specific legal opinion when preparing

BCP

.

Create a

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

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

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

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

Privacy Notices.

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.