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.
A SAML metadata curation service
An entity registrering SAML metadata in a metadata registry
An entity consuming SAML metadata
An entity which has administrative control of a DNS domain and/or URL
BEER (The service is intended to begin by serving a limited set of use cases, with additional use cases being brought in as policy and technology permit. We intend to be agnostic in accepted metadata, but will do schema validation below) 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 OpenId and IMI. The metadata assembled will depend on the use cases but will minimally support key changeover, and possibly organizational 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 trust associated with the entries in BEER 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 dimensions of this problem space. Federations that import metadata from BEER aspects of services represented by registered metadata. Consumers of metadata are expected to address privacy considerations such as required ARP's themselvesincluding management of attribute release policies.
Registrants come to the service with the expectation must be aware that they are publishing making their metadata available for publication without constraint and that registered metadata will be publicly available to all consumers. Federations that use BEER the systtem may well constrain what information they import.
The service will have a standardized metadata tagging service. Tagging should be done by registrars and aggregators, but not by EE or queries (they can use the tags). The semantics of the tags needs to be worked out.
- 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