This is a plan for a project to develop and establish a metadata registry based on the PEER User Stories and PEER Service Description. The PEER service and software draws from years of accmulated knowledge and is based on user-stories developed by representatives from WAYF.dk, MACE, InCommon, The UK Access Management Federation and SWAMID.
PEER aims to be a lightweight solution for the registration of SAML Metadata. PEER approaches SAML metadata differently from the well known and understood access management federations. Most federations in operation now:
PEER will provide only technical trust and metadata registration, and leaves the other considerations for consumers of the metadata to manage.
In order to ensure optimum use of federated access management, it is important that both ends of the security spectrum are examined. Whilst international efforts such as eduGain are examining this space from a policy driven perspective, PEER seeks to examine an approach where the registrar of the metadata does not involve itself in establishing policies for consumption.
The PEER service will provide the opportunity to examine the necessity of behavioural trust, challenge the current model of registration and publication as a central service for federations and review the points at which trust is established between end users and relying parties. This in turn will provide opportunities to improve the services offered by federations and provide economies of scale through a shared registration service for federations and support for more effective management of metadata.
The goals of the PEER project are:
The following diagram illustrates a reference model of metadata distrubtion. In this model, the PEER service is an instance of a metadata registry. Where it is unambiguous the word metadata refers to SAML metadata. Note that not all instances of SAML metadata entities describe SAML protocol endpoints - the PEER service is meant to be agnostic wrt the uses of the SAML metadata within the registry.
The following diagram illustrates the scope of the software developed for the PEER project and the role of a registrar in the federation model. The diagram is in the form of an ontology diagram. Read each ellipse-arrow-ellipse as a sentence, eg "A domain owner has a proof-of-possesson of SAML metadata" or "The MDX implementation obtains metadata from the metadata registry" and "The MDX implementation publishes signed metadata.
The PEER service (the grey box) will perform the following functions (the PEER service description provides a full list) :
In particular the following are expected to be out of scope for the PEER software (but not for the PEER service):
The components marked in green represent those software components which are expected to be part of the PEER software development project.
In accordance with agile methods best practices a product owner will be identified to act as a liason between the future users of the PEER software and service and the developers. The product owner will chair the project reference group and will be responsible for evolving and prioritizing the user-stories between each development sprint.
Additionally a project steering group will be responsible for oversight and budget control.
The project team is made up of the following people:
The steering group for the project is:
The project consists of 3 phases:
Four work-areas will run across these phases to ensure consistency and co-ordination"
The planning phase of the project began in October 2010 with the identification and articulation of user stories. The development-phase of project will use SCRUM and will consist of a number of coding sprints. As the code for the PEER software starts to form the service deployment phase will start. During this phase new releases from the code sprints will be deployed in a pre-production environment.
The PEER service is intended to be operated in more than once instance and the software will be made available under a BSD or comparable OpenSource License as soon as possible after the development phase of the project is underway.
At least two instances will be run during the Development and Service Deployment phase:
Budget Amount |
Funded Party |
Work Areas |
Deliverables |
---|---|---|---|
$37,300 |
Yaco Sistemas |
Development and Delivery of PEER User Interface. Funding will be used to provider approximately 330 hours of development time from Yaco Sistemas plus contributions to bi-weekly conference calls and full involvement in sprint testing. |
|
$5,000 |
WAYF.dk |
Development and Delivery of PEER use cases. Funding will be used to support the development of the PEER use cases plus contributions to bi-weekly conference calls. |
|
$8,400 |
Shibboleth Consortium |
Development and Delivery of PEER storage engine and metadata validator. Funding will be used to provide approximately 80 hours of development time from the Shibboleth Consortium plus contributions to bi-weekly conference calls and participation in sprint testing. |
|
$7,000 (NH) |
Nicole Harris, Leif Johansson and Ian Young |
Product and project management including full development of project plans, oversight of the coding sprints, development of appropriate user documentation and recommendations for future service delivery. |
|