Inconsistent requirement to provide issuer in Fetch and Subordinate Listings endpoints

[Razumain]

Both these endpoints are targeted at Federation Entities that issue Entity Statements for subordinates.

In one of the endpoints (Fetch) you MUST provide "iss" to clarify which issuer that is targeted. The rationale for this is said to be:

Because of the normalization of the URL, multiple issuers MAY resolve to a shared fetch endpoint. This parameter makes it explicit exactly which issuer the Entity Statement must come from.

But the same logic is not applied to The Subordinate Listings endpoints, and that appears inconsistent. This argument seems equally true in both cases.

I would argue that "iss" is redundant in both cases. If you have to provide your own endpoint for Subordinate Listings, it makes no sense to have a shared endpoint for Fetch. And I would argue that a shared endpoint for fetch makes no sense as it would require these services to share databases and signing keys.

I really can't see a compelling use-case where "iss" is not redundant.

I suggest that "iss" is removed from the request, or at least made optional. If no issuer is provided the responding endpoint simply returns an Entity Statement for one of its own subordinates, or an error code if not found.

One more nit. Why is the endpoint called "Listings" endpoint while it is called "Listing" request. All other "Listing" endpoints such as Trust Mark Entities Listing have no trailing "s".

[peppelinux]

I remember when I made the same question, asking about this kind of ambiguity related to the parameter iss provided in the fetch request.

the answer that addressed my question was that a fetch endpoint might be used for proxying purposes, and that made sense.

A lot of water passed under the bridge and in particular the born of the resolve endpoint addressed all about proxying.

At the current stage, I can say that the iss parameter is not interesting anymore as it was before the draft number 24, and therefore we might start thinking to get it out from the specs

[Razumain]

Thanks for providing context. I'm happy removing it. Reiterating that if it is kept, then at least consider making it optional.

[rohe]

Yes! This you could say is a historical artefact. Way back when there where person/persons interested in the draft that felt that having specialised services providing for instance listing to federation entities was viable services.

Today, I think that the support for that kind of services has waned.

So, I support getting rid of it.

[selfissued]

Roland to create PR removing "iss" from the Fetch endpoint and the text about error conditions related to the "iss" value.