Several places in the Connect suite  have language that says the jwk/x509_url can also be used for encryption keys, if the jwk/x509_encryption_url isn't provided or registered.
I suggest we drop this fallback option and explicitly require encryption keys to be provided or registered when encryption is used. Two main reasons for this:
1) While I imagine the fallback approach was intended as a simplification, it actually makes most implementations more complicated as they need to support two ways of finding the keys. A wise man recently said, "having two ways to do something almost always hurts interop and always makes implementations bigger" . I wholeheartedly agree and say Connect should have only one way.
2) More importantly, using the same key for signing and encryption is terribly insecure. I'm no cryptographer but am told this concern is no longer just theoretical and will point out that the W3C XML SEC folks recently published some best practices including an explicit recommendation to use distinct keys for different operations  citing signature forgery as a potential consequence of ignoring the recommendation.
Yes, Connect does recommend against it (to varying levels) but signature forgery is really bad. Despite the few SHOULDs suggesting that separate keys be used, just having the option of dual use is tacitly approving of it at some level. Let's just get rid of that.
 These 3 at least and maybe more: http://openid.net/specs/openid-connect-messages-1_0-15.html#sigenc.key http://openid.net/specs/openid-connect-discovery-1_0-12.html#ProviderConfigurationResponse http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegistration
 and that man was our very own Mike Jones
 XML Signature Best Practice 27: Signers: When encrypting and signing use distinct keys http://www.w3.org/TR/xmldsig-bestpractices/#signers-separate-keys