News or events of interest to Governance Stack WG members:

Drummond Reed 

Drummond Reed  lead the discussion and provided a context for the 3rd generation ToIP Stack diagram.

Why a 3rd generation diagram? (Drummond Reed):

• Driven by insights gained in completing the Technical Architecture specification last year but getting very little feedback from others including governance who have a completely different viewpoint

• Trust registries are not represented in the current diagram and there is no good way to fit it in the stack, we need a good alternative diagram.

• Earlier stack diagram with the governance first/left and technology on the right/second (see Fig. 1) hasn't really worked.
  
  

Key revisions needed (Drummond Reed):

1. Layer Names (L1: 'Trust support', L2 :'Trust Spanning', L3: 'Trust Tasks', and L4: 'Trust Applications')
2. Trust Registries & DID Utilities: need to depict these correctly as these are supporting systems for every layer. 

Visions for 3rd generation diagram - canonical examples

• Fig.2 is from Darrell O'Donnell who suggested 'Trust Registry' and 'Governance Architecture' to span all layers. Trust Registries will provide 'governed information' for helping make trust decisions on any layer of the stack.
• Fig.3 is from Jo Spencer 
  • Dennis Landi liked it while Anita Rao indicated she had a hard time mapping some of information to the previous 4 layer diagrams.
    Savita Farooqui pointed out for her 'applications = business level applications' and wallet was a tool. 
    Mary Lacity on chat highlighted that trust registries were only on one stack.
    Neil Thomson felt the diagram mixed components and processes
    Carly Huitema on chat "I agree with Neil - one diagram only needs to do a lot of lifting. The original diagram was a great message and easy to show and makes entry to the 'world of ToIP' simple. But when it comes time to start making decisions and design, you need other types of diagrams to guide."
    Kyle Robinson agreed with Carla and felt this diagram can be an interactive and inform audiences at different levels.
    Daniel Bachenheimer  on chat "I think the diagram is fine for capturing our point in time discussion but too much disparate info... we should not attack OPERATIONS at this point, for example"
    Brent Zundel on chat "I will appreciate the hourglass translation on the left-hand side, this makes sense to me now. But I would have difficulty translating this to second generation stack"
• Fig. 4 is from Michael Herman 
• Fig. 5 is from Scott Perry 
  • Drummond presented this diagram on behalf of Scott - where his diagram proposed governance half of the stack with no layers instead it is expected to cover risk across all components in the technical stack. He expects to move the Trust Spanning layer inside the cloud. Others like Neil Thomson felt this governance cloud represented a scaffolding for the technical stack and Savita Farooqui indicated that in the diagram the Trust Registry was the target of governance. Daniel Bachenheimer pointed out that although there are no layers on the flip side governance still applied to each layer of the technical stack.
  • Scott sees Trust Registry as central component of governance, this is because the Trust Registry TF also arrived at a definition which describes Trust Registry as 'a repository of governed information about a trust community'
  • Savita Farooqui felt keeping the layered model is still valuable as the concerns at each layer is different.
    
• Fig. 6 is from Savita Farooqui 
  • Here the focus is on technology solving a business problem and therefore the context of each business problem could be different.
  • Layer 4 - Trust Applications: the governance considerations here can be specific to business, domain and jurisdiction.
  • Layer 3 - Trust Tasks: here you consider governance for technology development.
  • Layers 2-1: as you go down the stack the governance is more towards technology rather than business or application focus.
  • Scott's pattern can be applied at each layer
  • Kyle Robinson agreed with Savitha, it is still important to keep the multiple layers, there could multiple governing authorities within a layer.
  • Carly Huitema - the technical stack is a list of components arranged hierarchically, but that does not mean Scott's governance components needs to be 'twisted and pushed' to match the technical stack. Likes Scott's diagram because he is thinking of governance as an 'own thing'.
  • From Mary Lacity on chat: "On Savita’s text (which is intuitive—perhaps because we’ve framed it this ways long)…would it help to have trust registries in all layers? Layer 1—doesn’t a DID method rely on a trust registry for example?"
  • Follows the governance model of IEEE (Fig. 7) where the governance may apply to all layers but the trust decisions and risks are different in each layer.
  • Anita Rao - both Savitha's and Scott's diagram can be combined if the risks associated with components in the technical layer can identified and  Scott's governance framework can be applied to address those risks.
  • Kyle Robinson - we must be careful not to put too many constraints because this is a conceptual model and not a specification. For example, a trust registry or list can be in all 4 layers, it shouldn't be restricted to one layer as the ecosystem/ use-cases come in very different shapes and forms.
  • Judith Fleenor suggests to have multiple diagrams depending on the audience.