Fix a bunch of typos

IdentityServer/v5/docs/content/fundamentals/resources/isolation.md

@@ -105,7 +105,7 @@ redirect_uri=...&
 resource=urn:invoices
 ```
 
-Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another round-trip to the token endpoint.
+Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another roundtrip to the token endpoint.
 
 ```
 POST /token

IdentityServer/v5/docs/content/quickstarts/0_overview.md

@@ -4,7 +4,7 @@ date: 2020-09-10T08:22:12+02:00
 weight: 1
 ---
 
-The quickstarts provide step by step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order.
+The quickstarts provide step-by-step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order.
 
 * adding Duende IdentityServer to an ASP.NET Core application
 * configuring Duende IdentityServer

IdentityServer/v5/docs/content/quickstarts/1_client_credentials.md

@@ -4,7 +4,7 @@ date: 2020-09-10T08:22:12+02:00
 weight: 2
 ---
 
-The following quickstart provides step by step instructions for various common Duende IdentityServer scenarios. 
+The following quickstart provides step-by-step instructions for various common Duende IdentityServer scenarios. 
 These start with the absolute basics and become more complex as they progress. We recommend that you follow them in sequence.  
 
 To see the full list, please go to [Quickstarts Overview]({{< ref "0_overview" >}}).

IdentityServer/v5/docs/content/reference/endpoints/end_session.md

@@ -27,7 +27,7 @@ The URL for the end session endpoint is available via discovery.
 
     If a valid *post_logout_redirect_uri* is passed, then the client may also send a *state* parameter.
     This will be returned back to the client as a query string parameter after the user redirects back to the client.
-    This is typically used by clients to round-trip state across the redirect.
+    This is typically used by clients to roundtrip state across the redirect.
 
 
 ```

IdentityServer/v5/docs/content/reference/services/interaction_service.md

@@ -32,7 +32,7 @@ It is available from the dependency injection system and would normally be injec
     Used to create a *logoutId* if there is not one presently.
     This creates a cookie capturing all the current state needed for signout and the *logoutId* identifies that cookie.
     This is typically used when there is no current *logoutId* and the logout page must capture the current user's state needed for sign-out prior to redirecting to an external identity provider for signout.
-    The newly created *logoutId* would need to be round-tripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page.
+    The newly created *logoutId* would need to be roundtripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page.
 
 * ***GrantConsentAsync***
 

IdentityServer/v5/docs/content/ui/login/external.md

@@ -192,7 +192,7 @@ Typically, the *sub* value used to login the user would be the user's unique id
 
 ## State, URL length, and ISecureDataFormat
 
-When redirecting to an external provider for sign-in, frequently state from the client application must be round-tripped.
+When redirecting to an external provider for sign-in, frequently state from the client application must be roundtripped.
 This means that state is captured prior to leaving the client and preserved until the user has returned to the client application.
 Many protocols, including OpenID Connect, allow passing some sort of state as a parameter as part of the request, and the identity provider will return that state on the response.
 The OpenID Connect authentication handler provided by ASP.NET Core utilizes this feature of the protocol, and that is how it implements the *returnUrl* feature mentioned above.

IdentityServer/v5/docs/content/ui/logout/external.md

@@ -45,7 +45,7 @@ public IActionResult Logout(string logoutId)
 To redirect back to your IdentityServer after the external provider sign-out, the *RedirectUri* should be used on the *AuthenticationProperties* when using ASP.NET Core's *SignOutAsync* API.
 
 Recall that after we return, we must perform the other steps to complete the logout workflow.
-These steps require the context passed as the *logoutId* parameter, so this state needs to be round-tripped to the external provider.
+These steps require the context passed as the *logoutId* parameter, so this state needs to be roundtripped to the external provider.
 We can do so by incorporating the *logoutId* value into the *RedirectUri*.
 
 If there is no *logoutId* parameter on the original logout page request, we still might have context that needs to be round tripped.

IdentityServer/v6/docs/content/deployment/data_protection.md

@@ -29,7 +29,7 @@ builder.Services.AddDataProtection()
 ASP.NET's data protection keys are sometimes confused with IdentityServer's signing keys, but the two are completely separate keys with different purposes. IdentityServer implementations need both to function correctly.
 
 #### Data Protection Keys
-Data protection is a cryptographic library that is part of the ASP.NET framework. Data protection uses private key cryptography to encrypt and sign sensitive data to ensure that it is only written and read by the application. The framework uses data protection to secure data that is commonly used by IdentityServer implementations, such as authentication cookies and anti-forgery tokens. In addition, IdentityServer itself uses data protection to protect sensitive data at rest, such as persisted grants, as well as sensitive data passed through the browser, such as the context objects passed to pages in the UI. The data protection keys are critical secrets for an IdentityServer implementation because they encrypt a great deal of sensitive data at rest and prevent sensitive data that is round-tripped through the browser from being tampered with.
+Data protection is a cryptographic library that is part of the ASP.NET framework. Data protection uses private key cryptography to encrypt and sign sensitive data to ensure that it is only written and read by the application. The framework uses data protection to secure data that is commonly used by IdentityServer implementations, such as authentication cookies and anti-forgery tokens. In addition, IdentityServer itself uses data protection to protect sensitive data at rest, such as persisted grants, as well as sensitive data passed through the browser, such as the context objects passed to pages in the UI. The data protection keys are critical secrets for an IdentityServer implementation because they encrypt a great deal of sensitive data at rest and prevent sensitive data that is roundtripped through the browser from being tampered with.
 
 #### IdentityServer Signing Key
 Separately, IdentityServer needs cryptographic keys, called [signing keys]({{<ref "/fundamentals/keys">}}), to sign tokens such as JWT access tokens and id tokens. The signing keys use public key cryptography to allow client applications and APIs to validate token signatures using the public keys, which are published by IdentityServer through [discovery]({{<ref "/reference/endpoints/discovery">}}). The private key component of the signing keys are also critical secrets for IdentityServer because a valid signature provides integrity and non-repudiation guarantees that allow client applications and APIs to trust those tokens. 

IdentityServer/v6/docs/content/fundamentals/resources/isolation.md

@@ -105,7 +105,7 @@ redirect_uri=...&
 resource=urn:invoices
 ```
 
-Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another round-trip to the token endpoint.
+Which will return an access token for the invoices API and a refresh token. If you want to also retrieve the access token for the products API, you use the refresh token and make another roundtrip to the token endpoint.
 
 ```
 POST /token

IdentityServer/v6/docs/content/quickstarts/0_overview.md

@@ -5,7 +5,7 @@ date: 2020-09-10T08:22:12+02:00
 weight: 1
 ---
 
-The quickstarts provide step by step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order.
+The quickstarts provide step-by-step instructions for various common Duende IdentityServer scenarios. They start with the absolute basics and become more complex - it is recommended you do them in order.
 
 * adding Duende IdentityServer to an ASP.NET Core application
 * configuring Duende IdentityServer

IdentityServer/v6/docs/content/quickstarts/1_client_credentials.md

@@ -7,7 +7,7 @@ weight: 2
 Welcome to the first quickstart for IdentityServer! To see the full list of
 quickstarts, please see [Quickstarts Overview]({{< ref "0_overview" >}}).
 
-This first quickstart provides step by step instructions to set up
+This first quickstart provides step-by-step instructions to set up
 IdentityServer in the most basic scenario: protecting APIs for server-to-server
 communication. You will create a solution containing three projects:
 - An Identity Server

IdentityServer/v6/docs/content/quickstarts/2_interactive.md

@@ -558,7 +558,7 @@ schemes](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/?v
 *AddGoogle* adds the Google scheme, which handles the protocol flow back and
 forth with Google. After successful login, the application needs to sign in to
 an additional scheme that can authenticate future requests without needing a
-round-trip to Google - typically by issuing a local cookie. The *SignInScheme*
+roundtrip to Google - typically by issuing a local cookie. The *SignInScheme*
 tells the Google handler to use the scheme named
 *IdentityServerConstants.ExternalCookieAuthenticationScheme*, which is a cookie
 authentication handler automatically created by IdentityServer that is intended

IdentityServer/v6/docs/content/reference/endpoints/ciba.md

@@ -22,15 +22,15 @@ The client id and a client credential is required to authenticate to the endpoin
 
 * ***login_hint***
 
-    hint for the end user to be authenticated. the value used is implementaiton specific.
+    hint for the end user to be authenticated. the value used is implementation specific.
 
 * ***id_token_hint***
 
     a previously issued id_token for the end user to be authenticated
 
 * ***login_hint_token***
 
-    a token containing information for the end user to be authenticated. the details are implementaiton specific.
+    a token containing information for the end user to be authenticated. the details are implementation specific.
 
 {{% notice note %}}
 To validate these implementation specific values and use them to identity the user that is to be authenticated, you are required to implement the *IBackchannelAuthenticationUserValidator* interface.

IdentityServer/v6/docs/content/reference/endpoints/end_session.md

@@ -27,7 +27,7 @@ The URL for the end session endpoint is available via discovery.
 
     If a valid *post_logout_redirect_uri* is passed, then the client may also send a *state* parameter.
     This will be returned back to the client as a query string parameter after the user redirects back to the client.
-    This is typically used by clients to round-trip state across the redirect.
+    This is typically used by clients to roundtrip state across the redirect.
 
 
 ```

IdentityServer/v6/docs/content/reference/services/interaction_service.md

@@ -32,7 +32,7 @@ It is available from the dependency injection system and would normally be injec
     Used to create a *logoutId* if there is not one presently.
     This creates a cookie capturing all the current state needed for signout and the *logoutId* identifies that cookie.
     This is typically used when there is no current *logoutId* and the logout page must capture the current user's state needed for sign-out prior to redirecting to an external identity provider for signout.
-    The newly created *logoutId* would need to be round-tripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page.
+    The newly created *logoutId* would need to be roundtripped to the external identity provider at signout time, and then used on the signout callback page in the same way it would be on the normal logout page.
 
 * ***GrantConsentAsync***
 

IdentityServer/v6/docs/content/reference/validators/dpop_proof_validator.md

@@ -12,11 +12,11 @@ A default implementation is provided and can be overridden as necessary.
 
 * ***ValidateAsync***
 
-    Validates a DPoP proof token with the provided *DPoPProofValidatonContext* for the current request.
-    Returns a *DPoPProofValidatonResult* object.
+    Validates a DPoP proof token with the provided *DPoPProofValidationContext* for the current request.
+    Returns a *DPoPProofValidationResult* object.
 
 
-### DPoPProofValidatonContext
+### DPoPProofValidationContext
 Models the information to validate a DPoP proof token request.
 
 * ***Client***
@@ -27,7 +27,7 @@ Models the information to validate a DPoP proof token request.
 
     The proof token sent with the request.
 
-### DPoPProofValidatonResult
+### DPoPProofValidationResult
 Models the result of a DPoP proof token validation.
 
 * ***IsError***

IdentityServer/v6/docs/content/ui/login/external.md

@@ -192,7 +192,7 @@ Typically, the *sub* value used to log the user in would be the user's unique id
 
 ## State, URL length, and ISecureDataFormat
 
-When redirecting to an external provider for sign-in, frequently state from the client application must be round-tripped.
+When redirecting to an external provider for sign-in, frequently state from the client application must be roundtripped.
 This means that state is captured prior to leaving the client and preserved until the user has returned to the client application.
 Many protocols, including OpenID Connect, allow passing some sort of state as a parameter as part of the request, and the identity provider will return that state in the response.
 The OpenID Connect authentication handler provided by ASP.NET Core utilizes this feature of the protocol, and that is how it implements the *returnUrl* feature mentioned above.

IdentityServer/v6/docs/content/ui/logout/external.md

@@ -45,7 +45,7 @@ public IActionResult Logout(string logoutId)
 To redirect back to your IdentityServer after the external provider sign-out, the *RedirectUri* should be used on the *AuthenticationProperties* when using ASP.NET Core's *SignOutAsync* API.
 
 Recall that after we return, we must perform the other steps to complete the logout workflow.
-These steps require the context passed as the *logoutId* parameter, so this state needs to be round-tripped to the external provider.
+These steps require the context passed as the *logoutId* parameter, so this state needs to be roundtripped to the external provider.
 We can do so by incorporating the *logoutId* value into the *RedirectUri*.
 
 If there is no *logoutId* parameter on the original logout page request, we still might have context that needs to be round tripped.

IdentityServer/v6/docs/content/ui/server_side_sessions/_index.md

@@ -78,4 +78,4 @@ public void ConfigureServices(IServiceCollection services)
 
 The [*IServerSideSessionStore*]({{<ref "/reference/stores/server_side_sessions">}}) is the abstraction for storing the server-side session.
 
-A EntityFramework Core implementaiton is already provided as part of our [operational store]({{<ref "/data/ef#operational-store">}}), but you can implement the [interface]({{<ref "/reference/stores/server_side_sessions">}}) yourself for other backing implementations.
+A EntityFramework Core implementation is already provided as part of our [operational store]({{<ref "/data/ef#operational-store">}}), but you can implement the [interface]({{<ref "/reference/stores/server_side_sessions">}}) yourself for other backing implementations.

IdentityServer/v7/docs/content/bff/architecture/_index.md

@@ -14,7 +14,7 @@ A BFF host is an ASP.NET Core application with the following components:
 
 These components handle OIDC and OAuth protocol requests and responses, manage user sessions and tokens, secure API endpoints for the front end, and optionally serve UI assets.
 
-Duende.BFF builds on widely used tools and frameworks, including ASP.NET Core's OpenID Connect and cookie authentication handlers, YARP, and Duende.AccessTokenManagment. Duende.BFF combines these tools and adds additional security and application features that are useful with a BFF architecture so that you can focus on providing application logic instead of security logic:
+Duende.BFF builds on widely used tools and frameworks, including ASP.NET Core's OpenID Connect and cookie authentication handlers, YARP, and Duende.AccessTokenManagement. Duende.BFF combines these tools and adds additional security and application features that are useful with a BFF architecture so that you can focus on providing application logic instead of security logic:
 
 ![](../images/DuendeBFF_blocks.png?height=30pc)
 

IdentityServer/v7/docs/content/bff/architecture/ui-hosting.md

@@ -23,7 +23,7 @@ dotnet new bfflocalapi
 ```
 
 #### Host UI in the BFF using Microsoft Templates
-Many frontend applications require a build process, which complicates the use of the static file middleware at development time. Visual Studio include's SPA templates that start up a SPA and proxy requests to it during development. Samples of Duende.BFF that take this approach using [React]({{< ref "/samples/bff#reactjs-frontend" >}}) and [Angular]({{< ref "/samples/bff#angular-frontend" >}}) are available. 
+Many frontend applications require a build process, which complicates the use of the static file middleware at development time. Visual Studio includes SPA templates that start up a SPA and proxy requests to it during development. Samples of Duende.BFF that take this approach using [React]({{< ref "/samples/bff#reactjs-frontend" >}}) and [Angular]({{< ref "/samples/bff#angular-frontend" >}}) are available. 
 
 Microsoft's templates are easy to use at dev time from Visual Studio. They allow you to simply run the solution, and the template proxies requests to the front end for you. At deploy time, that proxy is removed and the static assets of the site are served by the static file middleware.
 

IdentityServer/v7/docs/content/bff/extensibility/management/logout.md

@@ -5,7 +5,7 @@ date: 2022-12-30 10:55:24
 weight: 40
 ---
 
-The BFF logout endpoint has extensibility points in two interfaces. The *IlogoutService* is the top level abstraction that processes requests to the endpoint. This service can be used to add custom request processing logic. The *IReturnUrlValidator* ensures that the *returnUrl* parameter passed to the logout endpoint is safe to use.
+The BFF logout endpoint has extensibility points in two interfaces. The *ILogoutService* is the top level abstraction that processes requests to the endpoint. This service can be used to add custom request processing logic. The *IReturnUrlValidator* ensures that the *returnUrl* parameter passed to the logout endpoint is safe to use.
 
 ## Request Processing
 *ProcessRequestAsync* is the top level function called in the endpoint service and can be used to add arbitrary logic to the endpoint.

IdentityServer/v7/docs/content/bff/tokens.md

@@ -84,7 +84,7 @@ public async Task<IActionResult> CallApiAsUserTyped(
 The client will internally always try to use a current and valid access token. If for any reason this is not possible, the 401 status code will be returned to the caller. 
 
 ### Reuse of Refresh Tokens
-We recommend that you configure IdentityServer to issue reusable refresh tokens to BFF clients. Because the BFF is a confidential client, it does not need one-time use refresh tokens. Re-useable refresh tokens are desirable because they avoid  performance and user experience problems associated with one time use tokens. See the discussion on [rotating refresh tokens]({{< ref "tokens/refresh#one-time-refresh-tokens" >}}) and the [OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.2.2) for more details.
+We recommend that you configure IdentityServer to issue reusable refresh tokens to BFF clients. Because the BFF is a confidential client, it does not need one-time use refresh tokens. Reusable refresh tokens are desirable because they avoid  performance and user experience problems associated with one time use tokens. See the discussion on [rotating refresh tokens]({{< ref "tokens/refresh#one-time-refresh-tokens" >}}) and the [OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-2.2.2) for more details.
 
 ### Manually revoking refresh tokens
 Duende.BFF revokes refresh tokens automatically at logout time. This behavior can be disabled with the *RevokeRefreshTokenOnLogout* option.