Model Trust Decision Data Flow Process

[andorsk]

Model how data flows in a trust decision. i.e Service Discovery. Management. And how it relates to the flow.

Early capture: Needs some work

sequenceDiagram
   participant  Trust Registry   
   participant Issuer
   participant Holder
   participant Verifier
  Trust Registry-->>Issuer: Makes a claim about issuer.
  Issuer -->> Holder : Makes a claim about X
  Verifier -->> Holder : Requests claims (i.e PEv2)
  Holder -->> Verifier : Presents claims 
  Verifier -->> Trust Registry : checks if issuer is authorized to make claim. 
  Trust Registry -->> Verifier :  responds to verifier if yes or no.

Loading

[sawhitmire]

I'm going out on a limb, here, but I have a really basic question. I see a lot of requirements for a trust registry, but I don't see a lot of discussion about the need for one. Take the diagram above. The left most column could just as well be the governance authority for the ecosystem, to which the verifier actually verifies the credentials of the issuer. What the diagram does not show is the verification of the claim itself. Verification is a chain of verification requests until one gets to a final authority or an authority that one trusts. Verification <> trust, which is a pre-determined decision about whose verification is "good enough" for the purposes at hand.

Verifying the issuer's credentials is a matter of ensuring that the key controlled by the next step in the chain, perhaps a governance authority, was used to sign the issuer's credentials and that those credentials include permission to issue the credential that has been presented. Verification is thus a technical operation that follows a chain of VCs to some end and returns either a yes or no. Trust in the result is based on the trust placed in the issuer at the far end of the chain. Thus, every participant in a trust chain will be a verifier at some point (which implies that verifiers do not need to be registered since the operation is part of the one of the layers in the architecture).

So, my question, well, questions: Do we really need trust registries? What do they provide that cannot be provided by other more necessary components? What operations are unique to trust registries? What does "interoperability between trust registries" really mean in practice?

[trbouma]

Here is another over-simplified diagram that is helping me to understand the problem and to try to answer @sawhitmire's question.

I think we are trying to define a "Trust Response" that can be looked up in a "Trust Register" so that a "Trust Decision" can be made.
Not sure yet what to call this "Trust Response" thing, but hopefully it can be defined in such away that it can be used across many governance authorities (i.e., contexts). As I described in an earlier post, I think this "Trust Response" thing, has in part something like a SUBJECT_DID, SCOPE, signed by a CONTEXT_DID (representing the governance authority). This answers the following questions:

1. Can I trust the SUBJECT_DID? (authenticate the SUBJECT_DID)
2. Can I trust the scope under which the SUBJECT_DID is acting? (verify using signature from CONTEXT_DID)
3. Can I trust the CONTEXT_DID? (trust the governance authority controlling the CONTEXT_DID)
4. Finally, can I trust whatever the SUBJECT_DID signed? (verify using signature of the SUBJECT_DID)

In the end, I believe we are trying to define something that is new in legal conception. For more info, I try to get at it here: https://trbouma.substack.com/p/data-object-or-is-it-a-thing-of-intention

[sawhitmire]

I get where we are trying to go: we need to be able to make a decision about whether to trust a verification, and that means we need to be able to trust the verifier. Trusting an organization requires due diligence, research done before a transaction, another form of "we can trust only those we know". Supply chains have done something analogous for new suppliers for years. In our context, we have to decide to trust a verifier or governance authority and then try to create a chain of verifications that leads to one of our trusted verifiers. If we can do that, we can trust the entire chain and we trust the link in that chain closest to us.

Given all that, I don't see how a trust registry gets us there, especially one that spans multiple governance authorities. Membership in such a registry would have to be vetted by some, what, a meta-governance authority? If not, it becomes something like the blue check mark on Twitter: something that can be bought and hence cannot in any way be trusted.

I have yet to see a compelling argument that a trust registry is a solution to this problem, let alone the best solution. I am skeptical, and can be convinced; it just hasn't happened yet.

[guru-barbes]

I think the human part of the trust equation has been asking for a trust registry. Coming at this from a pure technological perspective, it seems we don't "need" a trust registry - i.e. we already have the VDR to support issuance and verification...

But I've found that people I talk to outside the our space really want to "see" some demonstration / representation of the processes, protocols and technology (magic cryptography, private keys that no one has ever seen...) that is happening behind the scenes/screens.

I find the solution a trust registry solves is making 'tangible' all the stuff happening behind the screens, by providing evidence that can be explored / expanded, and hopefully tracked to its purported source.

The real challenge for me is to understand what evidence the trust registry needs to / can support. From that point, it's up to someone else to make it simple to visualise / interact with that evidence in order to make their trust decision.

[darrellodonnell]

@sawhitmire, your points are well-received and timely. We've had two conversations that are overlapping and bleeding into each other. Your response may help separate these concerns. I am still forming some better writing but I will share a few things here piecemeal for now:

NOTE: I will throw in some examples of system-of-record/source-of-truth using a professional engineering licensing institution. Professional Engineers Ontario is the body that manages licensing of professional engineering (P.Eng. - known as PE in the US). They have been legislated into this role.

• A Trust Registry, in my worldview, provides ANSWERS to QUESTIONS from an ENTITY from the perspective of the ecosystem that is represented (by the trust registry). Those answers are used as input by the ENTITY, and are NOT trust decisions. The ENTITY must make its own decisions about what to do with inputs from the various entities it interacts with.
• A Trust Registry exposes data (answers in point above) that are made available from some system-of-record/source-of-truth that operates under a given Ecosystem Governance Framework (EGF).
  • EXAMPLE: You can ask "Is PersonX a licensed professional engineer in Ontario?" to a PEO trust registry.
• The Trust Registry Protocol is concerned about providing the answers to EXTERNAL entities - i.e. those parties that need to know what a system-of-record says about "the thing" (Authoritative Issuer, Authorized Verifier, Approved Wallet, DID Methods, etc.) that the EGF manages.
• The Trust Registry Protocol is NOT about the internal management of the system-of-record/source of truth. The internal management (e.g. adding/revoking Authoritative Issuer status, adding/removing Approved Wallets) of those data are handled by the system-of-record/source-of-truth.
  • EXAMPLE: In providing the earlier answer about a P.Eng. holder, PEO may manage a license in whatever way they want. The external world can ask, "Is PersonX currently a professional engineer in Ontario?" and get an answer. They don't get to ask "and show me all the work you did to meet your regulatory requirements". That's a different conversation and outside the scope of the Trust Registry Protocol.
• Trust Decisions are made by entities and require INPUT. j
  • EXAMPLE: You, as a company, may look to PEO to find out if someone is a licensed P.Eng. in Ontario, but your business decisions to act on that is yours, not PEO's.
• Trust Decisions are NOT made by a Trust Registy. The most a Trust Registry can say is "I am the system-of-record and here is my answer in the context of this EGF".

I am forming more thoughts on this as well, but wanted to share the above.

[sawhitmire]

@darrellodonnell Your response and others are leading me to the conclusion that a trust registry is the same as a blockchain or KERI ledger. If that is indeed the case, we can end this discussion and get on with things. After having been gone awhile, coming back to the new term was a bit confusing. I have been looking for black boxes and operations to use in designing systems and "trust registry" seems to be a good generic name for the public register used in the verification operation. Verify, as an operation, validates the provenance of a message/VC and that the claimed sender is a valid issuer in the context of the governance framework in which the operation is performed. Verification is not trust, but an input into a trust decision, as you describe. If we all agree, then we're good to go. Note that verifying a message/VC and verifying the sender may require accessing two different ledgers.

If we don't, however, my question then morphs to become: How is a trust registry different that a blockchain or KERI ledger? Are we assuming some intelligence? Does it have defined operations? If so, what are they? Why do we talk about "interoperability between trust registries"? Will they communicate directly with each other or only via a trust task operating over the trust spanning layer?

[andorsk]

So I'd like to explore a little more the relationship to this and KERI as the idea of trust chaining described below has a lot of overlap with KERI. I was kinda interested in the Service Discovery and trust chaining aspect of this work.

Here's my ideation/brainstorming about how this can work in practice. This is super rough below, and I preface this with there might be some inconsistencies, it's definitely not perfect, but I think it follows with @trbouma's primiative model in the deliverable section a little and hopefully allows the group to leverage this for further discussion. Entirely possible I'm missing something in this that's super obvious.

For clarity, I'm going to ignore adding non-critical fields that are important for technical completion with the final goal.

Scenario:
Example University is an accredited university according to the Example Standards Body governance framework. Example University issues a credential to Bob. Alice, the verifier, is hiring bob for a job, and wants to know if Bob's credential is valid for the context of the position.

Keys and Actors

• 2 Issuers:
  • did:key:standard <- the standards body
  • did:key:exampleuniversity <- the issuer
  • did:key:bob <- bob's did
  • did:key:alice <- alice's did

Flow

1. Example University is accredited
2. Example University issuers to Bob
3. Alice asks bob for claims
4. Bob presents Alice with credential
5. Alice verifies claims are valid. As a requirement, she follows the trust chain all the way to the standards body. Alice trusts the standards body, so she trusts Example University.

Example Credential

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/1872",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "did:key:exampleuniversity",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:key:bob",
    "alumniOf": {
      "id": "did:key:exampleuniversity",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": {
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

Questions

• Is the issuer who he says he is?
• Is the issuer capable of making this claim?
• Is this claim valid for this intended context?

Proposal

did's have attached service definitions to be compliant with the task force here. They become verifiable trust sources, b/c they allow trust chaining.

It would look something like: <did>?service="attestation"&relativeRef=<fragment>&context=<context>. The intent here is you should query a DID for attestations about why you should trust it relative to a claim. The did can respond back with proofs that they are trustworthy, often linking to new dids, which allows you to trust chain.

Technical Flow

1. Alice queries did:key:issuer1?service=attestation&relativeRef=/credentials#degree&context="validation"
2. Receives:

{
     "contextProof": [
       Credential Proof that "did:key:standardsbody" has accredited you 
     ],
     "valid": <bool>, <- says this was a valid issuance
   }

3. Now, if Alice wants to follow the chain she can. She then can query the following with an additional assertor field. This verifies that the Example Standards Body. Why trust the Standards Body? Well, you can query them, for trust assertions, providing them the ability to "prove" they are trust worthy.

did:key:issuer1?service=attestation&relativeRef=/credentials#degree&context="validation"&assertor=did:key:exampleuniversity

and gets the response:

{ 
     contextProof: [
          "reason's why you should trust Example Standards Body,
     ],
     "valid": <bool>, <- assertor was capable of making this claim under this context
}

Now Alice knows that the question: Is the issuer capable of making this claim within this context is Yes. Because the Standards Body she does trust has advocated for it. She believes the Standards Body, because the trust chain, and a believe in the root of trust. What ends up happening is trust bubbles up, and you might have a few root trusts, which give you better assurances. It's completely decentralized, and it's up to you who you want to put as your root trust.

Advantages

There are a few core advantages with this approach:

1. It's fully decentralized, and mostly just modifying the existing data models rather than adding new ones.
2. It's can work offline
3. It allows for trust chaining.
4. It solves the service discovery question and the api question.

Disadvantages

1. In this example, there needs to be a clean way for a trust authority to handle the question: "is this person able to make this claim under this context". I think special considerations need to be considered for how to make sure you can query the body without them knowing you are querying them (i.e anonymous verification ).

What this would mean for the scope of TRTF
With this, I see the work we do impacting a few things:

1. What's the model for the "proof of trust". I.e that json I sent back saying "you should trust me relative to this claim"
2. What's the way to interact with the did for trust attestations.
3. How does the verifier appropriate provide context for the "context proofs"

Those 3 things in a nutshell are where the focus would be.

[andorsk]

Relevant to link here: #61 (reply in thread)

[jacqueslatour]

There's a national academia trust registry for universities
Bob's university is part of national academia trust registry
Alice trust the national academia trust registry
Alice can trust Bob's credential are valid

[darrellodonnell]

A trust registry provides answers to entities and is a technical implementation of the EGF. As an example - the EGF may describe who are authoritative Issuers (e.g. that P.Eng. I mention above). The data they hit are likely in a database but could be (rare now, perhaps growing) in a ledger. The point is that data on chain may not be reliable (the data may be cryptographically verifiable but how do you know that the entity that wrote something is authoritative).

"Interoperability between trust registries" - not a phrase I use. As an implementor, I want to speak to many trust registries that provide answers. Imagine the state and provincial professional engineer bodies - each has their own system for managing their licensees (database backend likely). My system may just want to know "is Scott licensed as a professional engineer in ______?" I can call any number of trust registries that I know of and ask that question consistently.

I see "interoperability" as applying to the users of the trust registries, not the trust registries themselves.

[talltree]

I see "interoperability" applying to trust registries as very simple: do they support the same Trust Registry Protocol or not? It's like DNS servers: they interoperate because they all speak the DNS protocol to resolvers.

[sawhitmire]

On the call today, we talked about one ecosystem trusting the members of another, like reciprocal recognition of a PE license between states. Each ecosystem's governance framework defines who qualifies to be an issuer of one or more of the VCs or verifiable messages defined for the ecosystem. Could it be as simple as including another ecosystem's registry by reference? We would need to identify an entry type that would point to another registry which basically says: "All of the issuers in our registry are authorized to issue one or more of our VCs, and oh, by the way, we also recognize all of the issuers and their permissions in this other registry." It provides the verify operation another path to follow to build the trust chain for a decision. Is this on the right track?

[darrellodonnell]

Yes. Further, you may refer to some ecosystem that is adjacent (i.e. not directly in your ecosystem/world). Educational credentials may link various national and subnational trust registries for educational institutions directly, but point to adjacent government identity credentials for identifying the individuals to whom educational credentials are issued.

[neiljthomson]

Looking at trust (specifically trust of data, (verifiable data registry) aspects there are several "vectors" of trust that are relevant.

While the data trust "model" is generic to data including data collected by hand, all types of data, including data about SSI entities and whether they can be trusted is a variation of how do you trust any data

• Data Chain - from raw data collection to published data - traceability to each data set from raw to published data signed by (governance) the data processor and data verifier (responsible humans)
• Data processing chain (what processing steps (linear/parallel) were applied from raw data to published data
• Signing officer (authority) chain (signatures of process owner & process verifier) - and who certified them and so on
• Governance process chain (company process -> regulations -> legislation....)

There is also a trust "stack" where information about entities is build from a base of (do I trust this DID, its key management) to (do I trust this entity to do specialize task X)

I've not worked through the details, but I suspect there are different trust registries that align with each of the Layers in the Tech stack.

For example, what level of trust is required before I will trust the other end point fo a Trust Spanning Protocol interaction?

[a-fox]

Based on discussions in the task force meetings, we chairs came together to see if we can start to bring things together. We identified that within our discussions, we're actually handling two very different topics.
We're discussing about the Trust Registry and Trust Task interchangeably. And this currently causes some confusion and inability to root decision making. I will open both terms below.

Trust Registry
Trust Registry is what it implies. It's a registry (any form) with an API to make queries against. I believe this is what mostly @darrellodonnell @sawhitmire etc are mainly talking about. This is about extending the capabilities of the specification of the Trust Registry v1 spec, so it's fairly straightforward.

Trust Task
Secondly we are talking about Trust task as a process to receive inputs for a trust decision (which in itself is outside of scope). This answers to a wider question about the ability to request ANY kind of inputs to accept or continue with the processing of a trust task. Inputs sources may also come from anywhere, including Trust Registries, other entities, etc. This is what @andorsk @a-fox et al are proposing. In this we talk about contexts, Trust Decisions, Trust Models, etc.

In the 2023-02-09 TF meeting we will be discsussing both of these. For the context of discussion, I'm posting here a simple model on the Trust Task. It portrays similar things to what @trbouma presented above, but from a ToIP terminology POV.

[a-fox]

@neiljthomson excellent questions, these came to my mind as well during thursday's session. I will answer few of them, to which I have an opinion or a clear understanding.

There is considerable debate on what happens in Layer 2 vs. 3 and the potential stacks of "thin layers" (as per Sam Smiths' TSL presentation this week).
Is Layer two about building Relationships?
What does that mean?
This is an ongoing discussion as to what Layer 2 is in its full form. So I don't have a definitive answer. It will clarify during next few weeks.

My opinion is that L2 is about strong key binding, connections and message routing. All of these are all separate thin layers within L2. L3 should not need to know anything about the transport mechanism or the channel that the connection is made through. Or even in some cases, how many parties are in an N-wise connection. As long as a Trust Task in L3 has a DID or other similar connection identifier, it should be able to execute its 'task' by giving L2 the message & target DID.

I submit that I can see many trust "checkpoints" for any type of interaction across Layer 2 (Trust Spanning Layer) and Layer 3. What trust checkpoints happen in what layer and at what point in an interaction?
Yes! Absolutely, this is what I see as well! L2 will likely have some key- & connection related checks, whereas L3 will have its own stack of checkpoints.

Your thoughts on the checkpoints and appropriate trust questions are really good. I think it could help us clarify things a bit more, if we formulate the correct trust questions and map where they should be answered.

[JoOnGT]

I like your use of the layer colour coding @a-fox - If we use Sam's definition of endpoints of the TSP, the "other wallet" would be a combination of application-task-endpoint (and local routing there too) on the left hand side of the diagram.

That's the same for a Trust Registry application too, if it is deemed to be a ToIP aligned application. If the external endpoint isn't inside the ToIP concept boundary, it's an external system and the TSP isn't used... just other interaction protocols (without end-to-end trust).

The one thing I'd suggest is to change the "Transaction" terminology to the "Application" or "Trust Application" at layer 4.

[guru-barbes]

Your thoughts on the checkpoints and appropriate trust questions are really good. I think it could help us clarify things a bit more, if we formulate the correct trust questions and map where they should be answered.

FYI - I've created a new discussion thread (#72 (comment)) and googledoc (https://docs.google.com/spreadsheets/d/1tZmAlq__GW_3-fCA6XkIE8qJXg8D4nNhF_ujm_Q4kTk/edit?usp=sharing) in an attempt to collect and collate the trust questions a trust registry should respond to.

Please visit and help improve it, make it useful for us!

[neiljthomson]

Observation - a lot of effort is going into ensuring that components fit into a 4 layer "stack". Why 4? Why a stack?

What are the requirements driving trust decisions? Is a Trust Registry the only tool to do this? Suggest requirements driven components, with layering and partitioning to separate routing from messaging, layers based on distinct variations in functionality. Maybe in the interests of extend-ability there are many micro-layers and related groups and variations of components.

[talltree]

@neiljthomson Our Design Principles for the ToIP Stack goes into great detail about why the ToIP stack is the same four layers as the TCP/IP stack and why it follows the same Hourglass Model as the TCP/IP stack. The latter question is also answered in great detail by Sam Smith's Hourglass Model presentation.

While the TCP/IP stack exists to enable all actors using it to make their own trust decisions, those actual trust decisions are out-of-scope for us. There could be hundreds of factors going into a particular actor's trust decision.

The requirements for each of the four layers in the stack are enumerated in the ToIP Technology Architecture V1.0 Specification. If you think any requirements are missing there, by all means submit issues; it is still in public review.