1) Can you add something near the top of the document, to explain briefly at a high level what problem we are talking about? maybe what a federation proxy is, what they are used for, what kinds of problems they could cause, etc? I think this should be more clear. I sort of expected to find a paragraph that is something like the following. But I didn't. Is my paragraph close to what we're talking about? Even after reading the document, I am not really sure.

---

Federation Proxies are services that act as a middleman, authenticating users against federated organizations on one side and then sending an assertion to services on the other side. The downstream service trusts the proxy for identity information, which in turn trusts the federation IDPs.

Sometimes this might be done entirely within the federation, e.g. as a protocol translation layer (e.g. to enable eduoram wifi login, or perhaps SSH login, etc). This seems like a relatively safe use case.

In other cases, the proxy is used to supplement or change identity information coming from the authoritative institution, on its way to a service (still within the federation). This seems like a grey area in which one could imagine problems arisng e.g. when one is trying to debug inaccuracies in the assertion.

In yet other cases, a proxy might be used to log users from federation institutions into serivces that are outside the federation. This situation creates clear issues of trust, since those outside services were never vetted, never agreed to abide by the baseline expectations, are more likely to misuse student data that is sent to them, etc.

This document represents an attempt to think through some of these issues and make recommendations about best practices for mitigating the risks or addressing the problems.

---

2) The federation is all about trust. Organizations are vetted and agree to follow certain practices, as part of joining the federation. Once inside, they can be trusted at some baseline level by other federation members.

If someone sets up a proxy that functionally adds unvetted organizations to the federation, that seems like a direct breach of trust. My hot-take is that whoever set up that proxy should be removed from the federation. Maybe there are some use cases I am not thinking about here, but, this seems to be the core issue at stake here and it seems incongruous that problem is just sort of briefly discussed in an appendix. Am I thinking about it wrong?

3) I appreciate the recommendation that federation proxies should self-identify in metadata. This seems like a pragmatic middle ground.

To build on this, perhaps we could:

Add different metadata flags for different types of proxy behavior (e.g. one flag for simple protocol translation, another for proxying to non-federation services);

Add configuration options in Shibboleth IdP (and other IdP software) to control attribute release based on these proxy flags;

Default these controls to not release attributes to proxies that indicate they forward data to unvetted organizations;

Allow institutions to opt-in to trusting such proxies if they choose to.

This way, institutions can make informed decisions about whether to trust different types of proxies, rather than having it be an all-or-nothing proposition. It also creates natural pressure for proxy operators to be transparent about their practices, since failing to properly identify as a proxy would be a clear violation of federation policy.

The "transparency of practices" section indicates information must be published, but then provides a big loophole in footnote 4.

Are the details required or not?  (Thinking an explicit minimum needs to be specified....)

Does the informationURL have to be "public" content, or can there be an "authenticated" version (either in place of or in addition to public content)?

(I'm old enough to remember when "whois" information was actually useful....  )