Page History

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.

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

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".
I.e., the use case of an outsourced examination system (this one based on LibreEOL; provided by someone/-thing that's not an "educational institution") would be allowed by the defintion in section 1 but not by the registration criteria in section 2.

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.
(When looking for alternative wording suggestions I already made those and they went into the Definition. That's not enough, though, in light of later sections prohibiting these use cases again.)

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.
Same for Erasmus+ (add reference), of course!

That's quite a mouthful. No use of the ESI outside of the def is clear (enough).
But "as presented at the time of registration to its users"? What registration? The registration of a service with a federation (or when this EC is to be assigned by the federation) – there are no users present "at this time".
Or does "users" refer to the registrar personnel assigning this category to a service? (That would be an unusal use of that term and should be clarified.)
Or does "as presented at the time of registration to its users" talk about "registration" of end users with the actual services? Accessing federated services will not usually (and certainly not necessarily) come with a "registration" process for the end user. Does this text mandate such a process exists? (That would be unrealistic and a barrier to adoption of this spec, IMO.)

Finally, what is this last part trying to say: "and [a Service Provider] will support this statement within their published Privacy Note" – that:

1. an SP is required to publish a "Privacy Note" ("Privacy Statement" would match SAML MDUI spec terminology, "privacy policy" is common), and that
2. This privacy statement has to include language to the effect that the service provider (implied: processes the ESI and) will not use the ESI for purposes other than specified in the ESI SAML Entity Category specification?

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.

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:

1. the aforementioned expectation that adoption will need to be close to universal for European IDPs, and
2. detailed existing monitoring in place what IDPs factually release (as provided to ESI-WG participants via the "Attribute Readiness" wiki page).

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.
(FTR, I have zero issues with adding the support EC to our IDPs, so I'm not arguing on my own behalf but from observation that getting new ECs supported takes some effort for some/many federations. And contrary to other ECs this one may have very few or zero SPs using it but would still require most/all IDPs to carry it.)

I.e., remove the 3rd paragraph in section Semantics (about the "support" EC).

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.

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.
Maybe it would be better for those be collected and presented in one place and then only call out which of those the registrar is supposed to verify / attest to in a different section?