Page Comparison

...

• identity assertion, person proofing, and registration
• terms and conditions and signing ceremony
• document binding and document integrity

The Hawaii Longline Logbook ENon-Commercial Bottomfish e-signature Evaluationevaluation has concluded that OMB Assurance Level 2 1 (little or no confidence exists in the asserted identity) was appropriate for the Hawaii Longline Logbook.   This was a considered decision justified by low likelyhood of occurrence, low and moderate impact of harm, and multiple and strong emphasis on usability and public acceptance, and mitigating controls, including : multiple and sometimes counter-balancing sources of information; permitted entities with an ongoing trusted relationship with NMFS; a rigorous certification process for e-logbook applications; and unique identifiers on each e-logbook submission.  matching of the asserted identity with a specific fishing permit and the email address of record for that fishing permit. Note that the identity is established from association with a fishing permit holder, and not solely through the registration to submit logbooks electronically.

The proposed identity assertion, person proofing, and registration starts with a permit holder completing a NMFS electronic logbook agreement, establishing a linkage between the permit, the permit holder, and the fishing vessel operator who is authorized to submit electronic logbooks for that permit. more?_..._ initiating an online registration process to establish username and password credentials for e-signature. The registration web application will guide the permit holder through choosing a username and password, entering their fishing permit number and email address, and entering a //en.wikipedia.org/wiki/Captcha string. The registration program will verify the CAPTCHA string (as a defense against automated attacks) and then confirm that the email address supplied matches the email address-of-record for the specified fishing permit. If these tests are passed, the program will generate an email message to this address-of-record. The email message will contain a URL link unique for this particular registration transaction. When the email message has been sent to the address-of-record, the registration program will explain to the permit holder that they must now follow further instructions which will be supplied via email to complete their registration. The permit holder should now access their email, read the registration message, and click on the unique link enclosed. When they click on the enclosed link, the registration program will recognize the unique key in the URL and will accept that unique key as confirmation that the permit holder does have control of the email address-of-record.
(See Identity Assertion, Person Proofing and Registration for a broader discussion of these issues and alternatives.)

...

Terms and conditions presented during the signing ceremony (when the vessel operator has entered logbook data into the e-logbook program and is saving the data or when the vessel operator is exporting data to portable media for submission to is submitting logbook data to NMFS) includes the following statement just above the required signature block:

...

The signer must make a willful act to demonstrate that they have read and agreed with the statement above. They must place a check mark in a check box that is labeled "I have read and understand the statement above." In addition to placing a check mark in the check box, the applicant must also type their name and their password to complete the electronic signing ceremony. Attempting to proceed to the next step of the electronic transaction without completing the above steps will cause the system to display a message instructing the applicant that they must read the terms and conditions statement, and enter their name, and their password before their information will be accepted.

Technically the transaction data is bound to entity identity data by a shared identifier (permit number) in the registration data (electronic logbook agreement), the permit database, and in e-logbook submissions. Further binding could be established by asking the e-logbook vendor to correlate customer identities to the unique keys which are embedded in each installation of certified e-logbook software. (See document binding and integrity for a broader discussion of these issues and alternatives.)

Since the Hawaii Longline Logbook is not an online application no authentication token and protocol issues are involved in non-repudiationThe authentication tokens are username and password, and they are protected by Secure Socket Layer (SSL) transmission protocol. Technical controls for document integrity and audit trails contribute to binding the transaction to the entity and non-repudiation, but those controls are more appropriately discussed in the next section.

...

The proposed design implements the following audit trail controls for submission of e-logbooks via emailthe web:

1. The NMFS email interface program will run periodically (perhaps every 5 minutes), login to the postoffice, and open the inbox.
2. The email interface program will consider every message currently in the inbox, and for each message:
   1. Log receipt of the email message into audit trail tables.
   2. If the email message is recognized (recognized messages were generated by certified e-logbook software and submitted by registered permit holders).
      1. Generate a unique e-logbook message identier.
      2. Handle possible return-receipt-requested.
      3. Extract e-logbook message payload(s) (zip attachments)
         1. For each e-logbook payload:
         2. Log receipt of payload into audit trail tables.
         3. Unzip and unmarshall the payload, creating an e-logbook page object; if payload cannot be unzipped or unmarshalled the receipt is formed from the raw input data and unzip/unmarshall errors are noted and logged.
         4. Process the e-logbook page, inserting into the database (if possible) and creating a receipt (appropriate data checks are applied in this step and any errors noted in the receipt.)
         5. Return the receipt to the appropriate party.
         6. Log the result into audit trail tables.
3. These audit trail data items should be written to audit trail tables by the email interface application using a database account which has insert privileges to the database but does not have update or delete privileges. (And update and delete privileges on the audit trail tables should be carefully controlled by the database administrator.)

The proposed design implements the following audit trail controls for submission of physical media:

1. the NMFS employee who received the portable media will return to the office, login, and start a data import program.
2. The data import program will present the operator with fields to record where and when the portable media was delivered, who delivered it and who received it. The data import program will require this information before proceeding, and will institute appropriate data checks to ensure the most accurate data possible.  The data import program will record these fields as well as the login name of the operator, the time that the data import was run, and the raw uninterpreted contents of the submitted e-logbook file(s), into a NMFS databaseAudit trail entries will be written for each registration submission, recording a timestamp, origin and destination IP addresses, username, permit number, email address-of-record... and generated email message.
3. Audit trail entries will be written upon request of the uniquely coded URL that indicates confirmation of control of the email address-of-record, recording a timestamp, origin and destination IP addresses, username, and the unique URL requested.
4. Audit trail entries will be written upon each e-signature transaction, recording a timestamp, origin and destination IP addresses, username, an e-signature transaction id, and the data submitted in the e-logbook entry which is being signed.
5. A receipt page will be displayed to the permit holder after each e-signature transaction, and a copy of the receipt will also be sent via email to the permit holder's email address-of-record. (See more detail in the Receipt section below.)
6. Audit trail entries will be written to log the processing of the e-logbook entry and generation of the e-signature transaction id and display and emailing of the receipt.

• These audit trail data items should be written to audit trail tables by the

...

• web application using a database account which has insert privileges to the database but does not have update or delete privileges. (And update and delete privileges on the audit trail tables should be carefully controlled by the database administrator.

...

• )

...

Providing an Electronic Receipt or Acknowledgment of a Successful Submission

The system proposed is not online and does not provide a user interface directly to the customer.  As proposed the electronic signature is executed by certified (trusted) software onboard the vessel, but, since the data is being submitted to satisfy NMFS record keeping and reporting regulations, it seems appropriate that any receipt be provided by NMFS and not by the e-logbook software vendor.  Accordingly, the proposed receipt process is as follows: Subsequent to each e-signature transaction, a receipt page will be displayed to the permit holder, and a copy of the receipt will also be sent via email to the permit holder's email address-of-record. The receipt will document the timestamp and the e-signature transaction id.

1. After the data import program has interpreted (or attempted to interpret) the submitted e-logbook data, the data import program writes a receipt file. The proposed receipt will consist of an exact recapitulation of the submitted data with the following additions:
   1. a "messages" element will be added to the XML as a child element of the top level "LogbookReport" element
      1. the messages element will contain one or more messages documenting success or failure(s) in the interpretation of the e-logbook submission; for example:
         • in the case of a successful data import one message would be returned which might look like:
           <messages>
           <message msgid="1000" severity_code="I" severity_desc="INFO">Ok</message>
           </messages>
         • in the case of a failed data import one or more messages would be returned to explain the failure which might look like:
           <messages>
           <message msgid="1179" severity_code="E" severity_desc="ERROR">Line 1 49 is not a recognized gear code</message>
           </messages>
   2. for each element in the returned XML which consists of a code, for example, gear code, the XML schema will provide an optional attribute for a name; when the XML is submitted from the vessel these optional attributes will not be present (and if they are present they will be ignored); when the XML is returned from the agency as a receipt, these optional attributes will be populated by the agency to indicate that the code was recognized and to confirm what the code represents; for example:
      • incoming XML markup for gear may look like <gear>91</gear>
      • outgoing (receipt) XML markup for gear may look like <gear name="Pot">91</gear>
2. The receipt file will be written back onto the portable media if that media is to be returned to the vessel operator
3. Assuming that the data import was successful, or at least successful enough that the e-logbook's permit could be ascertained, the receipt file will also be emailed directly by the data import program to the address of record for the permit holder
   1. The XML file will be an attachment to the receipt email message; the body of the receipt message will contain a synopsis of any "messages" elements contained in the receipt.
4. If the receipt file cannot be emailed directly to the address of record for the permit holder the operator executing the data import program is notified so that they can take steps to inform the submitter

...