This is a proposal for a project to develop and establish a metadata registry based on the PEER User StoriesBEER User Stories and PEER Service DescriptionPEER 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.
Goals
The goals of the PEER project is:
- Develop a software package based on the PEER user-stories.
- Deploy the PEER software in combination with other software and tools (cf below) as a service fulfilling the PEER service description.
Architecture and Scope
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 it acts as a registry for. 
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) :
- Validate that the registrant owns the metadata it is trying to register
- Validate that the registered metadata is syntactically (and to some extent semantically) correct
- Store the metadata in a metadata repository where it can be retrieved by an MDX implementation for publication.
In particular the following are expected to be out of scope for the PEER software (but not for the PEER service):
- Signing metadata and publishing signed metadata. This will be the responsability of an MDX implementation TBD.
- Implement all aspects of a fully functional metadata store. Metadata is expected to be stored in either a general purpose VCS (version control system) or in some form of XML store abstraction layer which supports indexed retrieval of individual entities. Depending on the tools available the PEER software may need to provide indexing and searchability of metadata.
The components marked in green represent those software components which are expected to be part of the PEER software development project.
Governance
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.
Plan
The project consists of 3 phases:
- Planning
- Development
- Service deployment
The planning phase of the project has already begun 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:
- SWAMID will operate an instance of PEER for internal use
- NORDUnet will operate a public instance of PEER
- ... UK?
Budget
Initial estimates for the development phase is 300-350 hours.