In the context of activities related to the digitization of Student Mobility processes, the need for an identifier was identified and such identifier called European Student Identifier has been defined. Such an identifier is needed to identify students as part of their formal learning activities which require data exchanges to take place, primarily, within or between institutions.
This ESI, European Student Identifier, Entity Category aims to regulate which Service Providers qualify to request the ESI and to facilitate Identity provider in the release of such attribute value.
The final version is now available for consultation: https://docs.google.com/document/d/1SUY9ZV2ya3VOx4lnWqlfLa0mT-bi4lwguYKvmm0W2LY/edit#
You can provide your comments either via the google doc or via this wiki page.
Please provide your comments by the 8th of October.
# | Reference | Comments/Proposed changes | Proposer | Actions |
---|---|---|---|---|
1 | Sec.1: "Due to data privacy legislation, the ESI Entity Category can only be used for services within the EU/EEA" | I don't think this is due to legislation (which doesn't speak about the ESI and also allows for data transfers outside the EU/EEA) so this is the decision of the spec's authors/editors, no? If so don't blame legislation for your own choices. | Agreed - text removed | |
2 | Sec.2: "Services outside the EU/EEA where there are agreements in place with entities within the EU/EEA where personal data privacy is regulated are also in scope." | The current wording is a bit convoluted and somewhat underspecified. (Agreements with just any "entity within the EU/EEA" make transfers/processing outside EU/EEA fine?) In general and also applicable to comment #1 I'd avoid trying to restate EU law as part of a SAML attribute deployment specification. GDPR allows what it allows, why is it this entity category spec's job to tell people what's allowed (by enumerating "within EU/EEA" and "otherwise contracts") and what's not (by leaving out other mechanisms GDPR provides)? Are these 2 criteria at least the easiest ones to verify for the registrar? (I guess the registrar could demand some form of documentation from the SP that data processing is physically located with the EU/EEA which I think is what counts under GDRP. Still that would raise the bar to proper adoption – meaning where people don't simpy ignore such details – significantly.) | Text removed | |
3 | Sec.2 "services that transfer student records or transcripts of records between educational institutions" | This significantly narrows the definition made in section 1 to "educational institutions" whereas the Definition allowed for "formal learning and teaching activities and/or the administrative activities related to those" and added "primarily" when talking about (no further qualified) "institutions". Knowing of such use cases exist (provision of "remote e-assessment tools" – in the words of LibreEOL, the result of an initiative by the EC itself! – by third parties) I would regret having to exclude them from scalable use of the ESI via this spec. | Good point - following a discussion it was agreed we should allow this such use-case | |
4 | Sec.2: "Support University Alliances scenarios where students’ records are shared across (some of) the universities of the Alliance" | Clearly "(some of) the universities of the [University] Alliance" is already included in the bullet before, talking about services that "transfer student records or transcripts of records between educational institutions"? So this bullet can be removed but if mention of this "University Alliance" should be retained you could add "for example as part of the University Alliance" to the end of the prior bullet. Just like Erasmus+ is used as an example for Student Mobility at the end of the first bullet. Also, what "University Alliance" specifically? Provide a reference if it's sufficiently imporant to be called out in this spec. | We agreed to keep as a separate item - | |
5 | Sec.4: "In possessing the Entity Category Attribute with the above value, a Service Provider claims that it will not use the ESI attribute for purposes that fall outside of the service definition as presented at the time of registration to its users and referred to in metadata and will support this statement within their published Privacy Notice." | That's quite a mouthful. No use of the ESI outside of the def is clear (enough). Finally, what is this last part trying to say: "and [a Service Provider] will support this statement within their published Privacy Note" – that:
I think you'll find that such requirements will be ignored from day one (or the next time the SP has its privacy policy changed): 47 out of 212 CoCo-claiming SPs currently have errors wrt the required reference to the CoCo in their privacy statement. And that's even with all the work that has gone into CoCo adoption over almost a decade: a published privacy policy template, lots of supporting documentation, fully automated monitoring of privacy statements, etc. – none of which exists (and is unlikely to be created/established) for the ESI category spec. | Thanks for this - we have proposed a different approach. | |
6 | Sec.4: "In possessing the Entity Category Support Attribute" | I expect close to 100% of the European academic IDPs will need to support the ESI (for continued Erasmus+ participation alone). It would take quite a bit of effort to get 3 dozen federation operators to adjust their tooling in order to allow essentially all European IDPs to assert that ESI "support" category. And for what? The main/only thing "support" ECs offer is allowing an assessment of the scope of the adoption. But for this we have:
So it seems the added benefits of also having an ESI support category are essentially nil, while it would take significant amounts of work to get every ESI-supporting IDP to also state that via the support entity category. Work that's hard to justify or sell given the intangible benefits possible derived from it. I.e., remove the 3rd paragraph in section Semantics (about the "support" EC). | We do not believe that all IdPs will support the ESI/ESI EC (at least not in the short term). For the time being this is useful | |
7 | Sec.6 SP requirements | This section merely contains an example of how a registrar would format the entity attribute. Cf. comment #10 for why that's hardly a complete statement about an SP's requirements in order to carry this category. | This has been fixed | |
8 | Sec.7 IDP requirements | Remove section 7 as argued for in comment #6. | As we believe it is useful to keep the IdP side of the ESI EC, we cannot delete this section | |
9 | Sec.8 References | Add refs for University Alliance (if needed) and Erasmus+, cf. comment #4. | Done | |
10 | Sections 1, 2 and 4: Who's requirement is it | Continuation of comment #7: What could be called "SP requirements" are actually strewn across sections 1 (Definition), 2 (Registration Criteria) and section 4 (Semantics) — purpose, location of data processing (within EU/EEA), legal requirements (contracts with ??? if located outside EU/EEA), data/ESI usage, privacy statement, etc. | We follow the format of the other EC - would this comment apply to the other ECs managed by REFEDS? | |