Child pages
  • Home
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

BEER - Bucket of End Entities Registry


BEER is envisioned as a lightweight, global registrar for SAML Metadata representing both SAML and non-SAML endpoints (eg OpenID, IMI). It is intended as a quick activity to catalyze easier international use of federated identity. The service is not intended to be a replacement for federation or inter-federation, but is intended to be a tool supporting such activities. The service is intended to be operational Jan 2011. It may be operated by an interim operator and move to a permanent home if the service is seen as useful.




Metadata Registry

A SAML metadata curation service


An entity registrering SAML metadata in a metadata registry


An entity consuming SAML metadata

Domain owner

An entity which has administrative control of a DNS domain and/or URL

Service Description

BEER ("the service" in what follows) will accept registration of SAML metadata by registrant who is the domain owner of the domain associated with the SAML metadata entityID hostname. The service will perform schema validation on registered metadata. The service will make registered metadata available to consumers equally, unfiltered and unrestricted.

The service will not impose restrictions on the type of metadata registered but may 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 minimally support managing key rollover and will probably support updating organization name and contact information.

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.

The service is not intended to address the privacy aspects of services represented by registered metadata. Consumers of metadata are expected to address privacy considerations including management of attribute release policies.

Registrants must be aware that they are making their metadata available for publication without constraint and that registered metadata will be publicly available to all consumers. Federations that use the systtem may well constrain what information they import.

User Stories

  • The Czech medical atlas wants a single point of registration metadata in order to cut down on the work that they need to do with all the federations that want to use the medical atlas.  Eg. the spaces wiki wants to have the same. E.g. the REfeds wiki
  • As a consumer of metadata from BEER, I want the metadata to be a full representation of all the data in BEER about the entity in question in order to not depend on proprietary interfaces
  • 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.
  • As a consumer of metadata, I want the metadata to be available in multiple publication protocols, including an MDX endpoint. At least one publication protocol should be some of revision or versioning system.
  • As a registrant, I want to be able to import metadata from well-known locations based on SAML based approaches. Primarily One-time thing.
  • As a registrant I want the system to be able to refresh the metadata fetched from a previously specified (known) location.
  • As a registrant, I want to be notified about required changes to metadata, including certificate and metadata expiration.  Either by certificate expiration or on a regular basis.
  • As a manager of BEER, I need to be able to add additional XML schema to the metadata evaluation mechanism in order to support future development.
  • As a consumer of metadata I need to know and understand the level of assurance with metadata published by BEER in order to support my business processes.
  • As a consumer, I require clarity on the LOA associated with each part of the published metadata. (Know who has supplied which items of metadata to BEER)
  • As a consumer I need contact info for all metadata
  • As a consumer, I want the problems of metadata in order to evaluate its trustworthiness.
  • As a consumer, I need a human-readable descriptor of each entity. As a registrant I want to be able to insert a human-readable descriptor.
  • As a registrant, I want to be able to delete my metadata, even though it may not purge all traces of my metadata.
  • As a registrant, I want the service to publish appropriate caching hints in order to ensure that stale metadata doesn't live forever.
  • As a registrant, I want to be able to transfer control of metadata (permission to modify)
  • As a domain owner, I want to be able to delegate all or part of the registration and administer metadata on my behalf.

Next steps:

  • We have a set of user stories that are sufficient to set up a first generation BEER service.
  • Prioritization is next for the service, not the tool
  • Stick this on spaces.
  • Conf call next week.
  • The Janus use cases have either been labeled non-goals or included in the above list. Jacob will reword the BEER use cases and include those from Janus.
  • The Janus software may need to have too much ripped out to just do these services.  Or it may not deal with the generality required. Either a fork or a new code.
  • Modularizing the Janus software might be hard - current code structure and problems with SSP dealing with metadata
  • No labels