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 \(T_V\), Transparency \(T_T\), Composability \(T_C\) and Semantic-Match \(T_{SM}\) 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 \(r_{SO}\) in the range \(1.0\) to \(2.0\) excluded, as in \(r_{SO} \in [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 \(T_V,T_T,T_C,T_{SM}\) are meant to be used by all parties - licensor, licensee, producer, provider, consumer, \(\dots\) - 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 (\(\texttt{VC}\)) as inputs. The output is a number in \(\mathbb{R}\).

\[ T: T_V, T_T, T_C, T_{SM} \rightarrow \mathbb{R}\]

with each sub-index \(T_i\) as \(T_i: \texttt{\{VC\}} \rightarrow \mathbb{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 \(T_V\) is a function of the \(n\) chains of the public keys from the issuer to the Trust Anchor.

\[\forall C_k \in \{Chains\}, T_V = \frac{1}{n}\sum_{k=1}^{n} \alpha^{length(C_k)-1}\]

Tip

\(\alpha = 0.9\) is recommended to keep a meaningful \(T_V\) value even with long machine-to-machine chains.

Evolution of the index with \(\alpha\)

Smaller is \(\alpha\), more aggressive is the index with regards to long chains.

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)

flowchart LR
    keychain1[cert #1]
    keychain2[cert #2]
    keychain3[cert #3]
    keychainA[cert #A]
    keychainB[cert #B]
    vc1(credential #1)
    vc2(credential #2)
    cs([subject])
    keychain1 -- issues --> keychain2 -- issues --> keychain3 -- signs --> vc1 -- refers to --> cs
    keychainA -- issues --> keychainB -- signs ---> vc2 -- refers to --> cs

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)

flowchart LR
    root1[root cert]
    interm1[intermediate cert #k]
    leaf1[leaf cert]
    vc1(credential #1)
    cs([subject])

    root1 -- issues --> interm1 -- issues --> leaf1 -- signs --> vc1 -- refers to --> cs

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.

\(T_T\) is computed in a two steps approach:

\(T_{T_n}\) values for each VC \(n\) of the graph \(G\).
an overall \(T_T\) value from the previous \(T_{T_n}\) values, for the VC \(n_0\) representing the object of interest.

\(T_T\) and \(T_{T_n}\) are characterised by:

\(0 \le T_T \le 1\)
\(T_T = 0\) when \(|\{p\}|=0\), ie the cardinality of the set \(\{p\}\) of property \(p\) is \(0\), ie no property are filled in.
\(\lim_{|\{p\}| \to +\infty} T_T = 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, \(T_{T_2} > T_{T_1} > T_{T_0}\)

Minimun requirement \(T_{T_0}\)Improved requirement \(T_{T_1} > T_{T_0}\)Improved requirement \(T_{T_2} > T_{T_1}\)

flowchart TB
    so1{{Fortune teller}}
    part1[Provider 1]
    so1 -- providedBy --> part1

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

flowchart TB
    so1{{Fortune teller}}
    part1[Provider 1]
    vr1[\Software 1\]

    so1 -- providedBy --> part1
    so1 -- aggregationOf --> vr1
    vr1 -- copyrightOwnedBy --> part1

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

flowchart TB
    so1{{Fortune Teller}}
    part1[Provider 1]
    part2[Participant 2]
    part3[Participant 3]
    vr1[\Software 1/]
    vr2[\DataSet\]
    pr1[/Datacenter\]

    so1 -- providedBy --> part1
    so1 -- aggregationOf --> vr1 & vr2 & pr1
    vr1 -- copyrightOwnedBy --> part1
    vr1 -- tenantOwnedByBy --> part1
    vr1 -- maintainedBy --> part1

    vr2 -- copyrightOwnedBy --> part3

    pr1 -- maintainerBy --> part2

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 \(w_p\).

\[w_p = \frac{1}{countTotal}\]

each property \(p\) is given a value \(v_p\) depending of its cardinality and the number of given values \(c\)

\[\forall p \in n, T_{T_n} = \sum_p w_p v_p\]

Example

for a VC with 5 properties, each property \(p\) has a weight \(w_p = 0.2\)

For a cardinality with known boundaries n..m

\[v_p = \begin{cases} 0, & \text{if } c \le 0 \\ \frac{c}{m},& \text{if } 0 \lt c \lt m \\ 1, & \text{if } c \ge m \end{cases}\]

Example with a known maximum

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

\[v_p = \begin{cases} 0, & \text{if } c \lt n\\ 1-\beta^{c-n},& \text{if } c \ge n \end{cases}\]

Tip

\(\beta = 0.9\) is recommended to keep a meaningful \(v_p\) value even with long array of values.

Example with a unknown maximum and evolution of the value with \(\beta\)

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

12.1.2.2 For the node of interest¶

Once all the \(T_{T_n}\) values for each VC \(n\) from the graph \(G\) are calculated, an overall \(T_T\) value is calculated taking into account the length of the path \(d_n = dist(n_0, n)\) from the VC of interest \(n_0\) to a VC \(n\) in the graph \(G\), with the principle that further away from \(n_0\) is a VC, less impact it has on the overall \(T_T\) index value.

If there are several VC at the same distance from \(n_0\), the average \(\overline{T_{T_d}}\) of the \(T_{T_n}\) indexes at the distance \(d\) is computed.

\[\exists n_0 \in G, \forall n \in G, T_T = \sum_{d_n} \gamma (1-\gamma)^{d_n-1}\overline{T_{T_d}}\]

Info

The above formula was built to normalise the index \(T_T\) in the range \([0, 1]\).

\[\text{for } 0 \le \gamma \le 1, \int_1^\infty \gamma (1-\gamma)^{x-1}dx = 1\]

Tip

\(\gamma = 0.5\) is recommended to have a balance between VC with and VC without linked VC.

Evolution of the value with \(\gamma\)

When \(\gamma\) is close to 1, linked VC have a low impact on the overall Transparency index \(T_T\).

When \(\gamma\) is close to 0, linked VC have a high impact on the overall Transparency index \(T_T\).

Example

For the graph below, various transparency indexes \(T_T\) are calculated for different values of \(T_{T_n}\).

flowchart TB
    service[Service Offering]
    res1[Resource 1]
    res2[Resource 2]
    res3[Resource 3]
    res4[Resource 4]

    service -- is composed of --> res1 & res2
    res1 -- is composed of --> res3 & res4

12.1.3 Composability¶

The Composability index \(T_C\) 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 \(T_{SM}\) 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, …)

PDP https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml ↩