One of the major challenges on the Decentralized Identity model is how to trust the issuers of credentials, and how to make sure that all legal requirements regarding the identity validation have been correctly fulfilled.
In the Decentralized Identity world, multiple "governance" platforms differentiated by technology, geographical, economical or legal frameworks will coexist.
If we wish to ensure interoperability between technology providers, and more precisely verifiers, it is necessary to establish a common standard interface that is agnostic of the governance platform to allow external actors to retrieve a list of trusted issuers for a specific credential.
Despite its format, this document doesn't aim to be published on the W3C as a standard normative, rather it aims to offer a new protocol that is applicable to known SSI governance frameworks.
Many technology providers have offered different solutions to solve the problem of "who should be trusted as an issuer". Some known solutions could be hardcoded lists in configuration files, API services, Domain name consultations, or Blockchain/DLT registries.
In the SSI world however, it's the Verifier who must have the final decision on who he can trust. That means that a verifier should be allowed to query different governance platforms to retrieve their issuers and assign different levels of trust to each one of them. The verifier could even have a private registry of issuers that is not publicly available.
Only in the context of the Essiflab project, there are multiple solutions trying to offer partial solutions to this problem:
In the context of EBSI Essif, a trusted issuer registry has been designed with a complex governance protocol to determine who can issue which credentials and who can vouch for those issuers. A generic, agnostic approach to that kind of behaviour, portable to any governance platform, could be the solution required by verifiers.
This document will try to offer a generic adaptation compatible with EBSI Essif trusted registries that can be a solution for any governance framework. The verifier will only need to build a generic query interface, similar to the Universal DID Resolver, to retrieve the issuers from any platform, and manage them as he pleases.
The data model marks the representation of a Trusted Issuer
A Trusted Issuer is a signed document that presentsa credential issuer's information along with the accreditations backing the identity validation process performed.
JSON-LD is a JSON-based format used to serialize Linked Data.
The JSON-LD representation defines the following representation-specific entries:
The trusted issuer registry contains all the information about organization issuing the credentials. That implies both legal information and information to present the issuer to the users.
The MANDATORY properties about the organization info are:The accreditations are issued by trusted members in charge of the platform management.
The accreditations indicate which credential schemas can be issued by the issuer and give information about the validation process executed to issue those credentials.
Data Proof asserting the event and the current resulting state of the Data Agreement, as described in VC Data Model. This can be one or more cryptographic proofs that can be used to detect tampering and verify the authorship of a modification or acceptance event.
The governance service MUST assert the truth of the contents of an Issuer record by signing them with a platform DID.
{
"@context": "https://gataca.io/schemas/tir/2020/v1",
"accreditations": [{
"accreditor": "did:gatc:2abcd...ABC",
"createdAt": {},
"credentialSchema": "https://gataca.io/tsr/exampleSchema1.json",
"evidence": {
"evidenceDocuments": ["Passport"],
"documentPresence": "Physical",
"id": "https://essif.europa.eu/tsr/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231",
"subjectPresence": "Physical",
"type": [ "DocumentVerification"]
},
"expirationDate": {},
"levelOfTrust": 2,
"proof": [{
"created": {},
"jws": "abc...123=",
"proofPurpose": "assertionMethod",
"type": "EidasSeal2021",
"verificationMethod": "did:gatc:2abcd...ABC#123456789"
}],
"validFrom": {}
}],
"eidasCertificates": [{
"eidasCertificateIssuerNumber": "123456",
"eidasCertificatePem": "[...PEM-ENC-CERT...]",
"eidasCertificateSerialNumber": "123456"
}],
"dids": [
"did:gatc:2abcd...ABC#123456789",
"did:ebsi:2abcd...ABC#123456789"
],
"domain": "Education",
"id": "e20993d1-2430-462b-a9d0-2f2ead3345f8",
"organizationInfo": {
"areaGroup": "Education",
"EORI": "AT123456789101",
"discoveryURL": "https://example.organization.com",
"domainName": "https://example.organization.com",
"identifierBag": "ddd1ebce-8305-4edf-b6b6-7588aa021311",
"legalAddress": "Example Street, 38, 3 Izq, Madrid, Spain",
"legalName": "Example Legal Name",
"legalPersonalIdentifier": "123456789",
"LEI": "12341212EXAMPLE34512",
"preferredDisplay": {
"background": {
"color": "#ABCDEF",
"uri": "https://example.org/background.jpg"
},
"logo": "https://example.org/logo.jpg",
"preferredName": "Brand Name",
"style": {
"color": "#ABCDEF",
"fontFamily": "arial"
}
},
"SEED": "AT12345678910",
"SIC": "1234",
"taxReference": "123456789",
"VATRegistration": "ATU12345678"
},
"proof": [{
"created": {},
"jws": "abc...123=",
"proofPurpose": "assertionMethod",
"type": "EidasSeal2021",
"verificationMethod": "did:gatc:2abcd...ABC#123456789"
}],
"serviceEndpoints": [{
"id": "did:gatc:2abcd...ABC#123456789#openid",
"serviceEndpoint": "https://openid.example.com/",
"type": "OpenIdConnectVersion1.0Service"
}]
}
The resolution API is a very simple query REST API, only with GET Operations
This document does not aim to standarize operations for platform management, just resolution operations.
The governance resoluion API to expose the trusted issuer registry MUST conform with the Issuer Resolution API defined on the corresponding VUI working package.