Currently, signature schemes are limited to data, with the client knowing who delegated it where and how. This is a problem if a consuming server is nosy and wishes to grant colluding servers a benefit or enemy servers a downside.
I suggest having an "adaptive" signature type--initially empty due to standardization problems--that allows ZK proofs to encapsulate delegation instead of signatures. The naming of "adaptive signatures" is to emphasize that they are ZK proofs of both a secret key and a parent delegation and that still authenticate data, and also so developers can understand it more effectively.
See #6 for prior exploration
Currently, signature schemes are limited to data, with the client knowing who delegated it where and how. This is a problem if a consuming server is nosy and wishes to grant colluding servers a benefit or enemy servers a downside.
I suggest having an "adaptive" signature type--initially empty due to standardization problems--that allows ZK proofs to encapsulate delegation instead of signatures. The naming of "adaptive signatures" is to emphasize that they are ZK proofs of both a secret key and a parent delegation and that still authenticate data, and also so developers can understand it more effectively.
See #6 for prior exploration