diff --git a/configuration/token-formats.md b/configuration/token-formats.md
index ccb69fe..0356788 100644
--- a/configuration/token-formats.md
+++ b/configuration/token-formats.md
@@ -1,8 +1,9 @@
 # Token formats
 
 > [!NOTE]
-> In OpenIddict 3.0, being able to revoke a token is not tied to the token format and doesn't require enabling reference tokens:
-> regular JWT or ASP.NET Core Data Protection tokens can be revoked as long as token storage is not explicitly disabled by the developer
+> In OpenIddict 3.0, the ability to revoke a token is not tied to the token format and doesn't require enabling reference tokens:
+> regular JWT or ASP.NET Core Data Protection tokens can be revoked as long as token storage is not explicitly disabled in the server options.
+>
 >
 > For more information about reference tokens, read [Token storage](token-storage.md).
 
@@ -42,15 +43,15 @@ OpenIddict 3.0 can also be configured to use [ASP.NET Core Data Protection](http
 Data Protection tokens instead of JWT tokens. ASP.NET Core Data Protection uses its own key ring to encrypt and protect tokens against tampering and is supported for all
 types of tokens, except identity tokens, that are always JWT tokens.
 
-Unlike JWT, ASP.NET Core Data Protection tokens only support symmetric encryption and rely on a binary format developed by the ASP.NET team rather than on a standard like JWT.
+Unlike JWTs, ASP.NET Core Data Protection tokens only support symmetric encryption and rely on a binary format developed by the ASP.NET team rather than on a standard like JWT.
 While this prevents using such tokens in scenarios where interoperability is needed, opting for ASP.NET Core Data Protection rather than JWT has actually a few advantages:
   - ASP.NET Core Data Protection tokens don't use a JSON representation and therefore are generally a bit shorter.
   - ASP.NET Core Data Protection has been designed to achieve high throughput as it's natively used by ASP.NET Core for authentication cookies,
   antiforgery tokens and session cookies.
 
 > [!WARNING]
-> Despite its name, ASP.NET Core Data Protection is not tied to ASP.NET Core and can be used in any
-> .NET Standard 2.0-compatible application, including legacy ASP.NET 4.x applications using `Microsoft.Owin`.
+> Despite its name, ASP.NET Core Data Protection is not tied to ASP.NET Core and can be used in any .NET Standard 2.0-compatible
+> application, including legacy ASP.NET 4.6.1 (and higher) applications using `Microsoft.Owin`.
 >
 > To enable ASP.NET Core Data Protection support in the OpenIddict OWIN server and validation hosts, you need to
 > manually reference the `OpenIddict.Server.DataProtection` and `OpenIddict.Validation.DataProtection` packages.
@@ -80,8 +81,8 @@ services.AddOpenIddict()
 > existing tokens can still be used alongside newly issued ASP.NET Core Data Protection tokens until they expire. When sending a refresh token request containing
 > a JWT refresh token, the application will receive an ASP.NET Core Data Protection refresh token and the previous one will be automatically marked as redeemed.
 
-By default, enabling ASP.NET Core Data Protection support will automatically switch the token format from JWT to Data Protection for all tokens, except JWT tokens.
-The OpenIddict/Data Protection integration can be configured to prefer JWT when creating new tokens, **which can be useful to use the ASP.NET Core Data Protection
+By default, enabling ASP.NET Core Data Protection support will automatically switch the token format from JWT to Data Protection for all types of tokens, except JWT tokens.
+The OpenIddict/Data Protection integration can be configured to prefer JWT when creating new tokens, **which can be useful when using the ASP.NET Core Data Protection
 format for specific token types only** (e.g for authorization codes and refresh tokens, but not for access tokens).
 
 ```csharp
@@ -99,7 +100,7 @@ services.AddOpenIddict()
 
 > [!WARNING]
 > When the authorization and API/resource servers are not part of the same application, ASP.NET Core Data Protection MUST be configured to use
-> the same application name and share the same key ring to allow OpenIddict validation's handler to read ASP.NET Core Data Protection tokens
+> the same application name and share the same key ring to allow the OpenIddict validation handler to read ASP.NET Core Data Protection tokens
 > generated by an authorization server located in another project.
 >
 > For more information, read [Configure ASP.NET Core Data Protection](https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview).
\ No newline at end of file
diff --git a/configuration/token-storage.md b/configuration/token-storage.md
index 8c4ccdc..e881876 100644
--- a/configuration/token-storage.md
+++ b/configuration/token-storage.md
@@ -13,8 +13,8 @@ Such tokens – called reference tokens – are not returned as-is to the caller
 or with resource servers (if reference access tokens are enabled in the server options).
 
 > [!NOTE]
-> In OpenIddict 3.0, being able to revoke a token is not tied to the token format and doesn't require enabling reference tokens:
-> regular JWT or ASP.NET Core Data Protection tokens can be revoked as long as token storage is not explicitly disabled by the developer.
+> In OpenIddict 3.0, the ability to revoke a token is not tied to the token format and doesn't require enabling reference tokens:
+> regular JWT or ASP.NET Core Data Protection tokens can be revoked as long as token storage is not explicitly disabled in the server options.
 
 ## Enabling reference access and/or refresh tokens
 
diff --git a/docfx.json b/docfx.json
index 1a2b948..1a5b669 100644
--- a/docfx.json
+++ b/docfx.json
@@ -38,7 +38,9 @@
     "globalMetadataFiles": [],
     "globalMetadata": {
       "_appFaviconPath": "images/favicon.ico",
-      "_appLogoPath": "images/logo.png"
+      "_appLogoPath": "images/logo.png",
+      "_appName": "OpenIddict",
+      "_disableSideFilter": true
     },
     "fileMetadataFiles": [],
     "template": [
diff --git a/index.md b/index.md
index 7da06c4..a98add5 100644
--- a/index.md
+++ b/index.md
@@ -3,8 +3,8 @@
 
 # OpenIddict: the OpenID Connect stack you'll be addicted to
 
-OpenIddict aims at providing a **versatile solution** to implement an **OpenID Connect server and token validation in any ASP.NET Core 2.1, 3.1 and 5.0 application**,
-and starting in OpenIddict 3.0, **any ASP.NET 4.x or OWIN application too**.
+OpenIddict aims at providing a **versatile solution** to implement an **OpenID Connect server and token validation in any ASP.NET Core 2.1 (and higher) application**.
+**ASP.NET 4.6.1 (and higher) applications are also fully supported thanks to a native Microsoft.Owin 4.2 integration**.
 
 OpenIddict fully supports the **[code/implicit/hybrid flows](https://openid.net/specs/openid-connect-core-1_0.html)**, the **[client credentials/resource owner password grants](https://tools.ietf.org/html/rfc6749)** and the [device authorization flow](https://tools.ietf.org/html/rfc8628). You can also create your own custom grant types.
 
diff --git a/templates/discordfx/partials/li.tmpl.partial b/templates/discordfx/partials/li.tmpl.partial
index 2c8a3d0..3317805 100644
--- a/templates/discordfx/partials/li.tmpl.partial
+++ b/templates/discordfx/partials/li.tmpl.partial
@@ -11,7 +11,7 @@
             <a href="{{topicHref}}" class="sidebar-item" name="{{tocHref}}" title="{{name}}">{{name}}</a>
           {{/topicHref}}
           {{^topicHref}}
-            <a>{{{name}}}</a>
+            <a class="sidebar-item" name="{{tocHref}}" title="{{name}}">{{{name}}}</a>
           {{/topicHref}}
         
         {{^leaf}}