changed files by pdets auto publish service, publishid[b6754242-e85f-434c-9a58-5fef500cd70f] and do [publish].

Author: wwlpublish

learn-pr/wwl-sci/implement-app-registration/10-knowledge-check.yml

@@ -18,11 +18,11 @@ content: |
 quiz:
   title: "Check your knowledge"
   questions:
-  - content: "Which of the following directories is maintained by Microsoft and used to publish applications?"
+  - content: "Microsoft maintains which of the following directories and uses them to publish applications?"
     choices:
     - content: "SaaS directory"
       isCorrect: false
-      explanation: "Incorrect. Application publishers/vendors who integrate with Microsoft Entra ID are required to have a SaaS directory."
+      explanation: "Incorrect. Application publishers/vendors who integrate with Microsoft Entra ID are required to have an SaaS directory."
     - content: "App gallery directory"
       isCorrect: true
       explanation: "Correct. The two directories that Microsoft maintains are the App gallery directory and the Microsoft services directory."
@@ -33,13 +33,13 @@ quiz:
     choices:
     - content: "Follow the principle of least user access to ensure that your app only requests permissions it actually needs."
       isCorrect: true
-      explanation: "Correct. Provide appropriate names and descriptions for any permissions you expose as part of your app. This helps users and admins know what they're agreeing to when they attempt to use your app's APIs."
+      explanation: "Correct. Provide appropriate names and descriptions for any permissions you expose as part of your app. The description helps users and admins know what they're agreeing to when they attempt to use your app's APIs."
     - content: "Test your app in each tenant to ensure functionality."
       isCorrect: false
       explanation: "Incorrect. You should test your app in a tenant that has configured Conditional Access policies. Testing in every tenant isn't a best practice."
     - content: "Use names and descriptions that are only meaningful to your team."
       isCorrect: false
-      explanation: "Incorrect. Provide appropriate names and descriptions for any permissions you expose as part of your app. This helps users and admins know what they're agreeing to when they attempt to use your app's APIs."
+      explanation: "Incorrect. Provide appropriate names and descriptions for any permissions you expose as part of your app. The description helps users and admins know what they're agreeing to when they attempt to use your app's APIs."
   - content: "Which two ways do you declare app roles by using the Azure portal?"
     choices:
     - content: "Certificates and secrets."

learn-pr/wwl-sci/implement-app-registration/includes/1-introduction.md

@@ -1,4 +1,4 @@
-In this module, you will plan your line-of-business application registration strategy, implement application registrations, and configure application permissions.
+In this module, you plan your line-of-business application registration strategy, implement application registrations, and configure application permissions.
 
 ## Learning objectives
 

learn-pr/wwl-sci/implement-app-registration/includes/5-configure-application-permission.md

@@ -36,7 +36,7 @@ Microsoft identity platform supports two types of permissions: **delegated permi
 *Effective permissions* are those that your app will have when making requests to the target resource. It's important to understand the difference between the delegated and application permissions that your app is granted and its effective permissions when making calls to the target resource.
 
 - For delegated permissions, the *effective permissions* of your app will be the least privileged intersection of the delegated permissions the app has been granted (via consent) and the privileges of the currently signed-in user. Your app can never have more privileges than the signed-in user. Within organizations, the privileges of the signed-in user are determined by policy or by membership in one or more administrator roles. To learn which administrator roles can consent to delegated permissions, see Administrator role permissions in Microsoft Entra ID.
-- For example, assume your app has been granted the *User.ReadWrite.All* delegated permission. This permission nominally grants your app permission to read and update the profile of every user in an organization. If the signed-in user is a application administrator, your app will be able to update the profile of every user in the organization. However, if the signed-in user isn't in an administrator role, your app will be able to update only the profile of the signed-in user. It will not be able to update the profiles of other users in the organization, because the user whom it has permission to act on behalf of doesn't have those privileges.
+- For example, assume your app has been granted the *User.ReadWrite.All* delegated permission. This permission nominally grants your app permission to read and update the profile of every user in an organization. If the signed-in user is an application administrator, your app will be able to update the profile of every user in the organization. However, if the signed-in user isn't in an administrator role, your app will be able to update only the profile of the signed-in user. It will not be able to update the profiles of other users in the organization, because the user whom it has permission to act on behalf of doesn't have those privileges.
 - For application permissions, the *effective permissions* of your app will be the full level of privileges implied by the permission. For example, an app that has the *User.ReadWrite.All* application permission can update the profile of every user in the organization.
 
 ## OpenID Connect Scopes
@@ -55,11 +55,11 @@ The email scope can be used with the openid scope and any others. It gives the a
 
 ### profile
 
-The profile scope can be used with the openid scope and any others. It gives the app access to a substantial amount of information about the user. The information it can access includes, but isn't limited to, the user's given name, surname, preferred username, and object ID. For a complete list of the profile claims available in the id\_tokens parameter for a specific user, see the id\_tokens reference.
+The profile scope can be used with the openid scope and any others. It gives the app access to a substantial amount of information about the user. The information it can access includes, but isn't limited to, the user's given name, surname, preferred username, and object ID. For a complete list of the profile claims available in the `id_tokens` parameter for a specific user, see the `id_tokens` reference.
 
 ### offline\_access
 
-The offline\_access scope gives your app access to resources on behalf of the user for an extended time. On the consent page, this scope appears as the "Maintain access to data you have given it access to" permission. When a user approves the offline\_access scope, your app can receive refresh tokens from the Microsoft identity platform token endpoint. Refresh tokens are long-lived. Your app can get new access tokens as older ones expire.
+The offline\_access scope gives your app access to resources on behalf of the user for an extended time. On the consent page, this scope appears as the "Maintain access to data you have given it access to" permission. When a user approves the `offline_access` scope, your app can receive refresh tokens from the Microsoft identity platform token endpoint. Refresh tokens are long-lived. Your app can get new access tokens as older ones expire.
 
 On the Microsoft identity platform (requests made to the v2.0 endpoint), your app must explicitly request the offline\_access scope to receive refresh tokens. This means that when you redeem an authorization code in the OAuth 2.0 authorization code flow, you'll receive only an access token from the /token endpoint. The access token is valid for a short time, usually expiring in one hour. At that point, your app needs to redirect the user back to the /authorize endpoint to get a new authorization code. During this redirect, depending on the type of app, the user might need to enter their credentials again or consent again to permissions.
 

learn-pr/wwl-sci/implement-app-registration/includes/6-grant-tenant-wide-admin-consent-application.md

@@ -18,7 +18,7 @@ Granting tenant-wide admin consent requires you to sign in as a user that is aut
 5.  Review the dialogue box, and then select **Yes.**
 
    > [!WARNING]
-   > Granting tenant-wide admin consent through App registrations will revoke any permissions that had previously been granted tenant-wide. Permissions previously granted by users on their own behalf will not be affected.
+   > Granting tenant-wide admin consent through App registrations will revoke any permissions that had previously been granted tenant-wide. Permissions previously granted by users on their own behalf won't be affected.
 
 ## Grant admin consent in Enterprise apps
 
@@ -63,7 +63,7 @@ If the application is requesting application permissions and an administrator gr
 ## Using the admin consent endpoint
 
 > [!NOTE]
-> After granting admin consent using the admin consent endpoint, you've finished granting admin consent and users don't need to perform any further additional actions. After granting admin consent, users can get an access token via a typical auth flow, and the resulting access token will have the consented permissions.
+> After the admin grants admin consent using the admin consent endpoint, you've finished granting admin consent and users don't need to perform any further additional actions. After granting admin consent, users can get an access token via a typical auth flow, and the resulting access token will have the consented permissions.
 
 When a Company Administrator uses your application and is directed to the authorized endpoint, Microsoft identity platform will detect the user's role and ask them if they would like to consent on behalf of the entire tenant for the permissions you've requested. However, there's also a dedicated admin consent endpoint you can use if you would like to proactively request that an administrator grants permission on behalf of the entire tenant. Using this endpoint is also necessary for requesting application permissions (which can't be requested using the authorized endpoint).