12. Trust Indexes¶
As described in the Conformity Schema section, the ecosystem authority can define different assessment scheme, but those:
- Don’t automatically adapt to the market which always evolves faster than the rules.
- Don’t capture the subtleties of organisational and semantic interoperability complexity, de facto lowering the interoperability to the basic commonly conceded denominators.
To address this challenge, additional scoring tools named Trust Indexes are developed as Veracity
Example
Those indexes enable the ecosystem parties to:
- As a consumer to compare objects or offerings with a more granular ranking that wouldn’t necessarily fit into one of the predefined conformity schemes.
Example
Given 2 compliance scheme, one built on top of the other, a service offering compliant with the first one but not second one will be assessed with a score
- The providers to compare their offering with existing ones and help them to improve their interoperability.
Example
As a provider “is my service interoperable and composable with 10% or 90% of the other offerings in the ecosystem catalogues ?”
The proposed Trust Indexes
Example
A provider that declares its services or products by providing only the bare minimum information without machine readable claims nor policies may still meet the mandatory ecosystem compliance criteria but will have a low interoperability score with other offerings from the ecosystem catalogues and it would be in the provider’s own interest to improve the quality and quantity of the provided information.
The Trust Index
with each sub-index
Sample code included in the source of this page
All the graphs in this page are dynamically computed in Javascript.
If you are looking for an index implementation, look at the source code of this page.
12.1 Sub-Indexes¶
12.1.1 Veracity¶
The Veracity index
Tip
Evolution of the index with
Smaller is
If there is one chain then the value is 1 else more chains there are, higher is the veracity index.
Example
For a given claim, the number of signatures on that claim (root → … → leaf → VC → subject ← VC ← leaf ← … ← root)
If the issuer is the Trust Anchor then the value is 1 else longer the chain is, lower is the veracity index.
Example
For a given claim, the length of the signing key chain (root cert → intermediate cert → … → leaf → VC → subject)
12.1.2 Transparency¶
The goal of the transparency index is to reward parties exposing information.
Transparency vs Compliance
The transparency index is not linked to the notion of compliance. It’s possible to have a high transparency index and not being compliant, because mandatory properties are missing or with a wrong format.
Transparency vs VC type
The transparency index can only be compared across VC of the same type.
The transparency index is based on the number of exposed properties and their cardinality.
values for each VC of the graph .- an overall
value from the previous values, for the VC representing the object of interest.
when , ie the cardinality of the set of property is , ie no property are filled in. when more properties are filled in.
Example
Example of the same offering - an API endpoint returning a fortune from the BSD packet fortune - with an increasing transparency index,
Service Offering
name: Fortune teller
description: API to randomly return a fortune
providedBy: url(provider1)
termsAndConditions:
- https://some.url.for.terms.and.condition.example.com
Provider 1
Service Offering
name: Fortune teller
description: API to randomly return a fortune
providedBy: url(provider1)
aggregationOf:
- url(software1)
termsAndConditions:
- https://some.url.for.terms.and.condition.example.com
Software 1
Service Offering
name: Fortune teller
description: API to randomly return a fortune
providedBy: url(provider1)
aggregationOf:
- url(software1)
- url(dataset1)
- url(datacenter1)
termsAndConditions:
- https://some.url.for.terms.and.condition.example.com
policies:
- type: opa
content: |-
package fortune
allow = true {
input.method = "GET"
}
API 1
name: api software
maintainedBy:
- url(provider1)
tenantOwnedByBy:
- url(provider1)
copyrightOwnedBy:
- url(provider1)
license:
- EPL-2.0
Dataset 1
name: fortune dataset
copyrightOwnedBy:
- name: The Regents of the University of California
registrationNumber: C0008116
headquarterAddress:
state: CA
country: USA
legalAddress:
state: CA
country: USA
license:
- BSD-3
- https://metadata.ftp-master.debian.org/changelogs//main/f/fortune-mod/fortune-mod_1.99.1-7.1_copyright
Participant 2
name: Cloud Service Provider
registrationNumber: FR5910.424761419
headquarterAddress:
country: FR
legalAddress:
country: FR
Datacenter 1
12.1.2.1 For each VC of the graph¶
To meet the objectives of the Transparency Index set in the previous section, each VC with its associated SHACL shapes must be analysed as follow:
- with
the number of available properties for a VC , every property is given a weight .
- each property
is given a value depending of its cardinality and the number of given values
Example
for a VC with 5 properties, each property
For a cardinality with known boundaries n..m
Example with a known maximum
For a cardinality with an unknow upper boundary n..*
Tip
Example with a unknown maximum and evolution of the value with
Example of the same VC type for different level of information
In the example below, we have a VC schema with 6 properties with different cardinality and 7 different VC instances, each with more or less defined values.
property with max cardinalty |
VC 1 | VC 2 | VC 3 | VC 4 | VC 5 | VC 6 | VC 7 |
---|---|---|---|---|---|---|---|
prop1, maxCard = 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 |
prop2, maxCard = 1 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
prop3, maxCard = 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 |
prop4, maxCard = 2 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
prop5, maxCard = * | 0 | 0 | 0 | 1 | 2 | 1 | 2 |
prop6, maxCard = * | 0 | 1 | 1 | 1 | 1 | 1 | 6 |
0.083 | 0.267 | 0.433 | 0.450 | 0.465 | 0.617 | 0.693 |
12.1.2.2 For the node of interest¶
Once all the
If there are several VC at the same distance from
Info
The above formula was built to normalise the index
Tip
Evolution of the value with
When
When
Example
For the graph below, various transparency indexes
Example 1 | Example 2 | Example 3 | Example 4 | Example 5 | |
---|---|---|---|---|---|
Service Offering (d = 1) | Tn=0.2 | Tn=0.2 | Tn=0.5 | Tn=0.5 | Tn=0.5 |
Resource 1 (d = 2) | Tn=0 | Tn=0.1 | Tn=0.1 | Tn=0.9 | Tn=0.9 |
Resource 2 (d = 2) | Tn=0 | Tn=0.1 | Tn=0.1 | Tn=0.8 | Tn=0.8 |
Resource 3 (d = 3) | Tn=0 | Tn=0.3 | Tn=0.3 | Tn=0.3 | Tn=0.3 |
Resource 4 (d = 3) | Tn=0 | Tn=0.9 | Tn=0.9 | Tn=0.1 | Tn=0.9 |
0.100 | 0.200 | 0.350 | 0.488 | 0.537 |
12.1.3 Composability¶
The Composability index
- the capacity of those services to be technically composed together, e.g.: software stack, compute, network and storage characteristics, plugin and extension configurations, …
This index is computed, for example, by instances of the Federated Catalogues, by analysing and comparing the characteristics of several service descriptions.
This index can be decomposed for each service description into several sub-functions:
- the level of detail of the Software Bill of Material
- the list of known vulnerabilities such as the ones listed on the National Vulnerability Database.
- Intellectual Property rights via the analysis of the licenses and copyrights.
- the level of stickiness or adherence to specific known closed services
- the level of readiness for lift-and-shift migration.
Check Fundamental/Linked Data for an example.
12.1.4 Semantic Match¶
The Semantic Match index
- the use of recommended vocabularies (Data Privacy Vocabulary, ODRL, …)
- the unsupervised classification of objects based on their properties
- Natural Language Processing and Large Language Model analysis from and to Domain Specific Language (DSL)
- Structured metadata information embedded in unstructured data containers (PDF/A-3a, …)