DHS.ST.SVIP-Blockchain-Preventing_Forgery_Counterfeiting_(Release 2)-FOR-POSTING.pdf

PREVENTING FORGERY &

COUNTERFEITING OF

CERTIFICATES AND

LICENSES (RELEASE 2)

Other Transaction Solicitation Call # 70RSAT19R0000002/0001 https://www.dhs.gov/science-and-technology/svip DHS-Silicon-Valley@hq.dhs.gov

DHS S&T Silicon Valley Innovation Program (SVIP)

Preventing Forgery & Counterfeiting of Certificates and Licenses (Release 2)

SVIP OTS Call 70RSAT19R0000002/0001

1. Introduction

This Other Transaction Solicitation (OTS) Call 70RSAT19R0000002/0001 is being reissued against the Department of Homeland Security (DHS), Science & Technology (S&T), Silicon

Valley Innovation Program (SVIP), 5-Year Innovation OTS (HSHQDC-16-R-B0005). All terms and conditions of the DHS S&T SVIP 5-Year Innovation OTS (HSHQDC-16-R-B0005) remain incorporated into this Call unless otherwise noted herein.

The U.S. Department of Homeland Security (DHS) is committed to using cutting-edge technologies and scientific talent in its quest to make America safer. The DHS Science and

Technology Directorate (S&T) Silicon Valley Innovation Program (SVIP), on behalf of DHS

Operational Components, invests in startup companies with viable technologies suitable for rapid prototyping projects from across the nation and around the world to adapt, develop and harness cutting-edge capabilities that are commercially sustainable while simultaneously meeting the needs of DHS Operational Components and Programs.

1.1. DHS Operational Need

Decentralized and Distributed registry and time-stamping implementations such as Blockchain and

Distributed Ledger Technology (DLT), from a government perspective, holds the potential for enhanced transparency and auditing of public service operations, greater visibility into multi-party business operations, and automation of paper-based processes to improve delivery of services to organizations and citizens.

DHS Operational Components and Programs have common needs across their mission sets for potential use of interoperable implementations of these technologies that also support the growth and availability of a competitive marketplace of diverse technology implementations for government and industry to draw upon to deliver cost effective and innovative solutions.

This SVIP Call seeks technical capabilities that could serve the mission needs of one or more DHS

Operational Components and Programs including:

● U.S. Citizenship and Immigration Services (USCIS)

● U.S. Customs and Border Protection (CBP)

● DHS Privacy Office (PRIV)

1.2. Illustrative Use Cases

There exists across DHS Components and the Homeland Security Enterprise the need to issue identifiers, entitlements, attestations and certifications for a variety of purposes including travel, training, education, affiliation, organizational identity, delegated authority and supply chain security. Current issuance processes are often paper based, non-interoperable and are susceptible to loss, destruction, forgery, and counterfeiting.

The following illustrative scenarios / use cases are intended to describe where the technologies being sought by DHS in this topic call could potentially be applied. DHS is not necessarily seeking the technologies for these specific use cases but instead are providing them to give some context for interested parties.

At the same time, given that responses to this OTS Call may be relevant to these and other use cases, it is expected that an applicant will use one or more of these DHS specific scenarios to frame their application.

1.2.1. Scenario I: Alternative Identifier to the Social Security number

The U.S. Department of Homeland Security Privacy Office is responsible for preserving and enhancing privacy protections and promoting transparency in Department operations. Accordingly, the Privacy Office has initiated a Social Security number (SSN) reduction initiative in support of its Privacy Policy Instruction 047-01-010 Social Security Number Collection and Use Reduction.

As a part of this privacy policy, the DHS Privacy Office requires the use of a unique alternative identifier to the SSN. The application of technologies sought in this topic call could potentially enhance the implementation of the initiative by ensuring that:

● The alternative identifier is meaningless by itself, but globally unique;

● The alternative identifier does not leak personally identifiable information (PII) or information considered sensitive by a person or DHS;

● Public exposure of the alternative identifier does not allow for it to be used as an authenticator or shared secret;

● When needed and allowed by policy, the alternative identifier can be shared and resolved across systems, agencies and organizations without compromising its security and privacy properties; and,

● The alternative identifier is based on global standards to ensure interoperability across and availability within diverse future COTS products.

1.2.2. Scenario II: Food Supply Chain Safety and Visibility

U.S. Customs and Border Protection (CBP) has a complex mission at ports of entry with broad law enforcement authorities tied to screening imported cargo that enters the United States at more than

300 land, air and sea ports. Additionally, CBP along with Partner Government Agencies (PGA) are in charge of protecting U.S. consumers from entering illegal and harmful food products. Principal

PGAs for food import inspection include the US Department of Agriculture (USDA) as well as the

Food and Drug Administration (FDA). CBP and PGAs rely on country of origin data from importer documentation. Validating the point of origin for food products by CBP/PGA requires costly inspection and cannot be implemented at scale. The application of technologies sought in the topic call could potentially enhance the CBP capabilities to:

• Enhance the visibility of food supply chains (from farm to point of purchase).

• Enable the application of appropriate duties.

• Reduce spoilage and waste.

• Reduce paper documents.

• Expedite inspection times.

• Enhance targeting.

1.2.3. Scenario III: Supply Chain Traceability of Natural Gas Imports

With the onset of the United States-Mexico-Canada Agreement, U.S. Customs and Border

Protection (CBP) is identifying opportunities to enhance facilitation and enforcement missions through additional data exchange and modernization of processes. CBP is investigating potential applications for blockchain and blockchain-enabling identity technologies. Validating point of origin and supply chain traceability is complex within continuous flow imports. Existing work is https://www.dhs.gov/publication/privacy-policy-instruction-047-01-010-ssn-collection-and-use-reduction https://www.dhs.gov/publication/privacy-policy-instruction-047-01-010-ssn-collection-and-use-reduction being done within crude oil, however, natural gas tracking and tracing include further complexity.

Natural gas purchases are displacement based, and fluctuations in demand lead to additional complexity import/export declarations. The application of technologies sought in the topic call could potentially enhance CBP capabilities to:

• Allow paperless identification of private sector and government actors related to natural gas exchange

• Facilitate communication between national, state/provincial governments, and private sector entities

• Increase transparency in natural gas exchange between Canada and the US

• Connect supply chain documentation (ex. purchase orders, bills of lading) to related import/export declaration

• Accounting for en route storage and resale

• Simplified in-bond processing

• Avoiding OFAC violations

• Standardized / streamlined reporting in all CBP ports of entry

• Simplified USMCA Claims and Verifications

• Reduced exposure to customs errors caused by third parties

1.2.4. Scenario IV: Supply Chain Traceability of Direct-to-Consumer E-Commerce Shipments

U.S. Customs and Border Protection (CBP) must adapt to the changing ways business is conducted due to the increasing volume of low-value packages, driven by direct-to-consumer e-commerce.

Total e-commerce sales for 2019 were estimated at $601.7 billion, an increase of approximately

14.9 percent from 2018. CBP processes more than 600 million express consignment and international mail shipments a year – approximately 1.8 million a day. The unprecedented growth in volume of these low-value shipments requires creative solutions to interdict illicit and dangerous products to enter the United States, including illicit narcotics, unregulated prescription drugs, brand counterfeits, and unsafe food and beauty products. Transnational criminal organizations are shipping illicit goods to the United States via small packages due to a perceived lower interdiction risk and less severe consequences if the package is interdicted. Furthermore, new or infrequent importers, generally created through the growth of marketplace sites, often possessing less familiarity with U.S. customs laws and regulations, which can lead to the importation of non-compliant goods. Access to data earlier in the process could provide CBP visibility, analytics and optimization, reducing counterfeits and friction in the process, and enable legitimate trade. The application of technologies sought in the topic call could potentially enhance the CBP capabilities to:

• Enable Importers/websites/sellers to classify merchandise

• Build in automated Duty payments

• Connect all parties involved in the transaction to build a transparent supply chain o Traceability of packages from internet purchase to consumer o This includes shipping for all modes of transportation and postal

• Improve targeting on illicit goods and identify emerging risks

• Ease the burden caused by the increased in quantity of package

• Ensure importers to comply with Customs and other Partner Government regulations, particularly small item sellers that may be unintended importers

• Create a better and more simplified way of entering goods into the US

• De minimus

1.2.5. Scenario V: Privacy Respecting Essential Work and/or Task License

The COVID-19 global pandemic has made clear the role that essential workers play in ensuring the continuity of operations in emergency response, supply chain fulfillment, essential business, and other previously overlooked areas of interest and the need for them to self-identify in the performance of their duties. In addition, there continues to exist the need for individuals to interact in-person with DHS to conduct official tasks, duties and appointments while ensuring public health and safety.

Given the reality that certain areas of the economy will need to continue to operate in parallel for an extended period of time while effective counter-measures are being developed, the ability for workers and individuals conducting essentials tasks to assert their respective eligibility in a manner that safeguards their individual privacy and civil liberties while ensuring public health is a critical need. The eligibility criteria will be law and policy driven to support federal and state efforts around public health. The application of technologies sought in the topic call could potentially enhance DHS capabilities to:

• Assert and validate the eligibility of individuals conducting official tasks such as applicants for citizenship, asylum, and other immigration benefits who need entry to DHS offices for the purpose of conducting these official tasks.

• Enable digital representations of currently paper based documentation such as vaccination records or medical releases in a manner that preserves security and ensures the privacy of the individual.

• Assert and validate the eligibility of persons conducting travel designated as essential

• Assert and validate the eligibility of persons conducting business designated as essential

2. Topic Description

DHS is interested in solutions that address the challenges of interoperable digital identifiers and entitlement attestations that support individual privacy, control and accountability of data release, while incorporating digital counter-fraud technologies and tactics, enterprise lifecycle management, and a high degree of usability across service delivery modalities.

2.1. Security, Privacy and Interoperability Guidance

This potential for the development of “walled gardens” or closed technology platforms that do not support common standards for security, privacy, and data exchange would limit the growth and availability of a competitive marketplace of diverse, interoperable solutions for government and industry to draw upon to deliver cost effective and innovative services based on Blockchain and distributed ledger technologies.

Industry is leading the way in the development of these technologies, as many see implementing blockchains and DLTs as a key competitive advantage. The private sector’s significant investments and the ability to adopt technologies and processes faster than the public sector has presented the government with a key decision point on how to best participate in this growing field.

DHS has chosen to approach this decision point in a strategic manner that leverages its strengths and is aligned with its missions. Our investments in time, treasure and talent over the last five years include:

1. Developing, through its DHS Science & Technology Directorate (S&T), an unbiased understanding of when it makes sense to utilize this technology as well as the necessary implementation expertise regarding its security, privacy and interoperability aspects

2. Investing in business-driven proof-of-concept implementations with forward leaning

Operational Components to identify scalable integration architectures and determine the gains and the pains of adopting and integrating the technology with existing infrastructure and business processes

3. Motivating and shaping innovative and potentially risky product development that supports security, privacy and interoperability to meet the operational needs of its Components via the DHS Silicon Valley Innovation Program (SVIP)

As such, this call will require any proposed solution to incorporate the lessons learned from

DHS investments in R&D, specifications/standards, and proof-of-concepts that has resulted in our support for existing and emerging standards-based protocols, data exchange formats and security policy frameworks to ensure interoperable integration with enterprise systems.

The International Organization for Standardization (ISO) uses specific verbal forms to convey clarity on what is a requirement and what is a recommendation or other type of statement. This

Topic Call adopts and uses the following ISO document conventions:

● Requirements - SHALL, SHALL NOT

● Recommendations - SHOULD, SHOULD NOT

● Permission - MAY, MAY NOT

● Possibility and Capability - CAN, CANNOT

2.2. Scope of Work

There are a variety of challenges that must be overcome to provide a capability that supports the multiple entities that are part of any such process while ensuring the security, privacy, interoperability and integration with existing back-end processes.

The graphic above provides a high-level and conceptual view of the multiple entities involved in any such process.

Holder A person, organization or non-person entity that controls a Digital Wallet or Personal Data Store that stores entitlements, attestations and certifications and key management materials.

Issuer An authoritative source that is capable of issuing credentials e.g.

Government Agency, Employer etc.

Verifier An entity that validates integrity and provenance of the credentials provided by the Holder and ensures that the credentials asserted belong to and are relevant to the Subject of the credential which may or may not be the Holder.

Resilient Registry

Infrastructure

The infrastructure that supports the public validation of potentially private data (e.g. credentials) without the need to directly store that data.

This may be a blockchain, a DAG, or some other distributed, massively fault tolerant data storage mechanism.

There is no expectation that all of the entities in the model above are managed or operated by a single entity but instead represents an ecosystem that enables a pluralism of operators and technologies to ensure interoperability, encourage diversity, and prevent technology lock-in.

In such an implementation, providing Issuer facing and Verifier facing Application Programming

Interfaces (APIs) that are publicly documented, patent free, royalty free, non-discriminatory and available to all mitigates technology and vendor risk to Issuers and Verifiers while simultaneously providing the technology provider the ability to utilize innovative and possibly proprietary technologies behind the API.

To that end, the following are specific items to be incorporated into each Technical Topic Areas

(TTAs) listed below to ensure that solutions are secure, privacy respecting, scalable and interoperable:

● All APIs that are presented to the Issuer and the Verifier SHALL be publicly documented, patent free, royalty free, non-discriminatory, available to all, and free to implement using widely available and supported programming languages.

● The solution SHALL incorporate, if appropriate to the particular use case, the following emerging specifications and/or standards for interoperability that have been funded, tested and/or championed by DHS:

○ Verifiable Credentials Data Model (Standards Development Organization - W3C)

○ Decentralized Identifiers (Standards Development Organization - World Wide Web

Consortium / W3C)

○ JavaScript Object Notation for Linked Data / JSON-LD (Standards Development

Organization - W3C)

● The Subject SHALL have control over and be accountable for the release of their data

(credentials) to the Verifier

● The solution SHALL provide very high resistance to data deletion, modification, masking or tampering e.g. Show equivalency or better between the digital solution and physical security features currently required official licenses and certificates.

● The solution SHALL NOT have a dependency on a single Resilient Registry Infrastructure.

● The Identity Verification component that is implemented between the Subject/Holder and the Verifier SHALL use standardized, strong authentication technologies that is at least

Authenticator Assurance Level 2 (AAL2) compliant as documented in NIST Special

Publication 800-63 Revision 3 (or later).

● The solution SHALL support Federal Information Processing Standard (FIPS) compliant cryptographic algorithms for hashing, encryption, digital signatures, random number generation and any other relevant cryptographic operations that are performed as part of the solution to ensure its ability to be operationally deployable on a US Government network.

● The Subject/Holder SHOULD have the ability to selectively disclose credential information with consent

● The solution SHOULD support online and offline presentation of Credentials to the

Verifier

● The solution SHOULD support non-Certificate Revocation List (Non-CRL) based revocation methods (Issuer initiated, Person Initiated, Multi-Sig based and others) that removes Issuer dependencies i.e. “Phone Home Problem”.

NOTE: Following the initial release of this Call and its subsequent awards to a cohort of startup companies, that cohort in concert with the global technical community, has actively worked together in a public and transparent manner to incubate and move into formal W3C standardization pathways via the W3C Credential Community Group (W3C CCG), a set of emerging specifications that ensure global, multi-vendor interoperability for this technology that is a critical requirement of meeting the needs of DHS. Those emerging specifications include:

• Secure Data Stores (Encrypted Data Vaults)

W3C CCG & DIF joint work item https://identity.foundation/secure-data-store/

• WebKMS https://w3c-ccg.github.io/webkms/

• Verifiable Credential Issuer API https://w3c-ccg.github.io/vc-issuer-http-api/index.html

• Verifiable Credential Verifier HTTP API https://w3c-ccg.github.io/vc-verifier-http-api/index.html

• Revocation List 2020 https://w3c-ccg.github.io/vc-status-rl-2020/

• BBS+ Signature Linked Data Proofs https://github.com/w3c-ccg/ldp-bbs2020

It is expected that any company awarded under this call will actively participate in and support as relevant to their implementation, these emerging specifications as they mature to become global

W3C standards.

3. Technical Topic Areas (TTAs)

DHS is seeking technologies and solutions that address this need via one or more of the following

TTAs.

While DHS is interested in meeting the goals of all the TTAs, we want to make it clear that is not a requirement and as such you are encouraged to apply even if your prototype project meets only one TTA.

3.1. TTA #1: Issuance and Verification of Certificates, Licenses and Attestations

Issuers are the authoritative sources of any credentials and it is desirable to provide the maximum flexibility in the solutions they can integrate with by ensuring a consistent set of integration points.

The Issuer is expected to integrate with two (2) solution capabilities:

1. Credential Issuance – Provides a standardized mechanism to issue a Credential to a Holder via a secure process. It is expected that the Credential(s) will be stored and managed in a secure environment that is under the control of the Subject of the Credential e.g. A hardware wallet, Secure element in a mobile device, etc.

2. Credential Registration - Provides a standardized mechanism to register a record in a manner that ensures its integrity and validity as of a particular point in time and its provenance on a Resilient Registry Infrastructure that allows for public validation of potentially sensitive Credential data without storing that data directly on the Resilient

Registry Infrastructure and to validate the source as being the Issuer.

Verifiers are the entities that validate the credentials provided by a Subject and ensure that the

Credentials asserted belong to and are relevant to the particular Subject who provides them. As such it is desirable to provide them maximum flexibility in the solutions they can integrate with by ensuring a consistent set of integration points.

The Verifier is expected to integrate with two solution capabilities:

1. Identity Verification – Demonstrating proof of ownership of a Credential is not a Resilient

Registry Infrastructure specific technology but instead is the application of existing standardized, strong authentication technology. As such it is expected that existing and standardized strong authentication technology SHALL be used (e.g. OIDC, FIDO2 etc.)

that support at least Authenticator Assurance Level 2 (AAL2) compliance as documented in NIST Special Publication 800-63 Revision 3 (or later).

2. Credential Validation – Provides a standardized mechanism to validate the integrity of an issued credential as of a particular point in time, that it has not been revoked, and to ascertain that came from a trusted Issuer.

Analysis and recommendations that support and articulate the trade-offs associated with particular implementation choices are an important aspect of the information sought as part of any proposed solution.

3.2. TTA #2: Storage and Management of Certificates, Licenses and Attestations

The Digital Wallet or the Personal Data Store under the control of a Subject can take many forms including hardware tokens, secure elements in mobile devices, secure web application and more.

What has typically been missing from the current implementations has been lifecycle management of such capabilities from an Enterprise perspective combined with the ability to plug in to standardized APIs.

This TTA is directly focused on enabling a set of technologies that deliver the following outcomes:

● Integration with multiple Issuers via standardized APIs for:

○ Credential Issuance and Registration as noted in TTA #1

○ Identity Verification and Credential Validation as noted in TTA #1

● Enterprise managed provisioning, revocation and re-issuance of keys and credentials stored within the Digital Wallet or Personal Data Store

● Support for Enterprise driven key recovery rather than social key recovery mechanisms

Given the criticality of key management to any such solution, DHS expects that the baseline requirements for any such capability SHOULD use NIST Special Publication 800-130: A

Framework for Cryptographic Key Management Systems as a starting point and that a ‘design pattern’ and a reference implementation will be made available in a manner that allows for public, transparent and expert review of the security, privacy and cryptographic analysis of the solution.

3.3. TTA #3: Decentralized and Derived PIV Credentials

Federal Information Processing Standard (FIPS) 201 originally required a common set of credentials in a smart card form factor, known as the Personal Identity Verification (PIV) Card which is currently used U.S. Federal Government-wide, as intended, for both physical access to government facilities and logical access to Federal information systems.

While the use of the PIV Card for electronic authentication works well with traditional desktop and laptop computers, it is not optimized for mobile devices. In response to the growing use of mobile devices within the Federal government, FIPS 201 was revised to permit the issuance of an additional credential, a Derived PIV Credential (DPC), for which the corresponding private key is stored in a cryptographic module with an alternative form factor to the PIV Card.

Conceptually, a Hardware Digital Wallet under the control of a Holder that contains Decentralized

Identifiers and Verifiable Credentials serves the same purpose as a cryptographic module containing a DPC.

This TTA is directly focused on enabling the following outcomes:

● Development of an architecture that allows for a single managed hardware wallet that supports DPCs, Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs)

● Applying Fast Identity Online (FIDO) and W3C Web Authentication (WebAuthN) standards that are standardized ways of performing public-key based authentication in the consumer space to DPC standards and usage.

● Unifying the enrollment and authentication experience across DPC and DID/VCs from an

Enterprise Perspective

● Consistent User Experience when using DPCs and DIDs/VCs

4. Project Deliverables and Phases

DHS S&T anticipates making phase 1 awards of $50,000 to $200,000 in funding for each award, covering a period of performance of 6 to 9 months. Successful projects will be eligible for subsequent phases of funding with similar levels of funding and duration.

The SVIP is structured in 4 Phases, with an opportunity to award a Phase 5 on a case-by-case basis for further testing/piloting in additional operational environments and potentially addressing additional use cases. Accordingly, a project receiving 4 phases of funding may receive a total of

$200,000 to $800,000 over a total period of performance of 24 months.

Phases 1-4 cannot exceed $200,000 per Phase for a total of $800K.

At the end of this period, DHS S&T intends that successful projects will have reached a sufficient stage of development for a potential test deployment, or commercial availability to stakeholders, including potential follow on production ordering by DHS.

The Government, solely at its discretion, may determine that further operational testing is required, and in such cases may award a Phase 5. If a Phase 5 is awarded, it will be scaled to meet the operational requirement in both length of time and cost, therefore a Phase 5 is not restricted to the limits set forth in Phases 1-4.

Phase detail is listed in the following chart.

Phase Funding Level Deliverables Due Date

1 $50,000 to

$200,000 payable on OTA award

Prototype development to address DHS challenge

6-9 months after award

2 $50,000 to

$200,000 payable on OTA award

Further prototype development to demonstrate viability

6–9 months after successful completion of Phase 1

3 $50,000 to

$200,000 payable on OTA award

Prototype demonstration and functional and red team testing

6–9 months after successful completion of Phase 2

4 $50,000 to

$200,000 payable on OTA award

Operational test and evaluation in multiple user scenarios

Begin after successful completion of Phase 3

5 TBD at the

Government’s discretion

Additional operational testing which may include additional use cases in additional operational environments

Begin after successful completion of Phase 4

Referring to the table above, the required milestones and deliverables for each phase should incorporate the objectives defined as follows:

● Phase I: Delivery of a Minimum Viable Product that demonstrates proof-of-concept and supporting documentation inclusive of verifiable test evidence, technical drawings, software demonstrations or other proof that the technical approach to address a DHS requirement or challenge as identified in this Call is sound. At the end of this Phase, successful applicants will have:

○ Either created a proof of concept of a new technology suitable for demonstration or;

○ Produced reviewable modifications to pre-existing technologies suitable for demonstration

○ Validate the proposed architecture and design to incorporate interoperability specifications

○ Validate digital security criteria equivalency to existing paper-based security features.

○ Evaluate the design of the APIs

○ Evaluate support for Federal Information Processing Standard (FIPS) compliant cryptographic algorithms

○ Articulated a go-to-market commercialization strategy

● Phase II: An end to end working prototype with full capabilities. Objectives of this phase are to use the results of Phase 1 to build out all features and functions in the prototype to demonstrate viability. At the end of Phase 2, the prototype must:

○ Implement the architecture and design to support needed capabilities

○ Ensure that APIs are fully documented and are available for public review

○ Demonstrate the implementation of interoperability specifications within the solution

○ Demonstrate end-to-end operational viability

○ Be ready for independent review and evaluation

○ Validate the commercialization strategy with potential customers and partners

● Phase III: Production ready prototype that will be deployed into a realistic test and evaluation environment to experiment against realistic conditions and to undergo an independent test and evaluation process to ensure operational suitability. These tests will be fully coordinated with the DHS component and operational stakeholders and it is anticipated that all independent testing feedback will be incorporated into the technology solution by the end of this Phase. Objectives of this phase are to:

○ Demonstrate a fully functional end to end capability

○ Support the functional, security, privacy and interoperability testing and validation of the capability by an independent Red Team

○ Incorporate the feedback and results of the independent test into the prototype

● Phase IV: At this phase, technologies would be fully completed designs and reputably provide all proposed features and functionality. Any tests and demonstrations in this Phase will be fully coordinated with the DHS component and operational stakeholders and may result in a limited number of prototypes or licenses of the technology in order to conduct the testing in multiple user scenarios and conditions. Objectives of this phase are to:

○ Deploy the capability for operational testing and demonstration

○ Incorporate and adjust the capability based on the operational testing

● Phase V: Phase 5 awards are made only to meet a Government need and additional testing requirements. The additional testing may be done in different environments using additional use cases. This Phase may result in a limited number of prototypes or licenses of the technology in order to test the prototype in multiple user scenarios and conditions. In order to meet an identified Government need, this phase may be funded beyond the total

$800K Phase 1-4 limits.

In order to make sure the project is on target and meeting relevant milestones and deliverables, the awardee will provide Monthly Project Status Reports, due at the end of the reporting month. In addition, a telephone conference call will be conducted each month to discuss project status and any issue/concerns/problems, questions that the awardee may have.

5. General Information and Instructions

5.1 Response Dates

Event Time Due Date or Date Due

Virtual Industry Day

Register to attend at:

www.regfox.com/dhs-svip-blockchain-call-2-industry-day

8:30 AM – 12:30

PM PT* June 23, 2020

Applications Due: Applications will be accepted on a continuous, rolling basis until the application deadline. The deadline for submitting the application is listed on the right. Applications must be received prior to the deadline to be evaluated in the review cycle.

12:00 PM PT* July 10, 2020

Notification of Application Pre-Oral Presentation

Evaluation Results N/A

Approximately 3-4 weeks following an application deadline

Oral Pitches N/A

Approximately 4-5 weeks following an application deadline

(if requested)

Closing Date/Final Deadline 12:00 PM PT* July 10, 2020

* Eastern Time (ET), Pacific Time (PT)

Applications and Application resubmissions received after the closing date/time will not be considered for review.

DHS may decide to close the call early. If this occurs, DHS will publish notification 30 days prior to closing the call.

5.2 General Instructions

5.2.1 Written applications as described in 5.3 must be received by the deadlines in the following e-mail box: DHS-Silicon-Valley@hq.dhs.gov . Applicants will receive a reply to the application email acknowledging receipt. Any invitations for oral pitches will be coordinated with the applicant and may be conducted by videoconference or in-person.

5.2.2 DHS S&T reserves the right to select for award and to fund all, some, parts, or none of the applications received in response to this OTS solicitation.

5.2.3 The Evaluation Criteria in DHS S&T SVIP 5-Year Innovation OTS (HSHQDC-16-R-B0005)

Section 7 “EVALUATION OF APPLICATIONS” applies.

5.3 Application Requirements

5.3.1. To be considered for award, Applicants MUST do the following:

http://www.regfox.com/dhs-svip-blockchain-call-2-industry-day http://www.regfox.com/dhs-svip-blockchain-call-2-industry-day mailto:DHS-Silicon-Valley@hq.dhs.gov mailto:DHS-Silicon-Valley@hq.dhs.gov

• Submit a written Preventing Forgery & Counterfeiting of Certificates and

Licenses (Release 2) application in Adobe PDF format using the application template provided with this call.

o An architectural Intellectual Property diagram must be included in the application document.

o The total number of pages including the application and diagram must not exceed 10 pages.

o Applications must describe the work proposed for Phase 1, answering the questions as outlined in the Preventing Forgery & Counterfeiting of

Certificates and Licenses (Release 2) Application Form.

o Applications should also provide an overview/strategy for the overall effort for each Phase.

o Only content contained in the application will be considered during the review process. No other documents, videos or links to information will be considered. Applicants should be alert for any amendments and changes to this Call.

o Create a user account and register their company in https://www.sam.gov/SAM/This does not need to be done at the application phase but must be done if the applicant is chosen to pitch and provides a successful pitch.

o The successful applicant must have a registered https://www.sam.gov/SAM/account in order to be awarded and funded.

• Applications must be compliant with the aforementioned response dates and other compliance requirements in accordance with the DHS S&T SVIP 5-Year Innovation OTS

(HSHQDC-16-R-B0005).

o Submissions not in compliance will be rejected.

DHS will conduct reviews following the submission deadline and anticipates that reviews will be completed within approximately 3 – 4 weeks following the submission deadline.

The Government may request Applications for other phases and will do so directly with the Company.

5.3.2. The OTS evaluation criteria published in the DHS S&T SVIP 5 Year Innovation OTS

(HSHQDC-16-R-B0005) will be utilized for the application evaluation process, and specific to this call, applications will be reviewed for:

• Ability to help DHS operational missions or critical infrastructure facilities;

• Applicability to the DHS use case(s) described;

• Financial soundness of the company, and the business model based on the technology to be supported;

• The scalability and cost-effectiveness of the proposed technology or solution;

• Existing relationships with relevant end users, stakeholders and/or consumers.

• Other Criteria …

5.4. Application Format

See the Preventing Forgery & Counterfeiting of Certificates and Licenses (Release 2) Application posted with this call.

5.5. Pitch Format and Requirements

Applicants invited to present pitches will be limited to fifteen (15) minutes for their oral presentations. In addition, applicants making pitches may provide up to ten (10) slides for presentation in either Microsoft PowerPoint or Adobe PDF.

5.6 Contractual or Technical Inquiries

All contractual or technical inquiries to this OTS Call 70RSAT19R0000002/0001 must be emailed to DHS-Silicon-Valley@hq.dhs.gov. Emails submitting questions are to include “Questions:

Preventing Forgery & Counterfeiting of Certificates and Licenses (Release 2) OTS” in the subject line. All questions and responses will be posted on the beta.sam.gov website https://beta.sam.gov/. Questions will only be accepted and answered electronically.

5.7 Order of Precedence

In the event that any of the terms and conditions contained in this OTS Call

70RSAT19R0000002/0001 conflict with terms and conditions included in SVIP 5 Year Innovation

OTS (HSHQDC-16-R-B0005), the terms and conditions in this OTS Call

70RSAT19R0000002/0001 shall take precedence.