Anchor an objective/goals for the group

[andorsk]

Discussed on the ToIP APAC call March 9, 2023

We discussed putting together a proposal on the objectives of the TF. It is clear the current objective set: "The primary objective of this Task Force is to develop the ToIP Trust Registry Protocol as a ToIP Specification. The purpose of this deliverable to enable interoperability between ToIP-compliant trust registries." are not directive enough to get the group to move forward. Lots of discussion ensued about that's the right way to move the group to the next stage. With objective's set, we can move better into requirements collection phase.

The discussion notes are here:

STRAWMAN of TRTF Objectives:

Objective:
Timeline Objectives:
Adoption Objectives:
Technical Objectives:
The primary objective of this Task Force is to develop the ToIP Trust Registry Protocol as a ToIP Specification. The purpose of this deliverable to enable interoperability between ToIP-compliant trust registries.
Drummond: “…trust registries as authoritative sources of the data necessary for the members of a digital trust ecosystem to make trust decisions about other members of that digital trust ecosystem or other digital trust ecosystems.”
Principles
Architecture and Implementation Implications
Comments/Thoughts:
Sankarshan: Do timelines and adoption need to be in the charter?
Dima: What's missing is a definition of what a trust registry is. What should be inside of the TR.
Neil: Technical Objectives -> Project Objectives -> Technical and Governance Specifications
Drummond: Charter not explaining what problem TR is solving.
Jo Spencer : Need more anchors
Equivalence of data
Rules
Daniel Bachenheimer : Is this primary objective TF : to define TR vs. TRP.
Jo Spencer TRP is an output
Daniel Bachenheimer x509 Certs to reference.
Drummond Reed : is CA a type of TR?
sankarshan : My hunch is that if the following can be clearly written down there will be better understanding : what is this TF doing; when will that be done; how will this be produced; why is the TF doing it.
Eric: What does a TR contain?

[andorsk]

@talltree it occurred to me while I was writing this, that I thought we had aligned to limit the scope of the TF to simply:

"What are the questions I want to ask a TR and what answers can I receive"

This is a very narrow scope on purpose, b/c if we don't narrowly scope things to start off with, we end up continually going down a rabbit hole of other problems. Where that lands w.r.t objectives, is that the objectives can be anchored with a relatively simple scope in place. I.e given that we are only answering these questions, we expect these adoption challenges within this time frame.

The scope needs to be continuously held tight, otherwise we end up wandering endlessly.

Thoughts?

[andorsk]

I've given a little more elaboration here. In retrospect, the above does not answer timelines, nor does it answer larger questions about adoptability. The focus of this ticket (IMO) is to figure out what are the objectives and goals that need to be defined to move the group forward into requirements collection.

[trbouma]

@andorsk @talltree

Working from @darrellodonnell 's diagram, these are my my thoughts in response to: "What are the questions I want to ask a TR and what answers can I receive"

For the absolute minimum., I believe the questions are always in relation to a DID.

There there are three DID-related questions:

1. What are the GOVERNANCE AUTHORITY DIDs ?
2. Is a given ISSUER DID authorized (or delegated) by a GOVERNANCE AUTHORITY DID
3. Is a given VERIFIER DID authorized (or delegated) by a GOVERNANCE AUTHORITY DID

This model can be elaborated/generalized, of course, but I think these are the minimum questions that a trust registry would answer.

[darrellodonnell]

the v1.0 specification already does pretty much that.

the v2.0 should be limited in scope but needs to answer more:

• What DID Methods are supported in this ecosystem?
• What kinds of credentials (type, schema, etc.) will I see/use in the ecosystem?
• How can I use those credentials? - better characterized as which Verifiers should use which Presentation Request templates?
• What other config information do I need? (resources, overlays, etc.)

[trbouma]

Agree. Let's enumerate them. So are these the questions that a trust registry would answer?

Info:

1. Governance Authority List

(For a given Governance Authority) the List of authorized:

1. Issuers
2. Verifiers
3. DID methods
4. Credential Schemas
5. Presentation Requests

[andorsk]

@trbouma let's not enumerate them yet. Let's keep that as part of the functional requirements collection. Right now the question should stay at what is the objective of the task force IMO.

As an example: TRTF will provide a technology that allows one to ask questions to a trust registry and receive answers back functionally scoped by the functional requirements document. The objective of this group is to deliver a STRAWMAN by at the latest mid this year, and eventually, possibly over multiple iterations, allow this proposal to be used at minimum by major governance institutions around the world (enumerate some trust registries we want to adopt the specs here)

Essentially, I want to make sure we answer the 3 questions:

1. What are we building?
2. What results need to be delivered to be successful?
3. What's our timeline for a first draft?

These are very much geared toward operationally getting the group to drive toward the deliverable. Our next step is requirements collection, and we need to be able to appropriately drive that initiative with the objectives set forth by this task force. Our energy needs to focus on simply how to get to the next step: Requirements collection, where a lot of of these questions (as you and @guru-barbes have enumerated) are certainly up for debate.

[andorsk]

Scott Perry brought up a good point: The objectives of the Trust Registry also needs to be clear. Let's not get too in the weeds here, b/c that's a rabbit hole.

What is the problem is the TR solving? Why do we need it? I think @trbouma had some good points about delegation on the call I'll need to pull up again.

[darrellodonnell]

many suppliers of data won't allow the list to be shared, but will allow individual items to be queried.

[darrellodonnell]

The purpose/objective of a Trust Registry, is, to me: Provide the answers to the questions a system has when it connects to and participates in the ecosystem.

[guru-barbes]

Courtesy of ChatGPT, based on the five items listed above:

With full access to a database of Authorized Issuers, Authorized Verifiers, Authorized DID methods, Authorized Credential Schemas, and Authorized Presentation Request Templates, here are some examples of queries you could make:

List all the Authorized Issuers in the database.
List all the Authorized Verifiers in the database.
List all the Authorized DID methods in the database.
List all the Authorized Credential Schemas in the database.
List all the Authorized Presentation Request Templates in the database.
Find all the Authorized Issuers that have issued a particular type of Credential.
Find all the Authorized Credential Schemas associated with a specific type of Credential.
Find all the Authorized Presentation Request Templates associated with a specific type of Credential and Verifier.
Find all the Authorized Verifiers that support a particular type of Credential and Schema.
Find all the Authorized DID methods supported by a specific Issuer.
Find all the Issuers that support a specific DID method.
Find all the Authorized Verifiers that support a particular DID method.
Find all the Issuers that have issued a Credential to a specific individual.
Find all the Presentation Request Templates that have been used more than 100 times.
Find all the Authorized Credential Schemas that have been modified in the last week.

Can you think of any more?
Certainly! Here are some more queries you could make with the database:

List all the Authorized Verifiers that have verified a Credential issued by a specific Issuer.
Find all the Authorized Credentials issued by a specific Issuer that have been revoked.
List all the Authorized Presentation Request Templates that have been used in the last 24 hours.
Find all the Authorized Verifiers that have rejected presentation requests in the last week.
Find all the Authorized Credential Schemas that have not been used in the last month.
Find all the Issuers that have issued Credentials to more than 1000 individuals.
List all the Authorized DID methods that support zero-knowledge proofs.
Find all the Authorized Credentials that are expiring in the next 30 days.
List all the Authorized Presentation Request Templates that have been modified in the last week.
Find all the Authorized Verifiers that have accepted presentation requests in the last month.

[andorsk]

These are good. I think ( see my comment here they are well up for debate in the functional requirements collection. Let's keep this thread specifically anchored toward more high level objectives of the TF, which will then drive the requirements.

[talltree]

@andorsk My personal POV is that, while we want to expand on the current TF charter statement, I am not in favor of changing its essence, which is that we are chartered to specify a trust registry protocol.

Given what we have learned since that original charter, here is a proposed revised Objective statement:

---

The primary objective of this Task Force is to develop the ToIP Trust Registry Protocol as a ToIP Specification for a ToIP Layer 3 trust task protocol. The purpose of this trust task is enable the participants in a trust community to make standardized queries to a trust registry as an authoritative source for information they need to make transitive trust decisions regarding the governance framework and governed parties of that trust community or of other related trust communities.”

---

[mathieuglaude]

@talltree

I've added a couple suggestions in bold. Let me know your thoughts.

authoritative source

A source of trust graphs or other information that a relying party considers to be authoritative for that information. The governance framework for a trust community—and any trust registry, or claim, it authorizes—is typically considered an authoritative source by the members of that trust community, based on their acceptance of the governance framework. A trust root is a particular kind of authoritative source.

I also think that two entities may use multiple inputs (e.g., TRs, claims) from multiple governance frameworks in making a trust decision. Does it make sense to pluralize governance framework?

[talltree]

@mathieuglaude I am confused by the addition of "or claim", because while a governance framework might seek to establish shared semantics within a trust community by publishing a set of claims (or more likely, a set of schemas containing claims), the governance framework itself does not "authorize" claims or schemas. It only authorizes parties to serve in specific roles defined in the governance framework (examples being issuer, verifier, auditor, and trust registry operator). It is the governing body (possibly acting through an administering body and/or a set of auditors) who actually authorizes specific governed parties to perform specific roles with specific capabilities.

I am also uncomfortable with the phrase "based on their acceptance of the governance framework" because of the following proposed definition of trust community:

trust community

A set of parties who collaborate to achieve a mutual set of trust objectives. A trust community may be formal or informal. In a formal trust community, the set of policies and rules by which the members agree to abide are published in a governance framework.

Lastly, yes, a relying party may consult as many authoritative sources (or even non-authoritative sources) as they want to gather the information they deem necessary to make a trust decision. But I would not make governance framework plural because any one trust community only has one governance framework (though members of that trust community may also be members of many other trust communities).

Make sense?

[mathieuglaude]

@talltree - I just figured out how to do inline code! Woohoo!

I guess I look at trust community as a centralized (or hierarchical) way of doing things. I think we can consider decentralized (or peer to peer) scenarios as well.

For example: I'm looking to hire a CPA to help me with my finances. Must I be part of a CPA trust community in order to trust them? I can understand that the individual CPAs can be part of a trust community, but for me to trust a CPA, I'm not required to be a member of their trust community. And if that's true, then I'm not governed under the governance framework that creates trust around the CPA designation.

Before interact with a 'so-called' CPA, I am going to ask them for a set of claims, and possibly claims from others. All of these can inform me to make my own trust decision. My trust decision can be made on the claims that I ask for, and the set of inputs I seek may not be the same inputs others seek in a similar context. So in that case, no individual input is an authoritative source, they're simply trust inputs.

My trust decision may not necessarily be made on a single governance framework that brought a single trust community together.

Does that make sense?

[talltree]

@mathieuglaude These discussions are exactly how we get to consensus about terminology, so thanks for continuing to push this forward. Here are my thoughts.

First, I think there is a misunderstanding that what is meant by trust community has anything to do with hierarchy. Rather it is about a group of any size. To make that clear, here's my proposed revised definition:

trust community

trust community
A set of parties who collaborate to achieve a mutual set of trust objectives. A trust community may be large or small, formal or informal. In an informal trust community, the policies or rules governing the behavior of members may be tribal knowledge. In a formal trust community, the set of policies and rules governing behavior of members are usually published in a governance framework or trust framework.

See also: ToIP trust community.

ToIP trust community

A trust community whose governance framework conforms to the ToIP Governance Architecture Specification and is identified by a ToIP identifier.

---

Now, here's the proposed definition of trust decision:

trust decision

A decision a party needs to make about whether to engage in a specific interaction or transaction with another entity that involves real or perceived risks.

---

Lastly, here's an updated definition of authoritative source based on your feedback:

authoritative source

A source of trust graphs or other information that a relying party considers to be authoritative for that information. In ToIP architecture, the trust registry authorized by the governance framework for a trust community is typically considered an authoritative source by the members of that trust community. A trust root is another kind of authoritative source.

---

Now, given all that, as I read back through your example scenario, I think it all fits nicely:

• You, as an individual actor, can use a trust application that uses the ToIP stack to perform the trust task of requesting claims from any party, including your potential CPA.
• You do not have to be part of any trust community to do that.
• If your CPA is a member of a trust community that publishes a governance framework and has a trust registry, that trust registry is an authoritative source for that trust community.
• Your trust application can call a trust task that uses the ToIP Trust Registry Protocol to query that trust registry to verify that the issuer of the claims you are verifying is authorized to issue such claims.
• You can continue that process for all the claims and all the trust registries of all the trust communities that you as the verifier might want to query (plus any any other information you might want to gather) to inform your trust decision about that CPA.
• On the basis of the information you have gathered, you as the verifier make your own trust decision.

All of these definitions can describe trust communities and authoritative sources that are centralized, federated, or completely decentralized. Do you agree? What would you further revise?

[mathieuglaude]

Thanks for this, Drummond. We're aligned.

[darrellodonnell]

I have created a google doc for joint editing as we would like to get to closure at the next TF call (Thursday PT). https://docs.google.com/document/d/1gxIKnHFm1BltoiW-TT0kn4rVc_RcwOB5NogY7EktDiM/edit?usp=sharing

[talltree]

I have copied over my proposed Objective text to Darrell's Google doc.

[a-fox]

I created a PR for the latest objective text:
#87

[a-fox]

@andorsk / @darrellodonnell I just red the revised objective in #90

The objective of the Trust Registry Task Force is to develop the ToIP Trust Registry Protocol.
The purpose of the ToIP Trust Registry Protocol is to support the participation in a trust community and enable trust tasks.
A trust registry provides authoritative information in relation to a governance framework needed to perform trust tasks and inform trust decisions.

I like especially the last sentence. It captures the essence nicely. But to be honest, the second "purpose" sentence is not clear and the current wording doesn't convey the idea clearly.
You may have had good discussions around this, so I wanted to see if there is some specific reasoning with the wording of the second sentence.

IMO, a similar, but more informative version could be:
The purpose of the ToIP Trust Registry Protocol is to support participation in a trust community, governed by a governance framework.

My reasoning for the sentence structure is that trust tasks are not the only enablement of a Trust Registry. Trust Registry's minimum requirement is a governance framework. No governance = no trust registry.

[andorsk]

LGTM!

[talltree]

Can I propose some additional wordsmithing to further align it with proposed TSWG terminology?

The objective of the Trust Registry Task Force is to develop the ToIP Trust Registry Protocol as a ToIP Layer 3 trust task protocol that enables standardized interactions with a trust registry. The purpose of a trust registry is to enable participants in a trust community to obtain authoritative information about that community's governance framework and governed parties.

[a-fox]

@talltree, I like your description. However at the same time, it changes few of the key elements:
1) It introduces the trust registry trust task – although we've discussed this in many occasions, especially when looking at the larger 'contextual trust decision protocol', I don't think we've expressed it this clearly and strongly.
2) It becomes agnostic to the value of the trust registry – "perform trust tasks and inform trust decisions" was considered good for this.

Now, I'm not saying these are wrong, but considering the discussions we had in last weeks meetings, this will need critical community review. I propose that since you're able to join in todays meeting, you would walk us through your text proposal, and let's have community discussion around it. Goal is to commit the Final version ASAP.

[andorsk]

Discussed in ToIP call:

• Drummond: Not tied to governance framework.

• Darrell: Governance not always required. Regulation is governance.

• Sam Curren: Regulation CAN be the governance.

• Tim: All a governance framework. Don't worry about the implementation. Authoritative by framework.

• Scott Perry: Force things into a governance framework. Alternative things required to satisfy the group in order to put governance framework.

• Michael Palage: Looking at DNS. Decentralized. Delegation at different governance levels. How do you federate registries? Keep a high level as possible. Need to be part of the winning team.

• Savita: Agreed with Scott. Does not need to be forced into governance.

• Group: Move forward with Drummonds proposal. Open to modifying this over time.

[talltree]

Proposed additional wordsmithed version based on feedback (from Jo, Judith, Andor, and others) in today's APAC call. Note that all highlighted terms in this proposed objective statement now have proposed definitions in the ToIP Glossary Workspace:

---

The objective of the Trust Registry Task Force is to develop the ToIP Trust Registry Protocol as a ToIP Layer 3 trust task protocol that enables standardized interactions with a trust registry. The purpose of a trust registry is to serve as an authoritative source for governed information about a trust community.

---

[darrellodonnell]

@andorsk Can you prep a PR for me to approve. I presume that the group ended up reaching alignment after I had to leave the call. I'm pleased with where it has landed.

[andorsk]

I will update the PR! Sorry for the delay

[andorsk]

Done! bb80a60

[jospencer-460]

A couple of comments from me that I think are important...

1. As pointed out in my discussion, trust registry related tasks and services can be at either layer 3 or 1 (or even layer 4). The protocol objective should be to identify and enable standard interactions for trust registry use. This might be through specific access to a trust registry or other solutions that enable the use of trust registry services. There is no need to specify that this is Layer 3 (implies that this is only layer 3).
2. The protocol should be supportive of both consumers and governing bodies. I'm less worried about updates to the objective to specifically identify these two access roles, but it could be included.

So I suggest a small change as follows...
The objective of the Trust Registry Task Force is to develop the ToIP Trust Registry Protocol that enables standardized interactions with a trust registry related services. The purpose of a trust registry is to serve as an authoritative source for governed information about a trust community.

[jospencer-460]

I also agree with Neil's slack discussion that "trust ecosystem" would be a better option to "trust community" as I'd assume this is a better defined term.

[talltree]

@JoOnGT I suspect the misunderstanding here is our definitions of specific terms used in the objective statement — which is why I provided a link to the ToIP Glossary Workspace for the definitions of each proposed term used in the proposal. Let me quote the proposed definitions of the three terms most relevant to this discussion:

---

trust community

A set of parties who collaborate to achieve a mutual set of trust objectives. A trust community may be large or small, formal or informal. In an informal trust community, the policies or rules governing the behavior of members may be tribal knowledge. In a formal trust community, the set of policies and rules governing behavior of members are usually published in a governance framework or trust framework.
See also: ToIP trust community.

---

trust registry

An authoritative source for trust graphs or other governed information describing one or more trust communities. A trust registry is typically authorized by a governance framework.

---

trust task

A task involving establishing, verifying, or maintaining trust that can be performed on behalf of a trust application by a ToIP Layer 3 trust task protocol.

---

trust task protocol

The ToIP Layer 3 protocol that implements a specific trust task on behalf of a ToIP Layer 4 trust application.

---

Now, to quote the first sentence of the proposed objective statement again:

---

The objective of the Trust Registry Task Force is to develop the ToIP Trust Registry Protocol as a ToIP Layer 3 trust task protocol that enables standardized interactions with a trust registry.

---

From the definitions above, the reason that sentence states that the ToIP Trust Registry Protocol is a ToIP Layer 3 trust task protocol is because all ToIP trust tasks are carried out as ToIP Layer 3 protocols by definition. And the purpose of that particular trust task protocol is to provide a standardized way to talk to a trust registry.

That trust registry may contained governed information pertaining to any ToIP component at any layer (which is what I believe you were saying on yesterday's APAC call). But the Trust Registry Protocol itself is a ToIP Layer 3 protocol.

Does that all make sense? Or do you think there's something wrong with these definitions?

[talltree]

I also agree with Neil's slack discussion that "trust ecosystem" would be a better option to "trust community" as I'd assume this is a better defined term.

As we've been working on the ToIP Glossary Workspace, the challenge we are finding with the term "trust ecosystem" (or "digital trust ecosystem") is that it has been heavily associated with ToIP Layer 4. For example, that's why the ToIP Foundation has an "Ecosystem Foundry Working Group", whereas at ToIP Layer 1 we have a "Utility Foundry Working Group".

So in the Concepts and Terminology Working Group, we started using the term trust community for any set of parties using the ToIP stack together, regardless of layer. Here are proposed definitions:

---

trust community

A set of parties who collaborate to achieve a mutual set of trust objectives. A trust community may be large or small, formal or informal. In an informal trust community, the policies or rules governing the behavior of members may be tribal knowledge. In a formal trust community, the set of policies and rules governing behavior of members are usually published in a governance framework or trust framework.
See also: ToIP trust community.

---

ToIP trust community

A trust community whose governance framework conforms to the ToIP Governance Architecture Specification and is identified by a ToIP identifier.

---

[jospencer-460]

Given the clarifications above, I'm happy with the definition as it is, @talltree. However, the assumption that the protocol will only define the layer 3 tasks implies that the layer 1 services have also been defined and agreed, or the layer 3 tasks will be untested.

Thanks for the glossary clarifications - you're closer to these than I've been.

I am a little concerned that we're trying to segregate the ToIP layers too much and that will create these concerns about ecosystems being at layer 4 only etc. I don't think that segregation of layer considerations in isolation is helpful.