[MINUTES] CCG Atlantic 2026-08-11

This meeting focused on the concept of Portable Trust Infrastructure (PTI),
presented by Alison Mukoma from TumiTrust. The core idea is to build a
layer above existing verifiable credentials and DIDs that allows for the
composition and contextualization of verified evidence into actionable,
governed, and privacy-preserving trust outputs. TumiTrust shared their
production learnings and a reference implementation called TumiTrust,
highlighting that verification alone does not equate to trust and that
real-world trust decisions are often multi-source and context-dependent.
The discussion explored architectural questions around making trusted
signals reusable across independent domains without losing context,
explainability, or privacy, and sought community input on key elements like
dynamic trust states, deterministic trust composition, and
privacy-preserving trust computation.

Here's a breakdown of the topics covered:

   - *Portable Trust Infrastructure (PTI) Overview:* Alison Mukoma
   introduced PTI as a layer between verified evidence and contextual trust
   decisions, focused on composing verified signals into actionable outputs.
   - *The Need for PTI:* The presentation highlighted that existing
   identity and credential primitives are mature, but a gap exists in
   translating verified evidence into context-specific trust decisions that
   different relying parties can use.
   - *TumiTrust's Production Experience:* TumiTrust shared learnings from
   implementing PTI in production, emphasizing that verifiability does not
   equal acceptance and that trust decisions are often multi-source and
   require privacy-preserving computation.
   - *Key PTI Elements and Questions:* The discussion identified areas for
   community collaboration, including managing dynamic trust states, composing
   and translating trust deterministically across domains, and making trust
   computation interoperable and privacy-preserving.
   - *Relying Party Implementation:* The meeting addressed the question of
   why relying parties can't implement these trust systems themselves,
   suggesting that interoperable infrastructure for trust composition and
   computation could be more efficient.
   - *Trust Computation Definition:* Trust computation was clarified as the
   process of contextualizing verified signals within a specific domain (e.g.,
   lending, agriculture) to produce meaningful outputs for decision-making,
   which can involve inferencing, rules, and governance.
   - *Trust Events and Contexts:* A trust object comprises a context ID
   (e.g., lending, remittance) and provenance data (e.g., on-time repayment,
   loan default) that describes what happened and how it affects trust in that
   context.
   - *Explainability and Trust Graphs:* Trust is represented in a weighted
   graph, allowing users to drill down into the contributing factors and
   events that led to a particular trust score, with explanaibility being a
   key feature.
   - *Managing Context Differentiation:* The challenge of managing
   differentiation in trust aggregation graphs for subsets within broader
   categories was discussed, with an acknowledgement that this is an area for
   potential community collaboration.
   - *Subject Interaction and Privacy:* Subjects interact with the system
   via companion mobile applications or web dashboards, managing their consent
   and privacy, with options to suspend or delete their accounts. TumiTrust
   does not handle KYC-level data.
   - *Deployment Topology:* The current reference implementation is
   centralized on TumiTrust's servers, but the long-term vision is for a
   decentralized and reusable infrastructure, with an RFC being developed to
   define this.
   - *Community Input and RFC:* The RFC for PTI specification is available
   on GitHub, and TumiTrust is seeking community input for refining the
   specification, particularly on managing state, interoperable computation,
   and reviewing existing governance areas.

*Action Items:*

   - Alison Mukoma to share the presentation slides via email.
   - Alison Mukoma to share the link to the PTI specification RFC on GitHub
   in the chat.
   - Harrison Tang to potentially share experiences with SHAP values for
   model explainability with Alison Mukoma.
   - Community members to review the PTI specification and RFC and provide
   feedback and suggestions for collaboration and potential merging with
   existing efforts.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-atlantic-2026-08-11.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-atlantic-2026-08-11.mp4
*CCG Atlantic - 2026/08/11 12:07 EDT - Transcript* *Attendees*

Alex Higuera, Alison Mukoma, Benjamin Young, Brent Zundel, Elaine Wooton,
Erica Connell, Harrison Tang, Jennie Meier, Mahmoud Alkhraishi, Phillip
Long, Ted Thibodeau Jr
*Transcript*

Mahmoud Alkhraishi: Hello Apologies for a delay. we're gonna bypass the
normal intros we do this week. Instead we're going to do it a little bit
quicker. Thank you all for joining us today. It is Tuesday, August 11th. so
without further ado, Alison is here to talk to us. Austin, would you mind
giving a quick intro about yourself and walking us through it? Yes.

Alison Mukoma: Hi. Was that me you mentioned? thanks. Thanks a lot. my name
is Alison MCM and I'm coming from Tumitas. Student trust is a reference
implementation of what we call portable trust infrastructure and I'm here
to discuss with the community or in portable trust infrastructure and where
the direction we believe it's likely to take. Yeah. Thank you very much.

Mahmoud Alkhraishi: Excellent. Thank Allison, are you going to be
presenting today?

Alison Mukoma: Yes, I will.

Alison Mukoma: I don't know if this was just a bare minimum intro or I have
a go ahead to present already.

Mahmoud Alkhraishi: You have the Thank you.

Alison Mukoma: Okay. Okay. let me share my screen. Hopefully Google Meet
doesn't disappoint me today. All right. C can you see my screen?

Mahmoud Alkhraishi: Yes.

Alison Mukoma: Okay, I'll avoid to just play in slide mode because it then
acts up and just stops working for me. So I have about six slides. I hope
you can allow me to go through them quickly. so what exactly is portable
trust infrastructure or rather PTI?

Alison Mukoma: PTI is our exploration of the layer between verified
evidence.

Mahmoud Alkhraishi: Alison. Sorry to jump in. I don't know if you're maybe
sharing the wrong screen or if you want to maybe full screen the slides.
Don't make it easy.

Alison Mukoma: Okay. Okay. can you see the trust primitives become portable?

Mahmoud Alkhraishi: Your presenter view, not the other. Yeah. …

Alison Mukoma: So, this is using the correct screen. Yeah. okay.

Mahmoud Alkhraishi: no. We're saying your presenter's view, not the slides
view. Stop.

Alison Mukoma: Let's share again entire screen.

Alison Mukoma: Are you seeing my slide? Trust primitives are becoming
portable.

Mahmoud Alkhraishi: That's perfect. That's perfect.

Alison Mukoma: Okay, thanks. Thank Yeah. what exactly is portable trust
infrastructure? PTI is our exploration of the layer between verified
evidence and contextual trust decisions. composing of verified signals into
actionable and governed and privacy preserving trust outputs. Yeah. So
that's in a nutshell what we think PTI is and how we can explain it in the
minimalist.

Alison Mukoma: So for the context if you allow me let me start with what I
think we already agree on. A lot of the foundational work needed for
portable identity and credentials is already mature. we already have
selective disclosure zero knowledge approaches and increasingly more
protocols. so this presentation is not proposing another identity or
credential standard. our observation comes from building on these existing
primitives in production. so such that once a credential is verified we
then have realized that there's another problem that needs solving.

Alison Mukoma: So our observation is that verification tells me that a
credential is authentic valid and comes from an issuer that I can verify
but it doesn't necessarily tell me what evidence means for my particular
decision that I'm making. for example, a lender, a government agency, an
employer or a merchant can all receive the same verified evidence, but they
evaluate it very differently across their domains. and so this brings us to
the architectural question that we want to share with the community. how
then do we make trusted signals reusable?
00:05:00

Alison Mukoma: across independent trust domains without losing their
context, explanability and privacy or rather governance. this is where we
have been exploring the idea of portable trust infrastructure. and so we
see portable trust infrastructure as a complementaryary orchestration and
computational layer that is above the existing cryptographic primitives
that are already mature and already exist. Yeah. So the primitives already
establish identity and evidence.

Alison Mukoma: On top of that, PTI then asks how do we compose that
evidence, apply the rules of a particular context, for example, lending,
and then produce a usable trust output that makes sense in that context.
Yeah. and it's also worth noting that multiple credentials from multiple
issuers may contribute to one decision in a particular context. Yeah. So
PTI is not replacing proposing to replace VCs DIDs or exchange protocols.
It is exploring what happens when those verified signals need to become
actionable across different domains.

Alison Mukoma: So these observations aren't purely theoretical for us at
tumit trust they come from tumit trust across the real institutional
workflows as a reference implementation of PTI and so firstly verification
verifiability rather does not automatically equal to acceptance
institutions still need context and governance alignment. secondly, when
evidence crosses domains from one domain to another, its original meaning
and constraints can easily be lost along the way. And thirdly, real trust
decisions are usually multissource, meaning the evidence can come from
different sources.

Alison Mukoma: And so you rarely make decisions from one particular
credential source and with those or such inputs it's worth noting that
inputs like that can be sensitive and so the computation itself needs to
become privacy preserving along the way. this leads us to the fact that we
are not presenting this PTI as a finished standard because we believe there
are areas where we think further community work would be extremely valuable
work and collaboration and further learnings from our side also.

Alison Mukoma: There are a couple of key elements that are worth noting
such as the state. How should dynamic trust states be presented alongside
static credentials? Yeah. That have been issued. secondly, how should trust
itself be composed and translated deterministically across different
domains. And thirdly, can trust computation itself become interoperable
deterministic and verifiably in a privacy preserving way.

Alison Mukoma: Those are some of the questions that we believe we could
collaborate to strengthen this or to see where the signage gaps would be
overlapping with what already exists or the existing efforts that are
ongoing. so our goal here is not to convince the community that trust has
solved these questions. No, that is far from it. It is rather to bring
implementation experience into the conversation and ask whether there is an
architectural gap worth exploring together. So one assumption you might ask
why can't the relying parties just do this themselves implement these trust
systems and portable systems that can then trust compute it and port it to
other across domains. Yes, they do.
00:10:00

Alison Mukoma: and actually many do they can and many already do. the
question is whether every relying party should independently rebuild the
same trust composition explanability and computational logic or whether
some of that or some of that layer can become interoperable infrastructure.
Yeah, thank you so much and I submit.

Mahmoud Alkhraishi: Thank do we have any questions from anybody in the
audience before I ask a couple of mine?

Mahmoud Alkhraishi: So, Alison on my end, I had a question for you on the
production readiness of what you're talking about.

Alison Mukoma: Yeah, Yeah.

Mahmoud Alkhraishi: You mentioned that you had a lot of learnings from
going to production. What's the current state of your work today? Where are
you? And is this something that you're sharing as a broad spec? what
exactly are you looking

Alison Mukoma: So the production state the specification itself is still in
alignment meaning we are contributing our production learnings further to
refine it but the production reference implementation we are calling tumit
trust is a product built off PTI.

Alison Mukoma: The maturity of that product is not extremely mature but
it's worth mentioning that we're running decent pilots with shopline for
their merchants. We are computing trust scores for over 600,000 merchants
in real time. And it's also worth mentioning that we are running pilots
with some financial institutions and lenders in southern Africa and the
outcome is the benefits are tangible and visible and our learnings keep
coming through and we revise the specification and contribute what we are
learning further. Yeah, that's how mature the reference implementation it's
a couple of months old in production. So we've been running pilots that are
concluding into production readiness.

Alison Mukoma: Yeah. Yeah.

Mahmoud Alkhraishi: Awesome.

Harrison Tang: By the way I really like your line that verification is not
trust. I totally agree with that. Now I just have a question in regards to
when you say trust computations. Can you kind of clarify what you mean by
that?

Alison Mukoma: So trust computation is that verification and bids are
already implemented by institutions. So when that is done those are signals
or events that are stored. So then that's what we consume or rather is
produced into our trust fabric our central space then we make sense of this
where it's coming from the domain or the life context where it applies or
increases the value and then all those computations then we make them
sensible and reasonable in a way that then we emit the signals we produce
the

Alison Mukoma: signals that can then make sense when regular layman people
look at them for their decisions further. Yeah. So the trust computation is
what we do when the events come into the fabric before they leave as
signals for decision making. Yeah. What happens in the Middle East?

Harrison Tang: So is it basically signals that fed to a model for example
in fraud mitigations you would actually use fraud as labels and…

Harrison Tang: then you train a model use a bunch of signals. It's like is
that what you mean? is about building models and inferencing and running
those models or is it something else? Yeah.

Alison Mukoma: Partly yes.

Alison Mukoma: Partly we do use some inferencing partly but the most part
of it is contextualizing. For instance, a borrower has repaid part of their
loan on time. That's an evidence that's an event that can be recorded can
improve the score in the context of lending for that particular subject.
And when emitting that as an output signal, it then makes sense and is
visible to the decision maker of how consistent and how reliable they are
in repayment.

Alison Mukoma: based on the different events happening from different
producers. Yeah. So we partly do model inferencing but also there's rules
and governance that are applied computationally based on particular context
or domain within the trust fabric.
00:15:00

Mahmoud Alkhraishi: Question for you on trust events and trust context.

Alison Mukoma: Yeah. Correct.

Mahmoud Alkhraishi: Trust events I assume are the events that based on
which something is issued So right what exactly does a trust context look
like? Is this a JSON object? where does it live? What does it do?

Alison Mukoma: Right. So a trust object consolidates I mean is composed of
firstly and foremost a context ID.

Alison Mukoma: A context ID tells you whether that applies makes a
difference to trust in lending or in agriculture or remittance. So it must
have a context ID. we have started with about 20 different contexts so far.
So it must have a context ID where the event belongs and it also must have
some provenence to it What happened? Was it a repayment on time? was it
that the loan was completed on time? Was it that there was a default?

Alison Mukoma: which then affects that particular trust in that context
negatively or positively based on how the events are configured. So a trust
event at most consists of the context it belongs to and then metadata that
explains what particularly happened and how it affects the subject in that
particular area.

Mahmoud Alkhraishi: Hello.

Phillip Long: Does that imply that the level of trust that you're deriving
from this is represented in a weighted graph of some sort that results in a
single measure or…

Phillip Long: that people can then dig down into the dimensions of that
graph to see what things are contributing more.

Alison Mukoma: Correct.

Alison Mukoma: Explanability or provenency we are calling So initially yes
the trust object is a JSON object an API portable object. yes it consists
of a graph. So explanability you might want to drill down as to what built
up to this to a certain score, what contributed the events, when they
happened, where are they sourced from Was it contributed from a partner?
Was it contributed from community signals? And what score each signal each
event contributed towards that buildup? So we do have a graph mapping of
these sources and the events where they come from and at which point they
affected the current buildup. Yeah.

Alison Mukoma: And at any point in time, you're also able to go back in
time to evaluate or drill down into this particular trust score to
understand the provenence and explanability of how it got there.

Phillip Long: Yeah, just a quick followup that suggests then that for the
category that you described, you're come up with 20 different categories of
these domains contexts that there might be a score for the category, but
any given and sub me individual member or subgroups within that that
category might in fact end up with a different primary aggregation graph of
the things that are valuable to that subset.

Phillip Long: I'm curious is how you're managing that sort of
differentiation.

Alison Mukoma: Yes. that's actually one thing I really appreciate that
detailed insight…

Alison Mukoma: because that's one of the challenges we've had to go through
and we believe I think some collaboration with the community we could get
some experienced insight on how we could handle things like that. how do we
define a particular event? For instance, in lending, how do we measure or
dictate the effect that repayment on time by a borrower affects the score?
How do we define the effect in numbers? how defaulting to loan repayment
affects the score. So, those are some of the things as of now.
00:20:00

Alison Mukoma: We have a baseline primary formula and computation that
defines the score aggregates for each of those primary contexts that we
have defined. they're defined by us. but then the source of events is
pretty much just giving us a definition of the types of events and what
they'll be doing towards that score. But the actual definition of how it
affects the score. which then translates to every subject having a
different score based on the events. and that we compute those is

Alison Mukoma: something that we have statically defined and we hope that
we could reach a set we could get to a certain place a ground that is
acceptable and collaboratively reviewed as acceptable for such a
computational requirement. Yeah.

Mahmoud Alkhraishi: I have a few questions for you. If anybody else would
like to jump in, please feel free to jump start. But one of the questions I
have is how does the subject actually interact? So from…

Mahmoud Alkhraishi: what I can see from the system, it seems like it's
multiple centralized registries. How does the subject actually interact
with those? What manages my authentication model? What prevents other
people from getting my data?

Alison Mukoma: for ma responsible for managing you and…

Alison Mukoma: your privacy. I just want to get the question very
accurately. Is it managing the privacy or…

Alison Mukoma: or managing how your trust is built and how the signals
towards you come into the fabric? kindly clarify please.

Mahmoud Alkhraishi: So as a subject,…

Mahmoud Alkhraishi: what are the ways that I can interact with the system
in general?

Alison Mukoma: Yeah. Correct.

Mahmoud Alkhraishi: And let's say I want to remove myself completely or I
would like to reduct some things.

Alison Mukoma: Correct.

Mahmoud Alkhraishi: Who's responsible? And where is the MA data actually
stored? What's going on there?

Alison Mukoma: Okay, so we have a data retention policy. So to start with
how you interact with the system, we have a companion mobile application
for individuals like myself. we also have a web dashboard which is usable
for institutions and also this is where consent trust lookup is managed.
this is where provenence drill down into what built up a certain
individual's score can be drilled down but there's also a companion mobile
app where because signals we don't only accept formal signals for instance
formal bank activity signals like lender signals we also process community
signals so a community member can vouch for another

Alison Mukoma: with provenence and explanability as to why they're vouching
for them in that particular context. So we also process community signals.
So you can interact with the mobile application. You can also interact with
the lication. For institutions as where we are now they can at most get the
most from the web interface or dashboard or our web platform. when it comes
to privacy, we have data

Alison Mukoma: tention policies. So, you can suspend your account. You can
also request to delete your account, which we get rid of that data within a
30-day retention period should you not be able to log into our platform
within that period or window. for data, we do not handle KYC level data.
so, we might never know your date of birth. You might never know things
that define you as a person. but we do require data that can map to you for
instance a lending institution would require to map you in our
infrastructure. data such as your name such as your PTI ID which is the
portable trust infrastructure ID that is uniquely mapped to an individual
in the infrastructure is what maps helps to map to a particular individual.

Alison Mukoma: So you have data management at hand. You can choose to
delete the data. You can also choose what is shared and when institutions
are looking up for your trust. If for instance a lending institution want
to look up your trust in lending context you choose whether to allow that
or to deny that lookup. Could be in the mobile application, it could be in
the web login. you manage your own consent. whom you allowed to look up
your trust in a particular area whom you do not allow. Yeah. Thank you.
00:25:00

Mahmoud Alkhraishi: I guess a follow up on that then. is the deployment
topology a centralized server on your end or is this something…

Mahmoud Alkhraishi: where it's a network of providers that work together
for the PTI or how would it work exactly? Is it one entity managing
infrastructure so to

Alison Mukoma: Yeah, that's a very good question.

Alison Mukoma: We had to start from somewhere and that somewhere is to
build a That working model right now sits on defined servers by us, our
servers. the long term to this is that with of course community
collaboration and best practices is to have this as central infrastructure
that can be decentralized and reusable by multiple parties. Yeah.

Mahmoud Alkhraishi: And is that built into the specification itself or is
that something that you're going to be adding to the spec later on?

Alison Mukoma: that for now the specification does not cover the broad
domain on defining that what the specification covers to the extent right
now is that any party can implement a reference implementation that does
this kind of work but at the end of the day if we have multiple of those in
parallel it just becomes another replication. So we actually working on an
RFC improvement to define how we could have this eventually as single
infrastructure that is pluggable and reusable by many. Yeah.

Mahmoud Alkhraishi: Excellent. …

Mahmoud Alkhraishi: and I guess final question from my end, where does this
RFC live today and what are you looking for from the community in general?

Alison Mukoma: Yeah. …

Alison Mukoma: the RSC lives on GitHub SL Tunit Trust organization and PTI
minus specification. If I can grab just a link, I could share that right
away. PTI specification throw it in the chat. yeah so it lives on an open
repository. discussions are welcome.

Alison Mukoma: What I'm looking for is pretty much a refining on how we
maintain the state as trust is being computed and you reusable across
different domains because a timely repayment in the lending context for a
borrower subject can improve credibility in the lending context for a
landlord. Yeah. So a on time repayment can signal credibility in renting
for a landlord's needs. So We're also looking at how computation itself for
these trust credibilities across different contexts how it can be
acoperable across different systems.

Alison Mukoma: We're also welcoming a review and critique on the existing
specification and RFC's and a few governance areas that we are looking into
that we have documented in the specification. critic collaboration and
improvement is welcome and suggestions of where we could merge the existing
gaps that have been covered by PTI or that are either way in another way
overlapping with existing efforts such that our eventual objective is to
contribute to the community to the standards where we might overlap with
what their ongoing efforts and work to see if this at all makes sense.
Yeah. Thank you very much.

Mahmoud Alkhraishi: Thank you, Alison. does anybody have any questions or
comments or anything else they'd like to bring up? There's
00:30:00

Harrison Tang: Yeah, I just want to add Allison is that if I listen to it
correctly earlier you asked about explanability and basically trying to
figure out the correlation between the dependent variable and the
independent variable to the dependent variable. I think the classical
methodology is shaped shape value u and it is model agnostic so shape value
kind of functions usually I think it's a standard features for xg boost or…

Harrison Tang: psychic learn libraries but it's actually not model specific
it's not like hey it only works for boosting algorithm

Harrison Tang: or bagging algorithms. No, it's actually model agnostic
because you only look at the outputs and inputs and then treat the models
as a black box. So you can try a shapely values on top of whatever you
built and then you can see basically how does the independent variables how
does the input variables affect the output variables. Yeah.

Alison Mukoma: Right. Right.

Alison Mukoma: Thank you so much Harrison for that. I'm actually our be
looking further to explore that and learn from your experiences if you have
some experiences with that. and probably secure review if we try that out
in that refinement. Thank you so much.

Harrison Tang: Yeah, it is a industry standard. there's probably other
cutting edge ones, but I feel pretty safe to recommend that. Yeah.

Alison Mukoma: Okay, thank you.

Mahmoud Alkhraishi: Thank you Alison again for presenting and…

Mahmoud Alkhraishi: thank you everybody for joining us today. have a great
rest of your week.

Alison Mukoma: Thank you so much Mohammad.

Alison Mukoma: I appreciate the time and thank you for everyone who was
sparing some time to listen to me.

Mahmoud Alkhraishi:

Mahmoud Alkhraishi: Yes, please. Alison,…

Alison Mukoma: Okay.

Mahmoud Alkhraishi: can you please send out an email sharing the slides
afterwards with the Thank you.

Alison Mukoma: Absolutely. Let me do just that.

Mahmoud Alkhraishi: Thank you everyone.

Alison Mukoma: Okay. Bye.
Meeting ended after 00:32:37 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*