Service Provider Operating Group


This group, modeled off of FOG, will provide a forum for Service Providers to facilitate open discussions about operational issues of running services for Research and Education Identity Federations such as deployment issues, gaps in existing guidance, and other SP specific concerns.

The list operates with the following agreement (consisting of the Chatham House Rule amended with the possibility to ask for permission):

Participants of this list are free to use the information received, but neither the identity nor the affiliation of the source(s), nor that any other participant, may be revealed. If this cannot be ensured, redistribution of any information received requires prior express permission from the source(s).

This forum is a mailing list that is open to Service Providers registered in any Federation - i.e., any system that uses Single Sign-On services from universities or other federated identity providers. We expect discussions to be non-technical, and focused on access and authorization topics of interest to services, for example, signing into your service, and using sign-in to gain access to appropriate resources and services.

HOW TO JOIN: Send an email to the mailing list owners to request access.


I'm not a Service Provider, how can I help?
If you are a Federation Operator, please share this opportunity with your Sevice Providers. If you are an Identity Provider, please encourage your key services to participate.

What do you mean, "Service Provider"?
Service Providers use federated sign-on services (for example, from universities and other institutions) to access their services. An important component of Federated Identity Management is the "dance" between Identity Providers and Service Providers that enable Single Sign-On services, and the exchange of information about the individual involved from the Identity to Service Provider. 

But aren't all Service Providers different?
There is great diversity in Service Providers, though, at the core of the FIM integration, significant similarities exist for implementation, need for attributes, assurances, and more. 

Why create a group?
While there are several specific-topic groups that advocate for the needs of Service Providers (e.g., FIM4R, FIM4L), there currently isn't an easy way to share information, understand needs, provide peer support or solicit feedback across the entirety of the Service Provider community. The inability to talk with this community as a whole can lead to assumptions about what this community needs, thinks, and knows, some of which are likely suffering from limited direct interaction. This group hopes to provide a larger, unified voice for topics where there is similarity across providers; we believe this will benefit the community as a whole.

Why are only Service Providers invited to join?
Participation is open to representatives from Service Providers from any Federation. We will use tools such as the Metadata Explorer Tool (MET) to verify participants. Our goal is to make this a safe, collegial and targeted place to have discussions specific to Service Providers. For this reason, it is only open to Service Providers. Those who represent different types of entities are encouraged to include someone who only works on the Service Provider work, or to FIRMLY wear their Service Provider "hat" when interacting in this community. ANY service provider can join. This group includes entities from commercial organizations to virtual organizations.

How much time is this going to take?
This is a mailing list; there are no specific time requirements to participate, and no work deliverables that you will be expected to contribute to. We expect discussions to be non-technical, and focused on access and authorization topics of interest to services, for example, signing into your service, and using sign-in to gain access to appropriate resources and services.


The following terms apply to all REFEDS Working Groups:

  1. When a working group is agreed, REFEDS Participants will be asked if they wish to participate. Working Groups tend to be small, so a consensus can be achieved quickly between participants.
  2. A chair for the group is chosen from the REFEDS Participants.
  3. GÉANT provides facilities for the working group, including meeting support, wiki space, mailing lists and, where appropriate, funding.
  4. An appropriate output from the group is produced. Currently, this is typically a draft white paper or a wiki page.
  5. When the Working Group is in agreement, the chair shares the outputs with the wider REFEDS community with an open period for discussion and comment. This is typically a period of 4 weeks, but may be longer if appropriate.
  6. After this period of time, the REFEDS Steering Committee signs off on the work item. Work is either written up as a formal white paper, left on the wiki but promoted as finished work or occasionally submitted as an Internet Draft.

In addition, members of SPOG must be registered as a current Service Provider in at least one federation. People can request access to the mailing list. To be accepted for membership, the individual should demonstrate that they are a representative of an active SP that is listed in the Metadata Explorer Tool or similar.


Laura Paglione , SCG

Work Items

Through the course of mailing list discussions, general trends, issues, and topics may be identified as being beneficial to share with a broader audience or to memorialize as documentation or formal recommendations.

As these items arise, members of the group may propose work items that may include written deliverables or calls for further discussion. Participation, or lack thereof, in these work items will not affect an individual’s membership in the SPOG.


No calls are expected unless work items as described above are identified. The group generally will engage via the mailing list.


List any internal / external resources that are useful for the group here, for example, 

  • Centralizing some of the guidelines for Service Providers
  • Packaging the material for a Service Providerconsumer

  • No labels