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

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

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

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