Secondary private key that produces limited certificates I want some notion of a secondary key that behaves like this:

Given a public/private key pair, it is not the private key but rather it is once-removed from it. Like the original private key, it is also not public. Unlike it, it was made for a specific purpose (a string) and has expiration.

The secondary key can produce certificates that prove that the certificate-maker has that secondary key, that the secondary key was produced using the original private key belonging to some public key, for some purpose (a string) with expiration limit, and the token produced is within the expiration limit.

When a user which owns a private key produces a secondary key, they essentially say "I grant the carrier of this token permission to act as me for this purpose for this period of time".

What am I looking for?

Some clarification:

The bearer of the secondary key is some half-trusted code in the user's PC. It cannot carry any secrets other than the secondary key, and it uses it with other users, which are also not trustworthy, so this code cannot pass the secondary key to them, so it needs to be able to generate new certificates from it.

So in diagram it is $A \rightarrow c \rightarrow B$, meaning Alice installs some software $c$ she wants to handle her banking stuff, so she grants a secondary key to $c$ that says they can impersonate her when it comes to banking stuff for a certain amount of time. The code $c$ then interacts with some other user, Bob, producing certificates that means it represents Alice when it comes to banking.

In addition there is no external authority, so everything must be validated locally.
When a user which owns a private key produces a secondary key, they essentially say "I grant the carrier of this token permission to act as me for this purpose for this period of time".


You could use the original private key to sign that message exactly.

The original keyowner Alice signs a message encoding "The carrier of this signed message has permission to act as me (id/pubkey:XXX) with caveats A,B,C (ie. permissions to _, expires at _)", and gives that signed message to Bob. Bob can now make requests to the server and include that signed permission slip in his requests as his authorization to act as Alice.

You could then change the design to be freely re-delegatable by making the message instead be "The user identified as id/pubkey:YYY has permission to act as me (id/pubkey:XXX) and delegate with caveats ...". Alice can create a message like this specifying Bob's public key as YYY, and give the message to Bob. Bob could make requests to the server including this signed message as his authorization, but could also create his own version of this to delegate permission to Alice's account to Charlie. Bob would give Charlie this new message and Alice's original signed message. Charlie could then make requests to the server and present a chain of messages showing the delegation of permission to Alice's account from Alice to Bob to Charlie.

This final design is pretty much equivalent to Macaroons (see also the answer of cypherfox) with the bonus that anyone could verify the permission slips, not just the server. But if you don't need that, macaroons are likely to be much more compact than using asymmetric crypto.