S000000311 DFA Mobile Drivers License REVISED 3.0.pdf

STATE OF ARKANSAS

DEPARTMENT OF TRANSFORMATION AND SHARED SERVICES

OFFICE OF STATE PROCUREMENT

501 Woodlane St., Ste. 220

Little Rock, Arkansas 72201-1023

REVISED REQUEST FOR PROPOSAL

SOLICITATION DOCUMENT

THE REVISIONS TO THIS DOCUMENT ARE IN RED

SOLICITATION INFORMATION

Solicitation Number: S000000311 Solicitation Issued: March 01, 2024

Description: Mobile Driver’s License (mDL)

Department: Arkansas Department of Finance and Administration – Revenue Services

SUBMISSION DEADLINE AND DELIVERY OF RESPONSE DOCUMENTS

Proposal Opening Date: March 29April 1st, 2024 Proposal Opening Time:

2:00 PM09:00AM, Central Time

Proposal submissions for this Request for Proposal must be submitted through ARBuy, the State’s eProcurement system. It can be accessed at arbuy.arkansas.gov. Proposals received after the submission deadline may be rejected as untimely.

LIVE PROPOSAL OPENING INFORMATION

Teams Meeting Link: Click here to join the meeting

Meeting ID: 263 242 450 114

Passcode: knMSa9

Call in (audio only): 501.244.3310 or find a local number

TSS OFFICE OF STATE PROCUREMENT CONTACT INFORMATION

TSS OSP Procurement Specialist:

Tiffany Maddox Procurement Specialist’s Direct Phone Number:

501-324-9320

Email Address: Tiffany.Maddox@arkansas.gov TSS OSP’s Main Number: 501-324-9316

TSS OSP Website: transform.ar.gov/procurement/ https://arbuy.arkansas.gov/ https://teams.microsoft.com/l/meetup-join/19%3ameeting_YzkxZTliMGEtYzhhNy00N2E1LTg5Y2YtYjU3MzZjZTc2MjE3%40thread.v2/0?context=%7b%22Tid%22%3a%225ec1d8f0-cb62-4000-b327-8e63b0547048%22%2c%22Oid%22%3a%229e90e135-bbe1-4767-b7b7-ba808ff42eae%22%7d https://dialin.teams.microsoft.com/6b6513dc-a034-48d2-8d06-7e711c4ecc0b?id=719036839 https://www.transform.ar.gov/procurement/

Rev 12/2023

SECTION 1 – GENERAL INFORMATION AND INSTRUCTIONS

1.1 INTRODUCTION

This Request for Proposal (RFP) is issued by the TSS Office of State Procurement (TSS OSP) for the Arkansas Department of Finance and Administration (DFA) Office of Driver Services and Motor Vehicle (DSMV) to obtain pricing and a contract for a fully functional turn-key secure Mobile Driver’s License (mDL) solution.

Contract(s) will be awarded to the Prospective Contractor determined to have submitted the proposal that is the most advantageous to the State. Direct all questions, comments, or concerns regarding this solicitation to the TSS OSP, not the Department.

1.2 TYPE OF CONTRACT

A. As a result of this RFP, TSS OSP intends to award a contract to a single Contractor.

B. The anticipated starting date for any resulting contract is June 01, 2024, except that the actual contract start date may be adjusted unilaterally by the State for up to three (3) calendar months. By submitting a signed proposal in response to the RFP, the Prospective Contractor represents and warrants that it will honor its proposal as being held open as irrevocable for this period.

C. The initial term of a resulting contract will be for three (3) years. Upon mutual agreement by the Contractor and Department, the contract may be renewed by TSS OSP for up to four (4) additional one-year terms or portions thereof, not to exceed a total aggregate contract term of seven (7) consecutive years.

1.3 DEFINITION OF TERMS

A. Unless otherwise defined herein, all terms defined in Arkansas Procurement Law have the same meaning herein.

B. “Applicant” means the person who is applying for a Mobile Driver’s License or State ID card.

C. “Attended transactions” means the mDL Holder and the mDL Verifier are in close proximity of each other.

D. “Card” means either a Driver’s License (DL) or State ID card, or any other card dedicated to a specific purpose, with a specific format and defined set of data that may be produced by the Issuance System.

E. “Credential” means a Driver’s License or Identification Card.

F. “Customer” means a resident of the State of Arkansas with a valid Arkansas Driver’s license or State ID credential.

G. “Department” means Arkansas Department of Finance and Administration unless stated specifically.

H. "Device Retrieval” means the method that works without outside connectivity (for both the mDL holder’s device and the mDL reader) at the time the transaction takes place, thus requiring the mDL data to reside on the mDL holder’s device.

I. “Electronic Credential System” means A digital process that includes a method for provisioning Electronic Credentials, requesting and transmitting Electronic Credential Data Elements, and performing tasks to maintain the system.

J. “Facial Recognition” means a way of identifying a human face through biometric technology.

K. “Host System” means an information system of the State serving as System of Record (SOR) for information on which the solution anticipated by this RFP would be dependent. The SOR is from FAST Enterprise Inc.

L. “Mobile Driver’s License (mDL)” means Driver’s License or State Identification card that resides on a mobile device or requires a mobile device as part of the process to gain access to related information.

M. “Mobile Driver’s License App (mDL App)” means software running on a mDL holder’s device; within the context of this document this included a standalone app as well as a wallet type app.

N. "Mobile Driver’s License Installer (mDL Installer)” means a valid driver’s license or state identification credential holder who is downloading the mDL App for registration.

O. “Normal Business Hours” means 8:00 a.m. to 4:30 p.m. Central Time, Monday through Friday, excluding any State Holidays. Any time outside of these parameters is considered After Hours.

P. “Operator” means user who uses the SOR.

Q. “Prospective Contractor” means a responsible offeror who submits a proposal in response to this Solicitation.

R. " Push mDL function” means the issuing authority sends instructions to the mDL to prevent outdated mDL information being shared with the verifier.

S. The terms “Request for Proposal”, “RFP,” and “Solicitation” are used synonymously in this document.

T. “Requirement” means a term, condition, provision, deliverable, Specification, or a combination thereof, that is obligated under the Solicitation, resulting contract, or both.

U. “Responsive Proposal” means a proposal submitted in response to this Solicitation that conforms in all material respects to this RFP.

V. “Server Retrieval” means mDL data is retrieved in real time directly from the Issuing Authority.

W. “Shall” and “must” mean the imperative and are used to identify Requirements.

X. “Specification” means any technical or purchase description or other description of the physical or functional characteristics, or of the nature, of a commodity or service. “Specification” may include a description of any Requirement for inspecting, testing, or preparing a commodity or service for delivery.

Y. “State” means the State of Arkansas. When the term “State” is used herein to reference any obligation of the State under a contract that results from this Solicitation, that obligation is limited to the Department using such a contract.

Z. “Solution” means the mDL Solution unless otherwise clarified in context.

AA. "Unattended Transaction” means the mDL Holder and the mDL Verifier are not in close proximity to each other.

BB. “Update mDL function” means the data residing on an mDL device must be updated as soon as possible after an issuing authority applies a change to its database.

CC. “Verification Process” means a method of authenticating the mobile credential using secure encrypted communication.

1.4 SOLICITATION SCHEDULE

For informational purposes, TSS OSP is providing a Solicitation Schedule; however, dates listed and noted with an asterisk (*) are anticipated dates only and are subject to change at the discretion of the State. All times are listed in Central Time.

TABLE A: TENTATIVE SOLICITATION SCHEDULE

ACTIVITY DATE

RFP Release to Prospective Contractors March 1, 2024

Deadline for Prospective Contractor Questions March 11, 2024

Answers to Questions Posted to ARBuy* March 15, 2024

Proposal Due Date March 29, 2024 @ 2 pm

Initial Proposal Evaluation* April 2, 2024

Interviews* April 4 – April 5, 2024

Final Proposal Evaluation* April 9, 2024

Discussions Kick Off Meeting* April 10, 2024

Finalize Discussions* April 26, 2024

Post Anticipation to Award* April 29, 2024

Award Contract* June 1, 2024

1.5 CLARIFICATION OF SOLICITATION

A. Submit questions requesting clarification of information contained in this Solicitation via the

Solicitation posting in ARBuy by the date and time listed in Table A.

1. For each question submitted, Prospective Contractor should reference the specific Solicitation item number to which the question refers, as applicable.

2. Prospective Contractors’ written questions will be consolidated and responded to by the State as deemed appropriate. The State’s consolidated written response is anticipated to be posted to the Solicitation posting in ARBuy by the close of business on the date provided in Table A. If Prospective Contractor questions are unclear or non-substantive in nature, the State may request clarification of a question(s) or decline to answer.

B. The Prospective Contractor should notify the TSS OSP Procurement Specialist of any term, condition, etc., that precludes the Prospective Contractor from submitting a compliant, Responsive Proposal. Prospective Contractors should note that it is the responsibility of the Prospective Contractor to seek resolution of all such issues, including those relating to the terms and conditions of the contract, prior to the submission of a proposal.

C. Prospective Contractors may contact the TSS OSP Procurement Specialist with non-substantive questions at any time prior to the proposal opening.

D. An oral statement by TSS OSP will not be part of any contract resulting from this Solicitation and may not reasonably be relied on by any Prospective Contractor as an aid to interpretation unless it is reduced to writing and expressly adopted by TSS OSP.

E. Only an addendum written and authorized by the State will modify the Solicitation.

1. An addendum posted within three (3) calendar days prior to the proposal opening may extend the proposal opening and may or may not include changes to the Solicitation.

1.6 RESPONSE DOCUMENTS

A. All proposal responses must be submitted through ARBuy, the State’s eProcurement system. The system can be accessed at arbuy.arkansas.gov.

1. Prospective Contractors must be registered in ARBuy to submit proposals responses.

B. Technical Proposal Packet

1. Prospective Contractors shall utilize the Technical Proposal Packet to submit their responses.

2. The following items are proposal Submission Requirements and must be submitted as part of a Prospective Contractor’s proposal response.

a. Signed Proposal Signature Page; signature may be ink or digital.

https://arbuy.arkansas.gov/

b. Technical Proposal response to the Information for Evaluation section included in the Technical Proposal Packet, which must be in the English language.

c. Completed Official Solicitation Price Sheet attached to the Solicitation in ARBuy.

i. Pricing must be proposed in U.S. dollars and cents.

ii. Quantities stated are estimates only and are not guaranteed. Prospective Contractor must submit unit price on the estimated quantity and unit of measure specified.

• The State may order more or less than the estimated quantity on term contracts, and the Contractor shall sell to the Department quantities ordered at no more than the submitted price.

iii. All charges must be included on the Official Bid Price Sheet and must include all associated cost for items and/or services being bid.

iv. If pricing documents do not allow for accurate pricing, Prospective Contractor should notify the OSP Procurement Specialist at least seventy-two (72) hours before the proposal opening time.

v. Prices must be firm offers and adjustments may be negotiated at the time of contract renewal/annually/quarterly.

• A request for a price increase must include supporting documentation demonstrating that the increase in contract price is based on an increased cost to the Contractor and that the proposed pricing is still competitive in the marketplace. The State has the right to approve or deny any request for a price adjustment.

vi. Discount from list pricing is not acceptable unless requested elsewhere in the Solicitation.

vii. State or local sales taxes should not be included in the price. Trade discounts should be deducted from the unit price and the net price should be shown in the Pricing Response.

d. Recommended Options Form

i. The Recommended Options form included in the Technical Proposal Packet allows Prospective Contractors to identify any recommended options or optional service ideas that may benefit the State that were not included in the Requirements and the proposed solution.

e. Copy of Prospective Contractor’s Equal Opportunity Policy

i. Pursuant to Arkansas Code Annotated § 19-11-104, OSP requires a Prospective Contractor bidding on a state contract to submit a copy of the Prospective Contractor’s Equal Opportunity (EO) Policy.

ii. Prospective Contractors not required by law to have an EO Policy must submit a written statement to that effect.

f. Proposed Subcontractors Form (see SRV-1, section 14)

3. The following items, which must be submitted prior to a contract award to the Prospective Contractor, may also be included with the Prospective Contractor’s proposal:

a. EO 98-04: Contract and Grant Disclosure Form (see SRV-1, section 11)

b. Voluntary Product Accessibility Template (VPAT), if applicable

4. Prospective Contractors should not include any other documents or ancillary information, such as a cover letter or promotional/marketing information.

C. Redacted copy of the Technical Proposal Packet https://www.transform.ar.gov/wp-content/uploads/Services-Contract-SRV-1-Fillable-Form-V.3.6.27.22.pdf https://www.transform.ar.gov/wp-content/uploads/Services-Contract-SRV-1-Fillable-Form-V.3.6.27.22.pdf https://www.section508.gov/sell/vpat/

1. One (1) redacted (marked “REDACTED”) copy of the Prospective Contractor’s proposal response (see Proprietary Information), if applicable.

D. Prospective Contractors should not alter language in Solicitation document(s) or Official Proposal Price Sheet provided by the State.

E. Prospective Contractor’s proposals cannot be altered or amended after the proposal opening except as permitted by law or rule.

F. Prospective Contractors may submit multiple proposals.

SECTION 2 – REQUIREMENTS

2.1 BACKGROUND AND ENVIRONMENT

Act 261 of the 94th General Assembly requires Arkansas to have a digitized driver's license by February 1, 2025.

The mobile driver's license (mDL) is the future of licensing and proof of identity. An mDL is a driver's license that is provisioned to a mobile device capable of being updated in real time. It comprises the same data elements used to produce a physical driver's license; however, the data is transmitted electronically to a credential verifier for authentication. Arkansas driver's license (DL) and state identification (ID) holders can obtain an mDL to use as digital credentialing. The current driver's license system will remain in place, and the traditional hard copy license will still be issued as per the law.

This RFP is not for replacing the Driver’s License System of Record (SOR) or the physical Driver's License Card Issuance System.

2.2 OBJECTIVES AND GOALS

To obtain an mDL Solution that provides the ability for Arkansas credential holders to download an mDL App from mobile manufacturers and to use the mDL Solution as proof of identification for multiple purposes, including as a login to authenticate and validate authorization to conduct online services.

2.3 PROSPECTIVE CONTRACTOR MINIMUM QUALIFICATIONS

A. The Prospective Contractor shall have a minimum of one (1) years of implementation experience in the following areas:

1. Requirements gathering, design, development, testing, installation, customization, training, and deployment of an mDL Solution.

2. Disaster recovery for the complete mDL Solution.

B. The Prospective Contractor shall have successfully installed at least one (1) or more mDL Solutions for the same services as required in this RFP.

2.4 HOSTING

A. The Contractor shall propose a Contractor hosted mDL Solution.

B. All servers and data associated with the Arkansas instance of the Contractor Hosted Solution must reside in the continental United States.

C. The State prefers the proposed Solution be hosted on a private cloud or a virtual private cloud. For the purposes of this RFP, a private cloud is either a single-tenant environment where the hardware, storage, and network are dedicated to the State, or a virtual private cloud, a multi-tenant environment with network isolation and private subnets. Contractors may propose other types of cloud in their proposal, but preferential scoring will be given for private or virtual private cloud.

D. The Contractor shall perform all work on the proposed Solution from within the continental United States of America. The Solution must not be accessed from outside of the U.S.

E. The Contractor shall be responsible for the acquisition and operation of all hardware, software, and network support related to the hosting services being provided.

F. The Contractor shall develop and implement the Solution and all dependent hosted hardware in such a manner that allows for direct network communications with the Contractor’s Solution and the exchange of data via approved industry standard protocols for interfacing with other systems as deemed necessary.

G. The Contractor shall provision all environments.

H. The security controls employed within the mDL Solution must meet or exceed requirements specified within this RFP and any other applicable regulatory requirements.

I. The Contractor shall provide configuration information, evidentiary documentation, or other information as is required in the event the State requires such information as to satisfy regulatory audit requirements in relation to the solution.

J. The Contractor shall keep all hosting-related software current and up to date.

2.5 SYSTEM UPTIME AND PERFORMANCE

A. The Contractor shall provide a proposed Solution Uptime and Performance Plan during the

Discussions Phase.

B. Dedicated bandwidth will not be provided for the proposed solution and the solution must not negatively impact or interfere with services from other existing systems.

2.6 mDL SOLUTION & APP A. The Contractor shall provide a secure mDL Solution to be used for identity credential verification and for authentication of customers while using online services that will transmit data from an mDL App to an mDL Verifier.

B. The mDL Verifier must be able to cryptographically authenticate the mDL information using the Issuing Authority’s Public Key.

C. The mDL Solution must be a downloadable application (App) format for the major mobile device manufacturers (Apple, Google, and Samsung).

D. The mDL App must be free to download. DFA will collect a fee upon registration of the mDL.

E. The Contractor shall provide professional design, development, and customization services.

F. The mDL App must have the ability to authenticate the identity of the mDL Installer during the registration process by using facial recognition comparison between the photo image taken at the time of registration to the latest photo in the SOR.

G. The mDL Solution must be capable of functioning in device retrieval and server retrieval mode.

H. The mDL credential information must be interoperable between different mDL issuing authorities (other States) and verifying authorities.

I. A visual rendering of a mDL on a mobile device's display must not be static credential (flash pass) information/data, including the portrait image of the mDL holder when mDL is consumed by any verifier. Flash pass is not considered as a mDL solution.

J. The portrait image and the signature of the mDL holder must follow AAMVA standards. (See Regulatory Compliance)

K. Law Enforcement and other verifiers shall be able to verify the mDL credential presented by the mDL Holder. The mDL Solution must include an mDL verification App for verifiers to download from major device manufacturers.

L. The Contractor shall provide a Software Development Kit (SDK) which allows a verifier to build verification capability into its own point-of-sale (POS) software or other solution.

M. The mDL Solution must possess the technical ability for verifier to verify an mDL credential without having to touch the mDL Holder’s device.

N. The mDL App must ensure that the customer enrollee has a valid non-expired credential to enroll in the mDL Solution.

O. The mDL App must have the functionality to enroll and unenroll an mDL for a mDL Holder remote and in-office.

P. The State shall have the ability to unenroll a mDL at any time. Example: This request can come from the mDL Holder (lost the phone, decide not to have it on device) or when the mDL Holder receives an mDL in another state.

Q. All logs and metadata information must be removed from the mDL device when the mDL is unenrolled or when the mDL App is removed from the holder’s device.

R. The mDL Holder or Issuing Authority (DFA) shall be the only ones with authority to delete or suspend an mDL.

S. The mDL App must provide the mDL Holder complete control over which data elements to share with the mDL Verifier.

T. The mDL data must only be released to an mDL Verifier via an International Organization for Standardization (ISO)/International Electrotechnical Commission’s (IEC) compliance interface standard.

U. The mDL App must have predefined privacy views (e.g., prove my age, rent a car, board a plane, etc.) built into it for the mDL Holder’s convenience. The predefined privacy views must be displayed with the mDL App on the phone.

V. The mDL App must support an informed exit from the verifier request if the mDL Holder opts not to share the information.

W. The mDL App must have a provision for DFA to add a terms and conditions disclosure.

X. mDL Holder authentication must be required over and above the phone unlock process each time the mDL data is accessed or released. The mDL solution must support both facial recognition and PIN.

Upon registration, the mDL App must require the mDL Holder to submit both facial recognition to cross verify with the SOR portrait and a PIN. Once the mDL Holder has successfully registered in the mDL App, the mDL Holder shall have the option to sign in using either facial recognition or PIN.

Y. The mDL App must be configurable to lock out an operator after a State-assigned number of failed attempts to log in. The Contractor shall reset and unlock the mDL for the customer.

Z. The mDL App must keep an audit log of all mDL transactions and verification that is accessible only by the mDL Holder. The mDL Holder shall have access to enable and disable log storage.

2.7 MDL FEE

A. The mDL solution must allow for the collection of an mDL registration fee.

B. The mDL solution must allow for the collection of the registration fee on behalf of DFA in App prior to finalizing registration.

OR

C. The mDL solution must interface with a State provided payment solution and redirect applicants to the solution for payment.

D. The mDL solution must require that the registration fee is paid prior to the issuance of an mDL.

E. The Contractor shall be responsible for any invalid transactions, bank reversals, or other similar transactions made through a Contractor provided payment solution.

F. The Contractor shall design, develop, test, and implement all interfaces required between the proposed solution, mDL app, and/or SOR for this purpose.

G. All associated costs to the State and to the applicant (i.e. processing fees) must be included on the Official Bid Price Sheet. To price transaction processing or other such fees, the Contractor should assume issuance of 15,000 mDLs per year for pricing purposes. Per the Official Solicitation Price Sheet instructions, Prospective Contractor may add additional lines to include the proposed fees.

H. The Contractor may propose both options (or additional options not contemplated in this RFP) by including secondary options as part of the Recommended Options section of the Technical Proposal Packet.

2.8 REMOTE MANAGEMENT

A. The Contractor shall provide a push mDL function allowing issuing authorities to push out credential information or any driver services notification to the mDL device, an update mDL function in the mDL App that can be invoked by the mDL Holder to update credential information, and an auto-update mDL function in its mDL App. The push and auto update functions must include an accompanying notification to the mDL Holder.

B. Updates and notifications from the mDL Solution must be a part of the mDL framework.

C. DFA shall be able to push notifications to a single mDL Holder, group of mDL Holders, or all the mDL Holders.

D. The Contractor shall update any changes to the mDL data within a periodic timeframe to ensure the mDL is kept as current as possible.

E. The mDL App must update customers about support and backward compatibility for all Operating System (OS) platform versions and all new features available in newer mDL platform versions.

F. Notifications must be sent through the mDL App to inform customers of status changes to their driving record or any other pertinent information that would be communicated by DFA to customers.

2.9 WEB SERVICES REQUIREMENTS

A. The mDL Solution must integrate with the existing State Driver Licensing SOR for any data exchange between the mDL Solution and SOR. The SOR is in the .NET framework.

B. The mDL and mDL App must interface with the SOR via web service utilizing Representational State Transfer (REST) webservice to transmit mDL data elements in and from the SOR system.

C. The mDL App must be capable of consuming Host System web services which will be hosted utilizing the latest version of Transport Layer Security (TLS) which will provide encryption of the information while in transit between the mDL Solution and SOR.

D. DFA Office of Information Services shall be the final authority in approving the proposed format and authentication method for all interfaces used between the SOR and the Contractor’s proposed solution.

2.10 PUBLIC AND PRIVATE KEY INFRASTRUCTURE (PKI)

A. The Contractor shall host the IACA, ensure secure lifecycle management of keys (private and public), certificates, encryption of data, and key stores required to support the key infrastructure for the mDL Solution.

B. Communication between an issuing authority (DFA) and an mDL device must always be encrypted.

The process by which an encrypted channel is set up must not exchange information by which the mDL Holder can be identified.

C. Any mDL information must be stored in an encrypted form in the mDL Holder device. The mDL Solution must not store any mDL information in the App when mDL App is deleted/removed or unenrolled by the customer.

D. The Contractor shall work with DFA in aggregating and disseminating the IACA certificates and document signer for signing the mDL during enrollment.

E. The Contractor shall be responsible for providing the secure enclave to store IACA certificates as required under the proposed rule for TSA acceptance.

F. The Contractor shall not cache/store any mDL registrant information during mDL enrollment, after enrollment, or after unenrollment of the mDL App from the device.

G. The mDL Solution must not allow the mDL Holder’s usage or location to be tracked.

2.11 REGULATORY COMPLIANCE

A. The Contractor shall follow the most current AAMVA, ISO/IEC, and NIST implementation guidelines and standards, even if they are updated during the implementation phase.

B. The mDL Solution and mDL App that is produced by the Contractor must be fully compliant with State of Arkansas and Federal statutes including the Real ID Act and applicable regulations.

C. The mDL Solution and mDL App must follow AAMVA and mDL implementation guidelines and the ISO/IEC standards in the implementation guidelines to provide interoperability, offline identity with refresh option, and driving privilege verification capabilities between devices, etc.

https://aamva.org/getmedia/b801da7b-5584-466c-8aeb-f230cef6dda5/mDL-Implementation- Guidelines-Version-1-2_final.pdf

D. The mDL Solution and mDL App must meet or exceed all standards contained in the AAMVA data elements specifications for DL/ID Card Design Standards.

https://www.aamva.org/getmedia/99ac7057-0f4d-4461-b0a2-3a5532e1b35c/AAMVA-2020-DLID- Card-Design-Standard.pdf

E. The mDL Solution must adhere to security controls and organization support related policies and procedures that align with applicable National Institute of Standards and Technology (NIST) 800-53B moderate baseline security controls.

(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53B.pdf).

F. The Contractor shall provide interoperability testing results from NIST, and if available any other certifications and performance ratings related to identity fraud to ensure the proposed mDL Solution is compatible with AAMVA and ISO standards.

G. The Contractor shall capture requirements, design, make changes, test, and implement any State, Federal mandate, or AAMVA, ISO changes that affects the mDL Solution for no cost to the State for the duration of the contract. The Contractor must comply with the State, Federal, AAMVA, and ISO implementation deadlines.

H. The Contractor shall receive approval from DFA prior to the start of any updates.

2.12 ONLINE DASHBOARDS

A. The Contractor shall provide an online dashboard that, at minimum, provides the following real-time information:

https://aamva.org/getmedia/b801da7b-5584-466c-8aeb-f230cef6dda5/mDL-Implementation-Guidelines-Version-1-2_final.pdf https://aamva.org/getmedia/b801da7b-5584-466c-8aeb-f230cef6dda5/mDL-Implementation-Guidelines-Version-1-2_final.pdf https://www.aamva.org/getmedia/99ac7057-0f4d-4461-b0a2-3a5532e1b35c/AAMVA-2020-DLID-Card-Design-Standard.pdf https://www.aamva.org/getmedia/99ac7057-0f4d-4461-b0a2-3a5532e1b35c/AAMVA-2020-DLID-Card-Design-Standard.pdf https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53B.pdf

1. Number of overall mDL Holders in Arkansas.

2. Number of mDL unenrollment’s in.

3. Number of incomplete installations of mDL App.

4. Time taken to register an mDL.

5. App Store Ratings.

6. User-Related Device Characteristics (geography, type of device, and model).

7. Message notifications sent out successfully and failed.

B. The dashboard must allow data to be exported in a Microsoft Excel format.

2.13 STAFFING

A. The Contractor shall be required to provide a Staffing Plan during the Discussions phase.

B. PROJECT MANAGER

The Contractor shall include in the Staffing Plan a Project Manager. The Project Manager shall, at a minimum:

1. Have two (2) years of project management experience working with the implementation of projects of similar size and scope to this RFP.

2. The Contractor project manager shall report to the State assigned project manager and manage the Contractor resources, produce project schedule/plan, status reports, attend meetings, and manage the software development life cycle.

3. Coordinate with the DFA through a staff team to finalize a solution, implement technology components, and manage needed changes to project scope.

C. DFA shall have the right to approve or reject proposed staff members prior to the finalization of the plan after Contract Award.

D. The Contractor shall include, in the Staffing Plan, a provision to address the vacancies of the Project Manager or other key personnel. In the event of the vacancy of a key person, the Contractor shall provide replacement candidates to DFA for review within fifteen (15) Calendar Days of the Contractor learning of the vacancy. DFA shall have the right to approve or reject proposed replacements if they do not meet the minimum requirements set forth in the RFP.

E. The Contractor shall replace key personnel upon request by DFA for justified reasons including but not limited to performance, behavior, and security.

F. The Contractor shall provide and maintain sufficient staffing resources to provide timely service for the life of the contract.

G. The Contractor shall not propose resources who are currently engaged full time on other contracts with the State. A single resource may not hold more than one full time position with the State.

H. BACKGROUND CHECKS

1. At commencement of contract award and prior to the hiring of staff, DFA shall conduct Federal and State Criminal Background Checks on all personnel involved in any aspect of the process described in this RFP.

2. The Contractor shall provide information necessary to conduct Criminal Background Checks on all key personnel and subcontractors who perform or supervise work on this contract for purposes of auditing.

3. DFA shall have the right to refuse personnel based on results of the criminal background checks.

2.14 IMPLEMENTATION AND TESTING

A. The Contractor shall provide a proposed Implementation & Testing Plan during the Discussions

Phase.

B. The Contractor shall comply with Act 261 of 2023 and implement a soft launch of the mDL Solution on or before December 1, 2024, unless otherwise agreed to by DFA in writing.

C. The Contractor shall develop a soft launch plan to be completed at least thirty (30) days before the delivery of the soft launch of the solution. The soft launch must be reviewed and approved by the State.

D. The Contractor shall allow the mDL App to be downloaded to selected users during the soft launch period. The State will test independently, but also in a controlled environment with the Contractor so DFA can monitor and verify all the requirements listed in this RFP are met.

E. During the soft launch phase, the system must perform successfully under all normal operational conditions in accordance with the requirements of this RFP, Manufacturer’s operating instructions, and the Contractor’s technical and user specifications.

F. In the event that DFA is ready with the Transportation Security Administration (TSA) certification on or before UAT starts, the Contractor shall work with DFA to conduct testing with the TSA to ensure the mDL Solution is interoperable with TSA readers.

G. The Contractor shall work with DFA on field testing as part of Cooperative and Research Development Agreement (CRADA) certification with TSA to ensure that the mDL Solution will be accepted at the TSA checkpoints.

H. The mDL solution must be available (Go-Live) for all Arkansas Citizens on or before January 31, 2025, unless otherwise agreed upon by DFA in writing.

2.15 TRAINING

A. The Contractor shall provide a proposed Training Plan during the Discussions phase.

B. Contractor shall provide all training sufficiently in advance to the “Go-Live” of the proposed System such that all Users required to be trained have had a sufficient amount of exposure to capably use the system.

C. The Contractor shall provide rollout training that includes:

1. mDL Administration and mDL App training to DFA employees, and managers.

D. Online access to manuals for the Office of Driver Services (DSMV) staff and business partners. The Contractor shall be responsible for providing a continuing education program for the duration of the contract.

E. The Contractor shall provide at a minimum the following training materials for the life of the contract:

1. User manual

2. Frequently asked questions (FAQ) list

3. Helpline phone numbers and how to submit an electronic request for help.

4. Website URLs or location information for all other online and printed resources.

2.16 MAINTENANCE AND SUPPORT

A. The Contractor shall provide a proposed Maintenance & Support Plan during the Discussions Phase.

The Maintenance & Support Plan must, at minimum, meet the requirements set forth in this section of the RFP.

B. The Contractor shall be responsible for providing ongoing maintenance of the mDL Solution and mDL App for the life of the contract.

C. The Contractor shall provide ongoing customer and technical support beginning at the time of soft launch and continuing for the life of the contract. The Contractor shall:

1. Customer support shall be available to Arkansas citizens, between Monday – Friday 8:00 a.m. – 8:00 p.m. Central Time, excluding State holidays.

2. Provide English Speaking Telephone Support Staff.

3. Provide properly trained Customer and Technical Support staff in sufficient quantities to support DFA and Arkansas Citizens.

D. The State may at its discretion choose to cancel or reduce Customer support at any time during the life of the contract.

2.17 DATA SECURITY

A. The Contractor shall provide a proposed Data Security Plan during the Discussions phase.

B. The Contractor shall sign a Department approved Non-Disclosure Agreement (NDA) prior to award of the contract.

2.18 DISASTER RECOVERY

A. The Contractor shall provide a proposed Disaster Recovery and Business Continuity Plan during the

Discussions phase.

B. The Contractor shall include the following in the final plan(s):

1. Plan Objectives

2. What situations and conditions are covered by the Plan

3. Technical considerations

4. System failover plans

5. Roles and responsibilities of Contractor staff

6. How and when to notify the Contract Monitor

7. Recovery procedures

8. Procedures for deactivating the Disaster Recovery Plan

C. DFA will evaluate and test the Contractor DRP during testing by requesting that the Contractor completely failover all test/production systems to Disaster Recovery (DR) systems. DFA does not have to give advance notice for these requests. Any changes made to the production environment must have a demonstrated way to be replicated in the Contractor DR environment and must have a way for testing to be verified.

2.19 NEW TECHNOLOGY

A. The State is interested in obtaining an option for emerging or future technology related to mDL App and Identity validation systems.

B. Throughout the term of this contract the State shall have the right to add or remove any services or commodities offered by the Contractor under the scope of this contract. These services/commodities may be existing optional services/commodities as offered in the Contractor’s proposal, or they may be newly created services/commodities based on improving technology or complying with Federal or State mandates which fall under the scope of work.

C. Pricing for any of these services/commodities, which are not already submitted on the Official Price Sheet, must be negotiated if/when they are added; must be consistent with current contract pricing for similar services/ commodities; and must be agreed upon in writing between DFA and the Contractor prior to implementation of the service.

2.20 DATA OWNERSHIP AND END OF CONTRACT TRANSITION

A. The State shall retain sole ownership, right, title, and interest to all data collected and stored by the

Contractor under a resulting contract, excluding intellectual property and exclusions governed by applicable State and Federal laws.

B. At the end of the contract and after confirmed transfer of 100% of the State-owned data, deliverables, and products the Contractor has created, developed, produced, and managed while performing the services outlined in this RFP back to the State or their designee, the Contractor shall destroy all copies of the State-owned data the Contractor possesses.

C. The Contractor shall ensure all data received as part of the Contract is used solely for the purpose of this contract and not shared, reused, or disseminated to any other party or entity without the express written consent of the DFA designated representative or as otherwise required under applicable State and Federal laws.

D. Upon termination or expiration, should any subsequent contract for this or similar services be awarded to a provider other than the Contractor, the Contractor shall, to the greatest extent possible and reasonable, cooperate with the DFA in initiating a smooth and orderly transition to the next contractor.

2.21 PERFORMANCE STANDARDS

A. State law requires that qualifying contracts for services include Performance Standards for measuring the overall quality of services that a Contractor shall provide.

B. The State may be open to negotiations of Performance Standards prior to contract award, prior to the commencement of services, or at times throughout the contract duration.

C. Performance Standards must not be amended unless they are agreed to in writing and signed by the parties.

D. Failure to meet the minimum Performance Standards as specified will result in the assessment of damages.

E. In the event a Performance Standard is not met, the Contractor will have the opportunity to defend or respond to the insufficiency. The State has the right to waive damages if it determines there were extenuating factors beyond the control of the Contractor that hindered the performance of services. In these instances, the State has final determination of the performance acceptability.

F. Should any compensation be owed to the Department due to the assessment of damages, the Contractor shall follow the direction of the Department regarding the required compensation process.

SECTION 3 – SELECTION

3.1 SELECTION PROCESS

A. TSS OSP will review each Technical Proposal Packet to verify Submission Requirements have been met. Technical Proposal Packets that do not meet Submission Requirements will be rejected and will not be evaluated.

1. The State may conduct cost checks based on the cost submitted by each Prospective Contractor on the completed Pricing Response.

a. Prospective Contractors submitting Responsive Proposals with a proposed cost that falls twenty-five percent (25%) or more from the average submitted cost may be asked to justify their submitted cost.

b. Should TSS OSP request clarification and/or additional information regarding cost, Prospective Contractors shall provide clarification and/or additional information as specified by the request.

B. A Department-appointed Evaluation Committee will evaluate and score qualifying Technical Proposals. Evaluation will be based on Prospective Contractor’s response to the Information for Evaluation section included in the Technical Proposal Packet.

1. Members of the Evaluation Committee (Evaluators) will individually review and evaluate proposals and complete an Individual Score Worksheet for each proposal. Individual scoring for each Evaluation Criteria will be based on the scoring description in Table B: Scoring Table.

TABLE B: SCORING TABLE

SCORE DESCRIPTION

The response provides metrics clearly establishing that the Prospective Contractor is reliable and capable of fully performing the required services.

The response provides metrics suggesting that the Prospective Contractor’s level of performance may be acceptable, but it does not clearly establish that the Prospective Contractor is reliable and capable of fully performing the required services.

The response provides metrics clearly establishing that the Prospective Contractor is unreliable and incapable of fully performing the required services.

2. After initial individual evaluations are complete, the Evaluators will meet to discuss their individual scores. At the initial consensus meeting, each Evaluator will be afforded an opportunity to discuss his or her score for each evaluation criteria.

3. After Evaluators have had an opportunity to discuss their individual scores with the committee, the Evaluators will be given the opportunity to change their initial individual scores, if they feel that is appropriate.

4. The final individual scores of the Evaluators will be recorded on the Pre-Interview Consensus Score Sheets and averaged to determine the group or consensus score and rank for each proposal.

5. Other agencies, consultants, and experts may also examine documents at the discretion of the Department.

C. Prospective Contractors submitting Responsive Proposals will be contacted by TSS OSP to schedule an interview.

1. Prospective Contractors shall attend the interview as scheduled by TSS OSP.

2. Evaluators will complete an Individual Score Worksheet for each interview. Evaluation will be based on Prospective Contractor’s responses to questions presented during the interview Individual scoring for each interview will be based on the Scoring Descriptions in 3.1.B.1.

3. During a final consensus meeting, after all interviews are complete, Evaluators will have the opportunity to discuss the interviews and change their individual interview scores on the Post- Interview Consensus Score Sheet, if they feel that is appropriate.

4. The final individual scores of the Evaluators will be recorded on the Post-Interview Consensus Score Sheets and averaged to determine the group or consensus score and rank for each proposal.

D. During the final consensus meeting, cost information will be provided to the Evaluators to allow them to determine if moving forward with the highest-ranking Prospective Contractor is the most advantageous to the State.

E. Should the State request clarification and/or additional information Prospective Contractors’ responses, Prospective Contractors shall provide clarification and/or additional information as specified by the State.

F. TSS OSP will submit responses and pricing received from the interviewed Perspective Contractors, along with the Evaluation Committee’s recommendation to the Department for review and approval to move into Discussions.

3.2 TECHNICAL PROPOSAL SCORE

A. The Information for Evaluation section has been divided into sub-sections.

1. Each sub-section has been assigned a maximum point value of ten (10) points. The total point value for each sub-section is reflected in the table below as the Maximum Raw Points Possible.

2. The Department has assigned Weighted Percentages to each sub-section according to its significance.

INFORMATION FOR EVALUATION

SUB-SECTIONS

MAXIMUM

RAW

POINTS

POSSIBLE

SUB-SECTION’S

WEIGHTED

PERCENTAGE

* MAXIMUM

WEIGHTED

SCORE

POSSIBLE

Experience 10 30% 210

Solution 10 35% 245

Risk 10 15% 105

Interview 10 20% 140

Total Technical Score 40 100% 700

*Sub-Section’s Percentage Weight x Total Technical Maximum Weighted Score = Maximum Weighted Score Possible for the sub-section.

B. The proposal’s weighted score for each sub-section will be determined using the following formula:

(A/B)*C =D

A = Actual Raw Points received for sub-section in evaluation

B = Maximum Raw Points possible for sub-section

C = Maximum Weighted Score possible for sub-section

D = Weighted Score received for sub-section

C. The proposal’s weighted scores for sub-sections will be added to determine the Total Technical Score for the proposal.

D. Proposals that do not receive a minimum Total Technical Score of 300 will not be subject to further consideration in the Solicitation process. The pricing for proposals that do not receive a minimum Total Technical Score of 300 will not be scored.

3.3 COST SCORE

A. When pricing is opened for scoring, the maximum amount of cost points will be given to the proposal with the lowest seven (7) year grand total as shown in Table One (1) on the completed Pricing Response. (See Grand Total Score for maximum points possible for cost score.)

B. The amount of cost points given to the remaining proposals will be allocated by using the following formula:

(A/B)*C =D

A = Lowest Estimated Cost

B = Second (third, fourth, etc.) Lowest Estimated Cost

C = Maximum Points for Lowest Estimated Cost

D = Total price points received

3.4 GRAND TOTAL SCORE

The Technical Score and Cost Score will be added together to determine the Grand Total Score for the proposal. The State may move forward to Discussions with the Prospective Contractor determined reasonably susceptible of being selected for award.

MAXIMUM

POINTS

POSSIBLE

Technical Proposal 700

Cost 300

Maximum Possible Grand Total Score 1,000

3.5 EXPLANATION OF THE SUB-SECTIONS OF THE TECHNICAL PROPOSAL

A. Experience

1. The Experience sub-section included in the Technical Proposal Packet allows Prospective Contractors to differentiate themselves based on their experience, technical capability, and understanding of the State’s specific needs.

2. Prospective Contractors should identify expertise in the form of a claim and provide relevant experience to support each claim.

3. Prospective Contractors should use verifiable metrics (number of accounts, size of accounts, years of experience, customer satisfaction ratings) to support each claim.

B. Solution

1. The Solution sub-section included in the Technical Proposal Packet allows Prospective Contractors to differentiate themselves based on their proposed solution and/or approach to solve the State’s specific needs.

2. Prospective Contractors should provide a high-level overview of the Prospective Contractor’s proposed solution and/or approach to services using the Requirements outlined in the RFP.

3. Proposed solutions should be non-technical and include the Prospective Contractor’s recommendations for meeting the objectives and Requirements of the RFP.

4. Additional service options and recommendations above and beyond those included in proposed solution should be included in the Recommended Options Form.

C. Risk

1. The Risk sub-section included in the Technical Proposal Packet allows Prospective Contractors to identify and prioritize major risks that they reasonably foresee could potentially prevent or impair the Prospective Contractor’s delivery of the solution as offered in the proposal or to otherwise fail to meet the State’s desired outcome, specifications, and performance standards, and how they will mitigate, manage, and/or minimize each risk listed.

a. Prospective Contractors should include sources, causes, or actions that are both within and beyond the control of the Prospective Contractors that they reasonably foresee may cause cost increases, delays, amendments, or dissatisfaction to the State.

b. Risks should be described in simple, clear, and non-technical terms.

c. Prospective Contractor should explain how the Prospective Contractor will mitigate, manage, and/or minimize each risk listed.

i. The Documented Performance cell should include details such as how many times any identified risk was previously mitigated and the impact on the Prospective Contractor’s performance in terms of time, cost, and client…