Assume I am working with crypto that supports hierarchical deterministic key generation, Bitcoin/Ethereum keys using secp256k1 is one example.
There is a decentralised key registry where users register their public keys for use and other users retrieve those public keys for verificaton. A similar setting could be a blockchain where users transfer coins to other people's public keys.
Now I want to support key revocation as if a user's private keys are stolen he can revoke corresponding public keys. The idea is that the user uses hierarchical deterministic key generation. The parent key is heavily guarded in maybe in a cold storage and its children keys are used for regular usage. It is the child public keys that are put on the registry. You use a knowledge of a parent (private) key to prove control over child keys to the registry and ask the registry to revoke child keys. The registry will verify that the child key is indeed derived from the parent key (can be done using this) and the revoker has the parent private key.
eg. Alice generates a parent keypair $A$ with secret and public keys as $A_s$ and $A_p$ respectively that it never uses apart for child key generation and keeps in a very secure storage. Now whenever Alice wants to create a new child key, it uses the parent key $A$. Say it 2 child keys based on keypair $A1$ ($A1_s$, $A1_p$) and $A2$ ($A2_s$, $A2_p$). Now it loses the wallet containing $A1$ and $A2$. Alice will not provide a signature to the registry using the private key $A_s$ and asking the registry to revoke $A1$ and $A2$. The registry checks that $A1$ and $A2$ are derived from $A$ and hence revokes.
As the answer below shows, this scheme is not useful as revoking a child key enables the possesor of any child private key to know the parent private key.