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.
The goal of this document is to define how affiliation information should be expressed when transported across AARC BPA-compliant AAIs. Two different types of affiliation have been identified, namely Affiliation within the Home Organisation, such as a university, research institution or private company; and Affiliation within the Community, such as cross-organisation collaborations. Both affiliation types should be communicated to the service providers that rely on affiliation information in order to control access to resources.
Links
Working docs
Google doc: https://docs.google.com/document/d/1o6uLlUW59F61mdImPGMCAwBR4KH4lfQIaLMfaqhOW3Q
Final PDF
...
| View file | ||||||
|---|---|---|---|---|---|---|
|
Meetings schedule and Minutes
| Date | Location | Agenda | Minutes |
|---|---|---|---|
| YYYY-MM-DD HH-MM TIME-COORDINATES (UTC/CEST/...) | link to webconf platform/room | IMPORTANT insert link to PUBLIC PAGE | IMPORTANT insert link to PUBLIC PAGE |
...