This creates two generic parameters, String and E. The String generic parameter there has no relation to the standard library std::string::String type.
Therefore when you write trait Deserialize<Vec<u8>, E> that is equivalent to trait Deserialize<A<B>, E> which of course is invalid syntax.
Rust doesn't have trait specialisation, at least yet (and if it did you would near certainly hit the orphan rule here, and you don't own either the trait or argument)
You should be able to get pretty close with a new blanket implemented trait, though (untested, I'm on a phone):
trait MyDeserialize<E>: Deserialize<Vec<u8>, E> {}
impl<E> MyDeserialize<E> for Deserialize<Vec<u8>, E> {
// default implementations here
}
This would be error in Rust 2021 and not what the asker wants anyway, since it's equivalent to impl<E> MyDeserialize<E> for dyn Deserialize<Vec<u8>, E>. One might want this instead:
impl<E, T: Deserialize<Vec<u8>, E>> MyDeserialize<E> for T {
// default implementations here
}
In this case, you know that PrivKey: Deserialize<Vec<u8>, Error> for some Error, so you simply do impl MyDeserialize<Error> for PrivKey while having this Error in scope.