some edits for clarity

Author: DominikMe

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

@@ -16,28 +16,28 @@ ms.subservice: identity
 # Identity model
 Azure Communication Services is an identity-agnostic service, which offers multiple benefits:
 
-- Reuse existing identities from your identity management system and simply map them with Azure Communication Services identities. 
-- Provides integration flexibility as identity-agnostic model works well with your existing identity system.
-- You can Keep your user's data, such as their name, private as you don't need to duplicate it in Azure Communication Services.
+- Reuse existing identities from your identity management system and map them with Azure Communication Services identities. 
+- Works well with any existing identity system and has no dependency on a specific identity provider.
+- Keep your user's data, such as their name, private as you don't need to duplicate it in Azure Communication Services.
 
 Azure Communication Services identity model works with two key concepts.
 
 ## User identity / mapping
-Uniquely identifies a user through a user-identifier, which is generated by Azure Communication Services when a user is created. External identifiers such as phone numbers, users, devices, applications, and GUIDs can't be used for identity in Azure Communication Services. You can create Azure Communication Service user identities for free. Charges are only incurred when the user consumes communications modalities such as a chat or a call. Your users identity can be mapped to Azure Communication Services user Identity in 1:1, 1:N, N:1, N:N configurations. A user can participate in multiple communication sessions, using multiple devices, simultaneously. Mapping between Azure Communication Services user identity and customer's private user identity is kept and maintained by the customer. For example, customers can add a `CommunicationServicesId` column in their user table to store the associated Azure Communication Services identity.
+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 will 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. This is described in more detail under [Client-server architecture](#client-server-architecture) below.
 
 ## Access tokens 
-After a user identity is created, a user is granted with the capability to participate in communications using chat or calls, using access tokens. For example, only a user with chat token can participate in chat and user with VoIP token can participate in a VoIP call. A user can have multiple tokens simultaneously. Azure Communication Services supports multiple types of tokens to account for users who require full access vs limited access. Access tokens have the following properties.
+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.
 
 |Property|Description|
 |---|----|
-|Identity|Uniquely identifies a token|
-|Expiration|An access token is valid for a period of time between 1 and 24 hours. After it expires, the access token is invalidated and can't be used to access any primitive. To generate a token with a custom validity, specify the desired validity period when generating the token. If no custom validity is specified, the token will be valid for 24 hours. We recommend using short lifetime tokens for one-off meetings and longer lifetime tokens for agents using the application for longer periods of time|
-|Scope|The scope parameter defines a nonempty set of primitives (Chat/VoIP) that can be used.
+|Subject|The user identity which is represented by the token.|
+|Expiration|An access token is valid for at least 1 hour and up to 24 hours. After it expires, the access token is invalid and can't be used to access the service. To create a token with a custom expiration time, specify the desired validity in minutes (>=60, <1440). By default, the token is valid for 24 hours. We recommend using short lifetime tokens for one-off meetings and longer lifetime tokens for users who use your application for longer periods of time.|
+|Scopes|The scopes define which communication primitives (Chat/VoIP) can be accessed with the token.|
 
-An access token is a JSON Web Token (JWT) and has integrity protection. That is, its claims can't be changed after it's issued. So a manual change of properties such as identity, expiration, or scopes will invalidate the access token. If primitives are used with invalidated tokens, then access will be denied to the primitives. Azure Communication Services supports the following scopes for access tokens.
+An access token is a JSON Web Token (JWT) and has integrity protection. That is, its claims can't be changed after it has been issued. So a manual change of properties such as subject, expiration, or scopes invalidates the access token because the token signature no longer matches. If communication primitives are used with invalid tokens, then access will be denied. Even though tokens aren't encrypted or obfuscated, your application should not depend on the token shape or its claims as they can change and aren't part of the official API contract. Azure Communication Services supports the following scopes for access tokens.
 
 ### Chat token scopes
-Three types of chat token scopes are supported. Permissions for each token are described below.
+Three different chat token scopes are supported. Permissions for each scope are described below.
 - `chat`
 - `chat.join`
 - `chat.join.limited`
@@ -61,7 +61,7 @@ Three types of chat token scopes are supported. Permissions for each token are d
 |Get participant for thread ID | Y | Y | Y |
 
 ### VoIP token scopes
-Two types of VoIP token scopes are supported. Permissions for each token are described below.
+Two VoIP token scopes are supported. Permissions for each scope are described below.
 - `voip`
 - `voip.join`
 
@@ -80,13 +80,13 @@ You can the use `voip.join` scope together with [Rooms](./rooms/room-concept.md)
 - Azure Communication Services Identity library can be used to revoke an access token before its expiration time. Token revocation isn't immediate. It can take up to 15 minutes to propagate.
 - The deletion of an identity, resource, or subscription revokes all access tokens.
 - If you want to remove a user's ability to access specific functionality, revoke all access tokens for the user. Then issue a new access token that has a more limited set of scopes.
-- Rotation of access keys revokes all active access tokens that were created by using a former access key. In this case all identities lose access to Azure Communication Services, and they must issue new access tokens.
+- Rotation of access keys revokes all active access tokens that were created by using a former access key. In this case all identities lose access to Azure Communication Services, and they need new access tokens.
 
 ## 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 additional charges on your resource when discovered and 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's not protected. Someone who has an access token can access a user's chat data or participate in calls impersonating the user.
+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 an user's access token can access that user's chat data or participate in calls impersonating the user.
 
 Make sure to only include those scopes in the token that your client application really needs in order to follow the security principle of least privilege.
 
@@ -97,7 +97,7 @@ Make sure to only include those scopes in the token that your client application
 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. 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 will end up with a different Communication identity for each session.
+   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.
 1. The identity management service issues a user access token for the applicable identity and returns it to the client application.
 
 Azure App Service or Azure Functions are two alternatives for operating the identity management service. These services scale easily and have built-in features to [authenticate](/../../app-service/overview-authentication-authorization.md) users. They're integrated with [OpenID](../../app-service/configure-authentication-provider-openid-connect.md) and third-party identity providers like [Facebook](/../../app-service/configure-authentication-provider-facebook.md).