PEER (Public End-Entity Registry) (MLS -> SPIT -> BEER -> PEER)

PEER(Public End-Entity Registry)(MLS -> SPIT -> BEER -> PEER)

Goals • Develop a software package based on the PEER user-stories. • Deploy the PEER software in combination with other software and tools as a service fulfilling the PEER service description. • At least two deployments, including Nordunet

Relationship to General Interfederation • I think it's important to emphasize that this activity is really a technical initiative, to advance an architectural notion of how the world should work by putting up a real service and seeing how the world reacts. Real policy change often has to happen to deal with real opportunities, and rarely happens to embrace or encourage gleams-in-the-eye. So we're trying to prime the interfed pump. That is, there are of course policy issues, and we don't care right now. • RL "Bob” • http://tools.ietf.org/search/rfc5218 - Lucy

Other considerations Agnostic to flavors of identity providers; conformance to SAML metadata. It is politically very important to the future of Internet identity to quickly establish open metadata exchange points The service is needed to scalably support a number of immediate needs – CZ medical atlas, spaces, COIN, refeds, etc.

PEER Service Description PEER ("the service" in what follows) will accept registration of SAML metadata by a registrant who is the domain owner of the domain associated with the SAML metadata entityID hostname. The service will make all valid registered metadata available to all consumers equally, unfiltered and unrestricted. The service will not impose restrictions on the type of metadata registered but will perform schema validation based on a controlled set of technologies including SAML 2.0 Interoperable Metadata Profile, OpenID and IMI along will a set of widely deployed extensions. The service will publish syntactially correct metadata but will not perform any semantic validation. It is expected that consumers of metadata from the service will perform additional testing against the locally deployed technical environment. In particular it is expected that metadata published by the service be consumed by a local metadata distribution point (eg a federation operator) and not by end-entities directly. The service will minimally support managing key rollover and will probably support updating organization name and contact information for individual entities. The level of assurance of the entities registered in the system is based on demonstrated ownership of the domain. Consumers of the metadata are expected to understand this. https://spaces.internet2.edu/display/PEER/PEER+Service+Description

Big Picture 1

Work flow

PEER Service 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. The components marked in green represent those software components which are expected to be part of the PEER software development project.

Out of scope of software 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 responsibility 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.

Work plan Proposal for funding being developed Model is JANUS code from WAYF, but implementation will be done fresh by an experienced group from Spain via Victoriano Time frames are ambitious – March? peer@lists.iay.org.uk

Use Cases A service provider like the Czech medical atlas or Internet2 spaces wiki wants a single point of registration for metadata in order to cut down on the work that they need to do with all the federations that want to use the service. As a consumer of metadata from PEER, I want the metadata to be a full representation of all the data in PEER about the entity in question in order to not depend on proprietary interfaces We wonder how all data can be fitted into metadata without any aggrements on predefined syntax. As a registrant, I want to be able to manage key rollover for my entities in order to not reregister full metadata As a registrant I want the system to be able to support SAML metadata, OpenId metadata and IMI metatadata in order to be able to support multiple federation technologies. As a consumer I want to have the system produce schema valid SAML 2 metadata. As an consumer I need clarity on IP rights issued by the service in order to avoid legal problems on publishing the metadata. https://spaces.internet2.edu/display/PEER/PEER+Software+User+Stories

PEER (Public End-Entity Registry) (MLS -> SPIT -> BEER -> PEER)