Guidelines for expressing affiliation information across infrastructures

Summary

This document describes the semantics associated with the use of the affiliation attributes eduPersonAffiliation and/or eduPersonScopedAffiliation when these are asserted by an Infrastructure Proxy when communiting to connected service providers and other Infrastructure Proxies.

DavidG: as I cannot edit or suggest in the Google doc: please fix/write this one quickly and - my preempting the discussion outcome - it should conclude by saying for the value of the ePSA/ePA: the semantics of eduPerson(Scoped)Affiliation changes for the Infrastructure Proxy .The value SHALL reflect the affiliation of the identity with the Infrastructure.

NicolasL: David Groep davidg@nikhef.nl Sorry for not being able to make suggestions - sharing permissions have now been fixed. Regarding this statement "The value SHALL reflect the affiliation of the identity with the Infrastructure." have we already concluded? Is eduPersonScoped affiliation going to be used only to express affiliation with the infrastructure (e.g. member@elixir-europe.org) while a new attribute will be introduced for home organisation affiliation? If so, will the new attribute follow the same syntax as ePSA? Lastly, are SPs connected to the IdP/SP Proxy supposed to perform any scope checking on the new attribute?

Hi Nicolas Liampotis: I think SPs will be doing scope checking anyway (you cannot prevent it, as anywhere else that is considered best if not the only acceptable practice. Since also SPs will likely serve multiple Proxies as well as independent customers, they will get different scoped and can never ultimately trust any of the single proxies. Which implies that, if we write something else here for eP(S)A that being the scope of the Proxy in all cases, things will start breaking in 'interesting' ways. So so keep consistency in the ecosystem, ePSA must be scoped to the proxy, QED . Meanwhile, we did define freshness to be scoped to the Infrastructure Proxy (which may use any kind of business logic to derive but, but that's out of scope for both this and the assurance doc, which is why I need this doc at least with rough consensus. Otherwise there will be too many dangling references in AARC-G021 ... Cheers, DavidG.

Links

Working docs

Google doc: https://docs.google.com/document/d/1o6uLlUW59F61mdImPGMCAwBR4KH4lfQIaLMfaqhOW3Q

Final PDF

To be published

Meetings schedule and Minutes