[CogSvcs] fixes for policheck scan

Author: Christopher McClister

articles/active-directory-b2c/manage-user-access.md

@@ -32,25 +32,25 @@ If a user is identified as a minor, you can set the user flow in Azure AD B2C to
 
 - **Send a signed JWT id_token back to the application**: The user is registered in the directory, and a token is returned to the application. The application then proceeds by applying business rules. For example, the application may proceed with a parental consent process. To use this method, choose to receive the **ageGroup** and **consentProvidedForMinor** claims from the application.
 
-- **Send an unsigned JSON token to the application**: Azure AD B2C notifies the application that the user is a minor and provides the status of the user’s parental consent. The application then proceeds by applying business rules. A JSON token does not complete a successful authentication with the application. The application must process the unauthenticated user according to the claims included in the JSON token, which may include **name**, **email**, **ageGroup**, and **consentProvidedForMinor**.
+- **Send an unsigned JSON token to the application**: Azure AD B2C notifies the application that the user is a minor and provides the status of the user's parental consent. The application then proceeds by applying business rules. A JSON token does not complete a successful authentication with the application. The application must process the unauthenticated user according to the claims included in the JSON token, which may include **name**, **email**, **ageGroup**, and **consentProvidedForMinor**.
 
 - **Block the user**: If a user is a minor, and parental consent has not been provided, Azure AD B2C can notify the user that they are blocked. No token is issued, access is blocked, and the user account is not created during a registration journey. To implement this notification, you provide a suitable HTML/CSS content page to inform the user and present appropriate options. No further action is needed by the application for new registrations.
 
 ## Get parental consent
 
-Depending on application regulation, parental consent might need to be granted by a user who is verified as an adult. Azure AD B2C does not provide an experience to verify an individual’s age and then allow a verified adult to grant parental consent to a minor. This experience must be provided by the application or another service provider.
+Depending on application regulation, parental consent might need to be granted by a user who is verified as an adult. Azure AD B2C does not provide an experience to verify an individual's age and then allow a verified adult to grant parental consent to a minor. This experience must be provided by the application or another service provider.
 
 The following is an example of a user flow for gathering parental consent:
 
 1. A [Microsoft Graph API](https://docs.microsoft.com/graph/use-the-api) operation identifies the user as a minor and returns the user data to the application in the form of an unsigned JSON token.
 
 2. The application processes the JSON token and shows a screen to the minor, notifying them that parental consent is required and requesting the consent of a parent online.
 
-3. Azure AD B2C shows a sign-in journey that the user can sign in to normally and issues a token to the application that is set to include **legalAgeGroupClassification = “minorWithParentalConsent”**. The application collects the email address of the parent and verifies that the parent is an adult. To do so, it uses a trusted source, such as a national ID office, license verification, or credit card proof. If verification is successful, the application prompts the minor to sign in by using the Azure AD B2C user flow. If consent is denied (for example, if **legalAgeGroupClassification = “minorWithoutParentalConsent”**), Azure AD B2C returns a JSON token (not a login) to the application to restart the consent process. It is optionally possible to customize the user flow so that a minor or an adult can regain access to a minor’s account by sending a registration code to the minor’s email address or the adult’s email address on record.
+3. Azure AD B2C shows a sign-in journey that the user can sign in to normally and issues a token to the application that is set to include **legalAgeGroupClassification = "minorWithParentalConsent"**. The application collects the email address of the parent and verifies that the parent is an adult. To do so, it uses a trusted source, such as a national ID office, license verification, or credit card proof. If verification is successful, the application prompts the minor to sign in by using the Azure AD B2C user flow. If consent is denied (for example, if **legalAgeGroupClassification = "minorWithoutParentalConsent"**), Azure AD B2C returns a JSON token (not a login) to the application to restart the consent process. It is optionally possible to customize the user flow so that a minor or an adult can regain access to a minor's account by sending a registration code to the minor's email address or the adult's email address on record.
 
 4. The application offers an option to the minor to revoke consent.
 
-5. When either the minor or the adult revokes consent, the Microsoft Graph API can be used to change **consentProvidedForMinor** to **denied**. Alternatively, the application may choose to delete a minor whose consent has been revoked. It is optionally possible to customize the user flow so that the authenticated minor (or parent that is using the minor’s account) can revoke consent. Azure AD B2C records **consentProvidedForMinor** as **denied**.
+5. When either the minor or the adult revokes consent, the Microsoft Graph API can be used to change **consentProvidedForMinor** to **denied**. Alternatively, the application may choose to delete a minor whose consent has been revoked. It is optionally possible to customize the user flow so that the authenticated minor (or parent that is using the minor's account) can revoke consent. Azure AD B2C records **consentProvidedForMinor** as **denied**.
 
 For more information about **legalAgeGroupClassification**, **consentProvidedForMinor**, and **ageGroup**, see [User resource type](https://developer.microsoft.com/graph/docs/api-reference/beta/resources/user). For more information about custom attributes, see [Use custom attributes to collect information about your consumers](user-flow-custom-attributes.md). When you address extended attributes by using the Microsoft Graph API, you must use the long version of the attribute, such as *extension_18b70cf9bb834edd8f38521c2583cd86_dateOfBirth*: *2011-01-01T00:00:00Z*.
 
@@ -62,15 +62,15 @@ A customized user flow can gather DOB and country/region information and use Azu
 
 The following steps show the logic that is used to calculate **ageGroup** from the user's date of birth:
 
-1. Try to find the country by the country code in the list. If the country is not found, fall back to **Default**.
+1. Try to find the country/region by the country/region code in the list. If the country/region is not found, fall back to **Default**.
 
-2. If the **MinorConsent** node is present in the country element:
+2. If the **MinorConsent** node is present in the country/region element:
 
     a. Calculate the date that the user must have been born on to be considered an adult. For example, if the current date is March 14, 2015, and **MinorConsent** is 18, the birth date must be no later than March 14, 2000.
 
-    b. Compare the minimum birth date with the actual birth date. If the minimum birth date is before the user’s birth date, the calculation returns **Minor** as the age group calculation.
+    b. Compare the minimum birth date with the actual birth date. If the minimum birth date is before the user's birth date, the calculation returns **Minor** as the age group calculation.
 
-3. If the **MinorNoConsentRequired** node is present in the country element, repeat steps 2a and 2b using the value from **MinorNoConsentRequired**. The output of 2b returns **MinorNoConsentRequired** if the minimum birth date is before the user’s birth date.
+3. If the **MinorNoConsentRequired** node is present in the country/region element, repeat steps 2a and 2b using the value from **MinorNoConsentRequired**. The output of 2b returns **MinorNoConsentRequired** if the minimum birth date is before the user's birth date.
 
 4. If neither calculation returns true, the calculation returns **Adult**.
 
@@ -85,13 +85,13 @@ For more information about gathering DOB data, see [Use age gating in Azure AD B
 
 When you develop your application, you ordinarily capture users' acceptance of terms of use within their applications with no, or only minor, participation from the user directory. It is possible, however, to use an Azure AD B2C user flow to gather a user's acceptance of terms of use, restrict access if acceptance is not granted, and enforce acceptance of future changes to the terms of use, based on the date of the latest acceptance and the date of the latest version of the terms of use.
 
-**Terms of Use** may also include “Consent to share data with third parties.” Depending on local regulations and business rules, you can gather a user's acceptance of both conditions combined, or you can allow the user to accept one condition and not the other.
+**Terms of Use** may also include "Consent to share data with third parties." Depending on local regulations and business rules, you can gather a user's acceptance of both conditions combined, or you can allow the user to accept one condition and not the other.
 
 The following steps describe how you can manage terms of use:
 
 1. Record the acceptance of the terms of use and the date of acceptance by using the Graph API and extended attributes. You can do so by using both built-in and custom user flows. We recommend that you create and use the **extension_termsOfUseConsentDateTime** and **extension_termsOfUseConsentVersion** attributes.
 
-2. Create a required check box labeled “Accept Terms of Use,” and record the result during signup. You can do so by using both built-in and custom user flows.
+2. Create a required check box labeled "Accept Terms of Use," and record the result during signup. You can do so by using both built-in and custom user flows.
 
 3. Azure AD B2C stores the terms of use agreement and the user's acceptance. You can use the Graph API to query for the status of any user by reading the extension attribute that's used to record the response (for example, read **termsOfUseTestUpdateDateTime**). You can do so by using both built-in and custom user flows.
 

articles/active-directory-b2c/phone-number-claims-transformations.md

@@ -58,8 +58,8 @@ This claim transformation validates the format of the phone number. If it is in
 
 | Item | TransformationClaimType | Data Type | Notes |
 | ---- | ----------------------- | --------- | ----- |
-| InputClaim | phoneNumberString | string |  The string claim for the phone number. The phone number has to be in international format, complete with a leading "+" and country code. If input claim `country` is provided, the phone number is in local format (without the country code). |
-| InputClaim | country | string | [Optional] The string claim for the country code of the phone number in ISO3166 format (the two-letter ISO-3166 country code). |
+| InputClaim | phoneNumberString | string |  The string claim for the phone number. The phone number has to be in international format, complete with a leading "+" and country/region code. If input claim `country` is provided, the phone number is in local format (without the country/region code). |
+| InputClaim | country | string | [Optional] The string claim for the country/region code of the phone number in ISO3166 format (the two-letter ISO-3166 country/region code). |
 | OutputClaim | outputClaim | phoneNumber | The result of this claims transformation. |
 
 The **ConvertStringToPhoneNumberClaim** claims transformation is always executed from a [validation technical profile](validation-technical-profile.md) that is called by a [self-asserted technical profile](self-asserted-technical-profile.md) or [display control](display-controls.md). The **UserMessageIfClaimsTransformationInvalidPhoneNumber** self-asserted technical profile metadata controls the error message that is presented to the user.
@@ -109,24 +109,24 @@ The self-asserted technical profile that calls the validation technical profile
 
 ## GetNationalNumberAndCountryCodeFromPhoneNumberString
 
-This extracts the country code and the national number from the input claim, and optionally throws an exception if the supplied phone number is not valid.
+This extracts the country/region code and the national number from the input claim, and optionally throws an exception if the supplied phone number is not valid.
 
 | Item | TransformationClaimType | Data Type | Notes |
 | ---- | ----------------------- | --------- | ----- |
-| InputClaim | phoneNumber | string | The string claim of the phone number. The phone number has to be in international format, complete with a leading "+" and country code. |
+| InputClaim | phoneNumber | string | The string claim of the phone number. The phone number has to be in international format, complete with a leading "+" and country/region code. |
 | InputParameter | throwExceptionOnFailure | boolean | [Optional] A parameter indicating whether an exception is thrown when the phone number is not valid. Default value is false. |
-| InputParameter | countryCodeType | string | [Optional] A parameter indicating the type of country code in the output claim. Available values are **CallingCode** (the international calling code for a country, for example +1) or **ISO3166** (the two-letter ISO-3166 country code). |
+| InputParameter | countryCodeType | string | [Optional] A parameter indicating the type of country/region code in the output claim. Available values are **CallingCode** (the international calling code for a country/region, for example +1) or **ISO3166** (the two-letter ISO-3166 country/region code). |
 | OutputClaim | nationalNumber | string | The string claim for the national number of the phone number. |
-| OutputClaim | countryCode | string | The string claim for the country code of the phone number. |
+| OutputClaim | countryCode | string | The string claim for the country/region code of the phone number. |
 
 
 If the **GetNationalNumberAndCountryCodeFromPhoneNumberString** claims transformation is executed from a [validation technical profile](validation-technical-profile.md) that is called by a [self-asserted technical profile](self-asserted-technical-profile.md) or a [display control action](display-controls.md#display-control-actions), then the **UserMessageIfPhoneNumberParseFailure** self-asserted technical profile metadata controls the error message that is presented to the user.
 
 ![Diagram of error message execution path](./media/phone-authentication/assert-execution.png)
 
-You can use this claims transformation to split a full phone number into the country code and the national number. If the phone number provided is not valid, you can choose to throw an error message.
+You can use this claims transformation to split a full phone number into the country/region code and the national number. If the phone number provided is not valid, you can choose to throw an error message.
 
-The following example tries to split the phone number into national number and country code. If the phone number is valid, the phone number will be overridden by the national number. If the phone number is not valid, an exception will not be thrown and the phone number still has its original value.
+The following example tries to split the phone number into national number and country/region code. If the phone number is valid, the phone number will be overridden by the national number. If the phone number is not valid, an exception will not be thrown and the phone number still has its original value.
 
 ```XML
 <ClaimsTransformation Id="GetNationalNumberAndCountryCodeFromPhoneNumberString" TransformationMethod="GetNationalNumberAndCountryCodeFromPhoneNumberString">

articles/active-directory-b2c/string-transformations.md

@@ -512,7 +512,7 @@ The following example looks up the domain name in one of the inputParameters col
     - **test.com**: c7026f88-4299-4cdb-965d-3f166464b8a9
     - **errorOnFailedLookup**: false
 - Output claims:
-    - **outputClaim**:	c7026f88-4299-4cdb-965d-3f166464b8a9
+    - **outputClaim**:    c7026f88-4299-4cdb-965d-3f166464b8a9
 
 When `errorOnFailedLookup` input parameter is set to `true`, the **LookupValue** claims transformation is always executed from a [validation technical profile](validation-technical-profile.md) that is called by a [self-asserted technical profile](self-asserted-technical-profile.md), or a [DisplayConrtol](display-controls.md). The `LookupNotFound` metadata of a self-asserted technical profile controls the error message that is presented to the user.
 
@@ -821,7 +821,7 @@ Extracts parts of a string claim type, beginning at the character at the specifi
 | InputParameter | length | int | The number of characters in the substring. |
 | OutputClaim | outputClaim | boolean | A string that is equivalent to the substring of length that begins at startIndex in this instance, or Empty if startIndex is equal to the length of this instance and length is zero. |
 
-For example, get the phone number country prefix.
+For example, get the phone number country/region prefix.
 
 
 ```XML

articles/active-directory-b2c/technical-overview.md

@@ -59,7 +59,7 @@ A user with a consumer account can sign in with multiple identities, for example
 
 ![Consumer account identities](media/technical-overview/identities.png)<br/>*Figure: A single consumer account with multiple identities in Azure AD B2C*
 
-Azure AD B2C lets you manage common attributes of consumer account profiles like display name, surname, given name, city, and others. You can also extend the Azure AD schema to store additional information about your users. For example, their country or residency, preferred language, and preferences like whether they want to subscribe to a newsletter or enable multi-factor authentication.
+Azure AD B2C lets you manage common attributes of consumer account profiles like display name, surname, given name, city, and others. You can also extend the Azure AD schema to store additional information about your users. For example, their country/region or residency, preferred language, and preferences like whether they want to subscribe to a newsletter or enable multi-factor authentication.
 
 Learn more about the user account types in Azure AD B2C in [Overview of user accounts in Azure Active Directory B2C](user-overview.md).
 
@@ -96,7 +96,7 @@ To help you quickly set up the most common identity tasks, the Azure portal incl
 You can configure user flow settings like these to control identity experience behaviors in your applications:
 
 * Account types used for sign-in, such as social accounts like a Facebook, or local accounts that use an email address and password for sign-in
-* Attributes to be collected from the consumer, such as first name, postal code, or country of residency
+* Attributes to be collected from the consumer, such as first name, postal code, or country/region of residency
 * Azure Multi-Factor Authentication (MFA)
 * Customization of the user interface
 * Set of claims in a token that your application receives after the user completes the user flow