This is the home page for the Fisheries Information System (FIS) Electronic Reporting (ER) e-signature project. This is a project of the United States National Oceanic and Atmospheric Administration (NOAA) Fisheries Service (NMFS).

The purpose of this project is to establish an approved process for implementing eSignatures for use with electronic reporting systems. This project will review the requirements of the Agency's eSignatures policy (32-110) and procedural directive (32-110-01), evaluate alternative methods and procedures, and develop a standard approach for implementing eSignatures for electronic reporting. This project is a planning, design, and plan approval exercise, and this project is not a system development process resulting in implemented production systems. Of course a development process (and/or procurement) is eventually intended, but it is not part of this phase.

Background

During the Electronic Reporting Planning Workshop held in July 2007, it was determined that a clear process for implementing e-signatures for electronic reporting would be of significant benefit to multiple regions. The FIS project management process annually considers proposals from members and partners for projects that can further FIS goals. A proposal was submitted requesting FIS funding for a project to review the requirements of the Agency's e-signatures policy (32-110) and procedural directive (32-110-01), evaluate existing methods and procedures, and develop a standard approach for implementing e-signatures for electronic reporting.

The proposal was funded in 2008. The FIS ER E-signature project was operational from June of 2008 through June of 2009. During the active period project collaboration was facilitated by this wiki space. As a final deliverable of the project, this wiki space has been re-oriented to provide guidance and structure to future e-signature initiatives. While the focus has been changed, most of the original content has been preserved under the assumption that the guidance and structure may be most useful when seen in the context of our project activities. In a few places the original documents have been edited to change present or future tense to past tense, or to annotate original deliberations with the benefit of hindsight. But mostly the original content has been left in place as it was drafted during the project, and, the refocusing for future relevance is primarily concerned with providing the roadmap, checklist and examples of deliverables sections.

At some future date e-signature alternatives, risks and benefits may become so well understood that e-signature solutions are readily transferable among problem domains. Or perhaps our agency may have a range of well-known solutions and a project seeking an e-signature solution can choose from a menu. However, while e-signatures remain novel, risk and cost/benefit tradeoffs are unclear, and legal precedents untested, each e-signature implementation should be individually vetted through the Agency's e-signatures policy (32-110) and procedural directive (32-110-01). This site should make it possible for e-signature projects to leverage experience from other practitioners and jump-start a new e-signature initiative.

Note that this project was all about a planning, design, and plan approval exercise, and this project does not specify a complete development process resulting in implemented production systems. Of course a development process (and/or procurement) may eventually be necessary, but if so, it will be documented elsewhere.

How to Use this Material

National Marine Fisheries Service (NMFS) readers who seek approval for an e-signature implementation should become familiar with all the resources posted on this site, and most importantly they should be familiar with our Agency's e-signatures policy (32-110) and procedural directive (32-110-01). After studying the policy and procedure documents consider reviewing the roadmap, checklist and examples of deliverables sections. When an e-signature project begins to produce documents, consider contacting the team that developed this site, adding your work products to our collection, and participating in this wiki as an collaborative aid for your work, and as a means to improving our guidance for future e-signature initiatives.

Readers who are not associated with NMFS may find many particulars that don't apply to their situation. However, NMFS policy and procedure is based on policy and guidance from the U.S. Office of Management and Budget (OMB), National Archives and Records Administration (NARA), Department of Justice, and related experts and authorities, so you may find that due diligence in your circumstances require most of the steps described here. And this site may have the most complete collection of examples and resources that are easily available.

Project Contents

Roadmap
Checklist — This checklist identifies the major steps of the process
Examples of Deliverables — Examples of major project deliverables
Background and Planning — A place for detailed context, history, and resource documents.
- eSignature Legal Context and Precedents
- eSignature Stakeholders
- FIS ER eSignature Project Proposal
- Prior Art in Citizen-to-Government eSignature
- Concepts
  - Document Binding, Integrity, and Audit Trails — Some distinctive mark must be affixed to the original document as evidence of the electronic signature, binding the document to the signing party's identity, indicating their approval or adoption, and providing evidence of the document's integrity.
  - Identity Assertion, Person Proofing and Registration — The requirement to identify and authenticate a particular person establishes a need for an initial person proofing and registration process and an authentication process to support an identity assertion implied in each eSignature transaction.
  - E-Signature User Experience - Terms and Conditions, Signing Ceremony, Receipt
    - Receipt
Participant and Resource Contact Info — Contact info for project participants and resources.
Activity Summaries — Summaries of project activity are drafted and emailed periodically to the "in the loop" mailgroup as a means of communicating with stakeholders and the curious.
Meetings — Meeting agendas are posted here prior to the meetings, and after the meetings these pages are turned into meeting summaries documenting decisions and work assignments.
Deliverables — Key project documents and deliverables are assembled here.
- Charter for eSignature Team — is not a deliverable but is published here to establish context for the other information.
- Stakeholder Impact Analysis — also known as the grid, characterizes potential pilot projects and stakeholders.
- Alternatives Analysis — complete and documented through Think Tank notes - characterizes alternative approaches to e-signatures.
- Risk Assessment and Cost Benefit Analysis — complete in draft, final formatting in progress – a risk assessment, cost estimates, benefits statement, and cost-benefits analysis prepared according to NMFS procedural directive 32-110-02 http://reefshark.nmfs.noaa.gov/f/pds/publicsite/documents/procedures/32-110-01.pdf.
- Presentation — in draft - of proposed e-signature plan to stakeholders.
- Critique — not begun – the critique or postmortem finalizes the project, wraps up any loose ends, and documents lessons learned for future initiatives.
- Risk Notes — a notepad to record thoughts about project risk which is not a deliverable, but may inform the formal Risk Assessment and Cost Benefit Analysis.
- ToDo List for Business Plans — task assignments as we finalize pilot project business plans.
- Observations on the Process
- Completion Summary as of June 10, 2009
Pilot Candidates — Potential e-signature applications under consideration as pilot projects. This section will include an overview of the e-signature pilot projects the team will review in September and then evaluate using Think Tank in October. This is an important in the OMB e-authentication evaluation process, which requires the team to identify the risks inherent in the business application. One outcome of the analysis is to assign the applicaiton to one of the four levels of assurance identified in the OMB

Browser not supported