high

Password reset

A user that forgets his/her password wants to be able reset it using a standard email-nonce flow.

med

External authentication

An administrator of a PEER instance wants to enable external authentication for PEER, overriding internal passwords for authentication in favor of an external mechanism including connecting PEER to an existing federation.

high

X509 Authentication

An administrator of a PEER instance wants to enable X509-based (using smartcards) authentication, overriding internal passwords and wants a configurable method to map information present in the X509 certificate to a PEER username.

high

Notification

A metadata consumer wants to be able to subscribe to notifications (eg using pubsubhubbub or XMPP) about changes to both individual entities and the full set of metadata in an instance.

med

Attribute-based Notification

A metadata consumer wants to be able to subscribe to notification about changes to a set of metadata that contains a specified metadata attribute-value pair.

high

Attribute access restrictions.

A PEER instance admin wants to be able to apply access restrictions to metadata attribute so that a specified (in configuration) set of attribute must only be edited by a team with elevated privileges. Such attributes must also be filtered on import of metadata.

med

DNS-based domain-validation

A PEER user wants to be able to choose between a set of roughly equally secure domain validation methods including one that involves putting a TXT-record in DNS.

high

Delegated domains

An administrator of a PEER instance wants to be able to allocate multiple domains (optionally including sub-domains) to a team without the need for the team to prove ownership of the domain. Such a team must then become "locked" so that only the administrator can add or remove users from the team.

high

Administration team

An administrator of a PEER instance wants to designate administrator rights to a team so that all actions that can be performed as the administrator can be performed by members of that team. Such a team must then become "locked" so that only the administrator (or members of the administrator team) can add or remove users from the team.

high

Rich metadata

A PEER user want the ability to add metadata elements that improve usability and findability of entities such as tags geolocalization and icon

low

GIT tags

A PEER user want to use GIT tagging to annotate metadata and wants GIT tags represented as metadata attributes on export and import.

med

Metadata refresh

A PEER user wants the option to re-import metadata from the same location as was initially used. The location must be represented in metadata.

high

Preview-before commit

A PEER user wants a preview of metadata changes before commit including a diff wrt current metadata for the entity. The commit flow should be visually and logically separated from the editing flow so that multiple edits can be done before a commit. A user should not be able to leave the edit flow until a commit or a decision to discard all changes has been made.

high

GIT repository co-existence

A PEER administrator wants to "point" a PEER instance to a subdirectory of an existing GIT repository so that PEER only controls entities in that subdirectory. The PEER instance can be assumed to have total control of the contents of "its" directory.

med

Metadata grouping

A PEER user wants to create groups of entities and obtain metadata, RSS etc for groups. Groups must be based on data stored in metadata, eg by using entity attributes.

high

SAMLmetaJS usability

A PEER user want clear feedback from the SAMLmetaJS editor about problems with user input and about dependencies between tabs.

low

SAMLmetaJS IE<9

A PEER user wants the editor to work in IE7 and IE8.

med

Monitoring

A PEER user wants the option to enable monitoring for endpoints associated with an entity. It should be possible to send notification/alarms using email.

low

Nagios integration

A PEER administrator wants the ability to obtain notifications as nagios events.