Date: Fri, 29 Mar 2024 15:04:04 +0000 (UTC) Message-ID: <1905515546.65.1711724644539@wiki-prod.refeds.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_64_1171609250.1711724644537" ------=_Part_64_1171609250.1711724644537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The PEER software and the REEP service were developed to provide= a single point of registry for SAML entities. In most current identi= ty federations, the federation runs its own registry locally and expects ea= ch entity to be able to prepare and deposit entity metadata with that regis= try. For some entities this is challenging, particularly where the en= tity is a member of multiple federations and is then required to maintain a= nd keep up-to-date information on each of those entities in multiple places= . The MET tool can be used to highlight this. The entity = https://met.refeds= .org/met/entity/http%253A%252F%252Fshibboleth.ebscohost.com/ is in 24 d= ifferent federations and the metadata maintained at each is different. &nbs= p;
A short FAQ is available.
The PEER software is intended to provide a lightweight registry service = that relies on domain validation only to assess whether a service can regis= ter any given entity. The software is available for general use and c= an be "skinned" for different service appearance. The software is cur= rently available on Github and is maintained by Emergya under= contract with REFEDS. Documentation on how to use the service is = available.
The REEP Service is an instance of PEER managed by REFEDS for use= by the REFEDS community as a testbed for the concept of using an external = registry for federations. It runs under the current lightweight policy.
The problem of registering Service Providers with federations is being l= ooked at by both GN4 (Enabling Users) and the AARC project. Federatio= ns can be confusing to join, typically for the following reasons:
There are some solutions looking a supporting these requirements, such a= s the GrIDP Identity Pool federation set up in Italy. It i= s unlikely that a service like REEP would ever be able to provide a complet= e solution to these issues with the absence of policy documentation within = REEP - eduGAIN for example requires registering federations to have clear p= olicy and does not register SPs directly without the trust framework of the= federation policy - but REEP could form part of a solution to alleviate th= e burden. It may be sensible for the community of identity federation= s to consider appointing a role to help act as Service Manager for SPs (and= indeed IdPs) with the challenges of joining federations.