Date: Fri, 29 Mar 2024 15:33:24 +0000 (UTC) Message-ID: <1943172953.75.1711726404637@wiki-prod.refeds.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_74_1428878229.1711726404636" ------=_Part_74_1428878229.1711726404636 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This group, modeled off of FOG, will provide a forum for Service Providers to fac= ilitate open discussions about operational issues of running services for R= esearch and Education Identity Federations such as deployment i= ssues, 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 oth= er participant, may be revealed. If this cannot be ensured, redistribution = of any information received requires prior express permission from the sour= ce(s).
This= forum is a mailing list that is open to Service Providers registered in an= y Federation - i.e., any system that uses Single Sign-On services from univ= ersities 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 g= ain access to appropriate resources and services.
I'm not a Service Provider, how can I help?
If you are a Federation Operator, please share this opportunity with your S=
evice 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 univers=
ities and other institutions) to access their services. An important compon=
ent of Federated Identity Management is the "dance" between Identity Provid=
ers and Service Providers that enable Single Sign-On services, and the exch=
ange of information about the individual involved from the Identity to Serv=
ice Provider.
But aren't all Service Providers different?
There is great diversity in Service Providers, though, at the core of the F=
IM 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 o=
f Service Providers (e.g., FIM4R, FIM4L), there currently isn't an easy way=
to share information, understand needs, provide peer support or solicit fe=
edback 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, uni=
fied voice for topics where there is similarity across providers; we believ=
e this will benefit the community as a whole.
Why are only Service Providers invited to join?<= br> Participation is open to representatives from Service Providers from any Fe= deration. We will use tools such as the Metadata Explorer Tool (MET)= to verify participants. Our goal is to make this a safe, collegia= l and targeted place to have discussions specific to Service Providers. For= this reason, it is only open to Service Providers. Those who represent dif= ferent types of entities are encouraged to include someone who only works o= n the Service Provider work, or to FIRMLY wear their Service Provider "hat"= when interacting in this community. ANY service provider can join. This gr= oup includes entities from commercial organizations to virtual organization= s.
How much time is this going to take?
This is a mailing list; there are no specific time requirements to particip=
ate, and no work deliverables that you will be expected to contribute to. W=
e expect discussions to be non-technical, and focused on access and authori=
zation topics of interest to services, for example, signing into your servi=
ce, and using sign-in to gain access to appropriate resources and services.=
The following terms apply to all REFEDS Working Groups:
In addition, members of SPOG must be registered as a curren= t Service Provider in at least one federation. People can request access to the mailing list. To be accepted for membe= rship, the individual should demonstrate that they are a representative of = an active SP that is listed in the Metadata Explorer Tool or similar.<= /p>
Laura Paglione , SCG
Through the course of mailing lis= t discussions, general trends, issues, and topics may be identified as bein= g beneficial to share with a broader audience or to memorialize as document= ation or formal recommendations.
As these items arise, members of = the group may propose work items that may include written deliverables or c= alls for further discussion. Participation, or lack thereof, in these work = items will not affect an individual=E2=80=99s membership in the SPOG.
No calls are expected unless work items as= described above are identified. The group generally will engage via the ma= iling list.
List any internal / external resources tha= t are useful for the group here, for example,
Packaging the material for a Service Providerconsumer