Cassio DeSanctis drafted this outline based on the procedural directive. Note that although terms such as implementation are used in this outline, this is all about a planning, design, and plan approval exercise, and this outline (and this project) do not specify a complete development process resulting in implemented production systems. Of course a development process (and/or procurement) is eventually intended, but it is not documented here.

Evaluation

Assuming that the evaluation results in a decision to implement:

Implementation
- Determine Assurance Level (AL) to Mitigate Risks (assurance level per NIST 800-63)
  - Use table of Potential Impacts and Probability of Occurrence
    - Choose lowest level that can mitigate risks
    - Use best judgment to determine appropriate AL
  - Identify and Implement Technical Requirements corresponding to AL
    - Level 1: allows PINs + challenge-response authentication
    - Level 2: strong password (no PINs) + tunneled pwd authentication
    - Level 3: one-time password device + PoP authentication protocol
    - Level 4: hard-tokens + private key PoP authentication
- Legally Bind Transaction to Individual or Entity
  - Ensure submitting party knows Terms and Conditions
  - Establish that submitting party is aware of obligations they are agreeing to (e.g. permits/logbooks)
  - Make party take willful action to indicate desire to sign
- Chain of Custody Audit Trails
  - Integrity of the transaction
    - Record sending location
    - Record sending individual / entity
    - Date and time stamp of receipt
    - Proof that agency sent a receipt
    - Confirmation that individual received the "receipt"
  - Handling of information once received
    - Changes to information requires the re-collection of all information that are part of the audit trail in the original document
    - Original documents should not be deleted when changes are made
    - Changes to information must be tracked including the person making the change, time stamp and accompanying documentation
  - Electronic Receipts
    - Should be printable
    - Indicates parties in the transaction and the agreement that was made
    - Contains confirmation code that can be used in the future to locate receipt
    - Requires audit trail to track that receipt was sent and received
  - Use of Information
    - ES should only be required when needed
    - Should not collect more information than necessary
    - User should be able to opt out to a paper process
    - Inform users that information collected will be managed and protected under Privacy Act, Computer Security Act, Federal Information Security Management Act, etc
  - Long-term Retention
    - Must meet requirements of Federal Records Act and NARA's Record Mgmt Guidance for ES
    - Permanently retained records must include the printed name of the signer and date of signature
    - Plan for software obsolescence / migrations to newer version without affecting existing documents
  - Review and Re-evaluation of ES Process
    - Should be included in the implementation strategy
    - Review quality indicators such as number of transactions, average completion time, resubmissions, etc
    - Evaluate opportunities from changes in technology

Browser not supported