Trust Anchors¶
TL;DR Trust Anchors definition
The Trust Anchors are for attestations, what TSP are for identities.
For a given ecosystem, the ecosystem authority identifies the Trust Anchors as the parties eligible to issue an attestation about a specific subject.
The Trust Anchors are parties, ie CAB or technical means, accredited by the ecosystem authority to be trustworthy anchors in the cryptographic chain of public keys used to digitally sign attestations or claims about an object.
For each accredited Trust Anchors, a specific scope of attestation is defined.
The Trust Anchors are not necessarily Root Certificate Authorities as commonly understood. A Trust Anchor can be relative to another property in a claim.
sequenceDiagram
autonumber
participant TA as Trust Anchor
participant holder as Holder
TA ->> holder: issues a signed and machine readable attestation
The list of valid Trust Anchors and rules are available via the ecosystem Registry.
Examples of Trust Anchors
For a sovereign identity, ie a legal or national identity issued by the state, only a state accredited party can be a Trust Anchor. In the specific case of identity, those are named Trust Service Provider.
PS: sovereign is here used as defined in the dictionary and doesn't relate to SSI.
For the consent to process personal data outside the scope of legitimate interest, only the data subject can be the Trust Anchor.
Trusted Data sources and Notaries¶
When an accredited Trust Anchors is not capable of issuing cryptographic material nor sign claim directly, then the ecosystem authority accredits one or more Notaries which will perform a validation based on objective evidence from a Trusted Data sources and issue an attestation about the previously made attestation from the Trust Anchors.
The Notaries are not performing audit nor verification of the object of conformity.
The VC signed by such a Notary will be second-party conformity assessment activity and have as credentialSubject
a statement about the original attestation.
The overall trust level of such a VC will be lower than if the CAB was able to digitally sign the VC directly without involving a Notary. See the Veracity Trust Index
The Notaries are converting "not machine readable" proofs into "machine readable" proofs.
sequenceDiagram
autonumber
participant TA as Trust Anchor
participant notary as Notary
participant holder as Holder
alt attestation comes directly from the trust anchor
TA ->> notary: issues an unsigned or non-machine readable attestation
else attestation comes from the holder
TA ->> holder: issues an unsigned or non-machine readable attestation
holder ->> notary: presents the unsigned or non-machine readable attestation
end
Note over notary: the notary uses Trusted Data Sources to validates the attestation
notary ->> notary: translates from a non-machine readable to a machine readable and signs
Note over notary: the notary becomes a Trust Anchor
notary ->> holder: issues a signed and machine readable attestation
Examples of Notary
The European Commission is providing several API, including one to check the validity of EORI number.
Unfortunately, those API are not returning Verifiable Credentials. Hence the development of a notary service for EORI using the European Commission API as Trusted Data source for validation.
Evidence¶
It is expected that the VC issued by the Notaries contain the evidence of the validation process.
Implementation¶
The list of Trust Anchors, Trusted Data Sources and Notaries are discoverable via the ecosystem Registry.
The Registry can implement several interfaces:
- European Blockchain Service Infrastructure API
- a Trust-service Status List (TSL) following ETSI TS 119 612 format exposed via:
- a well-known URL, like the European Commission TSL
- DNS PTR record, like in the TRAIN model, pointing to a URL (
https://
,ipfs://
, ...). - a smart-contract via blockain RPC nodes
- ...