> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ulm.m1amdocs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# MarketONE Connect 2021.10 - Release Notes
Release Date: October 28, 2021
## Announcements
There are no announcements for this release.
## Connect Features
This section describes the key updates in this release.
### New application settings
As of this release, Connect includes the following new optional application settings:
**Password Lifetime setting enforces routine password changes**
Your organization can enable the **Password Lifetime** setting to control how long an end user can use a password before they are required to set a new one. If an end user authenticates into your service while the setting is enabled, Connect first performs a check to see how long the end user has had their current password. If the password is expired, Connect then prompts for the end user to submit a new password before they can proceed.
For example, if you enable and set **Password Lifetime** to 90 days (or 7776000 seconds), and an end user signs in 91 days after they set their password, then the relevant Process prompts for the end user to supply a new password before they can continue into the service. Once an end user provides an acceptable new password, Connect closes all sessions that they may have open, except for the current one.
**Password Lifetime** has been added to the following Connect Processes:
* [Authenticate User](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_authenticateUser.html)
* Onboard, Authenticate, Associate Account, and Purchase — The new complex, "all-in-one" Process designed for service providers with an integrated billing account service (for example, MarketONE Subscribe).
By default, **Password Lifetime** is set to a value of 0 (that is, disabled). The maximum allowable number of days is 365 days (or 31,536,000 seconds).
| PCI Compliance |
| - |
| Setting a password expiration enables your organization to fulfill [Payment Card Industry](https://www.pcisecuritystandards.org/) (PCI) Data Security Standard (DSS) version 3.2.1, requirement 8.2.4: "Change user passwords/passphrases at least once every 90 days." |
**Password Historical Check Count prevents the reuse of recent passwords**
Your organization can enable the **Password Historical Check Count** setting to control the number of most recently used passwords that an end user is not allowed to reuse, when they are setting a new password.
For example, if **Password Historical Check Count** is set to 5, then an end user cannot reuse any of their 5 most recent passwords when they are setting a new password.
**Password Historical Check Count** has been added to the following Connect Processes:
* [Authenticate User Process](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_authenticateUser.html)
* [Update Password Process](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_updatePassword.html)
* [Recover ID and Reset Password Processes](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_forgotPassword.html)
* Onboard, Authenticate, Associate Account and Purchase
By default, **Password Historical Check Count** is set to 0 (disabled). The maximum allowable value is 10.
| PCI Compliance |
| - |
| Setting a password expiration enables your organization to fulfill [Payment Card Industry](https://www.pcisecuritystandards.org/) (PCI) Data Security Standard (DSS) version 3.2.1, requirement 8.2.5: "Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases that they have used." |
**Password Historical Check Period prevents the reuse of a password for a set duration of time**
Your organization can enable **Password Historical Check Period** setting to define a minimum amount of time that must pass before a previously used password may be used again.
For example, if you set **Password Historical Check Period** to 6 months (or 15,768,000 seconds), then once an end user replaces a password, that particular password can not be used again for 6 months.
Like the **Password Historical Check Count** setting described above, **Password Historical Check Period** has been added to the following Connect Processes:
* [Authenticate User Process](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_authenticateUser.html)
* [Update Password Process](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_updatePassword.html)
* [Recover ID and Reset Password Processes](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_forgotPassword.html)
* Onboard, Authenticate, Associate Account and Purchase
**Enforce Account Association setting ensures customer-only authentication**
As of this release, Connect includes a new Relying Party-specific application setting Enforce Account Association.
| About OIDC Relying Parties (RPs) and RP-specific settings |
| - |
| A relying party (RP) is defined in OpenID Connect (OIDC) as a client application registered with an authentication server. The authentication server (also known as "Issuer" in OIDC terms) validates credentials provided by the RP, and returns access and/or ID tokens to that RP. This enables an organization to deliver onboarding, authentication, and Single Sign-On (SSO) flows for multiple RPs from a single authentication server. You can register and manage your client applications as OIDC RP clients in the Connect Admin web application, and Connect serves as the authentication server for your RPs. See the [Connect Getting Started Guide](https://docs.vindicia.com/bundle/b_gettingStartedGuide) for a more comprehensive overview of how Connect implements OAuth 2.0 framework, and it's identity-centric extension, OIDC. An RP-specific application setting is a setting that only works if for specific RP. This setting can only be configured on the back end, with the registered client IDs included in the setting value. Reach out to your product support representative for more details if you want to enable a setting for a specific RP. |
| When this setting is enabled for a RP, and the RP provides user credentials to Connect during an onboarding flow, Connect will check to see if an end user has at least 1 external billing account associated to their Connect User ID. If the end user does not meet this requirement, Connect prompts for them to enter a mobile number/email address/account number. Connect then sends a One-time Passcode (OTP) to the end user to verify their ownership of an account. If your RP has this setting enabled, the end user must meet the requirement in order to be fully authenticated. |
**Enforce Account Association** has been added to the following Processes:
* [Onboard and Authenticate User with Social Account](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/identityManagementProcesses/c_onboardAuthenticateUserSocial.html)
* Onboard, Authenticate, Associate Account and Purchase
This setting ensures certain applications can only be accessed (that is, authenticated) by an end user with at least one billing account associated to their User ID. In simpler terms, it ensures certain applications can only be accessed by end users that are customers of your organization. For example: a self-service application where customers can view their bill and manage their services.
### Support for unlimited OTP action tokens
Connect issues and redeems [action tokens](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/c_actionTokens.html) to link two or more Connect Processes to complete certain user tasks. Token delivery and redemption typically follows this flow:
1. An end user goes through a Process (for example, Onboard User with Email and Mobile)
2. At the end of that Process, connect issues and delivers the action token to the user-supplied email address or mobile number.
3. The end user retrieves and redeems that token through one of two methods, depending on the token type that they receive:
* The end user receives a redirect link with the full token value appended to the end of the URL string. The end user clicks the URL link and redirects to your client application, where your client takes that token value from the URL and redeems it with the GET /session/token API.
* The end user retrieves a short One-time Passcode (OTP) that corresponds to the token value stored in the cloud. The end user supplies the OTP to your client application, and your client then redeems the OTP with the GET /session/token API.
4. Connect validates the token/OTP and initiates the subsequent Process (for example, Activate User).
**Note:** The type of action token that an end user receives depends on your organization's notification settings.
As of this release, Connect can support an unlimited number of issued available short tokens at any given time. Previously, if OTPs were 4 numerical characters in length, the service limited the number of active short tokens at a given time to 10,000. If OTPs were 6 numerical characters in length, the service limited the number of short tokens at a given time to 1,000,000. If there were significant user authentication volume in a short period of time, this could potentially cause OTP collision and an errors for end users. Rergardless of OTP length, this enhancement ensures that Connect can avoid any OTP collision regardless of OTP length.
| About token settings |
| - |
| You can set and manage your organization's OTP token settings such as length, format, and casing in the Connect Admin web application's Security Settings screen. |
### New Connect API verifies an end user's password
In the previous release, Connect exposed the `POST /user/verifyPIN` API that verifies an authenticated end user's PIN. As of this release, Connect now includes the `POST /user/verifyPassword` API that similarly validates an authenticated end user's current password. This API does not perform or require a session switch between separate User profiles, and it is actually more efficient (that is, faster response time, lower size) in comparison.
Clients can require PINs and/or passwords within an authenticated context to restrict access to secure areas of a given application (for example, parental controls), or to confirm risk-sensitive actions (for example, confirming a purchase).
### Enhancements to the Connect IdP UI
Connect's Identity Provider (IdP) UI is an easy-to-implement onboarding, authentication, and ID management application for end users. This UI leverages the same Connect APIs and Processes that are available to clients for their own site or service implementation. The IdP UI is available as a packaged solution for organizations that do not want to develop their own sign-up/sign-in portal.
As of this release, the IdP UI includes the following updates and enhancements:
**Enforce account association for new users**
The IdP UI can now leverage the above-mentioned **Enforce Account Association** setting. Service providers that leverage the IdP UI can now ensure that an end user can only onboard and authenticate once they verify ownership of an existing account in the service provider's billing/subscription management service.
**Support for Associate Billing Account Process v2**
The IdP UI now uses [Associate Billing Account to User ID Process](https://docs.vindicia.com/bundle/b_processGuide/page/connectProcessAPIGuide/processes/accountManagementProcesses/c_associateBillingAccountV2.html), version 2. The updated Process was introduced in the [Connect (2021.09)](2021_09_connectRN_tp) release.
**Restrict different onboarding options on the sign-up screen for individual OIDC RP clients**
By the default, the IdP provides the following onboarding methods for end users:
* Onboard with email address
* Onboard with mobile number
* Onboard with a social account provider (for example, Facebook, Google, etc)
You can optionally restrict/hide onboarding methods from end users who navigate to the IdP from one or more of your organization's registered OIDC clients. For example, perhaps you only want to offer only mobile-based onboarding, and prevent email-based onboarding.
To omit email or mobile options from your instance of the IdP UI, you can disable/clear the **Valid email format pattern** and **Valid mobile number pattern** on the **User Authentication Settings** menu in Connect Admin.
For example, if **Valid email format pattern** is emptied, then the IdP UI will only prompt for (and accept) only mobile numbers.
Similarly, to omit social onboarding options, disable (or simply do not configure) social integrations on the Social Connections Settings menu in Connect Admin.
If a social account provider is not enabled (or if it is enabled and then disabled afterwards), then the IdP UI does not show the corresponding social provider's button.
Making these changes in Admin automatically updates the default view of the IdP that your organization uses. However, if your organization has multiple registered RPs that use the IdP UI, and you want to show/omit different onboarding options for each individual RP, Vindicia can enable these RP-specific settings on the backend. Please reach out to your product support contact for more details.
**Onboarding with social account includes terms & conditions**
If your instance of the IdP UI has a configured and enabled a social onboarding option, and an end user goes through that onboarding flow, the final step before user creation now includes a prompt collect additional user information.
Onboarding with social account prompts user with a final step to collect **First Name** (optional), **Last Name** (optional), and the user's acceptance of **Terms & Conditions** (required).
**Note:** The hyperlink for Terms & Conditions and/or Privacy Policy are provided by your organization, and set on the back end by Vindicia.
### Enhancements to the Connect Care UI
Connect Care is a ready-to-use web application for your organization's customer support representatives (CSRs), also referred to as "Care agents." Care agents can search for and view your existing Connect User profiles, and take certain actions against that profile on behalf of end users.
As of this release, the single **Full Name** field for a selected user has been replaced with three individual **First Name**, **Last Name**, and **Display Name** fields. A Care agent can edit all three fields on behalf of an end user.
## Bug Fixes
The following bug has been fixed in this release:
| Summary | Description |
| - | - |
| IdP UI does not set preferred language for new users | When a new end user onboards through the Connect IdP UI, the application does not automatically set a preferred language on the profile management screen. This issue is now resolved. |
## Known Issues
There are no known issues in this release.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.