Context

To make the Trustflows charter meaningful, organisations need a lightweight way to sign it and publicly demonstrate that they did so. The signing must remain trustworthy, respect privacy, and create a durable proof that can be verified later.

Constraints and goals:

  • No accounts, no complex identity providers: keep onboarding friction low.
  • Still provide a clear Trustflow: identity, representation of an organisation, consent, and verifiable proof.
  • Publish a minimal public record (name + organisation + date) as evidence of signing.

The trust flow for signing the charter

Identity through email verification

We are going to use a light-weight email verification step, that then assigns a key, for verifying the identity. We use work email verification as a practical identity signal:

  1. A person enters their work email address (and optionally first/last name and organisation name).
  2. The system sends a verification email containing the signing intent and a confirmation link.
  3. Clicking the link confirms control over the email address.

We will link a couple of pre-defined people and organisations with a logo based on the attendees of the event, so we can display the logo automatically in the charter as well. To reduce false representation, we combine:

  • Email domain heuristics (e.g., @example.com suggests affiliation with Example Corp).
  • Manual confirmation by Trustflows maintainers for cases where:
    • The domain is generic (e.g., gmail.com),
    • The organisation is ambiguous,
    • Or additional assurance is needed.

In some cases, we will also allow people to sign the charter in their personal capacity.

The signer must explicitly agree that Trustflows may publish their name as representative of the organisation on the website as proof of signing on a given date.

We represent this using the Data Privacy Vocabulary (DPV) as a machine-readable consent statement, linked to:

  • The personal data being published (name, email-derived affiliation),
  • The purpose (public proof of signing),
  • The processing (publication on the Trustflows website),
  • The date/time and scope.

Verifiable proof

After consent is confirmed:

  • The charter signing statement (as RDF triples) and the DPV consent statement are bundled in a W3C Verifiable Credential (VC).
  • The VC includes a cryptographic proof so the signature can be verified later and does not rely only on the website database.
  • The signer receives a Verifiable Presentation (VP) (e.g., via email attachment), so they can keep their own evidence.

The Trustflows website can then be auto-updated to list the newly signed organisation with date and representative name.

Vocabulary / data model choices

We need to be able to express the charter in triples. We propose to use a specific Trustflows vocabulary on this domain to model that. The charter itself is annotated using RDFa, and the triples can be extracted using an RDF parser such as the npm library rdf-parse from the Comunica ecosystem.

We also need a consistent way to state “a party signs the Trustflows charter”. A minimal, interoperable approach is to represent the signing as an activity with time and parties, and embed it in the VC’s credentialSubject. We can use new terms from our Trustflows specific vocabulary as well for the purpose of linking a signee and their organisation with the charter.

In the form to sign the charter, we’ll also ask consent for publishing the proof on the website. This will be modeled using the Data Privacy Vocabulary.