- do not use the term 'cross-signing keys' anymore: Previously, the term
'cross-signing keys' was used to refer to the master, user-signing and
self-signing keys. This is not ideal since the master key is used for
cross-signing but may also be used to sign the backup key, for example.
In these contexts, the master key is not used for cross-signing.
The term 'cross-signing keys' has therefor been replaced by 'keys used
for cross-signing' or, more explicitely, by 'master, user-signing and
self-signing key'.
- the naming of the master key has been harmonised (no more 'master
cross-signing key' or 'master signing keys'). Also the abbr. 'MSK' has been
replaced by 'MK'.
- in the QR code example, the term 'cross-signing key' has been replaced
by 'master key' since in mode 0x00, the current user's own master key and
what the device thinks the other user's master key is used.
- it has been made more explicit that private keys used for cross-signing can
be stored on the server are stored as described in the secrets module (as
opposed to store them in unencrypted form)
Signed-off-by: codedust <codedust@so.urceco.de>
* Clarify that SSO login applies to the legacy authentication API
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Do not point to specific authentication API for obtaining access token
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add warnings about incompatibility with OAuth 2.0 to endpoints that use UIA
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add changelog
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Add note about API standards not applying to OAuth 2.0
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Apply suggestions from code review
---------
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Co-authored-by: Travis Ralston <travpc@gmail.com>
... and other improvements
Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
If an object definition already has an example, we shouldn't try to extend that
definition by adding examples derived from the individual properties. Doing so
is confusing, and there is no way to inhibit it when it is not desired. It's
also not what the RapiDoc viewere does, so we end up with examples being
inconsistent.
* Introduce a new "added-in" template and use it on endpoints
* Use "added-in" on schema properties too
* Annotate sections of the spec with their added versions
* Demo of "added-in" on a room version (to be fleshed out)
* Use clearer versioning semantics
* Update and fix validator for Swagger custom properties
* Fix docs
Historical note: this was originally a series of several commits, spread out
over several weeks. They have been squashed together to make `git annotate`
work properly.
The original commits were:
* 91ab3934 <Will> 2021-01-25 21:16:42 -0800 Add raw API end event schemas into /data directory
* aae22f47 <Will> 2021-01-25 21:33:06 -0800 Remove non-data files
* 1092d4ca <Will> 2021-01-26 20:41:33 -0800 Add data-compatiuble extension (.yaml) to all data files that currently omit one
* 21060109 <Will> 2021-01-26 20:57:28 -0800 Remove symlink to event-schemas, and update openAPI schema paths accordingly
* 4f633845 <Travis Ralston> 2021-04-12 21:54:54 -0600 Fix event schema examples too
* 301c7b2f <Will> 2021-02-05 10:15:42 -0800 Restore docs describing OpenAPI extensions that we use
2021-08-27 19:16:39 +01:00
Renamed from api/client-server/cross_signing.yaml (Browse further)
