Closed JoOnGT closed 4 months ago
I like this game! ;)
I have a different view to offer... here's my approach.
First observation is that the word "graph" in the term "Trust Graph" is a reference to a form of directed graph, consisting of nodes and arcs (or vertices and edges). It is directed in the sense that the links describe a relationship that has direction: for example Party A received goods from Party B.
Note 1. that I am not referring to the graph as a "directed acyclic graph" or DAG. This is deliberate. At some point in time we will want to reflect circular economies and product lifecycles. Hence we may want cycles, whereas a DAG reflects a mathematical requirement of no cycles, hence "acyclic". I'm suggesting that we make neither claim in our definition. Our graphs may contain cycles, or they may not. We don't stipulate a requirement either way.
Note 2. If we include a sequence of claims in an instance of a digital product passport as a VC, we are not producing a graph as such, but a multi-level data structure, a "compound" structure. When the claims provide links to be navigated to other actors and other claims then we form a graph. IF the claims inside the instance of the DPP have links that can be navigated, then we have both a compound structure, and a set of links we can navigate.
A Trust Graph then is created by the sequence of declarations made by the actors in a supply chain as a goods flow between them. The graph evolves as the product(s) pass through the supply chain. The graph of events reflects the history of passage and isn't defined in advance. Some aspects of the graph might be considered "static" in that they reflect accreditation or recognition claimed by participants and awarded to them by other parties.
Requirements for "trust" in this sense are satisfied by being able to find instances of the required verifiable data in the graph, not by defining the "shape" of the graph in advance. There will often (always?) be a requirement for immediate suppliers to meet certain requirements, and ultimately we want the "trust graph" to reflect the holistic passage of goods and products and to be able to satisfy our end goal of transparent supply chains.
Note 3. A quick diversion on the word "trust". I'm not a fan of using the word "trust" in this context. Trust is not an absolute, it is context dependent and in the eye of the beholder. It is "of the moment" and fuzzy. We cannot tell someone to trust something. Trust depends, always. Also there are many different types of relationships that we might want to explore to determine whether we trust what we've been presented with. For each upstream party making claims we might be interested in whether they are accredited to one or more standards, and if so, then who by.
HOWEVER I'm willing to bend my pedantic nature here since I understand that in its use here, we intend the graph to be able to convey what MAY (or may not) be trusted by the beholder.... and besides we've laid down previous works using the term "Trust Graph".
Towards a definition... "Trust Graphs" in the UNTP are a linked set of verifiable data points generated by parties documenting the flow of products and actions taken upon them in a supply chain. Trust Graphs can be navigated, explored and searched by resolving the links between each verifiable data claim made by each party. As such, they document the passage of the product through the supply chain and enable receiving parties to check the claims, and basis of claims, made by upstream parties about the product and about themselves.
We should also be aware of the prior work in the CBT whitepaper and articles such as the one written by @nissimsan, here: https://medium.com/transmute-techtalk/the-united-nations-trust-graph-d65af7b0b678
As well as this, which is already in the documentation...
and this prior presentation: https://unece.org/trade/events/40th-uncefact-forum-designing-digital-trust-graphs-using-un-tools-and-methods
@JohnOnGH then is it correct to say that the Trust Graph is emergent? And the 'shape' (if that is the correct word) cannot be predefined?
@JohnOnGH then is it correct to say that the Trust Graph is emergent? And the 'shape' (if that is the correct word) cannot be predefined?
Hi @mxshea - there is both an emergent and an extant quality, and an explicit and implicit quality.
The emergent quality is with respect to the path taken through a supply chain ("mesh" would be more accurate) by the goods that ultimately create a end-user product. I don't think we can or should try to predict what that path is. Each buyer can explore the past history using the events recorded by previous parties, but they cannot predict the future beyond the sale they make to the next buyer.
There is an extant graph present too. Each party may have one or more accreditations to various standards and regulations and these may be audited by other parties and governed by still others (and governance may have more than one layer and dimension). In addition, parties will often have standing agreements between each other with respect to the flow of goods between them and these agreements will have quantitative and qualitative expectations. This means that there is also a form of graph that could be explored, both in terms of the path that goods might take, and in terms of the inter-party agreements and governance that each party has committed to and makes public.
In the Cross Border Trade paper, a distinction was made between explicit and implicit links (see section 3.3, https://unece.org/sites/default/files/2023-08/WhitePaper_VerifiableCredentials-CrossBorderTrade_September2022.pdf) , where an implicit link example was given where two distinct Verifiable Credential claims reference the same node (the example made clear this is a reference to the same DID). This kind of analysis is one of many powerful uses that these graphs can be put to: identifying bottlenecks and single points of failure (vulnerabilities) in supply chains. However, in UNTP we are balancing the need for transparency and commercial confidentiality, such analysis demands that a party has the right to know the information, and that other parties are willing to share this information. In general, a party would have to be able to sense the many separate paths through which goods flow before they can gain a sense of the larger graph. This is probably the role of border controls or other forms of gatekeeper organisations rather than supply chain participants who only see what is relevant to their commercial transactions.
Given the way we want to use the term, we can see that the "trust graph" is the path followed by goods until the point of checking, which provides the initial graph, and we might choose to explore more about some of the parties on that graph, if we are able.
Yes, the term was coined as we were writing the VC White Paper. A graph of data build through cryptographically verified relationships tracing back to trust anchors. I support a more formal definition - it's essential to policy enforcement.
Each buyer can explore the past history using the events recorded by previous parties, but they cannot predict the future beyond the sale they make to the next buyer.
Can the graph link forward (maybe the wrong word)? So that the seller can see where/how their product is being integrated?
@nissimsan, actually the term has existed for a while. I would guess the cryptographic verifiability is new.
After a quick search it does not appear that any SDO has a published definition of "trust graph". I agree a definition is important, but we also may want to make sure we are not re-defining an existing term. Maybe a verifiable trust graph?
Each buyer can explore the past history using the events recorded by previous parties, but they cannot predict the future beyond the sale they make to the next buyer.
Can the graph link forward (maybe the wrong word)? So that the seller can see where/how their product is being integrated?
If an intermediate party is aware of the agreements downstream, then yes they have visibility of the established paths that goods are expected to pass through. If those agreements include commitments that this will be the only path chosen for goods, then it becomes possible to identify when goods are distributed outside of their agreed path, but only on the point of verification. The UNTP does no contain a signalling capability in the sense of sending messages to prior participants on the event of an action being taken downstream.
In other words, the UNTP does not give real-time visibility to a party of where the goods they have handled are being sent to, but it is possible that participants have agreements in place that define where goods should be sent.
@nissimsan, actually the term has existed for a while. I would guess the cryptographic verifiability is new.
After a quick search it does not appear that any SDO has a published definition of "trust graph". I agree a definition is important, but we also may want to make sure we are not re-defining an existing term. Maybe a verifiable trust graph?
Perhaps one way of increasing clarity is to consider what we are defining as a "UNTP Trust Graph", which is an instance of a Trust Graph that inherits properties from the UNTP. A "Trust Graph" itself being an instance of a "directed graph" that enables insights for trust decisions.
By naming it a "UNTP Trust Graph" we indicate that we are defining a meaning that is relevant in our context, rather than some grand whole of world definition. This will let us be specific and precise, at least within our own space.
Referring to an earlier comment about not much liking the use of the word "Trust" in this context, I would prefer we chose a more accurate term such as "Provenance", this would give us a "Provenance Graph" which is much closer to what the upstream data represents. However "provenance" doesn't do much for the downstream and pre-existing agreements, certifications, and governance structures that might exist outside of the specific goods data trail created by a DPP with its associated events. My preferred term for this structure is "governance graph" (full disclosure, this is what I've been working on/with the ToIP Governance Architecture Task Force).
@nissimsan - I have been re-reading your posts I noticed that you suggest that if a graph reaches a trust "anchor", then the observer can be satisfied that the branch is explored and trust satisfied. My perspective is different.
I think that even a "trust anchor" may have differing degrees of trust from the observer's perspective. If they are known to the observer and/or are recognised as a registered issuer of such claims within the observer's jurisdiction, then yes they might be trusted (or at least compliant). However if they are unknown or not listed in a "trust registry" (another term to define?) that the observer can use under the regulations in which they operate, then they will want to find out more about the "trust anchor". Who says they are an anchor? Under what governance structure, in what jurisdiction?
Ultimately the exploration of a branch of the graph will finish at a sovereign entity, a country's government or an internationally recognised body say. It may also terminate at a "peak" body which can be the case in sectors such as sport (think FIFA, UCI, IOC etc.) It may also terminate at a self-governed entity (or one that refuses to, or cannot, disclose any further details.
Anyhow, in my world, even anchors need verification...
+1 to "UNTP Trust Graph" or "UN Trust Graph".
+1 to "UNTP Trust Graph"
@JohnOnGH I understand your point about a "Provenance" or "Governance" graph, but would be concerned that we are getting 'too specific' and as we want to encourage uptake, the result may be continual discussion on what is the perfect word.
Is this a case of good enough over perfection?
@JohnOnGH, the idea of a Trust Anchor is that at some point you have to decide where to start. Like, I've done my due diligence and now know John well enough to accept your claims.
The second layer is the domain in which I trust you. If my due diligence was about, say, animal welfare I shouldn't blindly trust your claims about carbon emissions. I trust you about something. I refer to this as Policy: a restricted list of entities to issue a specific kind of claims.
The trust graph is build from linked claims each issued by in-policy entities.
Standards for "trust registries" do exist. Seems a little premature for us to go there just yet, let's focus on hashing out use cases and requirements.
@JohnOnGH, the idea of a Trust Anchor is that at some point you have to decide where to start. Like, I've done my due diligence and now know John well enough to accept your claims.
The second layer is the domain in which I trust you. If my due diligence was about, say, animal welfare I shouldn't blindly trust your claims about carbon emissions. I trust you about something. I refer to this as Policy: a restricted list of entities to issue a specific kind of claims.
The trust graph is build from linked claims each issued by in-policy entities.
Standards for "trust registries" do exist. Seems a little premature for us to go there just yet, let's focus on hashing out use cases and requirements.
Hi @nissimsan, I agree with the context / subject dependent qualities, and yes I am aware of the trust registries work being undertaken by organisations like ToIP, DIF and others.
I think we can approach this from a "satisfies" in the eye of the beholder point of view. The party checking the bona-fides (the beholder to use my rather archaic phrase) can decide that they are satisfied by the claims and issuer of those claims, at whatever point in their exploration of a branch that they chose. When they are sufficiently satisfied, or when they have exhausted their exploration of the graph, they can make a decision about whether they trust the claims being made or not. The degree to which they explore, and the confidence that they need in the proof(s) offered is determined by the risk, value and context of the decision they need to make.
I think this probably means we're on the same page, even if we're describing the page somewhat differently. What I am keen to avoid is that the reader sees "trust graph" and thinks of social graph analysis (such as the one described in this Google patent: https://patents.google.com/patent/US9264329B2/en) - or that episode of Black Mirror, or the Social Credit System of China (which doesn't actually exist in the way that many have presented it, see for example this https://www.technologyreview.com/2022/11/22/1063605/china-announced-a-new-social-credit-law-what-does-it-mean/).
Our UNTP "trust graph" is, I hope, none of these.
I've just come across (sorry for being slow on this), the inclusion of terms "trustScore" and "sustainabilityScore" in the DPP section. These trouble me because I don't think that any such score can be calculated algorithmically without reliance on one of two approaches (and neither are attractive):
I'm worried that we're heading down the path of CA's and roots of trust or a Standard & Poor / Moody's credit rating. The UNTP is meant to be a decentralised system (which would make 1 the possible thinking, but I believe this to be flawed).
I'll think about this some more. These definitions if we include them are related to how we define "Trust Graphs" since if we want these to be possible, our definition needs to make them possible.
As I write this comment, these definitions are shown here: https://github.com/uncefact/spec-untp/blob/main/website/docs/specification/DigitalProductPassport.md#productpassport
as follows:
Property | Definition | Type |
---|---|---|
trustScore | An aggregate numeric metric that represents the level of trustworthiness associated with the product. This score is derived based on the credibility and reliability of the issuing bodies that substantiate the claims being made about the product. The calculation rules are defined in the UNTP trust graph specification. | Numeric |
sustainabilityScore | An aggregate numeric metric calculated based on the various sustainability claims vs benchmarks associated with the product. It amalgamates scores assigned to individual sustainability claims, which are validated by various issuing bodies. The score provides a comprehensive view of the product's overall sustainability performance, giving users a quantifiable measure of the product's environmental and social impacts. | Numeric |
Issue 92 has now been raised to propose the removal of the the trustScore and sustainabilityScore https://github.com/uncefact/spec-untp/issues/92
+1 to "UNTP Trust Graph" or "UN Trust Graph".
If we use "UNTP Trust Graph", the expansion is "United Nations Transparency Protocol Trust Graph". While more verbose, this is usefully more precise than "UN Trust Graph" - which could describe a number of scenarios in which the UN has interests.
My proposal is that we define, and use, "UNTP Trust Graph". As such we are defining how a trust graph can be derived by supply chain participants communicating with the UNTP.
This discussion reminds me of the "Design Squiggle" idea:
In summary, I propose we use a narrow and specific definition:
This is consistent with the existing definition in this section: https://github.com/uncefact/spec-untp/blob/fc0bd6ff65b32bd8617cbbb5defffee36f300891/website/docs/design-patterns/index.md#trust-graphs
Note that this definition is significantly different to the "trust graph" defined and explored in works such as this: https://github.com/trustgraph/trustgraph and different to some of the previous discussions for the UN Trust Graphs highlighted above.
A more dramatic change, and one that I would support, would be to not use the "trust graph" phrase at all since it risks confusion. Rather I would use the concept of verifiable "provenance" since that is both more accurate and less likely to confuse.
We had discussed using the term Transparency Graph
in a call, which would outline the components of the supply chain that were made transparent by implementing this specification/publishing the relevant evidence
We had discussed using the term
Transparency Graph
in a call, which would outline the components of the supply chain that were made transparent by implementing this specification/publishing the relevant evidence
That would certainly remove my concern about the use of the term "Trust Graph".
We require a "trust graph" definition. The term is used widely and is very useful.
A supply chain point also needs a definition. A suppy chain activity also needs a definition.
Starter for 10 [for fans of University Challenge]...
A trust graph defines what data content is required at a point in a supply point to achieve a specific outcome at that point. The trust graph defines the list of the required credentials and attributes [claims], issued by a number of issuers and attribute specific values (and potentially associated business logic) required to successfully process / progress each supply chain activity