Define Requirements and/or Goals For You As a Stakeholder

[andorsk]

Please note your requirements for the TRTF. What do you care about accomplishing in this TF. Please be specific if possible.

[neiljthomson]

Trust Decisions - needs definition.

• what is the scope of a trust decision?
• what are the inputs (parameters) that feed a trust decision that can result in a result of entities, etc. that meet candidate entities that match those parameters
• trust decisions are usually a series, starting with
  • a bare minimum requirement (e.g. verifiable DID)
  • who are you, and can you prove it (basic entity trust)
  • what credentials do you have in the area I'm looking for expertise
  • narrow the expertise - what evidence do you have on my specific problem?
  • ...

This suggests a tree of trust registries where ultimately someone is parsing candidates on which to do a specific transaction

[andorsk]

Re: the above: How close is #62 to answering that in your opinion? I don't think the last point about series is addressed, but what about everything above?

[trbouma]

A fun little diagram where I try to situate the 'trust thing' to be defined.

[andorsk]

@trbouma again with the unique perspective. Love it. I'm wondering if we can migrate these comments to a new discussion which is a little more relevant. These are valuable, so I don't want to lose them, but a little out of scope for the initial discussion.

[neiljthomson]

I would suggest the context would be a discussion on tech and governance risk & related requirements

[JoOnGT]

As usual, terrific imagery... basis is selective end-to-end encryption and end-to-end non-repudiation...

[neiljthomson]

@darrellodonnell, can you take your Swagger definition in #61 and put that into muggle terms?

[andorsk]

I think you mean #60 here not #61

[andorsk]

Design requirements:

• Upgradable: We can adjust and version our frameworks without breaking everything in the process. i.e allow for easy upgrade paths.
• Generalizable: We don't anchor too much on a particular use case. These deliverables should be generalizable and aware that many use cases are not discovered yet. I like taking it to the extreme: How do you use this in a village?
• Conceptually anchored: We have a clear conceptual model to anchor against for a long time, with a clear way to define "breaking" updates to the model.
• Easy to adopt We can make adoption as easy as possible and accomodate as many existing trust frameworks as possible with minimal change overhead
• Flexible: We should robust standard for trust decision making that can accomodate a lot of trust decision frameworks ( some known, but many unknown ).
• Technologically Robust: A requirement that there is some technological robustness to the deliverable, in that it can handle many technical situations (i.e out of band, centralized or decentralized contexts, etc ).

As a group:

• Ability to see the bigger picture: I know there are a lot of use cases short term that need to be solved. I'd encourage we see the bigger picture past our initial goals.
• Recognize and balance the need for urgency: There is a lot of need TODAY for a good TR system. I think we need to recognize and balance the urgency for a solution today, with the requirements I specified above. Easy upgrade paths are one way to accomodate those tradeoffs.
• Humility of the unknown: I'd like us to be cognizant we don't know what we don't know and have some humility to remember that things evolve and adapt over time, in ways we can't possibly anticipate today.

Use cases I care about:

• Business Applications: I see business applications needing a robust decision making framework, that will require lots of inputs from different trusted sources. I'd hope our specs could accomodate them.
• Improving the Visa Process: I have a very personal use case as well. The visa process is horrendous. I have been waiting on a visa for 2 years for my wife to meet my family, and I can't express how bad the current situation is. It's one of my life's mission to fix this problem over the longer term, make the process more equitable, and to enable faster processing around the visa process. To do that, trust registries are a critical part of that equation and I hope we can solve that use case.

[trbouma]

For users, it has to be a simple as a DNS lookup to help with whatever trust decision.

[guru-barbes]

I'd like to get a clear sense of the following:

1. What is the minimum data / meta-data (if any) contained in a trust registry?
2. What is the minimum data essential for the functioning of a trust registry?

i.e. what are the minimum data points that need to exist in order to enable verification?

3. What kind of data / metadata may be linked to a trust registry in order to support the human verification / trust process?

[sawhitmire]

I'd like to see a simple example of what someone thinks a trust registry looks like. I've heard the conversation around them, but get conflicting notions. All I've seen so far are boxes in a diagram. Part of the example addresses what a trust registry contains, but also who owns it? Who maintains it? How can we verify them? Can it be spoofed?

[guru-barbes]

Me too! A lo-tech guy like me REALLY wants to see what this would look like. I have two rough concepts in my mind:

1st - An interface to a trust registry which allows (with access permissions) users to discover and explore:

• DID and details of governance framework which governs the trust registry
• DID and details of governing / administering authority
• DIDs and details of issuing parties, proof of their acceptance (signature) of GF T&Cs, proof of their authority to issue credential types
• DIDs and details of verifying parties, proof of their acceptance (signature) of GF T&Cs, proof of their authority to verify credential types
• ...

2nd - Innumerable interfaces via an app or other website that pulls the same type of information from the trust registry for evidence sharing and exploration

That's as far a as I can get ...

[talltree]

@sawhitmire and @guru-barbes: We're still at the problem definition and requirements stage for this second generation of the Trust Spanning Protocol work — and thus deciding how much broader in scope we want to consider vs. the first generation — but if you want a clear picture of the role of a trust registry within a digital trust ecosystem, check out the description in the ToIP Trust Registry Protocol V1 document. I'll put more about my own thoughts below.

[talltree]

Just so it doesn't get lost, below are the three basic problem statements I personally want to see the Trust Registry Protocol solve. Notes: a) these are the same three problem statements addressed (narrowly) by the V1 Trust Registry Protocol spec, b) the boldfaced terms used in these problem statements are either from the eSSIF-Lab Glossary or the ToIP Core Glossary.

1. How can a verifier determine if the issuer of a verifiable credential is authorized to issue that type of credential under a particular governance framework that the verifier trusts? Example: How can AceAirways determine that LuckyLabs, the issuer of a COVID test credential to Paula Passenger, is authorized to issue COVID test credentials in Canada?
2. How can a holder determined if a verifier is authorized to make a particular type of presentation request under a particular governance framework that the holder trusts? Example: How can Paula Passenger discover that her local Better Health Bureau believes it is safe to present a proof of her COVID test credential to MonsterMovie Theatre?
3. How can a party discover if one trust registry trusts another trust registry? Example: How can Paula Passenger discover where she can find a testing lab in Thailand that the Canadian government trusts to issuer her the COVID test credential she will need to return to Canada?

[trbouma]

I think these basic problem statements can be distilled further into one generalized problem and problem statement:

First - verifier, holder, issuer can be abstracted to 'actor'
Second - issuing, holding, verifying can be abstracted to 'action'

Then, the basic model is this:

• An actor is authorized to carry out an action, either on its own behalf, or on behalf of another actor.

So the basic query is this: Is the actor authorized to carry out an action, and by extension, can I rely on the output of this action?

I think this simple model can be mapped to the three problem statements above.

Also:

• an actor can be an individual entity, or a governance entity. (this distilled model makes no type distinction)
• this can be implemented using DIDs that have the ability to sign. We've had this discussion earlier in the thread.

[talltree]

@trbouma You nailed it. That is the basic problem statement that I believe the Trust Registry Protocol needs to be designed to answer.

[JoOnGT]

Nice! You might enjoy the ESSIF-Labs Mental Models, that looked to incorporate exactly this...

[JoOnGT]

1. High level - Define the ecosystem lifecycle for governed and suitably authenticated information, that supports trust decisions by holders and verifiers
2. Frame the use of Verifiable Data Registries in the context trust decision making (like 1, but from the trust decision making perspective)
3. Frame the actors, roles and activities in alignment with the governance groups
4. Identify data types which might be supported by VDRs (issuers, verifiers, credential types / versions, wallet types, use cases, use case rule sets etc.)
5. Ensure cross-jurisdictional VDRs support discoverable and controlled access by decision makers
6. Ensure that VDR management and dataset version uplift/change/enhancement is catered for (with backward compatibility, long term usage, platform migration etc.)
7. Frame VDR implications for specific topics like supported activities (guardianship), mutual recognition of credentials (rules), etc.
8. Assess VDRs and VDR management for potential harms and user challenges
9. Outline the VDR specific governance implications, for incorporation into other ToIP activities - act as a coordination group across tech arch, trust spanning protocol and governance groups
10. Provide a list of logical services and integration designs for accessing VDRs (inline with the TSPTF)