That section of the serial-vault is related to System-User Assertions.
When you do a fresh install of snappy on a device, it does not give you a user that you can login to the device as. The idea behind the System-User Assertion is that it allows for a system-user to be created on a device that is unmanaged i.e. hasn’t had a system-user created.
The Serial-Vault provides a form that allows a system-user assertion to be created for the device and provides a convenient file download so you can copy the file to a USB stick. Then, reboot the device with the USB stick and it will generate the user for you.
To create a valid system-user assertion for a device, a number of things are needed:
- Username and password of the user to be created
- Account assertion
- Account key assertion
- A signing key that has been registered with the store
The account assertion and account key assertion are documented on the main site, so I won’t repeat the info here. The Serial-Vault caches those assertions in the database and there is a command-line utility with the serial-vault that allows you to download them from the store (account-assertions command). However, we are refactoring the various commands into a singe serial-vault-admin command. The idea is that you can run the “serial-vault-admin account cache” as a cron and that will keep your various accounts and account-key assertions up-to-date within the database cache.
The signing key must be a passwordless signing key that has been registered with the store - similar to the “serial” key that is mentioned in the post your referred to. You can use the same key for multiple things, but it is probably better practice to have one key per function.