Replies: 9 comments 29 replies
-
@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? |
Beta Was this translation helpful? Give feedback.
-
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:
This model can be elaborated/generalized, of course, but I think these are the minimum questions that a trust registry would answer. |
Beta Was this translation helpful? Give feedback.
-
the v1.0 specification already does pretty much that. the v2.0 should be limited in scope but needs to answer more:
|
Beta Was this translation helpful? Give feedback.
-
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. Can you think of any more? List all the Authorized Verifiers that have verified a Credential issued by a specific Issuer. |
Beta Was this translation helpful? Give feedback.
-
@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 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
@andorsk / @darrellodonnell I just red the revised objective in #90
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. IMO, a similar, but more informative version could be: 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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
A couple of comments from me that I think are important...
So I suggest a small change as follows... |
Beta Was this translation helpful? Give feedback.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions