WAWF was built with security and privacy at every level, for every role. The application itself uses Standard Secure Socket Layer (SSL ) protocol for all Web connectivity to the WAWF system. WAWF utilizes one-way SSL that requires only a server-side certificate to establish the Hypertext Transfer Protocol Secure (HTTPS ) connection between users and the WAWF Web listener. The server certificate is issued from a DoD PKI certificate authority. Additionally, the user community must have a standard browser that supports the 128-bit version of SSL and any site firewall (if present) needs to allow SSL to pass through.

Access to the application is controlled via either a user ID/password or a digital certificate.

Security is based on the concept that individuals should only have access to data (documents) for which he/she has a responsibility. A Vendor is only permitted to submit documents for contracts on which he/she is identified as the Vendor (using his/her registered CAGE Code). A government official only has access to documents for his/her assigned DoDAACs. Extensions registered to that CAGE Code may or may not have permission to view EDA data.

When the Social Security Number is required as a data entry parameter it will be masked on the input screen. In all other record retrieval and access authorization processes, the Social Security Number will be masked to the last four with asterisks or other special characters, similar to the technique used when handling passwords and PINs.

NOTE: The Pay Official and Pay Official View Only roles will be permitted to view the entire Social Security Number on a document. The SAM and HAM will be permitted to view the entire SSN upon selecting the View INV_RR data table.

Location extensions may also be used within the application to provide a level of security within an organization, primarily within Vendor roles. In this instance, it would be possible to assign users to specific Location Code + Extensions to permit the parent company to restrict a user’s visibility to specific documents.

When a CAGE Code extension is established, the GAM , HAM , or SAM will be able to indicate whether that extension will or will not have EDA access for that CAGE Code. This will result in a situation within the WAWF Vendor folders (Reject folders (INV / RR), History folder, Vendor View Only) where a user registered against a CAGE Extension that does not have permission to view EDA data will not be provided with the Contract Number hyperlink in the folder view.

Additionally, to further restrict EDA access, any specific user who has Self Registered with an Extension may be denied access to the EDA Contract Information.

A second, and not obvious security capability, is that based upon the EDA toggle mentioned above, an extension may have documents restricted from their view. For example, it is possible for a user registered against a CAGE Extension to create a Receiving Report. The parent CAGE can then use that document and create an Invoice for billing purposes. Normally, WAWF will link those two documents together based upon the Shipment Number and display them both on the same line within the folder views. However, when a user at the CAGE Extension views their document folder they will not be able to see the Invoice that has been created against the Extensions Receiving Report. The parent CAGE will be able to see both documents since they do not have the EDA access restriction.

Lastly, the EDA toggle will be used to hide financial related data from an Extension with the toggle set to, "No EDA Access" when using the functionality to create one document from another or creating a document from a template. Provided the original document or template has this data, it will be restricted from view when a new document is created.