This consultation opened on 14th March 2025 and closed on the 2nd May 2025. All comments should be sent to consultations@lists.refeds.org or added to the change log below.
Background
Federation operators have rules for entity registration to ensure a good user experience within that federation. These rules are typically published in a Metadata Registration Practice Statement. When we look at a wider ecosystem where multiple federation operators register SPs and IdPs, we need prioritization and selection rules. The rule that many people know about is the metadata combination rule in eduGAIN metadata aggregation, which enforces unique entityIDs. However, unique entityIDs are not sufficient to provide a good user experience in an ecosystem. Accurate and complete metadata (such as DisplayName and logos) will help people select the appropriate IdP when logging in, although this still requires an individual to make the correct choice at login time. What if there was also a mechanism in metadata for an SP to describe which IdPs it would prefer to interoperate with? This Entity Selection Profile aims to provide that.
Building on earlier work from SeamlessAccess, we are developing a profile that can allow SPs to identify a set of IdPs, either by entityID or generically by registrationAuthority or entity attribute. They coined the term “trustinfo” although we’re realising it’s actually an entity selection profile. The first step is to define an entity attribute as a container for transporting selection rules and profiles. This step focusses on the current SAML environment.
Overview
Participants are invited to:
- Review and comment on the proposed Profile.
Following the consultation all comments will be taken back to the working group for review and if appropriate the Profile will then be forwarded to the REFEDS Steering Committee for sign-off and publication on the REFEDS website as per the REFEDS participants agreement.
The document for the consultation is available as an attachment to this page. Background on the Trust Info Working Group is available. All comments should be made on: consultations@lists.refeds.org or added to the change log below. Comments posted to other lists will not be included in the consultation review.
Change Log
Change Log for the Entity Selection Profile entity attribute Consultation.
| Number | Line / Reference | Proposed Change or Query | Proposer |
|---|---|---|---|
| 1 | General | I like the use of Entity Attributes but I think the use of a raw base64-encoded blob of JSON is not the best way to include the Entity Selection filter in metadata. I would suggest two changes: 1) Require the value to be a URL, either a link to the Entity Selection data as a remote file, or a data: URL embedding the selection filter directly into the metadata. - Both allow the use of different formats in the future via MIME types A downside to selection filters at arbitrary remote URLs is that they lack the level of trust possible with data embedded in federation metadata. If this is a critical requirement I suggest either limiting the values to data: URLs, or hosting the remote filter files at the federation alongside the metadata. 2) Allow multiple values - Allows the consuming service to choose the most suitable filter format These changes also make it easier to define the initial filter format specification because it is no longer so tightly coupled to the metadata. | Pete Birkinshaw, Mimoto |
| 2 | General | In the document, I don't see any example of selecting individual IdPs within a specific federation. Is this intentional, or should it also be possible to select individual IdPs to be shown in the Discovery Service? If I understand correctly, the document only illustrates how to select individual Registration Authorities, but Service Providers often need to restrict access to institutions with which they have signed an agreement, these may belong to multiple federations. If we only allow displaying or hiding all institutions within one or more Registration Authorities, services will not be able to use this EntityAttribute to show only those institutions with which a contract has been activated. If selecting individual IdPs per federation is allowed, could a proper example be added to the specification? | |
| 3 | Line 47 | Will guidelines be provided to help provide a consistent semantics of the decoded values for metadata consumers? For example, if Seamless access has guidelines for use with their discovery service can these be referenced in an FAQ so all implementations of discovery will respond consistently? | |
| 4 | Lines 51 thru 53 | Will there be a verification or test tool or example of such that will provide a warning if the decoded value does not conform? | |
| 5 | General | The general premise is sound and needs developing so improve the discovery user journey. The method of implementation, however, seems, on the face of it, rather lazy and opaque. To break out of XML into a base64 encoded JSON blob of data seems unnecessary -- you're already in a feature rich markup language which is "easy" to read but, in doing it this way, the actual data becomes rather removed from view. I appreciate this probably makes it "really easy" to slurp into some applications and may require adjustments to how EntityAttributes work but it's not in keeping and makes diagnosis of problems much harder. Further it removes the ability to validate the data structures being exchanged. The data structure should be created as a new or extended XML schema and encoded in XML directly. If the JSON data is to be kept then it should have a well defined schema (even if that can't be validated directly) and, preferably, *not* base64 encoded (could you use a CDATA block instead?) for transparency.
|