Skip to content

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 TV, Transparency TT, Composability TC and Semantic-Match TSM indexes.

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 rSO in the range 1.0 to 2.0 excluded, as in rSO[1.0,2.0[

  • 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 TV,TT,TC,TSM are meant to be used by all parties - licensor, licensee, producer, provider, consumer, - as a measure of distance for interoperability and trust with regards to the other offerings in the ecosystem catalogues. The intent being that the ecosystem helps the market by providing measurement tools and let the market actors themselves to converge to an optimum solution, similar to gradient descent algorithms where an error metric is given and a process iteratively applied converge to an optimum solution.

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 T is a function of several sub-indexes, all using VC (VC) as inputs. The output is a number in R.

T:TV,TT,TC,TSMR

with each sub-index Ti as Ti:{VC}R

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 TV is a function of the n chains of the public keys from the issuer to the Trust Anchor.

Ck{Chains},TV=1nk=1nαlength(Ck)1

Tip

α=0.9 is recommended to keep a meaningful TV value even with long machine-to-machine chains.

Evolution of the index with α

Smaller is α, more aggressive is the index with regards to long chains.

24681000.51
a = 0.9a = 0.7a = 0.5a = 0.2Keychain lengthIndexthe Trust Anchor is the Issuerconverge to 0

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.

TT is computed in a two steps approach:

  1. TTn values for each VC n of the graph G.
  2. an overall TT value from the previous TTn values, for the VC n0 representing the object of interest.

TT and TTn are characterised by:

  • 0TT1
  • TT=0 when |{p}|=0, ie the cardinality of the set {p} of property p is 0, ie no property are filled in.
  • lim|{p}|+TT=1 when more properties p 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, TT2>TT1>TT0

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

registrationNumber: FR5910.899103360
headquarterAddress:
country: FR
legalAddress:
country: FR

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

name: api software
copyrightOwnedBy:
- url(provider1)
license:
- EPL-2.0

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

name: datacenter
maintainedBy: url(participant2)
location:
- country: FR

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 countTotal(n) the number of available properties for a VC n, every property p is given a weight wp.
wp=1countTotal
  • each property p is given a value vp depending of its cardinality and the number of given values c
pn,TTn=pwpvp

Example

for a VC with 5 properties, each property p has a weight wp=0.2

For a cardinality with known boundaries n..m

vp={0,if c0cm,if 0<c<m1,if cm
Example with a known maximum

For a cardinality with an unknow upper boundary n..*

vp={0,if c<n1βcn,if cn

Tip

β=0.9 is recommended to keep a meaningful vp value even with long array of values.

Example with a unknown maximum and evolution of the value with β

024681000.51
beta = 0.9beta = 0.7beta = 0.5beta = 0.2Example without upper boundaryproperty valueconverge to 1

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 = 10011111
prop2, maxCard = 10000011
prop3, maxCard = 10111111
prop4, maxCard = 21111111
prop5, maxCard = *0001212
prop6, maxCard = *0111116
TTn0.0830.2670.4330.4500.4650.6170.693

12.1.2.2 For the node of interest

Once all the TTn values for each VC n from the graph G are calculated, an overall TT value is calculated taking into account the length of the path dn=dist(n0,n) from the VC of interest n0 to a VC n in the graph G, with the principle that further away from n0 is a VC, less impact it has on the overall TT index value.

If there are several VC at the same distance from n0, the average TTd of the TTn indexes at the distance d is computed.

n0G,nG,TT=dnγ(1γ)dn1TTd
Info

The above formula was built to normalise the index TT in the range [0,1].

for 0γ1,1γ(1γ)x1dx=1

Tip

γ=0.5 is recommended to have a balance between VC with and VC without linked VC.

Evolution of the value with γ

When γ is close to 1, linked VC have a low impact on the overall Transparency index TT.

When γ is close to 0, linked VC have a high impact on the overall Transparency index TT.

24681000.20.40.60.8
gamma = 0.2gamma = 0.5gamma = 0.8Example without upper boundaryproperty value

Example

For the graph below, various transparency indexes TT are calculated for different values of TTn.

Example 1Example 2Example 3Example 4Example 5
Service Offering
(d = 1)
Tn=0.2Tn=0.2Tn=0.5Tn=0.5Tn=0.5
Resource 1
(d = 2)
Tn=0Tn=0.1Tn=0.1Tn=0.9Tn=0.9
Resource 2
(d = 2)
Tn=0Tn=0.1Tn=0.1Tn=0.8Tn=0.8
Resource 3
(d = 3)
Tn=0Tn=0.3Tn=0.3Tn=0.3Tn=0.3
Resource 4
(d = 3)
Tn=0Tn=0.9Tn=0.9Tn=0.1Tn=0.9
TT0.1000.2000.3500.4880.537

12.1.3 Composability

The Composability index TC is a function of two or more service descriptions, computing:

  • 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 TSM is a function of:

  • 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, …)