Rozproszone tożsamości (trochę z bardziej technicznego punktu widzenia)

Ten wpis wynika głównie z mojego wcześniejszego marudzenia na frendica: To mnie uwiera: rozproszone tożsamości. tylko tym razem – dotyczy: jak można by rozwiązać problem dostarczycieli takich tożsamości.

Założenia – czyli co miałoby rozwiązywać toto.

Uch. Dużo i mało. Naturalnie na myśl przychodzi OAuth i delegowanie logowania, ale w tym wypadku chciałbym jeszcze, żeby można było w weryfikowalny sposób wysyłać wiadomości.

Bardzo z grubsza zarys pomysłu realizacji.

To jest raczej zbiór na razie luźnych pomysłów a nie kompletny, ostateczny zarys.

Tworzenie tożsamości.

Do tworzenia tożsamości musimy być potwierdzonymi właścicielami domeny, w ramach chcemy tworzyć tożsamości. Możemy to zrealizować przez odpowiednie wpisy z rekordach txt DNSów. W tej chwili widzę przynajmniej dwa takie rekordy:

Podejście z użyciem domen pozwala nam stworzyć usługę, która będzie samoopisująca się i łatwa do odkrycia dla innych usług. Jak widać, zaczerpnąłem tutaj inspirację z rozwiązań używanych przez serwery poczty (spf, dkim, dmarc), które reguły właśnie w taki sposób przechowują. Do tego jest to mechanizm relatywnie elastyczny, pozwalający na łatwą rozbudowę o nowe reguły czy możliwości (jak np. deklarowanie grupy serwerów jako dostarczyciela tożsamości, np. w celach niezawodności działania usług).

Adekwatnie – oznacza to, że nie będąc właścicielami domeny rubiez.eu nie uruchomimy usługi dostarczania tożsamości w ramach przestrzeni nazw https://rubiez.eu/@uzytkownik

Łatwo mi tutaj też myśleć o rozszerzeniach protokołu o jakieś mechanizmy inne (dns blokchain, tożsamości na bazie identyfikatorów sieci i2p czy innych usług katalogowych), z tym, że przestrzenie nazw oparte na DNS powinny być możliwe do rozwiązania wyłącznie za pomocą dns.

Tworzenie wpisu / postu z wykorzystaniem “obcej” tożsamości dla serwera.

Jup, tu się robi trochę trudniej. Bo powiedzmy, jeśli chce mieć za pomocą tożsamości X stworzyć nowy element (wpis, toota, notke, dokument) na serwerze Y, oznacza to, że nie tylko ten serwer musi komunikować się z moim dostawcą tożsamości w trakcie logowania by mnie “wpuścić”, ale też każdy nowy element który tworzę za pomocą takiej “obcej” dla niego tożsamości wysłać do podpisania do mojej usługi i potem ten podpis zweryfikować za pomocą publicznego klucza dostępnego np. w rekordzie DNS.

Dopiero takiego artefakt powinien być wysyłany w świat.

Usunięcie tożsamości. Niedostępność usługi. Itd...

Rozproszone tożsamości, znaczy też, że często gęsto usługi takie będą uruchamiane i wyłączane, będą więcej niż normalnie nękane przerwami w działaniu i podobnymi rzeczami.

Z artefaktami nie ma większego problemu. Raz, że klucz publiczny powinien być dostępny przez DNS, który z założenia jest dosyć stabilną usługą, dwa, że można też wymusić na serwerze z którego dane artefakty są wysyłanie obowiązek przechowywania też klucza publicznego, by w razie potrzeby można było też i z niego go pobrać. Choć myślę, że DNS powinien być metodą preferowaną i obligatoryjną w przypadku jej dostępności.

Z usunięciem np. domeny (a tym samym związanych z nią kluczy) jest większy problem – nagle znika nam dostępność kluczy publicznych, za pomocą można by zweryfikować stare posty. Ponownie – metodą jakąś jest lokalnie przechowywanie klucza przez serwer wysyłający artefakt.

Na koniec.

Pomysł oscyluje wokół dostawcy tożsamości ale łatwo mi sobie wyobrazić go również jako serwer innych danych, nad którymi chcemy mieć zupełną, całkowitą i pozostawiającą w naszych rękach – kontrolę. Bo nic nie stoi na przeszkodzie, żeby w ten sposób prezentować wizytówki, listy profilów czy innych danych związanych z danym identyfikatorem.

#mozenakiedys #todo #pomysly