Overlaying the Trust Registry Considerations onto the ToIP Stack

[jospencer-460]

We all know and love the ToIP Stack approach to discussing trust architectures, from both technical and governance (not forgetting operational) viewpoints. One of the pictures in the technical specification had a particularly interesting discussion... this one...

You'll note that the Verifiable Data Registries is identified as outside the stack. Whilst I understand the reasons for this, the way it's depicted for me is that it implies that the stack definition doesn't apply to Trust Registries [or whatever we call them]. I saw something some time ago doing the same when considering "payment" solutions [which would be better called value exchange or commercial framework] which did something similar.

So I've always wanted to "overlay" the (technical and governance/ops related) considerations and capabilities required for Trust Registry functionality on top of the ToIP stack diagram. That's what I've done in this picture...

Let me work through some of the thinking ...

Layer 4 - Trust Applications

• there are two different types of applications that access/use Trust Registries; consumers and governors
• the consumers of trust registries are trust protocol endpoint systems that need to use the functionality provided by TRs for their own purposes (verify an issuer, understand what credentials are used in a use case, interpret credential definitions and versions, route to a specific endpoint system, etc.)
• the governors are those systems controlled by the governing bodies and responsible for maintaining the TRs
• the picture shown two consumers (Endpoint Trust Applications) and one governor (Trust Registry Owner Application)

Layer 3 - Trust Tasks

• the trust tasks relevant to TRs are those that consume then and those that manage / update them
• the consuming trust tasks (Protocol or Co-Protocol terminologies have been used, but these are importantly involved in communication with the TR and not just stand-alone) are the usual verify issuer, verify verifier for participants
• other consuming trust tasks include
  • those that define formal (governed) use cases
  • the mapping of use cases to those VCs (and versions) in supported presentation types
  • provision of governance information (Ts and Cs etc.)
  • mapping of data types inside this governed ecosystem and the alignment with those outside
  • the equivalence of processing rules and service equivalence at each endpoint - to the discussion last week, a PEng in Ontario may not be equivalent to a PEnd in BC, what's the difference and how does the verifier know these differences are governed and trusted?
  • access to other governed data by the participants in the ecosystem etc.

Layer 2 - Trust Spanning Protocol

• there's nothing specific to TRs in the TSP, except that one end of the protocol should be with the TR or their intermediary / supporting system

Layer 1 - Supporting Services

• These are the TR specific services that support the TSP and other Trust Tasks
• Examples of these are
  • Service endpoint definitions that define the access the participant registries
  • Revocation service access - a cryptographic accumulator could be deemed to be a TR [controversial??]
  • System routing services - again, if this is a curated list of mappings it could be a TR [even more controversial??]
  • Use case definition services - this could be essential for wallet logic in understanding whether the verifier is allowed to ask for what and from which credentials
  • and lots of other services that support access to curated data sources.

I've not segregated the tech and governance thinking as (at this level) it is inter-woven.

SO, to reiterate the intention here:

• I don't think we need a different box for TRs or VDRs outside the ToIP stack
• We just need to "overlay" the capabilities and segregation of duties on top of the stack [do you remember overhead projectors and how we used to lay two pictures on top to demonstrate the alignment to models?]
• We can apply the same thinking to other considerations and componentry - e.g. commercial models and value exchange

If we agree with the proposition, this means we should change the tech architecture picture as this is confusing.

I'm interested in what you think.

[andorsk]

@jospencer-460 This is fantastic. Nice work putting this together. I also agree that VDR's and TR's should be outside the stack. Either the stack is flawed, or they should be compatible with the rest of the stack architecture. Once you start pushing things outside the stack but saying they are compliant, it's a slippery slope.

[andorsk]

Sorry, typo : I meant "should not"

[jospencer-460]

Thanks @andorsk - I was starting to worry I'd articulated this badly before your correction.

[andorsk]

I'm just glad I caught that typo! It was saying the exact opposite of what I was trying to convey!

[darrellodonnell]

I'll remind folks that the TRs were never "outside the stack" they were (potentially) used at each layer.

…

On Thu, Mar 23, 2023 at 4:13 PM Andor Kesselman ***@***.***> wrote: @jospencer-460 <https://github.com/jospencer-460> This is fantastic. Nice work putting this together. I also agree that VDR's and TR's should be outside the stack. Either the stack is flawed, or they should be compatible with the rest of the stack architecture. Once you start pushing things outside the stack but saying they are compliant, it's a slippery slope. — Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWB5NHSWL6N4OCBEGEADW5TKIVANCNFSM6AAAAAAWEUMA3A> . You are receiving this because you are subscribed to this thread.Message ID: <trustoverip/tswg-trust-registry-tf/repo-discussions/91/comments/5412008@ github.com>

[andorsk]

@darrellodonnell more the reason @jospencer-460's overlay makes a lot of sense. Maybe VDR's shouldn't be explicitly described on the architecture diagram?

It seems like, abstracting this away, they are an implementation that can be overlayed on top of the architecture diagram, but out of scope for of the actual architecture diagram itself. I don't know the historical context for why VDR's were added to the initial diagrams, but it always seemed slightly strange to me.

@jospencer-460's dissection makes a lot of sense IMO.

And yes, you are right: I know VDR's were never intended to be "outside the stack" but the diagram is not helpful it making that clear IMO.

[jospencer-460]

That's exactly my thoughts too.

[darrellodonnell]

I've never liked the term Verifiable Data Registry. Drummond knows the back story about why it came to be.

…

On Thu, Mar 23, 2023 at 4:44 PM Andor Kesselman ***@***.***> wrote: @darrellodonnell <https://github.com/darrellodonnell> more the reason @jospencer-460 <https://github.com/jospencer-460>'s overlay makes a lot of sense. Maybe VDR's just shouldn't explicitly part of the architecture diagram? They are an implementation, that can be overlayed on top of the architecture diagram, but not part of the actual architecture diagram itself. I don't know the historical context for why VDR's were added to the initial diagrams, but it always seemed slightly strange to me. — Reply to this email directly, view it on GitHub <#91 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFHWB6NSPZSLR23X4E7NA3W5TN5DANCNFSM6AAAAAAWEUMA3A> . You are receiving this because you were mentioned.Message ID: <trustoverip/tswg-trust-registry-tf/repo-discussions/91/comments/5412125@ github.com>

[jospencer-460]

I don't mind if we call them fluffy-bunnies, as long as we understand what they are, what they provide, how they behave, how they're governed and how they fit with the other componentry.

[jospencer-460]

Thanks to the group for excellent discussion during the TRTF (APAC) on 23-4/3/23. The take aways for me are:

• There's large acceptance that the VDR/TR related features are expected to be provided under the layer structure of the ToIP Stack
• There is still some requirement to show the separation of governance related features and consumption features (Judith's preference for Neil's diagram)
• The "co-protocol" term is old-school and we should probably just use tasks (at layer 3) and services (at layer 1).

Let me know if you have any other comments/suggestions. I note that the meeting page hasn't been updated yet.

[andorsk]

Thanks for the callout. Meetings update was published. Sorry about that.

[jospencer-460]

I've updated the initial picture to the following...

Note, I've also included credential services at the layer 1, but this could also be at layer 3.