# Meeting 2025-10-02, Wenjing + Kevin
A 90-minute meeting betweeen Wenjing Chu and Kevin Boos discussing the UNICC's new endeavor to provide independent, decentralized developer resources with TSP as the foundation for authentic identities.

## Background: UNICC datacenter goal
* The UNICC wishes to host its own datacenter to fulfill developer needs
* Will offer a chat service, likely a Matrix homeserver
* And a git host, likely `gitcode.net`, which will be implemented by CSDN
* UNICC needs an identity provider/management solution
* We propose that they use decentralized IDs backed by TSP
* The Linux Foundation is also interested in using this, and has already started building a service based on TSP for the purpose of verified developer identities (e.g., signed commits)

* Why Matrix? UNICC is looking for an alternative to email
* Email can still be the basis for setting up an account, but not the default for *using* that account.
* This makes sense because email is not a good default choice for things beyond occasional administrative tasks, e.g., resetting a password
* TSP can be the basis for authenticated/verified/secure Matrix communication, but not really for email

## Our goal: convince UNICC to adopt our work
* UNICC is interested in our Matrix-based homeserver (Palopo) and client application (Robrix + TSP) workflow
* Augmented with TSP support for decentralized identity (DID) functionality. Each nation can bring its own form of identity, e.g., a passport or driver's license
* Suggested division of labor:
* We (Robius/FW) will provide the client-side application functionality
* Borrow the Linux Foundation's integrated workflow to set up a new pairing of TSP ID and email registration (i.e., backend onboarding)
* Palpo could provide the Matrix homeserver implementation (or something different, based on Palpo's status)

### Example usage scenario: onboarding workflow
* A new user (with their own TSP ID) wants to set up access to an existing project
* They must communicate with an existing administrator or project maintainer in order to set up their privileged access to said project
* The admin wants to be able to securely verify the new user's identity
* The admin may also require the new user to sign an agreement, terms of use, or another form of document, e.g., a [Developer Certificate of Origin (DCO)](https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin)
* Existing approaches for this are just a signature with an account, e.g., DocuSign, or even worse, a scanned image of a physical ink signature.
* There is no real guarantee that the user who "signed" the agreement/document is actually the person they say they are
* **Key Challenge:** The user must be able to provide and attach *proof* along with the signed document that they are (1) who they say they are, and (2) they are the one who signed the document, all without a centralized authority.
1. This is where TSP comes in: the TSP ID is algorithmically verifiable and authentic.
2. Use local biometric authentication (provided by the platform, e.g., FaceID, TouchID/fingerprints) before allowing the user to actually sign the document locally.
* This is analogous to going to a public notary to sign a document in person under their supervision.
* In this case, TSP + the platform together act as the notary to verify the user's actual identity and that they were the signatory.
* Thus, by virtue of the user sending TSP-signed messages in the Matrix room, the admin can be assured that they are who they say they are. Similarly, by virtue of them sending a signed document, the admin can be assured that they are the ones who signed & completed it.
* Additionally, the user can supplement their "proof of identity" by securely providing credentials or endorsements (from other TSP-verified users that the user has established relationships with) in their TSP wallet. This feature is enabled by TSP's *referral* concept.
* TSP + local biometric authentication prevent the attack vector in which your local device is stolen or otherwise compromised.
* Together, this meets national legal requirements for signatures, similar to public notary services.

## Robrix's to-do list for demonstrating these features
Our near-term goal is to publish pre-built releases of Robrix with the existing TSP featureset activated, and then implement the additional features below to proeprly realize the aforementioned usage scenario.

Robrix's existing releases (on all 5 major desktop & mobile platforms) are available [here on GitHub](https://github.com/project-robius/robrix/releases), but the existing prebuilt releases do not currently include TSP support.
Robrix's current status of TSP support is tracked [here in this issue](https://github.com/project-robius/robrix/issues/551).

1. Support the `WebVH` DID kind (VH: Verifiable History)
* Robrix currently only supports the `Web` DID kind; `WebVH` is newer and better.
* This requires a significant overhaul of Robrix's TSP identity mgmt code.
2. Support for TSP-level double encryption, within private Matrix rooms only.
* The UI and backend logic for this shouldn't be too difficult to add to Robrix.
3. (TSP SDK): add enhanced support for separating out the TSP signature & header from the message payload itself.
* Waiting on [this issue from the TSP SDK](https://github.com/openwallet-foundation-labs/tsp/issues/218).
4. Storing the password for the TSP wallet securely in the OS-native keychain
* We have a lightly-tested `robius-keychain` crate for this (as well as the third-party crate `keyring-rs`), so the platform abstraction is mostly be ready to go, but we'll still need to use it and test it thoroughly across all platforms, which is likely to be challenging.
5. Biometric authentication as a time-of-use check when sending sensitive wallet contents to a room
* We have a well-tested `robius-authentication` for this purpose, so it should be relatively straightforward to add this into RObrix.