Digest and signing are different operations. We should not mix them together. This should be configured separately for the two.

The metadata is just declaring something. We should prohibit actually using the algos when they are going to be used to sign docs or create digests.

Digest and signing are different operations. We should not mix them together. This should be configured separately for the two.

I understand but they are xmlsec's algs, so we could handle them in a unique parameter. This will simplify user's approach.. but somethings sounds to me that this solution won't like to you :)
It can be done both ways, just discuss it together first.

The metadata is just declaring something. We should prohibit actually using the algos when they are going to be used to sign docs or create digests.

I agree and this is just a basic implementation to start from. I saw how xmlsec is used in pysaml and I think that it would be better to handle this new born parameter together with the upcoming (?) xmlsec-handler refactor. Have you already choose a xmlsec API handler? This would be the point to start from, coupling in it this PR

I'd also put some reference here as personal notes:

• sigver.CryptoBackendXmlSec1.init, actually do not handle config directly but takes **kwargs;
• sigver.security_context, get configuration as paramenters. In it calls sigver.security_context that initialize sigver.CryptoBackendXmlSec1
• entity.Entity.sign get sign_alg and digest_alg as arguments (validate these in relation to blacklist)
• entity.Entity().sec = security_context(self.config)

Also:
sigver.SecurityContext().metadata handles metadata...

pyXMLsecurity is an alternative to xmlsec1, just need to have an example

https://github.com/IdentityPython/pyXMLSecurity

it only have signing features and no crypto:
https://github.com/IdentityPython/pyXMLSecurity/blob/master/src/xmlsec/crypto.py