Define Scope of TRTF

[andorsk]

This is related to determining the scope of the Trust Registry Task Force, with relationship to #48 . My proposal is the following:

1. We define a trust model (see below)
2. We define the scope of the work here w.r.t a trust decision

At conclusion to this, my suggestion is that the TRTF normative scope is limited to support of trust services. The non-normative scope may extend outside this restricted scope. support of trust services needs to be further clarified, as various specifications that can allow for interop and extension of services that provide a trust context, to enable trust decisions. I would propose that the models provided are required to allow for extensibility later on, and assume that there will be additional contexts required for trust decisions that we will not necessarily know.

Note: We are not encoding the how make a trust decision, i.e what business logic you use to make the trust decision. We are just providing the mechanics and framework to inject contexts to make a trust decision.

To close this: A PR would be required into the TRTF deliverable with a scope section included.

---

STRAWMAN
Trust Decision Model

• $h(g(f(C, x)))$
  • where:
    • $f(C, x)$ is a trust embedding ( Trust decision framework mapping )
    • $g(f(C, x))$ is a trust decision
    • $h(g(f(C, x))) = z$ represents an action (or effect) based upon a trust decision. It chooses $z_i \in \mathbb{Z}$ where $\mathbb{Z}$ represents a set of possible effects from a trust decision.
    • $C$ is the decision context
    • $x$ is the set of claims
  • Scope: This task force is focused on supporting system around $c_{\text{trust services}}$ and the data models in $x$, which represent claims. While recommendations may be provided on the other functions, anything outside of $c_{\text{trust services}}$ and $x$ is considered non-normative and out of scope. Some ways this translates within the deliverable:
    • Specification Deliverable
      • Service Discovery
      • Containers
      • Data Models
      • APIs
    • Companion Guide:
      • Recommendations and best practices
• ${c_i, c_j} \in C$ where C is the decision context and $c_i, c_j$, are different data contexts.
• $x$ represents claim data

[andorsk]

related to decentralized-identity/trust-establishment#46. Specifically might help inform them over the collaboration.

[andorsk]

• @a-fox and @neil: to take different trust models today to help inform the discussion. Probably part of the companion.

[andorsk]

• Discussion of whether this fits in scope.
• Container to move around the registry.
• Consume multiple data sources
• What’s the relationship between this and OCA.
• External to the credential definition.
• Jo Spencer: Don’t lose nonrepudiation.
• @talltree : BC gov pioneered every model verifiable. Maybe VC is the data model we use or referencable.
• @talltree : Remind me that the Governance Stack Working Group asked me to request a presentation (probably at their February meeting) to better understand trust registries so they can better understand what kind of governance is needed for a trust registry. Reference to https://bcgov.github.io/TheOrgBook/
• @darrellodonnell : in the wild a lot of groups are seeing the value of governance.
• jo: Is an injected source data a verifiable credential itself? @talltree it's one option.
• @darrellodonnell : To me the Trust Registry is the technical embodiment of key parts of the governance. Systems that want to integrated into a governed ecosystem need answers...
• @talltree : Companion guide and spec explaining how to make a trust decision
• @darrellodonnell : Subtly of same credential to different holder not understood by the wider audience.
• @talltree : Option of credential registry as trust registry.
• @andorsk : limit scope as much as possible but allow for extension.
• @jo : if becomes a hold up for VC, inquiring parties become the verifier.
• @darrellodonnell : if we do this right, if there's no formal authority, but can still build a trust decision.

[andorsk]

As I've thought about it more, I think we really need to think about how this TF fits in with the DIF efforts. IMO, DIF should be focused on building the mechanics out (i.e the actual JSON schema and MRG files ) that provide the standard formats. ToIP should provide the framework and models to direct the efforts of DIF. It's a 🌶️ take, but might make sense. Let's discuss next call.

[darrellodonnell]

I don't think it is a hot take. There will be upcoming hot takes on API design and decisions (e.g. simple vs. elegant) for sure. Where DIF has a data construct (MRG had some nice and simple one) we use/align with that. Where necessary we create our own. The hard part is when we end up with data structures that are overly-complex we may end up debating that simple/elegant line.

[andorsk]

A little off topic (apologies) but I like to think of analogies to help communicate ideas. A thought I had today that might help communicate why descriptive trust models (like the model above and tim bouma's model are important:

Let's look at the video game ecosystem as an analogy to the trust ecosystem.

Video Game Ecosystem
There are many different types of video games in this world. Some are action games. Some are adventure games. 2nd Life. World of Warcraft. Mario. Super Smash Bros. And of course, the GOAT, Zelda. There are many different companies that have enjoy to build many different "flavors" ( Nanco, Nintendo, Sony, Microsoft ). It is extremely common for the video games to use some form of a physics engines ( Unreal Engine, Unity as examples). These physics engines are not random fabrications. They are heavily reliant on math, and require a fundamental understanding of physics that has been illuminated over hundreds of years of science ( i.e $F=ma$, $p=mv$, etc) . The games use these physics engines, because the world quickly becomes unstable without the mathematics to drive it ( I know, because I've built them myself. Physics engines are really hard to build. ). In a lot of ways, this is similar to the work we are doing here.

Trust Ecosystem
There will be many different governance bodies (USA, Canada, your family, etc). In this analogy, they are analogous to video game companies. They may have different trust frameworks, with different parameters and rules they operate under ( i.e no two video games are alike). However, they will need to rely on an "engine", of some sort that powers the simulation that mirrors a normal trust decision. ( i.e the physics engine in video games or in our case, a probably a protocol ). The engine is built upon "models", which are usually born in mathematics, (i.e the model above) similar to how a physics engine uses F=ma and other formulas as the basis for operations. If they don't rely on these fundamental observations, they quickly can become unstable within the rest of the frameworks. We want to provide the right "engine" that allows the trust ecosystem to become stable.

There's obviously some nuances here I'm not capturing, but I think the analogy might be a little easier to interpret for some.

Happy to take feedback on it. Again, might be helpful and might not be, just trying to fit the story into something more consumable.

[talltree]

@andorsk I think that analogy is excellent. In fact, I have even referred to the set of design principles we defined in Part Two of the Design Principles for the ToIP Stack as the "physics of trust". And the design for the "game engine" is no less than the ToIP Technology Stack for technology and the ToIP Governance Stack for governance frameworks aka trust frameworks.

The video games companies are governing bodies, and the video games themselves are digital trust ecosystems defined directly or indirectly by specific governance frameworks.

Wonderful analogy!

[andorsk]

Reference to a conversation with @JoOnGT here

[andorsk]

From John at the ToIP call today:

Sorry for my late arrival (Jo caught up too). Joined around the half-hour point when Drummond was talking about trust graphs. Made me think...

Long comment/chat (happy to copy/paste to the right discussion on GitHub)

I like this analogy (but then I like directed graphs and graph theory in general, so I'm biased). I think it goes nicely to the generalised (and hence hopefully simple) solution.

For me, this means that a user/verifier should be able to "traverse" a trust graph (where registries are nodes on the graph and the things they refer to and/or are pointed to by are the arcs) and where each graph has a finite span, which may be large or small. Hence there is a finite amount of information that can be discovered defined by the graph extent. The verifier can traverse the graph until they are satisfied that they have enough trustworthy evidence for them to make their decision (in context), or until the graph has been fully traversed and there is no more to find, in which case they still decide what to do.

Trust registries are simply (but very powerfully) nodes in the trust graph.

Yes/No?

[andorsk]

tagging @JohnOnGH

Discussion on call today: v1 very credential centric. v2 is more generalized.

[JohnOnGH]

Thanks @andorsk - that's an accurate copy/paste of my comment :-)