Moved over from @poettering's post in NixOS/rfcs#59 (comment):

BTW, I thought about a creds concept in systemd the past weeks. It's a big topic, but this is what I'd probably propose in systemd:

1. Introduce a new setting per service setting LoadCredential=<name>:<path> for loading a credential off disk. The name is some user chosen ID, the path is some file system path to load the credential from.
2. Similar, add PassCredential=<newname>:<oldname> which takes a credential systemd itself received (think: pid1 in a container gets some creds from the container manager, or systemd --user from its parent).
3. Similar, add AskCredential=<name> for querying a credential from the user via the systemd-ask-password framework.
4. Then, add CredentialMode= for configuring how to pass credentials to the service. Can be a combination of options: file (pass as file in the fs), keyring (for kernel keyring), fd (for passing as fd via socket activation). We'd default to file and keyring. We should be graceful here, i.e. if keyring cannot work (because we are in a container where kernel keyring is blocked), use only the fs. We'd always attempt to pass all configured creds through all methods in parallel.
5. Then, let's add CredentialDirectory=, similar to RuntimeDirectory= and its friends, for defining a subdir of /run/credentials/ to pass the creds in in case file mode is used. There'd be $CREDENTIAL_DIRECTORY (again, similar to $RUNTIME_DIRECTORY and friends) we'd set for services to the resulting dir)
6. When passing via file system, we'd mount a ramfs (and not a tmpfs!) to /run/credentials// and place the creds there. ramfs has the benefit of never being swapped out. needs graceful fallback logic to using the dir without mount however, to cover for containers. we'd populate the fs atomically, and keep it read-only afterwards.
7. We'd never pass creds in env vars, they suck since they propagate down the process tree, even to suid programs.

everything passed will be immutable and only accessible to the user of the service, nothing else. there'd be no API for dynamically requesting more creds.