Credentials
Install Dependency
Package: meeting_place_credentials
dart pub add meeting_place_credentialsYou can check the latest version of this module on the pub.dev or view the source code at the GitHub repository.
Overview
The Credentials SDK is built on top of meeting_place_core and provides the credential layer for Meeting Place applications.
It supports:
- Relationship Cards and Verifiable Relationship Credentials (R-Cards and VRCs) - Verifiable Credentials for exchanging contact details (name, email, phone, company, and custom fields) as jCard (RFC 7095), exportable to vCard 3.0 (RFC 6350), and for recording mutual relationships between DIDs through a two-step VDIP handshake. Go to R-Card and VRC Feature. No AWS account needed.
- Human ZKP - Prove you are a real human to a contact without sharing biometric data. Go to Human Zero Knowledge Proof Feature. Requires an external liveness provider such as AWS Rekognition Face Liveness or Azure Face Liveness Detection for production; the Flutter Reference App includes a synthetic demo that works without one.
R-Card and VRC Feature
Relationship Card (R-Card)
An R-Card is a signed W3C Verifiable Credential containing a jCard (RFC 7095) payload. Think of it as a digital business card with verifiable contact and relationship details: name, email, phone, company, and optional custom fields that can be cryptographically verified. R-Cards are exchanged automatically when a DIDComm channel is established and can be resent or shared manually at any time.
Verifiable Relationship Credential (VRC)
A VRC demonstrates that two DIDs have established a verified relationship. It uses a two-step VDIP handshake: the initiating side requests, and the responding side sends a relationship credential back. Both participants receive a signed copy of the final credential.
Human Zero Knowledge Proof Feature
The Human Zero Knowledge Proof (Human ZKP) feature lets one participant prove to another that they are a real human, without sharing personal or biometric data. The proof travels over the secure DIDComm channel as a compact cryptographic token that the verifier can validate immediately.
This SDK owns Stages 2 and 3. Stage 1 (the liveness check) is handled by an external provider such as AWS Rekognition.
Pipeline Stage Map
| # | Stage | What happens | Owner | Output |
|---|---|---|---|---|
| 1 | Liveness Check | User performs real-time actions (such as blinking or turning their head) in front of their device camera. The liveness provider analyzes the session and scores whether a live person is present. | External provider (for example AWS Rekognition). | LivenessEvidence |
| 2 | Issue Liveness Credential | CredentialService.createLivenessCredential(evidence) signs a W3C VC from the evidence. | This SDK | Signed LivenessCredential (W3C VC) |
| 3 | Generate ZKP | LivenessVcZkpAdapter wraps the VC into the format required for zero-knowledge proof generation, then ZkpService.prove() generates a Groth16 proof. | This SDK | Groth16 ZKP |
| 4 | Transmit Proof | The ZKP is sent over the DIDComm channel with no personal data. | meeting_place_core transport | ZKP message on channel |
| 5 | Verify | The contact’s device verifies the proof cryptographically. | Verifier (contact’s device) | Verified badge shown in UI |
Why this is privacy-preserving: The Groth16 proof generated in Stage 3 is mathematically derived from the Liveness Credential, but it does not expose the credential contents. The verifier learns only that the holder passed a liveness check.
Try it in action: The Flutter Reference App includes a working end-to-end Human ZKP demo. Enable it with ZKP_ENABLED=true and follow the end-to-end demo flow to see all five stages execute on a real device.
For implementation details and setup guides, refer to:
Glad to hear it! Please tell us how we can improve more.
Sorry to hear that. Please tell us how we can improve.
Thank you for sharing your feedback so we can improve your experience.