01
Travel &
hotel booking
- Kept on the account card
- Next tripStay historyFavorites
Sign in with VESS — for service providers
Connect with your users,
without holding their data.
User data lives on an “account card” in the user's wallet app. You receive it at every sign-in and overwrite and return it at every sign-out. Nothing stays on your servers.
TABIO
ACCOUNT · v13NEXT TRIP
TYOKYO
Tokyo → KyotoDatesNov 23 – 25
Stays12
Favorites8
Present to sign in / overwrite on sign-out
Sign in with VESSJust receive and verify
Your serverusers
0personal records
- NameNot stored
- Email addressNot stored
- Usage historyNot stored
Your service only receives, verifies and returns.
Are you storing too much?
Is your database
holding too much personal data?
Member data piles up “just in case” — and the moment it leaks, all of it goes at once. The cost of protecting it and the liability for an incident last as long as you keep it.
Are you storing any of these?
- Email addresses
- Dates of birth
- Addresses & phone numbers
- Favorites & browsing history
- Purchase & visit history
- Passwords (hashed)
If even one applies, it is a liability you have to keep protecting.
SELECT * FROM users;| id | name | birthday | address | bookings | |
|---|---|---|---|---|---|
| 1001 | Yamada ●● | yamada●●@mail.jp | 1992-●●-●● | Tokyo ●●… | 12 |
| 1002 | Sato ●● | sato.●●@mail.jp | 1988-●●-●● | Osaka ●●… | 4 |
| 1003 | Suzuki ●● | suzuki●●@mail.jp | 2001-●●-●● | Fukuoka ●●… | 27 |
| 1004 | Takahashi ●● | taka●●@mail.jp | 1995-●●-●● | Aichi ●●… | 9 |
| 1005 | Tanaka ●● | tanaka●●@mail.jp | 1979-●●-●● | Hokkaido ●●… | 15 |
| 1006 | Ito ●● | ito.●●@mail.jp | 1999-●●-●● | Kanagawa ●●… | 6 |
| … | … | … | … | … | … |
Unauthorized access detected
Every row in this table may have been exposed
So, don’t keep it.
All you receive is
where they left off.
At every sign-in, the only thing you receive is the account card your service issued last time. While the user is active you work with the data you need, temporarily; at sign-out you write the latest state back to the card and hand it back. Because the user always carries where they left off, you no longer need to keep member data or usage history in your database.
What you receive at sign-in
session
- NameNot received
- Email addressNot received
- Date of birthNot received
- Address & phone numberNot received
- Service-specific IDIdentifier
- Account card (bookings, history, favorites)Last session
THE FLOW — Travel booking service “TABIO”
The save data stays
with the user.
Like a game cartridge, data is saved on the user's account card instead of your server. It is loaded at sign-in, overwritten at sign-out, and handed back to the user.
STEP 1 · Sign up
Receive an account card
Once sign-up is done, TABIO issues an account card. The user just saves it to their wallet app. TABIO's database keeps neither their name nor their email.
9:41
Wallet app
NEW CREDENTIAL
TABIO sent you
an account card
TABIO
ACCOUNT · v1NEXT TRIP
——
No upcoming trip yetDates—
Stays0
Favorites0
- Issuer
- TABIO
- Stored on
- This device only
- TABIO's server
- Not stored
Save to wallet
Card in handNone yet
Issue card
TABIO's serverIdle
Personal data stored
0
Temporary session data
0
- No personal data or usage history held
▍
Next time, they sign in again with the updated card
Benefits
Nothing held,
nothing to guard.
A design that never takes custody of personal data does more than cut risk. By passing the account card back and forth, you keep the relationship with your users going without holding their data.
Key difference
Keep the relationship,
not the data.
Account information such as bookings, stay history and favorites is issued and updated as an account card on the user's side. Retention and personalization without a bloated database.
- Account card — v122026.10.01 / bookings 2 / favorites 6
- Overwritten with this bookingNo history left in the service's DB
- Account card — v132026.10.28 / bookings 3 / favorites 8Latest
Remove leak risk at the root
No names, emails or addresses stored — and no storage or deletion overhead either.
No member database to grow
No member tables, no accumulated history. Your server only handles data for the current session.
Always pick up where they left off
Load the account card at sign-in and resume from the previous state — bookings, favorites and more.
Data stays with the user
Usage records stay in the user's wallet app, so your service and your user share the same history.
On the web and in your own app.
Web (no app needed)VESS Wallet SDKPayments such as StripeInbox + push notifications
0
recordsof names, emails or usage history stored in your database
Use cases
For services where
picking up where you left off matters.
Bookings, usage records, progress, participation. The more a service depends on each user's history, the more it gains from keeping that history on the account card instead of in a database.
Travel &
02
Fitness &
facilities
- Kept on the account card
- Visit historyProgram progress
03
Members-only
communities
- Kept on the account card
- ParticipationRank
04
Events &
ticketing
- Kept on the account card
- AttendancePriority access
05
Online
courses
- Kept on the account card
- Course progressCompletion record
Comparison
How is this different
from the sign-in you have today?
Stored at sign-up
Today
Name, email, date of birth, address
Sign in with VESS
Nothing — you just issue an account card
Account identifier
Today
Email address
Sign in with VESS
Service-specific ID
Data created by usage
Today
Accumulated in your DB
Sign in with VESS
Written back to the account card and returned
Server after sign-out
Today
Member data and history stay forever
Sign in with VESS
Session data is erased
Impact of a breach
Today
Personal data leaks all at once
Sign in with VESS
No unnecessary personal data to leak
FAQ
Frequently asked questions
Common questions about VESS Login and “Sign in with VESS” before you adopt it.
What is VESS Login?
VESS Login is a sign-in platform for service providers, built by VESS Labs. With “Sign in with VESS”, user data is stored as an “account card” in the user's wallet app. You receive that card at every sign-in and overwrite and return it with the latest state at every sign-out, so you don't need to keep member data or usage history in your database.
What does my service receive with “Sign in with VESS”?
At sign-in you receive only a service-specific ID that identifies the account and the account card your service issued last time (bookings, usage history, favorites and so on). You do not receive the user's name, email address, date of birth or address.
What is an account card?
It is account information that your service issues and the user keeps in their wallet app. It records things like bookings, usage history and favorites; you receive it at every sign-in and overwrite it with the latest state at every sign-out before handing it back. Like save data in a game, the data stays with the user rather than on your server.
Without an email address, how do you identify users?
Instead of an email address, accounts are identified by a service-specific ID issued for each service.
What happens to server-side data when a user signs out?
Data created during use — such as confirmed bookings or new favorites — is held on your server only for the session. At sign-out, the account card is reissued with those changes and returned to the user, and the data is erased from your database and cache.
What kinds of services is it a good fit for?
Services where each user has a history to pick up from — bookings, usage records, progress or participation. For example: travel and hotel booking, fitness and facilities, members-only communities, events and ticketing, and online courses.
Can I use it on the web and in my own app?
Yes, both. It works on the web (no app needed for the user), can be built into your own app with the VESS Wallet SDK, and supports payments such as Stripe as well as an inbox with push notifications.
Do you really need
to store that personal data?
Let's start by sorting out what your service can do without holding.