Page History

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 data URL allows the same base64 embedding as the current proposal at the cost of a few more characters
- Linking to a remote file is more efficient and allows faster updates to the filter or even dynamic filter policies

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
- Multiple values allow migration between different filter formats or versions

These changes also make it easier to define the initial filter format specification because it is no longer so tightly coupled to the metadata.

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?

Marco Malavolti, GARR

The intention of this entity attribute specification is only to define a container for selection rules. We expect the metadata consumers to define the selection rules in detail.

The examples in the specification are, therefore, not intended to define a standard for the rules, nor be a comprehensive reference. We provided an example from SeamlessAccess because several people on the working group are stakeholders in SeamlessAccess. The remainder of the examples show incorrect usage. They provide a set a failing test cases for implementers to incorporate into their testing process.

We note that the authors of the original "Metadata Extension Schema for SAML V2.0 Trust Information 1.0" defined a way to select individual IdPs. We anticipate that metadata consumers of the entity selection profile will also provide a way to explicitly select IdPs.

Acton item: we will update the examples to clarify that the entry for SeamlessAccess is one example of the format for the entity attribute.

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?

Terry Smith, AAF

Please see our response to 2.

The guidelines are the responsibility of the metadata consumers. We do also note the benefit of a consistent filtering language. The REFEDS draft workplan for 2025 proposes additional work for 2025 to determine composition rules for filters, by which we mean creating a consistent set of rules. The definition of an entity attribute as a container should allow these rules to be developed without having to coordinate schema updates.

Note that SeamlessAccess has written a page which defines how to use their own selection rules: https://seamlessaccess.atlassian.net/wiki/spaces/DOCUMENTAT/pages/1397686273/Filtering+search+results+-+indicating+which+IdP+s+are+supported.

Will there be a verification or test tool or example of such that will provide a warning if the decoded value does not conform?

Terry Smith, AAF

Please see our response to 2.

As we expect metadata consumers to define the contents of the entity attribute, we also expect them to provide verification and testing tools.

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.

Matthew Slowe, UK federation