Page Comparison

...

The proposed identity assertion, person proofing, and registration starts with a permit holder 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 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.)

...

1. Audit 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.
2. Audit trail entries will be written upon receiving an HTTP request of for the uniquely coded URL that indicates confirmation of control of the email address-of-record, recording a timestamp, origin and destination IP addresses, username, permit number, and the unique URL requested.
3. Audit trail entries will be written upon each e-signature transaction, recording a timestamp, origin and destination IP addresses, username, permit number, an e-signature transaction id, and the data submitted in the e-logbook entry which is being signed.
4. 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.)Audit , and audit trail entries will be written to log the processing of the e-logbook entry and generation of the , recording a timestamp, origin and destination IP addresses, username, permit number, an e-signature transaction id, and display and emailing the text of the receipt. (See more detail in the Receipt section below.)

• 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.)

...

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 , username, permit number, the e-signature transaction id.

...

, and included a recapitulation of the submitted data with the following additions:

1. If the receipt file
   1. a A "messages" element section will be added to the XML as a child element of the top level "LogbookReport" element the messages element document processing of the data submission:
      1. this section 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>

           Panel
           Ok

         • 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

           Panel
           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. 1. 1. • code Line 2: 412 is not a recognized species code

5. If the receipt cannot be emailed directly to the address of record for the permit holder the operator executing the data import program is appropriate NMFS operations personnel are notified so that they can take steps to inform the submitter and resolve the problem.

Collecting Only Necessary Information in the Electronic Signature Authentication Process

...