2016-07-25 JRA1.4 Meeting notes

Davide Vaghetti

Nicolas Liampotis

• Proposed content:

  • When the group membership information comes from an external Attribute Authority the scope MUST be indicated

  • VOOT protocol
• Nicolas Liampotis suggests to link this topic to the eduPersonScopedEntitlement discussion/proposal.
• Relevant links:
  • https://lists.geant.org/sympa/arc/aarc-jra1/2016-04/msg00053.html
  • Proposal for eduPersonScopedEntitlement
  • https://spaces.internet2.edu/display/Grouper/Exposing+Groups+Through+Shibboleth
• ALSO check requirements and current implementations:
  • EGI AAI approach for expressing VO/group membership and role information

• Proposed content:

  • IdP based vs SP based (PUSH vs PULL)

  • use cases

  • requirements

• Proposed content:

  • TTS as a gateway: i.e. a Proxy a the Federation level (CILogon model)

  • TTS at the end service, (almost) seamless for the user, and certainly seamless for the Federation

• Mischa Salle points out that actually CILogon is not a gateway, since it does not join two different administrative entities. It is more a technological bridge. So maybe it is more clear if we split the possibile use of TTS in more use cases.

• Delegation = "act on behalf of the user"
• Proposed content:
  • OAuth2
• Mischa Salle propose ECP for the SAML world

We all agree that "Groups vs Entitlements" in the end is not such an issue.

Nicolas Liampotis proposes the following main topics:

• distributed authorization
• delegation of management of authorization attributes in a VO

Proposed content:

• Concentrate on some, or maybe ONE, specific use case: SSH seems to be the most relevant one (see also FeduShare project: https://sites.google.com/site/fedushare/)
• Marcus Hardt proposes to wider the scope of the "non web access" deliverable to comprehend REST API use cases
• We all agree that REST API is an important matter, we will see if it does fit in DJRA1.4F, or if it is better to split the deliverables in two parts;
• Michal Jankowski and others point out that in non web access use cases where there is provisioning of local accounts, (federeted) de-provisioning should be taken into account;