The Zero Trust Sub-Working Group of the Architecture Working Group may propose that OCA join a NCCOE effort on evaluating Zero Trust Architectures. I applaud and support this effort. I think it would be a valuable addition to OCA and may draw in significant new membership. BUT I request we have our governance ducks in a row before doing so in that I think a decision like this is PGB level decision. If the Zero Trust Sub-Working Group, or even the Architecture Working Group were OCA Projects (ie like Stixshifter, Kestrel, PACE, Ontology) then it might be debatable whether PGB discussion/approval was required. But since it’s a more nebulous governance, I think it warrants PGB level discussion.

Note I am for doing this effort. I just worry that loosey goosey governance would increase probability of failure. I think tighter governance is needed because:

• NDA’s (or NIST equivalent, CRDA) will be involved,
• some OCA companies are participating directly
• plenty of non-OCA companies are participating
• gazillions of US procurement dollars at stake,

therefore I think establishing ground rules ahead of time would be warranted. I think we should discuss issues like:

• should ZT be a project (eg like stixshifter) instead of whatever ZT arch is now. I recommend ZT should be a project both for governance reasons and for resource reasons (ie we don’t want to publicly commit to join and then have nobody willing to do the work)
• who would and who wouldn’t have access to the CRDA data (ie we can’t be “open” on  data we promise to not disclose) and who would make the CRDA release decisions (it’s my understanding that NCCOE ZT participants have the ability to have their evaluations included or not once the evaluations are complete. Ie if you don’t like the answer, you get to keep the info private. Who makes that call for OCA? Give the “open” in our name, we could decide ahead of time that we’d always divulge. Or not – but then we need a process.
• what part of participation would be open to all and what part would be only open to PGB member companies (ie companies that paid).
• How would decisions get made when there is conflict of interest between OCA member companies participating directly and the OCA project we’d be creating (which is not too different than other OCA projects but since this would be much more in public eye, we probably want something written somewhere to point to, so that naysayers don’t have easy ammo to shoot us with).
• Establishing clear ZT charter including it’s relation to other OCA projects. Ie is this a “security of” or “security for” project or both? “Security of” meaning how can/should zero trust principles/arch/software be used to enhance the security of COA projects like stixshifter, kestrel, PACE? “Security for” meaning how can any zero trust software we create be used to enhance the security for client assets. I’d recommend we decide either “both” or  we decide this new project be only “security for” BUT that we add “how can ZT be used for “security of” to each of the existing projects.
•  

Maybe this could all get resolved via email prior to PGB and it would be a simple proposal/agreement. Or maybe we’ll argue for decades 😊. Hopefully the former, or at least close to it.

For more info on the Zero Trust topic:

• A recording of Jan-24 OCA Arch ZT meeting (where this was discussed) should be posted shortly to the OCA YouTube channel
• The slides used for the Jan-24 meeting are attached to https://lists.oasis-open-projects.org/g/oca-architecture-wg/message/327
• Public info on the NIST NCCOE ZT effort that OCA would potentially join:
• https://www.nccoe.nist.gov/sites/default/files/legacy-files/zta-project-description-final.pdf
• https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture