website/docs: update docs

Signed-off-by: Jens Langhammer <jens.langhammer@beryju.org>

website/docs/events/notifications.md

@@ -33,3 +33,5 @@ You have to select which group the generated notification should be sent to. If
 
 You also have to select which transports should be used to send the notification.
 A transport with the name "default-email-transport" is created by default. This transport will use the [global email configuration](../installation/docker-compose#email-configuration-optional-but-recommended).
+
+Starting with authentik 2022.6, a new default transport will be created. This is because notifications are no longer created by default, they are now a transport method instead. This allows for better customization of the notification before it is created.

website/docs/flow/stages/authenticator_webauthn/index.md

@@ -5,7 +5,3 @@ title: WebAuthn authenticator setup stage
 This stage configures a WebAuthn-based Authenticator. This can either be a browser, biometrics or a Security stick like a YubiKey.
 
 There are no stage-specific settings.
-
-:::warning
-Currently, the WebAuthn stage does NOT support Apple FaceID and Android Fingerprint/SafetyNet.
-:::

website/docs/releases/v2022.6.md

@@ -11,6 +11,18 @@ slug: "2022.6"
 
     These fields can be used to automatically configure OAuth Sources based on the [OpenID Connect Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html). Additionally, you can manually define a JWKS URL or raw JWKS data, and this can be used for Machine-to-machine authentication for OAuth2 Providers.
 
+-   Notifications are no longer created by default
+
+    Instead of creating a Notification with each transport, there is now a new Transport mode called "Local", which locally creates the Notifications. This also adds the ability to customize the notification using a mapping.
+
+-   Database-based sessions
+
+    Sessions have been migrated from the database, where as they previously were stored in the cache. This has a slight performance hit, however fixes random issues cause by non-atomic session changes.
+
+-   MFA Validation threshold has been migrated to signed cookies
+
+    Last MFA validation is now saved in a signed cookie, which changes the behavior so that only the current browser is affected by MFA validation, and an attacker cannot exploit the fact that a user has recently authenticated with MFA.
+
 ## Minor changes/fixes
 
 ## Upgrading