some improvements for clarity

Author: DominikMe

articles/communication-services/concepts/identity-model.md

@@ -23,7 +23,7 @@ Azure Communication Services is an identity-agnostic service, which offers multi
 Azure Communication Services identity model works with two key concepts.
 
 ## User identity / mapping
-When you create a user identity via SDK or REST API, Azure Communication Services creates a unique user identifier. External identifiers such as phone numbers, user/device/application ids, or user names can't be used directly in Azure Communication Services. Instead you have to maintain a mapping to your own user id system. Creating Azure Communication Service user identities is free. Charges are only incurred when the user consumes communication modalities such as a chat or a call. How to you use your generated Communication Services identity depends on your scenario. For example, you can map it 1:1, 1:N, N:1, or N:N, and you can use it for human users or applications. A user can participate in multiple communication sessions, using multiple devices, simultaneously. Mapping between Azure Communication Services user identity and your own identity system is your responsibility as a developer. For example, you can add a `CommunicationServicesId` column in your existing user table to store the associated Azure Communication Services identity. The mapping design is described in more detail under [Client-server architecture](#client-server-architecture).
+When you create a user identity via SDK or REST API, Azure Communication Services creates a unique user identifier. External identifiers such as phone numbers, user/device/application ids, or user names can't be used directly in Azure Communication Services. Instead you have to use the Communication Services identities and maintain a mapping to your own user id system as needed. Creating Azure Communication Service user identities is free and charges are only incurred when the user consumes communication modalities such as a chat or a call. How you use your generated Communication Services identity depends on your scenario. For example, you can map an identity 1:1, 1:N, N:1, or N:N, and you can use it for human users or applications. A user can participate in multiple communication sessions, using multiple devices, simultaneously. Managing a mapping between Azure Communication Services user identities and your own identity system is your responsibility as a developer, and doesn't come built-in. For example, you can add a `CommunicationServicesId` column in your existing user table to store the associated Azure Communication Services identity. A mapping design is described in more detail under [Client-server architecture](#client-server-architecture).
 
 ## Access tokens 
 After a user identity is created, a user then needs an access token with specific scopes to participate in communications using chat or calls. For example, only a user with a token with the `chat` scope can participate in chat and a user with a token with `voip` scope can participate in a VoIP call. A user can have multiple tokens simultaneously. Azure Communication Services supports multiple token scopes to account for users who require full access vs limited access. Access tokens have the following properties.
@@ -84,7 +84,7 @@ You can use the `voip.join` scope together with [Rooms](./rooms/room-concept.md)
 
 ## Client-server architecture
 
-You should generate and manage user access tokens by using a trusted service and not from your client application. The connection string or Microsoft Entra credentials that are necessary to generate user access tokens need to be protected and passing them to a client would risk leaking the secret. Failure to properly manage access tokens can result in extra charges on your resource when they are misused by somebody else.
+You should create and manage user access tokens through a trusted service and don't create tokens in your client application. The connection string or Microsoft Entra credentials that are necessary to create user access tokens need to be protected and passing them to a client would risk leaking the secret. Failure to properly manage access tokens can result in extra charges on your resource when tokens are dispensed freely and get misused by somebody else.
 
 If you cache access tokens to a backing store, we recommend encrypting the tokens. An access token gives access to sensitive data and can be used for malicious activity if it isn't protected. Anyone with a user's access token can access that user's chat data or participate in calls impersonating the user.
 
@@ -94,7 +94,7 @@ Make sure to only include those scopes in the token that your client application
 
 1. A user starts the client application.
 1. The client application contacts your identity management service.
-1. The identity management service authenticates the application user. Skip authentication for anonymous user scenarios, but be careful to then add other measures such as throttling and CORS to avoid abuse of your service.
+1. The identity management service authenticates the application user. You can skip authentication for scenarios where the user is anonymous, but be careful to then add other protective measures such as throttling and CORS to your service to mitigate token abuse.
 1. Create or find a Communication Services identity for the user.
    1. _Stable identity scenario:_ Your identity management service maintains a mapping between application identities and Communication Services identities. (Application identities include your users and other addressable objects, like services or bots.) If the application identity is new, a new Communication identity is created and a mapping is stored.
    1. _Ephemeral identity scenario:_ The identity management service creates a new Communication identity. In this scenario, the same user ends up with a different Communication identity for each session.