NACS Phase Two

--- title: NACS Phase Two tags: letters robots: noindex, nofollow --- Dear [XXX], We are now beginning phase 2 of our security review, which covers our architectural review of the NACS Age Verification System. This is a preliminary architectural analysis of a system that has not yet been deployed to production. That means that the review, out of necessity, occurs at a high level. We do not expect during this phase to cover all potential architectural issues. For example, we are aware that architectural choices made by POS vendors could cause issues, but this will be out-of-scope for our analysis. (Nonetheless, we expect to at least reveal the general outlines of such dangers when we proceed to phase 3.) Our goal in this architectural analysis phase is to use documents, interviews, and in-depth study to identify and prioritize areas for future investigation in phase 3 and to identify what topics still require additional data or support. Ultimately, we see phase 2 as a way to scope phase 3, the Risk Model and Threat Analysis Review. (The goal of phase 3 will then be to answer questions on whether privacy is being put at risk, using our experience and common sense to do so, since we are operating in a gray area without existing standards or frameworks.) From our work with the Information Lifecyle Engagement Model in phase 1, we are already aware of areas that are either underspecified or unspecified. We talked about many of these during on discussion on March 23rd and have developed action items for resolving them: 1. What are the trust boundaries in the system? (Joe with David E.) * Who runs which components of the system? * What are the communications and service calls that cross these trust boundaries? * What data crosses which boundaries at what time? * What data is retained in each trust boundary, whether ephemerally or in storage? How is it secured? * Who holds the certs? 1. Which Zcaps are being used? (Joe with David L.) 1. What are the 1.5 and 2 support levels? (Manu) 1. What is the CI/CD process flow for Github? (Matt or Tashi) 1. Key Holder questions (Manu) * What keys sign the external customer token? (Manu) * How are those keys managed? Who has control? How are they secured and used? 1. Customer Token Management questions (David L.) * What tokens are used? How are they created? What role do they perform? * What signing algorithms, if any, are used for the external customer token? (David L.) 1. What do we do about documentation that is out of sync? (Manu, Joe, Eric) We are beginning this work on the architecture analysis phase by coordinating with Digital Bazaar to complete sequence diagrams and by either acquiring documentation or initiating discussions, per the action items above. We also have identified some additional questions which may or may not require resolution at this time, but which point to elements that are currently undefined in the documentation we have seen. 1. How is data removed or updated? Both automatic and human-mediated updates need to be defined. 1. How often are OAuth tokens updated? 1. What cryptographic functions are used? Where, on what data, and for what purposes? 1. What DID methods, if any, are being used in phase 1? What are they used for? 1. What are the details of the differential privacy filter? 1. What are the details of the analytics system? 1. How will anomalies in usage of the system be defined and observed? 1. How will the system verify the performance of the anomaly detection system? Ultimately, we do not need all answers now, but if questions roll into the Risk Analysis of phase 3, they may increase the cost there. NACS can further support us as we begin work on phase 2 both by identifying specific areas that you think deserve attention and equally by telling us areas where you think that our attention is not required. The latter can include risks or threats that you accept or are aware of, and that we should not need to investigate further as a result. Knowing these areas to avoid will help us better scope our time for phase 3. Currently, the list of topics to not include in our risk analysis contains security and privacy concerns related to: * Any limits other than per-transaction limits * Returns * Zcap usage between other (non-internal) services * Credit card transactions * Loyalty transactions * Local cameras * POS terminals * Auxiliary data and systems held by a retailer Please let us know what we should add to this list (and what we should highlight for inclusion). We look forward to continuing our work with you on the architectural phase of our security review. Sincerely, Christopher Allen Executive Director & Principal Architect, Blockchain Commons