Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into yelevin/unified-IIT-take-two

Author: yelevin

.github/policies/disallow-edits.yml

@@ -153,15 +153,19 @@ configuration:
 
       - description: Disallow sign-off for articles in the /articles/reliability folder.
         if:
-          # If a 'sign-off' comment is added to a PR in the articles/reliability folder , and the PR author isn't Anastasia or John...
-          - payloadType: Issue_Comment
-          - isPullRequest
-          - filesMatchPattern:
-              matchAny: true
-              pattern: articles/reliability/*
+          # If a 'sign-off' comment is added to a PR that's assigned to anaharris-ms, and the PR author isn't Anastasia or John...
+          - or:
+            - payloadType: Issue_Comment
+            - payloadType: Pull_Request_Review_Comment
+          - isAction:
+              action: Created
+          - isActivitySender:
+              issueAuthor: True
+          - isAssignedToUser:
+              user: anaharris-ms
           - commentContains:
-              pattern: \#sign-off
-              isRegex: false
+              pattern: '#sign-off'
+              isRegex: False
           - not:
               or:
                 - isActivitySender:

.openpublishing.redirection.json

@@ -110,7 +110,7 @@ In the following example, when the Identity Experience Framework interacts with
 </ClaimType>
 ```
 
-As a result, the JWT token issued by Azure AD B2C, emits the `family_name` instead of ClaimType name **surname**.
+As a result, the JWT issued by Azure AD B2C, emits the `family_name` instead of ClaimType name **surname**.
 
 ```json
 {

articles/active-directory-b2c/claimsschema.md

@@ -229,7 +229,7 @@ Follow the steps in [Test the custom policy](custom-policies-series-validate-use
 
 1. In the first screen, for  **Account Type**, select **Personal Account**. 
 1. For **Access Code**, enter *88888*, and then select **Continue**. 
-1. Enter the rest of the details as required, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. 
+1. Enter the rest of the details as required, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. 
 1. Repeat step 5, but this time, select **Account Type**, select **Contoso Employee Account**, and then follow the prompts.  
 
 

articles/active-directory-b2c/custom-policies-series-branch-user-journey.md

@@ -35,7 +35,7 @@ In this article, you learn how to:
 
 ## Scenario overview 
 
-In [Create branching in user journey by using Azure AD B2C custom policies](custom-policies-series-branch-user-journey.md), users who select *Personal Account* need to provide a valid invitation access code to proceed. We use a static access code, but real world apps don't work this way. If the service that issues the access codes is external to your custom policy, you must make a call to that service, and pass the access code input by the user for validation. If the access code is valid, the service returns an HTTP `200 OK` response, and Azure AD B2C issues JWT token. Otherwise, the service returns an HTTP 4xx response, and the user must reenter an access code. 
+In [Create branching in user journey by using Azure AD B2C custom policies](custom-policies-series-branch-user-journey.md), users who select *Personal Account* need to provide a valid invitation access code to proceed. We use a static access code, but real world apps don't work this way. If the service that issues the access codes is external to your custom policy, you must make a call to that service, and pass the access code input by the user for validation. If the access code is valid, the service returns an HTTP `200 OK` response, and Azure AD B2C issues JWT. Otherwise, the service returns an HTTP 4xx response, and the user must reenter an access code. 
 
 :::image type="content" source="media/custom-policies-series-call-rest-api/screenshot-of-call-rest-api-call.png" alt-text="A flowchart of calling a R E S T  A P I.":::
 
@@ -228,7 +228,7 @@ Follow the steps in [Test the custom policy](custom-policies-series-validate-use
 
 1. For **Account Type**, select **Personal Account**
 1. Enter the rest of the details as required, and then select **Continue**. You see a new screen.
-1. For **Access Code**, enter *88888*, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. If you repeat the procedure, and enter a different **Access Code**, other than *88888*, you see an error, **The access code you entered is incorrect. Please try again.**
+1. For **Access Code**, enter *88888*, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. If you repeat the procedure, and enter a different **Access Code**, other than *88888*, you see an error, **The access code you entered is incorrect. Please try again.**
 
 ## Step 5 - Enable debug mode
 

articles/active-directory-b2c/custom-policies-series-call-rest-api.md

@@ -16,15 +16,15 @@ ms.reviewer: yoelh
 ms.subservice: b2c
 
 
-#Customer intent: As a developer using Azure Active Directory B2C, I want to collect and manipulate user inputs by writing a custom policy, so that I can customize the user interface and process the inputs as claims in a JWT token.
+#Customer intent: As a developer using Azure Active Directory B2C, I want to collect and manipulate user inputs by writing a custom policy, so that I can customize the user interface and process the inputs as claims in a JWT.
 
 ---
 
 # Collect and manipulate user inputs by using Azure Active Directory B2C custom policy
 
 Azure Active Directory B2C (Azure AD B2C) custom policies allows you to collect user inputs. You can then use inbuilt methods to manipulate the user inputs.  
 
-In this article, you learn how to write a custom policy that collects user inputs via a graphical user interface. You'll then access the inputs, process then, and finally return them as claims in a JWT token. To complete this task, you'll: 
+In this article, you learn how to write a custom policy that collects user inputs via a graphical user interface. You'll then access the inputs, process then, and finally return them as claims in a JWT. To complete this task, you'll: 
 
 - Declare claims. A claim provides temporary storage of data during an Azure AD B2C policy execution. It can store information about the user, such as first name, last name, or any other claim obtained from the user or other systems. You can learn more about claims in the [Azure AD B2C custom policy overview](custom-policy-overview.md#claims). 
 
@@ -260,7 +260,7 @@ Replace the existing contents of the `HelloWorldJourney` User Journey with the f
     </OrchestrationSteps>
 ```
 
-According to the orchestration steps, we collect user inputs, set values for *objectId*, *displayName* and *message* claims, and finally send the Jwt token. 
+According to the orchestration steps, we collect user inputs, set values for *objectId*, *displayName* and *message* claims, and finally send the JWT. 
 
 ## Step 6 - Update relying party 
 
@@ -486,7 +486,7 @@ Follow the steps in [Upload custom policy file](custom-policies-series-hello-wor
 
     :::image type="content" source="media/custom-policies-series-collect-user-input/screenshot-of-accepting-user-inputs-in-custom-policy.png" alt-text="screenshot of accepting user inputs in custom policy.":::
 
-After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. It looks similar to the following JWT token snippet: 
+After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. It looks similar to the following JWT snippet: 
 
 ```json
     {

articles/active-directory-b2c/custom-policies-series-collect-user-input.md

@@ -141,7 +141,7 @@ If you haven't already done so, create the following encryption keys. To automat
         </ClaimsProvider>
     ```
 
-    We've declared a JWT Token Issuer. In the `CryptographicKeys` section, if you used different names to configure the signing and encryption keys in [step 1](#step-1---configure-the-signing-and-encryption-keys), make sure you use the correct value for the `StorageReferenceId`.  
+    We've declared a JWT Issuer. In the `CryptographicKeys` section, if you used different names to configure the signing and encryption keys in [step 1](#step-1---configure-the-signing-and-encryption-keys), make sure you use the correct value for the `StorageReferenceId`.  
 
 1. In the `UserJourneys` section of the `ContosoCustomPolicy.XML` file, add the following code:
 
@@ -267,7 +267,7 @@ After you upload the file, Azure AD B2C adds the prefix `B2C_1A_`, so the names
 1. For **Select application** on the overview page of the custom policy, select the web application such as *webapp1* that you previously registered. Make sure that the **Select reply URL** value is set to`https://jwt.ms`.
 1. Select **Run now** button.
 
-After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. It looks similar to the following JWT token snippet: 
+After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. It looks similar to the following JWT snippet: 
 
 ```json
     {

articles/active-directory-b2c/custom-policies-series-hello-world.md

@@ -38,7 +38,7 @@ This how-to guide series consists of multiple articles. We recommend that you st
 
 |Article  | What you'll learn  |
 |---------|---------|
-|[Write your first Azure Active Directory B2C custom policy - Hello World!](custom-policies-series-hello-world.md) | Write your first Azure AD B2C custom policy. You return the message *Hello World!* in the JWT token. |
+|[Write your first Azure Active Directory B2C custom policy - Hello World!](custom-policies-series-hello-world.md) | Write your first Azure AD B2C custom policy. You return the message *Hello World!* in the JWT. |
 |[Collect and manipulate user inputs by using Azure AD B2C custom policy](custom-policies-series-collect-user-input.md) | Learn how to collect inputs from users, and how to manipulate them.|
 |[Validate user inputs by using Azure Active Directory B2C custom policy](custom-policies-series-validate-user-input.md) | Learn how to validate user inputs by using techniques such as limiting user input options, regular expressions, predicates, and validation technical profiles|
 |[Create branching in user journey by using Azure Active Directory B2C custom policy](custom-policies-series-branch-user-journey.md) | Learn how to create different user experiences for different users based on the value of a claim.|

articles/active-directory-b2c/custom-policies-series-overview.md

@@ -452,7 +452,7 @@ When the custom policy runs:
 
 - **Orchestration Step 5** - This step runs if the user doesn't already exist (`objectId` doesn't exist), so the `AAD-UserWriteUsingAlternativeSecurityId` Technical Profile executes to write the social account into Microsoft Entra ID.  
 
-- **Orchestration Step 6** - Finally, step 6 assembles and returns the JWT token at the end of the policy’s execution.
+- **Orchestration Step 6** - Finally, step 6 assembles and returns the JWT at the end of the policy’s execution.
 
 ## Step 5 - Update relying party output claims 
 
@@ -466,7 +466,7 @@ In the `ContosoCustomPolicy.XML` file, locate the `RelyingParty` element, and th
     <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
     <OutputClaim ClaimTypeReferenceId="identityProvider" />
 ```
-We've added the identity provider (*identityProvider*) as an output claim, so it will be included in the JWT token returned to the relying party application. 
+We've added the identity provider (*identityProvider*) as an output claim, so it will be included in the JWT returned to the relying party application. 
 
 ## Step 6 - Upload policy
 
@@ -485,7 +485,7 @@ If it's the first time running this policy (social account doesn't already exist
 
 Enter or update **Display Name**, **Given Name** and the **Surname**, and then select **Continue** button.  
 
-After the policy finishes execution, you're redirected to https://jwt.ms, and you see a decoded JWT token. It looks similar to the following JWT token snippet:
+After the policy finishes execution, you're redirected to https://jwt.ms, and you see a decoded JWT. It looks similar to the following JWT snippet:
 
 ```json
 {
@@ -504,7 +504,7 @@ After the policy finishes execution, you're redirected to https://jwt.ms, and yo
 }.[Signature]
 ```
 
-Notice the identity provider, `"idp": "facebook.com"`, has been included in the JWT token. 
+Notice the identity provider, `"idp": "facebook.com"`, has been included in the JWT. 
 
 ## A combined local and social sign-in
 

articles/active-directory-b2c/custom-policies-series-sign-up-or-sign-in-federation.md

@@ -311,7 +311,7 @@ When the custom policy runs:
 
 - **Orchestration Step 6** -  This step invokes the *UserInputMessageClaimGenerator* technical profile to assemble the user’s greeting message.
 
-- **Orchestration Step 7** - Finally, step 8 assembles and returns the JWT token at the end of the policy’s execution.
+- **Orchestration Step 7** - Finally, step 8 assembles and returns the JWT at the end of the policy’s execution.
 
 ## Step 4 - Upload policy