key rollover when keyname present

[Cantor, Scott]

> the current keyname is in place because of hard-coded usage of it
> within the config.... that usage including signing and encryption.
> would using a Chaining definition work for this eg

I don't believe so. If it's not documented as supporting that setting, then it's not supported.

I don't believe the RelyingParty keyName setting is used to derive decryption keys, in which case my original statement stands: there's no reason to need to overload two credentials with the name to change the key.

The name just matters for signing, and really that should only come into play for making attribute queries. If you're forced to support SAML 1 and old Shibboleth IdPs, I guess that still matters, but a SAML 2-only SP really doesn't need a signing key, and shouldn't need named keys in the configuration.

I could probably advise better if I understood the use case.

-- Scott