Considering that this parameter would be at the end informational only, I approve it for the scopes proposed.

Last time when we discussed this (and I was present), there were two solutions.

Both solutions have this metadata parameter, that lists the supported JWS algs for entity statements.

The difference is:

1. Entities Statements can be signed with any of the supported JWS algs. There is no method to request the issue of an Entity Statement with a given JWS alg. This means consumers must be prepared to handle all JWS algs that are supported.

2. Entity Statements are normally signed with a default JWS alg, but there is also the possibility to request a specific JWS alg using a query param like jws_alg=ES256. With that consumers have a mean to control the signature algorithm.

Solution 1 seems simpler, in terms of specification and API.

Solution 2 has the benefit that in multi anchored / lateral federations, where one of the federations supports additional JWS algs, but the algs still intersect (there is a commonly supported JWS alg, like RS256), consumers will be able to collect Entity Statements with an alg that they can work it. Otherwise they won't be able to do this.

As discussed on today's Federation editors' call, we would want actionable guidance on how and when to use this parameter before including this feature in the specification.