Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

PEER Project Meeting, Monday 14th February 2011 

  • Ken Klingenstein
  • Licia Florio
  • David Simonsen
  • Jacob-Steen Madsen 
  • Leif Johansson 
  • Nicole Harris 
  • Karen O’Donoghue 
  • Victoriano Giralt

1.  Overview

NH explained where the project was in terms of progress.

Contracts are mostly in place.  These will be:

  • Nicole Harris Project Management 15 days: $7000
  • WAYF.dk: $5000
  • Shibboleth Consortium 12 days: $8400
  • Yaco Sistema: $28,500 
  • NH would also like to build in 2 days of non-development work from Ian Young: $1,400. 
  • This currently totals $50,300, leaving $4,700 leeway for travel and contingency.  

ACTION: LF to arrange the initial contracts to be sent out by the TERENA Secretariat.  These will be circulated for confirmation with appropriate parties. 

ACTION: NH to update the project plan to reflect this information.  


2.  User Stories and Promotion 

The group discussed the target group for PEER promotion and the pressing need to address this as part of the PEER project.  LJ invited WAYF to take this work forward.  It was agreed that the PR work should focus on specific use cases - with a emphasis on directed questions such as: ‘what is PEER?’, ‘why should I put my stuff in PEER?’ ‘If I put my stuff in PEER, will it get to federations?’ ‘How do you I put my stuff in PEER?’ ‘Who is going to be bringing what end points in to PEER?’ ‘How do you know that my metadata are consumed?’, ‘Can I choose the metadata consumers?’.

ACTION: WAYF.dk to put together a first proposal for PEER ‘PR’ for the beginning of April, with a second draft to be discussed at TNC2011.  

ACTION: NH to arrange a teleconference for the beginning of April to discuss use cases, PR and the PEER story and to update the project plan to reflect the WAYF input.  


3. Architecture 

The group agreed that PEER should allow for assertion filtering, whereby you can pull information based on a certain group of entities who make certain assertions.  Any policy around these type of assertions should happen elsewhere.  In this sense, PEER supports policy decisions via technical controls but does not itself implement or define policy.  

An important focus for the project architecture will be bringing together the two core technical developments parts - LJ has proposed a hook-up with WebDAV between the frontend work from Yaco and the validation engine from Shibboleth.  This in turn builds in the need for well-managed error messages (which is a good thing).  

LF proposed to build PEER in such a way to support  ‘categorisation’ of metadata to handle, in the future, different LoAs associated with metadata, with the purpose to facilitate the metatada consumers. 


4.  Sustainability 

Sustainability planning has been built in to the project plan.  Focus on the sustainability of the service but also the software.  

Sustainability must address questions such as: How many PEERs are we going to have?  There is a concept of the ‘global’ PEER, a ‘federation’ PEER and possibly many others.  This has to inform the development of the sustainability case in coordination with the use cases.  The best end game will be eduGain using PEER. 

ACTION: NH to ensure that sustainability is discussed and reflected on throughout the project timeframe.  


5.  Best Practise for Interfederation

There is a general problem with issue surrounding ‘best practise for interfederation’.  One of the issues is how ‘tags’ can be managed across federations to support the release of sets of attributes.  These should be sets of filters based on good recommendations: e.g. ‘only release transient attributes’, ‘release personal data’.  

The Shibboleth Consortium has recently promoted work within the Shibboleth development roadmap to better support such functionality.  

The group discussed the possibility of defining the first three or four well known tags as a priority.  These can be set and agreed at a REFEDS level for example, but each federation operator would have a responsibility to ensure that this made sense within their context.  It would make sense to propose this as a REFEDS work item to produce a best practise document, but certain groups such as Kantara, ISOC and ABA may already have work that could be built on in this area.  

ACTION: NH and LJ to go away and look at a proposal for best practise in tagging to propose to the PEER steering group and REFEDS.