Trust Service Infrastructure

[adewes]

To create trust between users and providers we should extend the Kiebitz system with an additional actor type, a trust service (sometimes called trust service provider). Trust services can generate access codes with which users and possibly providers can use to gain access to the Kiebitz system and book or publish appointments.

Trust services are identified by public/private key pairs in the Kiebitz system. They interact independently with users and providers to verify certain attributes (e.g. that a user is in possession of a valid e-mail address) and then generate verifiable proofs of these attributes for the Kiebitz system. These proofs can e.g. be used in the sign-up or booking process in order to combat abuse and foster trust. Importantly, proofs generated by the trust services are not tied to any personal data, hence the Kiebitz system does not come into contact with such data.

Examples of trust services:

• A service that verifies that a given user is in possession of a valid e-mail address or a valid mobile phone number (assuring the given e-mail or phone number has only been used once).
• A service that verifies that a person is in possession of a digital identity document.
• A service that verifies that a person has been present in a given location to obtain a proof.
• A service that verifies that a person is member of a given profession (e.g. a health worker).

The anonymous proofs that are generated by a trust service can be propagates through the entire booking process within the Kiebitz system. This e.g. enables providers to verify information stated in the proofs, e.g. that a person is really member of a given profession. Independently proofs can be used by the Kiebitz system to combat abuse by ensuring that anonymous users cannot book appointments without actual intent to get vaccinated. The Kiebitz system can e.g. provide staggered access to vaccine appointments based on different types of proofs a user supplied, and the corresponding fraud probability.

Overall the trust services concept enables external trustworthy actors to support the Kiebitz system by providing provable attributes of users and providers, without "contaminating" the system with personal data. To further increase anonymity, trust services and their clients can employ e.g. blind signatures or zero-knowledge proofs in order to reduce the traceability of generated proofs within the system. This enables in principle fully anonymous proofs that potentially can remain anonymous even if trust services and the Kiebitz operators collude against the user.

Technically, in order to implement this we need to do the following:

• Implement a new actor, TrustService in the system, with a corresponding key list.
• Implement an onboarding process for trust services.
• Implement checking and attachement of verified proofs in the signup and booking process.
• Extend the provider app to show information about attached proofs.
• Publish a specification for external trust services on how to generate proofs compatible with the Kiebitz system.

This mechanism implements or enables many points discussed in https://github.com/kiebitz-oss/pm/issues/34.

Example: E-Mail Verification Trust Service

• User requests e-mail address verification from trust service
• Trust service sends e-mail with confirmation code
• User provides confirmation code to trust service, together with a blinded token.
• Trust service returns the signed blind token and the accompanying certificate.
• User unblinds the signature and presents it to the Kiebitz backend when signing up.
• Kiebitz verifies the signature and associated certificate based on the public key of the trust service.

As blinded signatures cannot include signer-verifiable meta-data, this meta-data needs to be encoded in the signing certificate. That means that an e-mail verification trust service will need to generate fine-grained certificates that contain public keys and associated meta-data (e.g. type: email-verification, date: 2021-12-30) and sign them with its master key. Anonymity is ensured by the fact that a single certificate is used to sign data for many users. The Kiebitz backend can then in turn verify the trust service child certificate against the service master key to ensure its legitimacy.