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 https://github.com/decentralized-identity/trust-establishment/issues/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.