sp signingAlg and digestAlg defaults and setting explicit values

[Paul B. Henson]

I had a client reach out that runs the shibboleth SP. Evidently one of 
the idp's he interoperates with complained that he was still signing 
logout requests with SHA1, which they no longer support.

Looking into it, I see that the documentation at the ApplicationDefaults 
level:

	https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2063695997/ApplicationDefaults


documents the default for signingAlg as RSA-SHA256 and the default for 
digestAlg as SHA256. However, the documentation for RelyingParty:

	https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334363/RelyingParty


documents the defaults as RSA-SHA1 and SHA1. That clearly can't be 
right, as adding a relying party override that doesn't specify those 
attributes surely won't change the settings to different defaults.

Empirically, for an SP not specifying either attribute working with an 
idp without the algsupport extension in its metadata, it appears to use 
RSA-SHA1 as the signature algorithm and SHA256 for the digest algorithm. 
  So evidently each documentation page is half right ;).

When interoperating with an idp that does document its supported 
algorithms, and no explicit configuration is present on the SP side, it 
appears to choose the best available option that is supported on both 
side; in particular when tested against the shibboleth idp, it chose 
RSA-SHA512 and SHA256.

Unfortunately, while explicitly specifying for example:

	signingAlg="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"

in the application defaults element will cause it to use RSA-SHA256 
instead of RSA-SHA1 with an idp that specifies no supported algorithms, 
it also prevents use of any better algorithm that the sp would have 
otherwise chosen in the case where an idp does list better supported 
algorithms.

It also forces it to use RSA-SHA256 even if idp metadata does not 
include it as a supported algorithm :(, whether that is because an idp 
only supports the older SHA1 or newer SHA384/512.

Is there some way I am missing that would allow you to set the "default" 
algorithm the same way that the "default" of not setting anything it all 
works, which would make it use said default if nothing better could be 
negotiated, but still use a better algorithm if available, or one that 
the idp actually supported if the "default" was not in that list?

I see in the schema that these attributes are defined as a single URI:

     <attribute name="signingAlg" type="conf:anyURI"/>
     <attribute name="digestAlg" type="conf:anyURI"/>

Theoretically if they were defined as a list:

   <simpleType name="listOfURIs">
     <list itemType="conf:anyURI"/>
   </simpleType>

more flexibility might be availed of.

At this point it seems the only option is to hardcode a single specific 
algorithm as the new default, and then add explicit overrides for any 
relying party that requires something else...

Thanks for any feedback.