matrix-spec-proposals/proposals/2874-single-ssss.md

# MSC2874: Single SSSS

[Secure Secret Storage and
Sharing](https://github.com/matrix-org/matrix-doc/pull/1946) (SSSS) was
designed to allow the user to create multiple keys that would be able to
decrypt different subsets of the secrets.  However, the vast majority of users
do not need this feature.

This proposal defines how clients should behave if they only wish to support a
single key, by defining which key clients should use if multiple keys are
present.  It also makes the `name` field in the `m.secret_storage.key.*` events
optional, as this field was mainly added to allow a user to select between
different keys.

## Proposal

If a client wants to present a simplified interface to users by not supporting
multiple SSSS keys, then the client should use the default key (the key listed
in the `m.secret_storage.default_key` account data event.)  If there is no
default key the client may behave as if there is no SSSS key at all.  When such
a client creates an SSSS key, it must mark that key as being the default key.

The `name` field in the `m.secret_storage.key.*` account data events is
optional, rather than required.  If a client wishes to display multiple keys to
a user and a given key does not have a `name` field, the client may use a
default name as the key's name, such as "Unnamed key", or "Default key" if the
key is marked as default.

For example, when a client creates a key with ID `abcdefg`, it will create an
`m.secret_storage.key.abcdefg` account data event to store information about
the key.  It will then mark it as the default key by setting the
`m.secret_storage.default_key` account data to `{"key": "abcdefg"}`.  When
another client logs in after this, it will see that the default key has been
set, and will know to use that key as the SSSS key.

## Potential issues

If secrets are encrypted using a key that is not marked as default, a client
might not decrypt the secrets, even if it would otherwise be able to.

## Alternatives

Rather than solely relying on the key marked as default, a client could guess
at what key to use.  For example, it could look at the secrets that it needs,
see what keys they are encrypted with, and if there is only one common key,
then it could use that.  (This is what Element currently does.)  Or if there
are multiple keys, it could use some sort of heuristic to pick a key.  However,
this approach can be error-prone, and it is better to rely on an explicit
marking.

## Security considerations

None

## Unstable prefix

An unstable prefix is not needed for a behaviour change in choosing the key to
use as there are no event/endpoint changes.

Some clients already omit the `name` field (notably, matrix-js-sdk
unintentionally does this -- mea culpa), and this does not seem to be causing
issues, so an unstable prefix seems unnecessary for this.