TRTF Meeting Notes

Note that normally meeting notes occur On the Wiki . Due to the wiki being broken today, we are using HackMD instead. I will transfer notes to the wiki when it's back alive.

Notes: Jan 19 Preparation

• Attendees:
  • Antti Kettunen
  • Darrell o' Donnell
  • Andor Kesselman
  • Isaac Henderson
  • Judith Fleenor
  • Kaliya Young
  • Dan Bachenheimer
  • Christine Martin
  • Lucy Yang
  • Christian Heimann
  • Michael Palage
  • Mathieu Glaude
  • Tim Bouma
  • Michael Herman
  • Simon Nazarenko

Meeting Notes: January 19, 2023

NA

• Attendees:
  • Antti Kettunen
  • Darrell o' Donnell
  • Andor Kesselman
  • Isaac Henderson
  • Judith Fleenor
  • Kaliya Young
  • Dan Bachenheimer
  • Christine Martin
  • Lucy Yang
  • Christian Heimann
  • Michael Palage
  • Mathieu Glaude
  • Tim Bouma
  • Michael Herman
  • Simon Nazarenko

• @a-fox and @neil: to take different trust models today to help inform the discussion. Probably part of the companion.
  • Call to action: Add to the trust model slides
  • trying to synthesize models together
  • top layer the charter: rights, privledges, duties, and responsibilties. typically called private law
  • covenant: promise between parties. typically public law
  • connection: relationship between parties
  • commitment: proved committed to a value

EU

Notes: Jan 12 Preparation

Agenda

• Darrell: Doodle. Where we at with that?
• PR-46
• Issues:
  • Darrell: Discussion around swagger protocol
  • @andor
    • Model: Scoping discussion
      • Trust Model
  • @andorsk Deliverables *

Notes: January 5 Preparation

Thoughts and prep work done in preparation for the Jan 5 meeting on TRTF.

Notes to move later:

• v1 spec:
  • Verifiable issuers vs. Verifiable verifiers.
  • @Darrell: Context was required to authorize issuers vs. verifiers. RWOT: naive. Assurance framework not the whole picture.

Proposal of a way forward that people can align on

• Proposal: Move v1 spec into subfolder. v2 spec work starts.
  • Start a PR to anchor discussions around initial TRTF scope and deliverables OR Open an issue OR work on Google docs.
• Proposal: Work off Github issues and discussions or continue to work on google docs
  • Propose options to the group. Let's settle this soon?
• Proposal: Define goals of the project limited by not including:

  • Goals of the Task Force?

    • What are the ambitions of the task force.

  • Audience?

    • To be discussed. See the deliverable doc.

  • Scope:

    • Proposal: Scope of this task force is to build a model that supports \(c_{\text{trust services}}\) and allows additional \(c\) to be incorporated in the data models.

  • Adoption

    • How will the work we do become adopted? What are the challenges? Make this into an discussion we can iterate over.

  • Deliverables

• Proposal: Figure out how to work with DIF
  • Proposal: @Darrell to setup meeting with DIF next coming week
• Proposed Deliverables: Spec and companion guide. Let's anchor this if this is actually the direction we go.
• Proposed Next github steps: get repo setup for contributions.
• Proposal: Landscape discussion. Bring as a discussion.
  • How these efforts fit into the larger landscape.
    • w3c
    • DIF
    • How does this work get us to point B? What puts point B at risk?

Proposal: Decision Model

Current model suggstion based upon various conversations over the last few weeks.

To continue to iterate and eventually move into a more formal document.

• Trust Action 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

Notes from December 23 Meeting

• Andor
  • \(f(x) \to g(y) \to h(z)\)
  • 
  • Humility we don't know what contexts will be required
  • Suggestion: Move the current stuff into a folder for v1 and create a new folder for v2.
• John:
  • Two different things:
    • Standards bodies aligning
    • Not a technology issue a goverannce issue for v1
    • Alice –> Bob : trying to discern trust:
      • might look up trust registry
      • might do other things.
      • \(f(x)\) very complicated decision process.
  • some of these decisions are not computationally decisive
  • In place conversion from v1 to v2 w/ PR
    • If major version change, might be easier to start with a fresh page.
  • Continuity
    • v2
  • 2 things we are doing:
    • Trying to do things right in the spec.
    • Adoption.
• Jo: More aware of the larger landscape in v2
  • VC: evidence field might be helpful * a set of ways you might check about it. * reference check dids
  • Discovery: * generalized search function * some other context
  • Mistake of reductionism toward a very complicated problem
  • v1: 3 simple trust services:
    • issues, verifiers, governance. Is that enough.
  • How do we create a more broad defined understanding of the role of the trust registries and consistent.
  • Split \(f(x)\) into two components.
  • f <- categories of internal, external information.
  • robodebt: work out how much people should be paid for social services.
  • generalize information to the whole environment. specific information not going to get into.
  • Trust registries. Not talking about trust decisions.
  • Externalization of capabilities through services.
    • Define services.
  • fuzzy matching
  • onion picture
  • v1: 3 basic bits of information
    • externalize that
  • \(f(x) = f(x_1) + f(x_2) ... f(x_n)\)
    • \(f(x_1, x_2, ..., x_n)\) = \((f(X))\) where \({x_1, x_2\,..., x_n \in X}\)
  • \(x_1\) services provided by the ecosystem
    • FOCUS OF SPEC is HERE
  • \(x_2\) internal to the decision maker.
  • \(x_3\) things external from the decision maker and the environment.
• Definitions of services in v1 need to be redefined in v2
• Terminology will change across versions.
• Good this TF is thinking about this more hollistically.

graph TD
    onion((onion))
    actor
    actor --> onion

Action Item

• Next Week Off
• Proposal of a way forward that people can align on.
• Primary models and basic evolution approach for future versions
• Agreement about how to move forward on collaboration. Google docs or Github.