Skip to content

DAC Spec Feedback

Created by: nickcordina

Impacted sections

Feedback related to First draft Decentralised Access Control

Issue Description

Note for background that this feedback is from the perspective of a value chain participants, with a specific heavy industry lens (earlier in the supply chain). Feedback is not really from a security or access protocol decision perspective. Feedback is prioritised (1 - key clarifications / feedback, 2 - likely less significant, 3 - clerical / documentation clean up).

  1. Key Clarifications / Feedback
  • [DAC Categories] Overall I think the DAC 1-7 categories act as good default access specifications. Thinking through application for critical minerals I would assume: a) Data elements to be mapped to a DAC category may in some cases be governed by legislation (min requirements) b) Sub-DAC categories could be expected to be needed by companies. There is still value in setting some base categories for thinking about DAC architecture needs. Attached excel file gives some examples of potential differing access levels in a given DAC category. I would expect DAC sub-category access privileges to change as you move along a supply chain in a given sector due to multiple factors (including manufacturing complexity, competition, data scale, market norms)
  • [Item Aggregation & Nesting] This feedback may be more UNTP item JSON related however impacts DAC considerations so listing. For upstream supply chains it is very likely that UNTP serials will be aggregated to new products. How UNTP serial items are dealt with at a point of product transformation along the line of custody transfer impacts how DAC for upstream/downstream N-tier Supplier Visibility. In the attached excel a rough example is given for a potential battery manufacturer and in this example more detail is available on UNTP items that are being aggregated/transformed in that processing step, than for prior steps in the supply chain. The point being made here is that if Aggregation & Nesting of UNTP items, and their respective serials numbers, is expected to be made it will naturally create some barriers to accessing full information on upstream supply chains. This in turn could simplify some of the design considerations for N-tier suppliers DAC requirements.
  • [Dataset Plurality Requirement] In the attached example, different versions of the same data categories are presented. These are in some cases required (eg different carbon footprints according to different disclosure rules) and in some cases could be used to pair with disclosure needs of companies (eg approximate facility location or material content rather than specific locations / recipes for lower privilege access). Sidenote that in the chemical world Material Safety Data Sheets, which are widely disclosed, have similar approximate compositions listed.
  • [Secret Provision / DIA] In the spec, there is emphasise on physical provision of access codes on the product itself. For heavy industry / upstream supply chains the access codes (eg secret QR) would need to be provided in other ways, such as on invoices that accompany custody transfer documents (eg for wet/dry bulk cargoes) and better still programmatically where custody transfer is principally electronic. I think this is obvious but wanted to reiterate it just in case it hasn't been considered in full. Furthermore any ESG software being deployed for UNTP item updates within a company would ideally be close in IT architecture to the programmatic access to inbound / outbound UNTP items (and their access codes) for a given facility.
  1. Other Considerations
  • [Legal Access] I have thought through wide access requirement privileges for a given company, which could be driven by higher level agents such as governments, audit, police, 3P data exchanges. Discussion question here would be how to we think companies would securely hold access codes to pull and provide near full data in one go? Note that if sub-categories of DAC's can be configured by companies, some of these cases could be managed by having a company wide item access secret....(eg DAC 4 sub-category).
  • [Patterns] Implementation thoughts for critical minerals. If we start with the basic structure of content (information aggregated and organised in linked set of serialised UNTP items) and access categories (DAC's with sub-specifications, set by companies and adhering to min req's of legislations), as we implement the mapping between content and access at each step of the supply chain we will see the patterns emerge in the sub-category access needs. We will also see which plural data sets are needed to meet confidentiality objectives. Refine sub-roles by trial and error.
  1. Lower Priority Feedback
  • [Terms & Typos] 'Secret' terminology doesn't jibe well for me but get the concept. Typo on line 211 ('In').
  • [Federated Authentication Section] Is this section clear enough to drive use for an access / security professional or are we trying to steer away from federated authentication?
  • [Confidentiality] Feels like we could combined the two confidentiality sections at the end
  • [Aggregation Added Complexity] Pending confirmation of UNTP item aggregation being assumed, need to confirm protocols for how multiple serials of the same material are collapsed into a new product (eg 10 different lithium serials combined into a battery pack....). For discussion at this stage and have some thoughts on how to handle but not sure if this is really a DAC spec.

DAC_Spec_Brainstorm__Battery_Rev00_nes.xlsx

Edited by Ashley HARWOOD