• Start recording
• Welcome & antitrust notice
• Introduction of new members
• Agenda review

• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
• New Members:

ToIP 3rd Gen top-level diagram (governance) & different views

For reference

• Third Generation ToIP Stack Diagram  
• Ways in which we might represent the ToIP governance architecture

Neil (post mtg summary):

Governance is a set of risk-driven principles and approaches, which are then applied to different aspects of the technical architecture with technology, architecture, stack level specific, role and purpose-specific approaches. The current proposed Governance view as a risk-driven iterative approach is a good trade-off. However, this is still an oversimplified "marketing-ish" diagram.  The discussion here on overlaying different views for different audiences.

As note scribe, I've dug into the transcript, which I've paraphrased and summarized and any mistakes are mine. For more detail, watch the recording starting @ 6:05

Third Generation ToIP Diagram - how does Governance fit?

Based on the GATF Slack discussions (Nov 30, 2023), this suggests a top-level view like the above, which is useful and meaningful, but without trying to be fully accurate or express all views/perspectives.

And, at the next level of detail, which provides for different overlays, expanding governance from a risk assessment, requirements, assurance, auditing, etc. Like any ToIP technical service, sub-system, etc., may use components from one or more layers in the stack, other views, such as governance and operations, may have different views of the technology components that don't map 1:1 to the technical layers. 

This also needs to accommodate different viewers of the system (development, governance, operations, business models)

There are also a wide range models: concept, logical, layering & partitioning (which is the current top-level ToIP model, implementation, workflows, data, operations (includes operations & alerting), and assurance (part of governance), trust (zero trust, auditability, verifiability) - are all candidates which need to be discussed from a risk and trust driven approach and how this is different for a ToIP approach vs. pre-zero-trust/trustworthy architectures. 

However, at a more detailed level, what is new and different about the ToIP approach for governance will need to be audience-focused. There are at least two types of audiences.

• Different organizational roles (e.g. developer, governance, operations, legal...)
• Different (problem) domains (e.g., telecom, travel, mining...). 

Explanations may need to map (for each audience) from their "understanding of how things work". Their concepts, terms and vocabulary to SSI/ToIP vocabulary, including use cases (ideally) from their domain.

BCGov's "Mining Act Permit Credential" documentation (see below) reflects mapping to the Mining problem domain. 

• BC Major Mines Office - Governance Framework Defines Governance in ToIP and domain/problem space terms, which includes references to the BC Mining Act legislation and regulation that underpins credential system.
• BC Mines Act Permit Credential - defines
•  BC project Git Repo

John Phillips: As with vocabulary, for diagrams for different audiences, from a ToIP perspective: "each of these needs to be consistent in the sense that from sort of an idea point of view, the way they express it and explain things, but also even from a sort of graphical point of view. They need to have some degree of commonality across the right things that are presented even down. So if you are apple, the curve on the edge of the curved boxes that we're using needs to be the same degree."

John Phillips on Use Cases: to aid in explaining a broad concept, use cases have to be broadly understandable (e.g., the Bob/Alice examples in Drummond's SSI book). Use cases are, almost by definition, kind of monotheistic, a single way of looking at something, a single kind of problem. And say, if you take a travel example. someone from, say, higher education, releasing education credentials may say, "That doesn't work for me". For example, two highly detailed use cases in the Sovrin Guardianship project were very specific to a domain (and jurisdiction) that would not map for many domain/jurisdiction combinations.

John Phillips: idea: generalize atomic-level actions, components and requirements that parties interact through to verify stuff, to issue things and govern things (this then lends a commonality and may simplify a set of elements used to describe ToIP to different audiences)

Note: see the recording for more details 17:59

Neil (post mtg): this suggests additional models, and components similar to the issuer/holder/verifier model, say for governance and trust chains (some of the work for the Attraction Pass TF may work here.

Kyle: agree with having a flashy, almost marketing picture, then applying different lenses for different audiences 

Neil: The Mining credentials project that BCGov is releasing may be a good example of what may be understandable in any government-regulated resource industry (logging, pulp and paper, oil and gas)

John: And it's got a real business scenario. Note: John also talks about supply chain examples related to ESG (Environmental, Social & Governance) in the video

Kyle: Mining Act Credential - first public credential issued. Working toward a "sustaining mining credential" (also ESG related)

Neil: one of the keys to the BCGov Mining credentials is tying-back to legislation and jurisdiction which is also core to travel credentials, including data privacy concerns. Core to work in the DIF Hospitality & Travel SIG is a comprehensive travel (traveller) profile, which is PII/Personal data on steroids, and as travel is frequently across multiple jurisdictions, privacy compliance will not be trivial, which may require data models which can be annotated with what data/properties are sensitive.

John: provides an example that on consent for what PII/Person data shares (birth date), cross-jurisdictional cases may not be possible for code to solve, it likely has to be left up to the user to decide, the issue is ow to ensure the user is making an informed decision/discretion.

Issuer Requirements - first draft complete - feedback and next steps? 

John: feeling the document is too complicated. It's one thing to provide that level of detail to experienced ToIP members, such as BCGov, but it may be more of a detailed companion guide, and perhaps there is a simpler to requirements specification.

Discussion, Perhaps the current version is overly prescriptive. Using the example of key rotation, perhaps provide minimum requirements, plus desirable requirements, with a worked example of both (e.g., KERI as the desirable requirements example) ? 

Perhaps all an Issuer has to do is to to explain is what kind of key rotation management they use, it's algorithms, etc. It's up to them to work the details. ToIP doesn't need to tell you how to manage your keys.

Kyle: Is the Issuer Requirements document a template to be filled in, or guidance?

Neil: It's predominantly guidance and specifies a few MUSTs, but has a great deal of SHOULD (recommend) and MAY (optional). Its core approach recommends that Issuer requirements be risk-driven, which is required for all aspects of any ecosystem and its components.

Kyle: Is the target for the ecosystem level (all your issuers must meet these requirements or is the target an individual issuer?

Neil: That's up to the ecosystem as to whether all its issuers must meet the same level of requirements

John: This does raise the question, should this be a ToIP Specification (which defines ToIP compliance)? And if so is there a certification program/body and services (Neil - which the OIDC foundation does), including compliance test suites)? Or perhaps it falls on the ecosystem and components it to define why they are trustworthy and provide ways in which you might check that, including how they are governed. Asserting all components, governance, etc. be ToIP compliant may be a barrier to entry, vs. an existing system which incrementally upgrades their compliance, including being transparent on how they are trustworthy. Can see both levels of compliance

Kyle: two aspects of trust - do you trust the ecosystem and governance, and do you trust the technology, which includes things like key rotation mechanisms? The Issuer Requirements, I think speaks to both sides, but mostly technical. And then there are cybersecurity aspects that are not specified (so far, by ToIP).

Insurance and "Legibility"

Neil (post mtg) :

Legibility - a working understanding of "legibility" for tech built on something like ToIP, is how easy is it to understand ToIP and ToIP-based implementation? Adoption requires bridging the gap from non-ToIP.

Wendy - other aspects - (cyber security) insurance and legibility. Insurance from the perspective of, "if something goes wrong, how am I "made whole"". Interoperating ecosystems, which may use different approaches, but there needs to be some legible interface (e.g., APIs) to the ecosystem components and operations/governance in order to interoperate and to trust.

John: Encountered insurance questions in 2017 - if I'm provided this claim as a verifier, can I get someone to insure me against it being false? And what would I have to pay for that insurance?

Neil: Scott Perry brought in HITRUST (recorded (2023-7-27)), which provides "information protection standards" and is a certifying body for organizations to demonstrate their governance and technology with cybersecurity, data protection and risk mitigation. I asked how organizations justify the expense and organizational time commitment. The answer was a reduction of cybersecurity insurance by as much as 50%

Trade-off - using ChatGPT-4 for meeting minutes (summary) vs. human notes

Based on in-meeting human notes and digging through the recording, GPT misses some key points and details, which, in hindsight:

•  it would have been simpler to update the GPT summaries with those missing points vs. generating a separate set of human notes.