Loren Data's SAM Daily™

FBO DAILY - FEDBIZOPPS ISSUE OF AUGUST 28, 2015 FBO #5026
DOCUMENT

D -- PIV NextGen RFI - Attachment

Notice Date

8/26/2015
 

Notice Type

Attachment
 

NAICS

541519 — Other Computer Related Services
 

Contracting Office

Department of Veterans Affairs;Technology Acquisition Center;23 Christopher Way;Eatontown NJ 07724
 

ZIP Code

07724
 

Solicitation Number

VA11815N0720
 

Response Due

10/15/2015
 

Archive Date

12/14/2015
 

Point of Contact

Brandon Caltabilota
 

E-Mail Address

5-1114<br
 

Small Business Set-Aside

N/A
 

Description

THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. Personal Identity Verification (PIV) System 3.0 This RFI is issued solely for delivery of information on Individual Credential Management Systems and/or solutions. It does not constitute a solicitation or a promise to issue a solicitation in the future. This request for information does not commit the Government to contract for any supply or service whatsoever. Further, the Department of Veterans Affairs (VA) is not at this time seeking proposals and will not accept unsolicited proposals for the effort described herein. Respondents are advised that the Government will not pay for any information, administrative, or shipping costs incurred in response to this request. All costs associated with responding to this RFI will be solely at the interested vendor's expense. All submissions to this RFI will be treated as business confidential materials, become Government property, and will not be returned or shared outside the Government. A.BACKGROUND On August 27, 2004 the President of the United States signed Homeland Security Presidential Directive-12 (HSPD-12), Policy for a Common Identification Standard for Federal Employees and Contractors, which mandated the use of Government-wide identification credentials for employees and contractors to enhance physical and logical security, increase efficiency, reduce identity fraud, and protect personal privacy. In February 2005, the Department of Commerce (DOC) issued Federal Information Processing Standards (FIPS) Publication 201, Personal Identity Verification (PIV) of Federal Employees and Contractors. This publication established the minimum requirements for agencies issuing credentials and for developing a Federal PIV System. On August 5, 2005 the Office of Management and Budget (OMB) issued Memorandum M-05-24, Implementation of HSPD-12, and Policy for a Common Identification Standard for Federal Employees and Contractors. On February 3, 2011 OMB released Memorandum 11-11, Continued Implementation of Homeland Security Presidential Directive (HSDP) 12. The combination of these directives established that all Federal PIV credentials must enable physical access controls to Federal facilities and logical access controls to Federal networks and electronic applications. The regulations provide Federal agencies and departments detailed logistical and technical specifications for the deployment of PIV credentials for their employees, contractors, and affiliates. On July 2, 2008, VA began its pilot program of credential issuance beginning at the VA Central Office (VACO). On August 13, 2009, VA expanded this pilot to include Veterans Health Administration (VHA), Veterans Benefits Administration (VBA), and other associated VA departments by establishing VA PIV Issuance Centers within VA facilities nationwide, as well as offices located in Alaska, Hawaii, and Manila Philippines. The VA solution utilizes multiple components for oversight of VA identity credential management including an identity management and provisioning system (IDMS) and a card management system (CMS). Since its inception, much of the technology and directives behind Federal smart card issuance have evolved and the VA PIV program now requires a technology redesign, development, and integration to enable a seamless incremental transition of VA's user population from the current legacy system to a new "next generation" PIV system which supports the evolution of smart card technologies. B.PURPOSE OF THIS RFI The Department of Veterans Affairs, Office of Acquisition and Logistics, Technology Acquisition Center (TAC), is seeking sources that are able to provide a full credential management solution. The VA PIV Program is mandated to provide compliant smart cards under HSPD-12 and all of its subordinate directives and regulations. The purpose of this RFI is to identify systems or solutions that can meet the multitude of VA desires. Understand that whatever applications a vendor offers must be HSPD-12 General Services Administration (GSA) approved products and must adhere to regulations subordinate to the HSPD-12 directive. The submission of a response does not constitute acceptance or solicitation of an order or a promise to order. Throughout this document the term solution is used which can also be subjugated to mean system or system of systems. The term credential management is understood to mean the combination of identity record(s), smart cards, certificates, and subordinate issuance activities. This RFI is concerned with application or software solutions and is not seeking descriptions or responses on hardware necessary to support the application or software solutions other than those items directly referenced within this RFI. VA's intent, with this RFI, is to find out what is or is not available in the current technological environment. Vendors are encouraged to respond to this RFI even if they cannot meet every requirement. As much knowledge can be gleaned from what is not possible as can be from what is possible. Some, but not all, of the relevant standards and specifications concerning this RFI, that the responder should be fully aware of are: HSPD-12, FIPS 201-2, FIPS 140-2, ISO 7810, ISO 7816, ISO 14443, ISO 18092, SP800-73, SP800-63, SP800-76, SP800-78, SP800-79, SP800-75 A/B, SP800-116, RFC 4122, OMB M04-4, OMB M11-11, and ANSI 378-2004. C. RESPONSE INSTRUCTIONS VA realizes much of what is covered in this RFI is highly technical and is not easily explained in limited fashion, but request the responder try and limit their responses to information requested in Section D. A fictitious example of a response is included in Appendix A for assistance formulating your response. When responding to this RFI, the following guidelines should be followed to the best ability of the responder: 1.The first page should be a cover sheet listing the Company Name, Cage Code, Duns Numbers, and title "Response to Personal Identity Verification (PIV) System 3.0." 2.The second page should be the Point of Contact (POC) sheet listing the following: a.Company Representative of the responder's contact information, which may be the Managing Director, President or Vice-President, Owner or overriding person responsible for the management of the company. b.Sales Representative or Company Government Representative contact information. c.Technical Representative or Technical Help Desk contact information. A company organizational chart would suffix for this POC page if the chart includes electronic mail address and phone number. ? 3.The third page should be the Evidence of Approval as a supplier, provider, integrator, or application manufacture providing solutions for HSPD-12 services or products under the HSPD-12 GSA managed systems. 4.The fourth page is the solution or company licensing model. If a solution is comprised of multiple applications or includes other applications not under the control of the responder, list those applications and manufacturer along with that company's licensing model if not inclusive in the responder's model. By licensing model, VA is looking for how the application(s) are licensed; unlimited, per user, per biometric conversion, per client or station, etc. There are many ways to license a solution or application and the manner at which the responder licenses their product(s) should be covered on this page. 5.Starting with the fifth page are the responses to each and every item listed under section "D. Requirements and Parameters". Specifically, each item should be listed with the following information: a.Item number and title from section D, b.Answer "Yes" or "No" - Yes being the offered solution does contain this item or can perform this function or has the support of the item in question. No would indicate this is not something which the responder's solution does not support. c.An explanation of the answer "Yes" - if the response is "yes" then the explanation would state if this item: i.is a component of the solution meaning it is built into or coded into the solution (or company directly supports this item,) ii.is integrated into the solution meaning it is delivered through enterprise class Commercial-Off-the-shelf (COTS) products (or company manages/has rights of use but another party provides the item,) iii.is coupled meaning a different application or software solution is included offering the service to deliver the item (or this item is supported or supplied by a third party. This would directly relate to applications included on the Licensing Model on page 4 of the response,) iv.is a component of the solution that is under development and the estimated delivery date into the production solution, d.An explanation of the answer "No" - if the response is "no" but the solution does offer something similar or different method for the item can be explained. 6.On the second to last page, describe or place an insert showing the company's Software Development Life Cycle specifically related to its HSPD-12 PIV Credential solution. 7.The final page(s) would be notes or items of further explanation. This page is an open forum for information deemed important to the responder. On this page(s), might be a list of known hardware needed to support a single instance of the solution, or additional features the responder's solution provides that were not covered within the items listed throughout Section D. 8.Responders may have additional questions so any RFI Clarification Questions should be submitted to the Contract Specialist, Brandon.Caltabilota@va.gov and Charles W. Ross, Contracting Officer, at Charles.Ross@va.gov. 9.Responders RFI Final Responses should be emailed to the POCs listed in paragraph 8 above by Thursday, October 15, 2015, 12:00 PM Eastern Standard Time. D. REQUESTED PARAMETERS While not always specifically mentioned all the items below should assume to include HSPD-12, FIPS, and National Institute of Standards and Technology (NIST) regulations as the controlling factors. Any response is required to meet the directives of HSPD-12, FIPS, and NIST regulations and assumed to be so unless specifically mentioned otherwise. 1.GENERAL A.General Delivery - Does the responder provide design, architecture, engineering, development, integration, deployment support, testing, and training personnel as an integrated service line? B.Life Cycle Management - Does the responder's solution support the full life cycle of the credential? In this case "life cycle" is defined as the initial identity creation, multiple levels of approval, new issuance, reissuance, renewal, revocation, rejection, auditing, reporting, and removal of the credential associated with an identity meeting the requirements of HSPD-12 and its subordinate regulations. C.System - Is the responder's solution a holistic system in regard to the overall application management of identity credentials which includes identity management, card management, and credential management as an integrated solution, meaning a manufactured single system verses multiple manufactured systems integrated or coupled together? D.Active Directory - Is the responder's solution Microsoft Active Directory aware and supports a multiple distributed domain environment, meaning the application(s) integrated with AD which includes the ability to join a Microsoft 2008 R2 Enterprise Active Directory as a member server, communicate across distributed domains and consume Microsoft Active Directory User Object attributes at the Organizational Unit level for identity population with customizable filter methodologies as a function of the delivered system? E.Operating Systems - Does the responder's solution support installation, configuration, and operation within a Microsoft Windows 64-bit platform? Is Microsoft 64-bit operating systems supported at the issuance client level on Microsoft Windows 7 and at the application and web services level on Microsoft Windows Server 2008 R2 and/or Microsoft IIS web platform? F.Load Distribution - Does the responder's solution support load distribution of client to server communications based on well-known standards and methods? This load distribution could be from either a hardware load distribution device, such as an F5 Big IP, or through Microsoft Active Directory URL management. G.Hardware Security Module (HSM) Support - Does the responder's solution support key material and certificate functions based on Luna 4/5 platforms and/or does it support the general PKCS #11 standard? H.Population - Is the responder's solution capable of delivering a FIPS 201-2 compliant PIV and PIV-I credential to all VA persons of interest which are VA's employees, contractors, affiliates, and volunteers with an estimated population of approximately 850,000 individuals with a turnover rate of approximately 15% per year? I.Technical Support Normal - Does the responder provide technical support assistance demands from VA during daily PIV operational times Monday through Friday from 6 AM to 9 PM EST period? J.Technical Support Emergency - Does the responder provide emergency technical support of a systematic outage affecting all credential issuance within two (2) hours during daily PIV operational times Monday through Friday from 6 AM to 9 PM EST period? K.Technical Support Upgrades - Does the responder provide advanced technical support for periodic afterhours or weekend systematic changes or upgrades when scheduled between VA and responder's support manager? L.End-to-end - Does the responder's solution provide end-to-end troubleshooting and trouble sectionalization tools for both application and systems investigation with error conditions, error messages, or system outages? M.Development Support - Does the responder's solution allows for and provide all Application Program Interface (API) tools, libraries, guides, and manuals in support of customization of the responder's solution by VA personnel? N.System Training - Does the responder provide multiple hours of training and/or certification in various support models directly related to the solution and/or application components of the solution? Is this training provided by the responder or through a third party education service or a combination of both? This training may include administrations, development, technical support, or areas specific to the responder's solution. O.Audit - Does the responder's solution provide a full detailed method for audit tracking and reporting? At a minimum the audit should include a time of day stamp, the account name, the user account, and the action performed on any accessed record including: searching, viewing, editing, approving, and deleting of applicant records or user objects. P.Protected Data - Does the responder's solution provide a method to "tag" specific executive level identities allowing for more advanced auditing or alerting based on that specific records access by a specific user? Q.Capacity Planning - Does the responder's solution collect near real time transaction and usages data which will provide trend analysis for future performance and capacity planning purposes? R.Scalability - Does the responder's solution provide scalability in its design; meaning when system or service resource(s) is/are being taxed, can additional servers and/or services be added without having to add a full instance of the solution? S.Monitoring - Does the responder's solution provide an integrated monitoring component for critical system or service functions with electronic alert with customized thresholds executing in near real time? 2.APPLICATION A.Certificate of Authority - Does the responder's solution have the ability to communicate to multiple Certificate Authorities? A listing of authorized CAs and intermediate CAs can be obtained from information available on the Federal Bridge Certification Authority (FBCA) website. Specifically, the solution should be compatible with Unicert (UPI), Entrust, and Microsoft certificate services. B.Certificate Issuance - Does the responder's solution include the ability to encode multiple certificate types as directed by HSPD-12 and FIPS201? Is this ability customizable and meet both required and optional credential types covered under FIPS 201 and VA directives (PIV, PIV-I, and Identity cards)? C.Key Management - Is the responder's solution able to automatically recover escrow key material(s) for access through the card production service component of the card management system for use during the device encoding process? Is the process, application, or solution to revoke, escrow, and recovery fully automated? D.Key Material - Does the responder's solution include the ability to customize the location, repository, and escrow data storage locations where certificate key material may be contained? Does the solution support either CMS, HSM, or CA managed repositories? E.Multiple Card Types - Does the responder's solution provide for the customization of multiple card types as defined by both FIPS 201 and VA directives? For example: VA PIV credential comes with and without logical access. When a credential is selected without logical access, a PIV Authentication certificate is still present on the card but is tied to the account name of the IDMS record and does not include a Digital Signing or Key Management certificate. Alternatively, a PIV credential with logical access includes the identities VA AD UPN for injection on the PIV Authentication certificate and includes the Digital Signing and Key Management certificates which are tied to the VA AD SMTP identity attribute. F.Different Card Types - Does the responder's solution provide for the customization of specific credential types based on multiple attributes of an identity? For example; FIPS requires that all Employees are issued PIV credentials, therefore, an issuance request for an identity who's employment type is "Employee" should only be able to receive a PIV credential, while a VA contractor may not have the correct background investigation as specified by FIPS so could only receive a VA PIV-I type credential. G.High Availability - Does the responder's solution support a highly available operational environment? To meet this criteria the solution is able to support at least one method of redundant services for all aspects of the given solution including: applications, web services, administrative services, directory services, data base services, provisioning services, auditing services, and reporting services in such a manner that any single service failure or outage will not halt the entire system or process for the end user. H.Disaster Recovery - Does the responder's solution support a multi-location disaster recovery configuration? There are many components of a system which will determine the method the responder's solution may meet this need. It is understood the responder is not responsible for or expected to provide the network or communication method to deliver the DR solution. At the minimum the solution should maintain a real time synchronization of all identity and credential issuance data between two geographically separated locations. I.Derivative Credential - Does the responder's solution support derivative credentials and is this support respective of FIPS? Is the derived credential associated with the PIV applicant record but still allows for the revocation of either the PIV or derived certificate without affecting the other credential? J.Third Party Recovery - Does the responder's solution support a method for third party recovery of certificates associated with an identity credential in such a manner that revoked certificates can be recovered to a secondary device? K.Data Storage - Is a single data store in the responder's solution used for the storage of all data? Does the data storage component of the responder's solution support encryption for the entire data element? Does the responder's solution support a hash functions for stored data based on certificate associations or some other element which automatically notes if a data set was changed upon recall? L.Incremental Transition - Does the responder's solution have the capability to function in a concurrent environment with a legacy system so the transition from one system to the other can staged while the systems are active parallel? M.Data Consumption - Does the responder's solution have the capability, tools, utilities, or expertise to convert already collected data from a legacy system to the data store used by responder's solution? 3.REPORTING A.Reporting Options - Does the responder's solution provide both static and dynamic reporting methods related to the life cycle management of identity credentials and system processes? Is the reporting function an integrated component of the responder's system or a separate component that is integrated or coupled with the system? The reports should be configurable and allow for customizable configurations to meet VA business reporting needs. B.Reporting Endpoint - Does the responder's solution provide a reporting mechanism which allows for external connections that are above or behind the actual data storage system used by the solution to ensure external connections do not cause systematic problems or interruption of end user client systems? For example: the main data repository is not directly queried by any external system. C.Reporting External - Does the responder's solution provide a reporting mechanism which allows for external read only connections that are configurable to the extent that specific issuance record data attributes can be selected for presentation to the connector? For example: customized reporting scripts may be written for specific business needs which should never have the capability to collect, view, or access PII information within the user records. D.Reporting Query - Does the responder's solution provide a reporting mechanism which utilizes a standard query language set such as LDAP,.Net, Java, etcetera? E.Reporting Print Times - Does the responder's solution provide a report which displays the true print/encoding time of a given record? True print time is defined as the time from request submission to delivery of physical card topology to clients Windows Print Spooler. F.Reporting Accepted Time - Does the responder's solution provide a report which displays credential acceptance numbers on a daily, weekly, monthly, yearly, and historical time frame? 4.BIOMETRICS A.Biometric Fingerprint - Does the responder's solution provide a full chain of record for collected fingerprints on per record level? Specific details of this item can be found within FIPS 201-2. The biometric fingerprint service(s) must meet all biometric federal regulations including the display of the minutia score. Does the biometric solution support the CrossMatch LSCAN Guardian for fingerprint captures? B.Biometric Verification Fingerprint - Does the responder's solution provide a method for verification based on the collection of the user's fingerprint(s) and comparison of the encoded minutia from the card? This verification can be "on" or "off" the card but must meet the requirements of FIPS for verification processing. Does the solution support the CrossMatch Verifier 310 LC USB device for the capture of fingerprints for comparison? C.Biometric Override Fingerprints - Does the responder's solution provide a method for overriding the requirement of fingerprint collection by the client? Is the solution supporting a systematic method of ensuring the collection attempts as specified within FIPS 201-2? At a minimum the solution must ensure the override is properly approved by the collector before allowing the override, and that the override approval is an audited event (logged.) D.Biometric Iris - Does the responder's solution provide a full chain of record for the collected iris image or template on per record level? Does the solution of iris collection include a method or process for overriding the collection? The solution must ensure the override is properly approved by the collector before allowing the override, and that the approval is an auditable event. E.Biometric Verification Iris - Does the responder's solution provide a method for verification based on the collection of the user's iris and comparison of the encoded image/template from the card? This verification can be "on" or "off" the card but must meet the requirements of FIPS for verification processing. F.Biometric Photograph - Does the responder's solution provide a full chain of record for the collected photographic image on a per record level? Does the capture of photograph include a "photo size" assurance prior to submission or storage? A photo size check is to ensure the size and structure of the photo meets the print demands under the topographic card regulations. Does the solution support both the Canon Rebel T5 Digital Camera and Logitech C920-C Webcam? G.Biometric Verification Photo - Does the responder's solution provide a method for verification based on the comparison of the encode image (photo) from the card with that of the person physically presented to collect the credential? This verification shall be "off" the card, is an audited event, and must meet the requirements of FIPS for verification processing. The verification by photo must only be available if neither fingerprints nor iris were collected. H.Biometric Recall - Does the responder's solution provide a method for the recall and reuse of all biometric components while maintaining the chain of record? Is this recall capability customizable based on information contained or collected within the identity record attributes? For example: an issuance type of renewal, where the validation date has not expired, would use the recalled biometric data while an expired re-issuance shall not be allowed use of recalled biometric data. I.Biometric Hardware - Does the responder's solution provide support of, or be capable of providing support of, all biometric collection hardware approved under the HSPD-12 GSA APL for biometric collection hardware devices. While a given system may not come ready to support all approved devices, a true method of delivering support of the hardware must exist. 5.INTERFACES A.Administration - Does the responder's solution provide a distinct and differential administrative interface for the various credential administrative functions including, but not limited to; record inspection, record editing, record state movement, audit reporting, and credential activities (certificate hold, revocation, and release). Are all administrative actions performed against any specific record auditable events? B.BI Confirmation - Does the responder's solution provide a method allowing for the confirmation of background check adjudication data? At a minimum the solution would allow the communication of applicant specific information to OMB's Personnel Investigations Processing System (PIPS) or to the Federal Bureau of Investigation (FBI) clearing house allowing for electronic confirmation of an applicant's background status. C.BI Collection - Does the responder's solution provide the capability to function as the collection portal for 10 fingerprint agency background submission with automated electronic confirmation of the applicant's status? This would include collection and submission for the FBI National Criminal History Check (NCHC) or a Special Agreement Check (SAC). D.External Interface Inbound - Does the responder's solution provide a method allowing for secure connections with external endpoints which is customizable to the point of defining these connections as read only and read/write, and include a method to restrict viewing of specific data attributes? For example: an Enterprise Dashboard system may need a read only connection to the credential issuance data to collect and display issuances numbers, but this connection cannot have access to PII information contained within any record while active directory services might need read/write capabilities. E.External Interface Outbound - Does the responder's solution provide a method which allows for secure connections with external endpoints which is customizable to the point of defining the attributes for data population within the responder's solution? For example: an endpoint would be the Enterprise VA AD domain and allow for a system query which can then return user object attributes used to populate data points within the credential record. F.External Interface Component - Does the responder's solution provide a method of allowing for external connections that is above or behind the actual data storage system used by the system to ensure external connections do not cause systematic problems or interruption of end user client systems? For example: the main data repository is not directly queried by any external endpoint. G.Scheduling - Does the responder's solution provide a scheduling component or integrate with a scheduling tool for biometrics capture, credential issuance, and credential proctoring? H.Kiosk - Does the responder's solution have a defined interface for a kiosk solution for PIN reset and/or renewal biometric collection? Is this feature based on biometric confirmation and/or PIV Authentication? I.Certificate Authority Encoding - Does the responder's solution provide a method which maintains the certificate(s) associated with the Identity credential so that in the instance of an encoding or printing failure the revocation and reissuance of a user certificate(s) is not necessary for a retry of the same submission? For example: if a user attempts to encode and print the same applicant's credential multiple times, only one set of certificates associated with the credential are utilized. J.Card Issuance Printer - Does the responder's solution provide support of HSPD-12 GSA APL card encoder printers so that the solution delivers the card production service to the physical system with the end result of an HSPD-12 FIPS complaint credential? K.Printer Support - Does the responder's solution support multiple encode print devices, to include the Fargo HDP5000 and the Fargo HDP8500 encoder printers? Does the client side of the solution support multiple printer types on the same client and/or IP encoding printing? L.Card Issuance Update - Does the responder's solution provide the ability to update specific FIPS approved components of an issued applicant's credential through remote services? This process is commonly referred to as "post issuance card update". M.Solution Services - Is the responder's solution installable, configurable, operational, and technically supported in a totally virtual environment? The virtual environment is specifically in a VMware or Microsoft virtual services hosting. 6.PORTAL A.Portal - Does the responder's solution provide a non-intrusive client interface which supports the Microsoft Internet standard without the need of "plug-in's" (i.e. Active X or Java controls)? The responder's solution may support multiple interface types but does it support this type of configuration as one such interface? B.Issuance Approval - Does the responder's solution provide for multiple approval states of a card issuance application in accordance with FIPS? For example: if the client interface is used for data point collections (identity) does the workflow of the solution allow for multiple approval roles (Manager, Sponsor, Issuer, and Registrar) at issuance milestones as directed by FIPS 201? C.Portal Fields - Does the responder's solution provide easy customization of the end user interface collection points (fields contained within displayed forms) including customization of the form and field validation scheme? D.Portal Access - Does the responder's solution provide for configuration of role based access on the condition of procession of a valid PIV Authentication certificate and provide for the condition where the end user's PIV Authentication certificate was issued from a different system? For example: most of the VA population has been issued an identity credential, and access to the next system should not require reissuance to gain access to the new system. E.Role Access - Does the responder's solution provide for role-based access control? If this answer is "no", then how does the solution control access privileges provided at the end user level? F.Role Level - Does the responder's solution provide a customized level of access at the granular level so specific field access can be controlled? Does the solution provide a customized level of access at the task level so only allowed tasks can be performed? G.Record Association - Does the responder's solution provide a function or ability for a "work list" or "task list" based on any type of linkage or past actions? For example: if an applicant record at the issuance state is associated with a facility ID and an Issuer is associated with the same facility ID number then the issuer would have the ability to produce a work list which associates the issuance task by the facility ID number. H.CMS - Does the responder's solution provide automatic card manufacture detection and select the appropriate communication parameters based on that detection for encoding purposes? I.PACS - Does the responder's solution provide any integration or notification to physical access control systems as an integrated function of the credential solution? If so is this interface to a specific manufactures system or is it customizable to a standard interface type? J.CPS - Does the responder's solution provide a card production service which is easily customizable allowing for changes on attribute data linked to population of specific physical card topology zones? K.Field Masking - Does the responder's solution have the ability to mask or force data entry into given fields? For example: if entry into the first name field is to be all capital letters even if the user types in lower case the data is converted to all upper case as it is submitted. Another example: if the requirement for a given field is a maximum of 3 letters and only letters, the solution has the ability to force this mask onto the data field. L.Data Collection - Does the responder's solution provide the ability to customize the data fields and data attributes of the client interface using a well-known programming or scripting language such as.Net, Java, C++, excreta? 7.CLIENT A.Data Submission - Does the responder's solution provide the ability to customize data submission button(s) within the interface (form) which is linked to the digital signing certificate contained on the end user's PIV card? Is the submission button configurable to the extent that biometric confirmation/validation could be enforced through the submission button? B.User Interface - Does the responder's solution provide a method for queuing user submission if a specific service is unavailable so that the user is warned of the queuing, the data is saved, and the user is able to continue with other actives on other records? C.Display Search - Does the responder's solution provide for state search returns, meaning if the applicant record is in a specific task, like ID Proofing for example, and the user searches for records, only those records ready for that specific task are returned in the search results? D.Save Form - Does the responder's solution provide for a save button allowing for the instance where an incomplete form can be partially filled, held, and recalled for later completion by that user? E.Unique Identifiers - Does the responder's solution provide a method or function which ensures the non-duplication of critical identity and credential identifiers to ensure that neither the identity or the card's electronic identifier are duplicated within the system or data storage? F.Client Compatibility - Does the responder's solution provide a method for an end user to verify the compatibility of their workstation with a given set of parameters required for a successful operation with the solution? Does the solution provide a method for a connection check which can confirm connection speed from client to server? G.Client Portal - Does the responder's solution provide separate and visually distinct portal interfaces for separate roles and are these interfaces displayed based on assigned privileges? For example, a given user might have multiple access privileges (Registrar and Issuer) so would have multiple portal rights which are displayed separately (like a Menu or Tab for each role) but would not see the interface of a Sponsor because the privilege of a Sponsor is not assigned to the user's access. H.My Status - Does the responder's solution support a method for applicants to view their own status during the reissuance process through a common interface or URL? ? APPENDIX A: FICTITIOUS EXAMPLE Page 1 of response Company Name: Chip's Smart Credential Solutions, 123 Some Street, Some Place, NW 10101 Cage Code: ##########-### DUN Number: ########### Response to Personal Identity Verification (PIV) System 3.0 Page 2 of response (Contact Information> Company Owner: Chip Smart, chip.smart@smartchip.net, 101-111-2221 Government Sales Representative: Alice Pki, alice.pki@smartchip.net, 101-111-2222 Technical POC: Bob Pki, bob.pki@smartchip.net, 101-111-2223 Page 3 of response Copy of GSA Approval Letter as HSPD-12 solution provider or integrator Page 4 of response Provide Solution is whole owned, developed, and operated by company. License is a onetime purchase with system solution, yearly maintenance cost, and user biometric conversions on a per storage model. Application License: $1.00 per application server Yearly Maintenance: $1.00 per application server per year Biometric Storage: $1.00 per user record Page 5 of response General Subject A.General Delivery - Yes, Chip's Smart Credential has a dedicated team of project managers, system engineers, application developers, and technical support staff who are all employees or contractors of the company B.Life Cycle Management - Yes, Chip's Smart Credential system is a fully integrated identity credential management system which includes an identity management and credential provisioning system which is fully integrated with its Chip's Card Management System. C.System - Yes, all applications, methods, and services within our solution is integrated together under a single user interface and are all supported by our company. ¦.. Page 6 - Copy of Chip's Software Development Life Cycle for its HSPD-12 product line. Page 7 of response Our system is a.Net system and utilizes Microsoft IIS services for all application level display functions. This allows for.Net application development which extends VA the ability to completely customize all aspects of the display forms. A single instance of our solution would require one IIS server, one SQL database server, one biometric collection server, one identity management server, and one multiple application server (reporting, directory, etc.)
 

Web Link

FBO.gov Permalink
(https://www.fbo.gov/notices/31381abd2f81720a5e0c05763c7bf930)
 

Document(s)

Attachment
 

File Name: VA118-15-N-0720 VA118-15-N-0720.docx (https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=2279736&FileName=VA118-15-N-0720-000.docx)

Link: https://www.vendorportal.ecms.va.gov/FBODocumentServer/DocumentServer.aspx?DocumentId=2279736&FileName=VA118-15-N-0720-000.docx

 

Note: If links are broken, refer to Point of Contact above or contact the FBO Help Desk at 877-472-3779.
 

Record

SN03856745-W 20150828/150826235704-31381abd2f81720a5e0c05763c7bf930 (fbodaily.com)
 

Source

FedBizOpps Link to This Notice
(may not be valid after Archive Date)

---

| FSG Index  |  This Issue's Index  |  Today's FBO Daily Index Page |