Cała tożsamość użytkownika w naszej platformie zbudowana jest na założeniu, o którym pisałem w grudniu: w Polsce numer SIM jest od 2016 roku powiązany z PESEL-em, więc jeden zweryfikowany numer telefonu = jeden konkretny człowiek. To jest najtańsza weryfikacja tożsamości na świecie. Działa świetnie dla mieszkańca, który chce wymienić się stołem z sąsiadem.
W kwietniu zacząłem pisać warstwę dla organizacji — spółdzielni mieszkaniowych, urzędów dzielnic, NGO-sów, firm. I cały ten model rozsypał mi się w jeden weekend.
Dlaczego phone-first nie skaluje się na instytucje
Spółdzielnia mieszkaniowa to nie człowiek. Nie ma jednej osoby, której telefon mógłby ją reprezentować. Jest zarząd, jest księgowość, jest administrator, są pracownicy techniczni. Każdy z nich może działać w imieniu spółdzielni — i żaden nie powinien być permanentnym właścicielem konta. Ludzie się zmieniają, spółdzielnia zostaje.
To samo dotyczy urzędu, NGO-sa, firmy. W modelu „SIM = konto” każde z tych trzech rzeczy się dzieje natychmiast:
- Pracownik, na którego numer założono konto, odchodzi. Numer trafia do innego klienta operatora. Konto spółdzielni jest teraz „własnością” zupełnie obcej osoby.
- Numer ginie razem z telefonem. Konto blokuje się, bo nikt nie potrafi odebrać SMS-a z odzyskiwaniem.
- Drugi pracownik chce się też zalogować w imieniu spółdzielni. Nie ma jak — konto ma jeden numer, jeden PESEL, jedną osobę.
Każde z tych zdarzeń to nie błąd produktu. To codzienność każdej instytucji, której rotacja kadr nie jest zerowa. A jest zawsze większa od zera.
Cztery próby
Kiedy zacząłem to projektować, miałem cztery sensowne pomysły. Trzy z nich odpadły szybko — i każdy odpadł na coś innego, co warto opisać.
Próba A: wymagać telefonu też od organizacji
Najprostsze. Niech ktoś ze spółdzielni założy konto na swój numer i jest upoważniony do działania w jej imieniu.
To odpada na pierwszym scenariuszu — odejście pracownika. A drugim, równie ciężkim: spółdzielnia z dwudziestoma pracownikami chciałaby mieć dwadzieścia loginów, bo każdy z nich działa w innej roli. Wymóg „jeden telefon = jedno konto” oznaczałby, że spółdzielnia musi sztucznie wybrać jedną osobę-figurkę. To nie jest produktowe ograniczenie. To jest po prostu zła decyzja modelu danych przebrana za prostotę.
Próba B: po prostu wyłączyć weryfikację dla organizacji
Druga próba — niech organizacje nie muszą weryfikować tożsamości. Jest specjalny przełącznik („to jest konto firmowe”), który wyłącza bramkę sprawdzającą PESEL.
To odpada na dziurze w bezpieczeństwie. Mamy w aplikacji jednego centralnego strażnika, który sprawdza tożsamość każdej operacji. Jeśli on ma do niego dodać „chyba że to konto z flagą firmową, to przepuszczaj” — to nie jest już strażnik, to dekoracja. Wyjątek wpuszcza całą klasę nadużyć, bo ktoś po prostu założy konto z flagą i będzie poza weryfikacją.
Centralna bramka działa tylko wtedy, gdy nie ma wyjątków. Jeśli musisz zrobić wyjątek, znaczy że modeluje się coś nie tak.
Próba C: dodać „typ konta” do użytkownika
Trzecia próba — niech użytkownik ma pole accountType: PERSONAL albo
BUSINESS. W zależności od typu, system wymaga innych rzeczy.
Tę odrzuciłem za semantykę. Jeden człowiek może być jednocześnie mieszkańcem Starachowic (konto osobowe), pracownikiem spółdzielni mieszkaniowej i wspólnikiem w spółce, którą prowadzi z bratem. Te trzy role to ten sam człowiek — ale to są trzy różne tożsamości w platformie. Pole „typ” na użytkowniku zakłada, że człowiek jest jednego rodzaju. A nie jest.
To pole należy do przynależności, nie do osoby.
Próba D: dwa anchory, dwa flow, jedna bramka
Czwarta próba — i ta zwyciężyła. Zostawić zupełnie nietknięte: jeden człowiek = jeden numer = jedna tożsamość, bramka bez wyjątków. Obok tego zbudować drugą warstwę: organizacja ma swój własny anchor tożsamości (rejestr CEIDG dla firm, KRS dla spółek, NGO-sów, spółdzielni). To są publiczne rejestry państwowe — taki sam stopień wiarygodności co PESEL, tylko dla podmiotów, nie dla osób.
Z tą warstwą pracownicy organizacji to nie są „specjalni użytkownicy” — to są zwyczajni użytkownicy (z normalnym numerem telefonu albo prowizorycznym emailem), którym organizacja wystawia pełnomocnictwo w postaci uprawnienia „reprezentuję tę organizację”. Bramka strażnicza nadal nie ma wyjątków: każdy musi mieć potwierdzoną tożsamość jakąkolwiek — telefonem albo pełnomocnictwem od zweryfikowanej organizacji.
Jak wpuścić pracownika, który nie ma jeszcze konta
Pozostawała jeszcze jedna rzecz do rozstrzygnięcia: jak nowy pracownik spółdzielni — taki, który dopiero zaczyna pracę — w ogóle zakłada konto. Wymaganie od niego rejestracji telefonem najpierw, a potem prośby do spółdzielni o włączenie do organizacji, jest tarciem, którego nie chce się mu wciskać w pierwszym dniu pracy.
Rozwiązanie podpatrzyłem u dużych: Slack, Notion. Spółdzielnia dostaje formularz „dodaj nowego pracownika” z polem email. System wysyła na ten email link z jednorazowym tokenem (ważny dobę), klikając w niego pracownik ustawia hasło i wchodzi już jako członek tej organizacji. Numer telefonu może dodać później albo nigdy — bo jego tożsamość pochodzi z pełnomocnictwa spółdzielni, nie z SIM-a.
Jest jeden warunek bezpieczeństwa: ten email musi należeć do zweryfikowanej
domeny organizacji (czyli spółdzielnia musi udowodnić, że posiada
spoldzielnia-kwiatowa.pl, dodając wpis DNS). Bez tego ktoś mógłby zakładać
pracowników na losowe adresy. Z tym — domena to anchor równoległy do PESEL,
tylko dla pracownika.
Co to zmienia w obrazie produktu
Do kwietnia myślałem o juz-ide jako o platformie dla mieszkańców. Spółdzielnia, urząd, sklep za rogiem — to byli „przyszli klienci”, o których pomyśli się później. Po tym tygodniu projektowania zacząłem ich widzieć inaczej.
Sąsiad za ścianą to jest pojedyncza osoba. Ale sąsiad pod blokiem to też spółdzielnia mieszkaniowa, która chciałaby ogłosić zebranie. Sąsiadem jest dzielnicowy ratusz organizujący sąsiedzki festyn. Sąsiadem jest miejscowy piekarz, który chce powiedzieć, że ma rogale tylko w niedzielę. To są instytucjonalne fragmenty tego samego sąsiedztwa.
Nie zaprojektuję platformy łączącej ludzi okolicy, jeśli wszystkie te instytucjonalne fragmenty muszą udawać osoby. Phone-first dla mieszkańca, domena + rejestr dla organizacji — to nie są dwa systemy. To jeden system, który w końcu rozumie, że sąsiedztwo nie składa się wyłącznie z ludzi.