Child pages
  • Home

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This is the home of the BEER space.

To help you on your way, we've inserted some of our favourite macros on this home page. As you start creating pages, adding news items and commenting you'll see the macros below fill up with all the activity in your space.

...

Column
width60%
Recently Updated

...

width5%

...

width35%

...

Navigate space

...

Page Tree Search

...

BEER

Box of End Entities Registry


Summary:
REfeds is setting up a lightweight, universal service to permit certain organizations to post their SAML metadata (representing both SAML and non-SAML endpoints) for broader consumption. It is intended as a quick activity to catalyze broader international use of federated identity. 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.


*The service


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 on a controlled set of technologies, including SAML 2.0 and OpenId and IMI.   The metadata assembled will depend on the use cases but will minimally support key changeover, possibly organizational and contact information.

The service is not intended to be a replacement for federation or interfed, but is intended to be a tool supporting such activities. 

The trust associated with the entries in BEER, is based on demonstrated ownership of the domain

The service is not intended to address the privacy dimensions of this problem space. Federations that import metadata from BEER are expected to address privacy considerations such as ARP's themselves.

Registrants come to the service with the expectation that they are publishing their metadata without constraint. Federations that use BEER 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). Semantics

Targeted use stories include:

         As a service provider, 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.

         As a service provider, the spaces wiki wants to have...

         As a service provider, 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 md 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 md. (Know what

As a consumer I need contact info for all metadata

As a consumer, I want the problems of md 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 descriptior.

As a registrant, I want to be able to delete my md, even though it may not purge all traces of my md.

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 md (permission to modify)

As a domain owner, I want to be able to delegate all or part of the registration and administer md 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.

         Janus may need to have too much ripped out to just do these services. Either a fork or a new code.

                  Modularizing might be hard - current code structure and problems with SSP dealing with md


* The software