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.

Both parts of this response demonstrate the tension between generality and specificity. Our intention is to be as specific as possible whilst allowing the flexibility to evolve the syntax of selection rules.

1) Allowing https URLs values would require metadata consumers to consider another trust model, as you describe. Transporting selection rules directly in SAML metadata, on the other hand, leverages the trust, caching, and resilience of the current metadata distribution system. Nevertheless, we think that metadata consumers might wish to de-reference a URL so we will relax the restriction on the decoded value of the attribute being a JSON element, so metadata producers can embed an encoded URL directly.

Adding data URLs requires a few more characters, as you say. It also requires metadata consumers to add code to remove those characters, and invites generalisations to other schemes. As we have decided not to allow https: scheme URLs directly in metadata, it doesn’t add much value on its own.

Action item: we will retain the restriction that the entity attribute is a base64 encoded value, although we will relax the restriction that the encoded value must be JSON and allow arbitrary content dependent on the metadata consumer.

2) To achieve the benefits you describe, the metadata consumer must query the contents of all attribute values to determine the appropriate attribute. However, if an entity was targeting more than one metadata consumer, there would need to be a way of namespacing the contents so that similar filtering rules are not processed by the wrong consumers. This would go against the intention of making as few restrictions on the content of the attribute as possible.

A straightforward way out of this dilemma is to narrow the scope of the entity attribute to IdP discovery, to assume that an SP will only configure one discovery service, and to require a single instance of the attribute. In the early stages of this working group, we tried to generalise the earlier "trustinfo" work and faciliate other concrete use cases for entity selection. We asked for suggestions online and in face-to-face meetings, but had no success. So the working group considers that we should return to the original scope of IdP discovery. If another use case does arise, another entity attribute can be defined.

As we have decided to relax the requirement that the raw value must be JSON, we allow metadata consumers to define their own versioning or formats.

We will not change the name of the entity attribute. The name is not wrong; it’s just too general. And there are already five organisations registering or consuming the metadata, so we do not want to incur the cost of change.

Action item: we will change the definition of the entity attribute from generalised entity selection to IdP discovery. We will continue with the restriction to a single instance of this entity attribute. We will retain the name of https://refeds.org/entity-selection-profile.

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.

Action Item: we will explicitly note that that the syntax and semantics of the decoded value are defined by the metadata consumer.

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

We operate in a mature ecosystem where many actors have little capacity for change. The working group want to make the smallest possible intervention to gain a benefit.

This work does not require any change to how entity attributes work; we know that the eduGAIN metadata publication service allows entity attributes to flow unhindered; and we know that federations can produce and consume entity attributes. Other changes to metadata content are a hostage to fortune.

We also want to be able to experiment with the syntax of the filtering rules. Defining an entity attribute as a neutral container and requiring the metadata consumer to define the syntax and semantics for the payload should facilitate that.