Interest of NameIDFormat in entity metadata

[Peter Schober]

* Guillaume Rousse via users <users at shibboleth.net> [2022-12-09 14:06]:
> The only use case I see would be to help an IdP supporting multiple
> formats to select the correct one in its response, if the SP
> explicitely mention what it wants in its metadata.

The simple alternative to any NameIDFormat elements in metadata (for
either the IDP or the SP) would be the SP always requesting a specific
format in its authentication request. But since the intersection of
supported NameIDFormats across IDPs is essentially empty an SP
intending to interoperate widely cannot ever request a specific
format.
To me it also makes sense to have the IDP pick the format since some
formats are more intrusive than others (e.g. emailAddress
vs. persistent) and the SP generally has no incentive to request a
more privacy-preserving one.

> But I don't see the need for an IdP to enumerate supported formats,
> for instance, at least for automated processing.

Well, if all/most IDPs enumerated their supported formats an SP could
dynamically request a specific format from an IDP's set of supported
ones but IDP's don't generally do (publish) that and therefore SP's
don't (determine this dynamically), either.

More importantly, though, all of this is moot with saml2int v2
https://kantarainitiative.github.io/SAMLprofiles/saml2int.html
where the only NameIDFormat left is transient and that only if you
needed to support SLO. I.e., with saml2int NameIDs are a thing of the past.
(At least going forward and to the degree that saml2int is relevant
for the entities involved.)

-peter