Define entity_statement_signing_alg_values_supported metadata parameter

[selfissued]

Fix #65

Cc: @Razumain

[vdzhuvinov]

On its own, the definition of this parameter is okay. However, having this parameter parameter defined would not be sufficient for the entities in a federation to be able to use a specific JWS algorithm when more than one is supported. People will ask - what do we do with this parameter? How do I get an ES signed with say ES256 when RS256 and ES256 are supported?

[peppelinux]

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

[vdzhuvinov]

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.

[selfissued]

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.