So, let's see if we can build something from the ideas in the question and the ones collected in the comments.
While the plain keys for asymmetric signature schemes need to be quite long (longer than normal humans can memorize), creating an asymmetric key pair from a password is doable [as pointed out by fgrieu in a comment]. Here is what Alice (or some program in her control) would do when first signing up:
Alice feeds the password and some other data, like her user ID (what Alice uses to login), system ID (an identifier for the server/system/...), system parameters, maybe some random salt from the user database, etc. as input to a key derivation function like PBKDF-2, bcrypt or scrypt, with suitable work factor so this takes as long as Alice is normally ready to wait whenever giving out a new authorization (this might be 10 seconds, for example), and obtain a 256-bit number $s$.
Alice uses this number $s$ as the seed to some (deterministic) cryptographically secure random number generator.
Alice uses the generator to generate a key pair. The exact procedure will depend on the algorithm in use - for RSA, Alice would generate two numbers $p$ and $q$, and check them for primeness (using more random numbers from the same generator) - if one of them turns out not to be prime, repeat. Then Alice creates their key pair from these in the normal way. (There are known standards for this, this is just a sketch.) For (EC)DSA or ElGamal, she just takes some random number $x$ from the generator, and calculates the public key $y = g^x$ in the group in use - nothing more to do.
She now gives the public key from this key pair to Bob (Bob is the "resource administrator" here.)
The private key will not be stored anywhere - whenever Alice needs it (e.g. to create a token), she will do this whole procedure again.
As all inputs are fixed and everything is deterministic, the key pair will only depend on the password (and Alice's user ID, so other users will have other key pairs).
How to create the token:
To generate a token, Alice takes all the necessary data together:
- Alice's user ID
- the ID $X$ of the resource which is to be accessed
- Some form of the validity time (could be the current date in the simplest form)
Hash these together, and sign it with the private key (recreated from the password as above).
Now encode enough of the information mentioned before (the user ID could be enough) together with the signature in a token, and hand this token to Charles.
Charles takes the token, and shows it to Bob to access some resource $X$.
How to check the token:
Bob gets the token (and the resource ID $X$), extracts the user ID, and looks up the Alice's public key (and checks if she is actually permitted to access the resource, and to authorize such access to others).
Then Bob hashes together the user ID, the resource ID $X$ and the current date. Then he checks (with Alice's public key) if the signature is a valid signature for this message, and only then allows Charles access to $X$.
This scheme is extensible to other validity time spans - either encode the validity date into the token, too, or let Bob check the last some days as input.
