Google brengt Credential Manager-api uit voor wachtwoordloos inloggen

Google heeft een api uitgebracht waarmee ontwikkelaars makkelijker alternatieve inlogmethodes kunnen toevoegen aan hun apps. Via de Credential Manager kunnen gebruikers dan inloggen met een gebruikersnaam en wachtwoord, maar ook met een alternatief zoals een vingerafdruk.

Credential Manager is volgens Google bedoeld om het inlogproces in apps van derden te versimpelen. Met de api kunnen ontwikkelaars alle opgeslagen inlogmethodes op een Android-apparaat oproepen om een gebruiker te authenticeren.

Als bijvoorbeeld een willekeurige socialemedia-app de api implementeert, krijgt de gebruiker bij het inloggen de keus waar hij mee wil inloggen. Dat kan een traditionele combinatie van gebruikersnaam en wachtwoord zijn, maar ook een vingerafdruk of een single sign-on van bijvoorbeeld Google zelf.

Voorlopig worden alleen inlogmethodes ondersteund die in Googles eigen wachtwoordmanager worden opgeslagen. In de toekomst moeten echter ook thirdpartywachtwoordmanagers en -apps worden ondersteund, schrijft Google. Wanneer die ondersteuning komt en of externe managers dat dan zelf moeten toevoegen aan hun software, is nu nog niet bekend.

Met het plan zet Google een nieuwe stap richting wachtwoordloos inloggen. Google, net als veel andere techbedrijven, werkt al jaren aan een manier om het traditionele wachtwoord in combinatie met een gebruikersnaam te kunnen vervangen. Wachtwoorden en gebruikersnamen zijn namelijk enigszins achterhaald omdat ze op zoveel plaatsen moeten worden gebruikt maar tegelijkertijd altijd uniek moeten blijven. Dat maakt het onpraktisch of juist onveilig voor gebruikers. Techbedrijven werken daarom aan manieren om credentials op te kunnen slaan op één apparaat zodat gebruikers het van daaruit kunnen oproepen, ongeacht wat de credentials precies zijn. Tweakers schreef in 2019 een achtergrondverhaal over de toekomst van het wachtwoord en waar inlogmethodes de komende jaren naartoe bewegen.

Reacties (56)

Ik vind het toch jammer dat we voor zoiets basaals als identity en authentication weer afhankelijk lijken te gaan worden van Big Tech

Je bedoelt authentication en authorization Authentication is identity.

Identification is het vaststellen van de identiteit. Authentication is de verificatie er van.

Dat is niet zoals ik het op school geleerd heb:

Authentication verifies the identity of a user or service, and authorization determines their access rights.

@!GN!T!ON Dat is precies wat @snellehenkie zegt:

IAAA => Identification, Authentication, Authorization and Accountability.

Voor Tweakers:
Identification: gebruikersnaam
Authentication: wachtwoord + MFA
Authorization: de rechten, hier bepaald door Tweakers
Accountability: door de 3 bovenstaande kan (bijv. in de logging) achterhaald wat ik heb gedaan en ben ik daar verantwoordelijk voor.

[Reactie gewijzigd door Theone098 op 7 februari 2023 09:40]

Je hebt gelijk, ik las te snel. Mea Culpa.

Op een andere manier uitgelegd: als Organisatie 1 jou, op afstand, om een kopie of scan van jouw identiteitsbewijs vraagt, is dat identificatie.

Dat is géén authenticatie omdat degene die de kopie of scan van jouw identiteitsbewijs in handen heeft of krijgt (geautoriseerd of ongeautoriseerd), zich voor kan doen als jou bij Organisatie 2 - simpelweg door die kopie of scan door te sturen.

Dus ook Organisatie 1 heeft geen zekerheid dat jij die kopie of scan hebt opgestuurd. En hoe meer organisaties "kopietjes-ID" ontvangen, hoe groter het risico op identiteitsfraude na datalekken en/of door foute medewerkers.

"Absolute" * authenticatie daarentegen, kan alleen betrouwbaar in levenden lijve plaatsvinden - waarbij zowel het identiteitsbewijs op echtheid en manipulatie moet worden gecontroleerd, als de beschreven kenmerken (pasfoto, lengte, kleur van de ogen, -discutabel- geslacht etc.) moeten worden vergeleken met de betreffende persoon.

* "Absolute" in de zin van dat je ergens (nog) geen account hebt waarbij jouw identiteit eerder voldoende betrouwbaar (voor de betreffende toepassing) is geverifieerd.

Hoewel ik je opmerking snap, is dit ook niet iets wat ik zou willen overlaten aan een klein bedrijfje..

Dit dus. Moet er niet denken dat een politiek gelobbyed klein ICT bedrijfje van de achterneef van een topambtenaar dit in elkaar zou moeten flansen. Dan liever iets laten bouwen door big tech, al voelt het wel als kiezen tussen twee kwaden.

Wat dacht je van een grote onafhankelijke partij zonder commerciële instelling zoals Let's Encrypt. Laat alle big tech bedrijven maar gezamenlijk investeren in een wachtwoordloos alternatief zodat we er gelijk een universele standaard van kunnen maken.

Je zou een moeten kijken naar www.readid.com. Dat is een Nederlands bedrijf wat online identificatie diensten aanbiedt. Vele (inter)nationale bedrijven, banken en instellingen gebruiken die SAAS dienst.
Dit is een bedrijf wat in 2014 startte en inmiddels een stormachtige groei doormaakt. Hun NFC app kun je in de verschillende app-stores downloaden.Leuk om mee te spelen.

Overigens is identiteit een "breed" begrip. In het GBA heb ik een door de Overheid vastgelegde en geverifieerde identiteit (die verificatie gebeurt o.a. aan de hand van het hielprikje). Online, bij websites/forums hoef ik niet persé die identiteit aan te nemen, dan kan ik mezelf anders noemen. Dus ik kan meerdere identiteiten aannemen die al dan niet aan elkaar te relateren zijn. Ik kan ze gebruiken voor de verschillende use-cases. Dus, als we het over identiteit hebben, waar hebben we het dan precies over?

Het probleem is dat de innovatie op dit gebied gewoon volledig plat ligt bij de rest. Microsoft en Google (en misschien Okta) zijn de enige die echt vooruitgang maken en het probleem serieus aanpakken.

Ik zat vorige week nog in een vergadering met een leverancier die slechts een wachtwoordveld voor zijn (persoonsgegevens verwerkende) applicatie had. En het was een eenvoudig wachtwoord kan ik je vertellen... De leverancier vondt het prima en zag het probleem niet. Ik was juist de zeur... Heel veel applicatie leveranciers zijn gewoon extreem lui en slecht. Gelukkig hebben we in de publieke sector verplichtingen vanuit de overheid waaraan ze moeten voldoen.

Het staat in de screenshot en in de bron - helaas niet expliciet in de tekst van het nieuwsbericht - maar het wachtwoordloos inloggen kan ook met passkeys, wat een marketingterm voor de W3C WebAuthn-standaard is. Dit is een open standaard dat door verschillende makers van browsers, wachtwoordmanagers en security keys wordt ondersteund en nu in rap tempo door verschillende websites wordt uitgerold.

Ik snap je teleurstelling, en in een zeker opzicht ben ik het ook met je eens, A&A is natuurlijk een essentieel onderdeel van hedendaags computergebruik en je bent hier inderdaad weer een stukje daarvan aan de output van die bedrijven aan het koppelen.

Tegelijkertijd zie ik dit wel als iets wat ontzettend veel moeilijker op te zetten is zonder Big Tech. Ik denk zeker wel dat het technisch (en cryptografisch) uit bijvoorbeeld de open source community had kunnen komen. Maar passwordless inloggen heeft nog veel meer coördinatie met organisaties dan technische coördinatie nodig lijkt mij. En het gemak wat hiermee voor eindgebruikers wordt gecreëerd lijkt mij essentieel voor adoptie op een grote schaal.

Maar de belangrijkste reden voor mij dat ik hier minder problemen mee heb is dat de incentives voor gebruikers en de techbedrijven in mijn ogen redelijk in lijn liggen. Apple, Google, Facebook hebben er allemaal geen baat bij mensen die hun accounts verliezen of hun wachtwoord vergeten. Het kost hen klauwen met geld in customer support en fraudebestrijding, dus ik denk dat de problemen an sich hier nog wel mee zullen vallen. Neemt natuurlijk niet weg dat er zat problemen zijn met de techplatformen die we gebruiken.

Als zo'n app mijn digitale leven op een veilige manier simpeler maakt, heb ik daar totaal geen problemen mee.

"Credential Manager is volgens Google bedoeld om het inlogproces in apps van derden te versimpelen."

Credential Manager is volgens mij bedoeld om wéér een afhankelijkheid van Google in te bouwen waar je ook zonder kan....

Je kunt ook wachtwoorden hergebruiken, maar of dat nou de beste optie is...

Ik heb diverse dezelfde wachtwoorden, puur als check/test als er ergens weer een breach is, maar voorlopig.. werken ze nog steeds zonder iets mis te gaan. Fail moment is de server van de host, onderschepping in het midden, per default is jouw dubbel gebruikt wachtwoord niet slechter dan alles random.

Ik ben alleen geen fan van single point of failure, de 'app'.

Hoe kun je hetzelfde wachtwoord hergebruiken ter controle voor een breach? Leg dat eens uit. Want zoals ik het nu begrijp heb je het niet goed doordacht.

Een dubbel gebruikt wachtwoord is zeker wel slechter dan alles random. Met het hergebruik van een wachtwoord ben je namelijk afhankelijk van de zwakste schakel. Slechts 1 van die partijen hoeft zijn beveiliging niet op orde te hebben om jouw wachtwoord voor alle andere diensten uit te laten lekken.

En hoe bepaal jij, wanneer jij data hebt, dat deze dezelfde wachtwoord is van een andere site, waarvan jij geen data, geen salt, geen hashes hebt?

Het falen zit in de manier van opslag, plaintext, MD5, dat soort zaken waarmee een wachtwoord te herleiden is vanuit (hopelijk enkel opgeslagen) hash in de database. Natuurlijk kan je een rainbowtabel maken, op elk mogelijk wachtwoord met deze salt combinatie, hoewel mogelijk, of mogelijk pak je slechts een plaintext leak en ga je op zoek naar matches, in de hoop er 1 te vinden. Goed, dan heb je nog de encrypted versus hashes, maar wederom, de veiligheid (of eigenlijk het falen ervan) zit niet in het wachtwoord, maar in de database en methode van opslag. Noem eens 1 methode, zonder databreach, om te bepalen of mijn wachtwoord op site A hetzelfde is als site B.

Sorry, maar @3raser heeft hier volledig gelijk. Het is letterlijk altijd beter een willekeurig wachtwoord te gebruiken. Dat is simpelweg een waarheid gezien je niet hetzelfde wachtwoord gebruikt op meerdere sites... Dat is toch niet zo moeilijk te begrijpen?

En hoe bepaal jij, wanneer jij data hebt, dat deze dezelfde wachtwoord is van een andere site, waarvan jij geen data, geen salt, geen hashes hebt?
Dit is gewoon een volledig geautomatiseerd process.. Je pakt de inlognaam en wachtwoord en ' probeert' deze tegen een hele sloot van diensten met je (eventueel ingehuurde) bot netwerk...

Noem eens 1 methode, zonder databreach, .
Waarom? data breaches en datalekken zijn orde van de dag... Deze lijsten zwerven ook heel lang op internet voordat ze echt algemeen bekend worden.

om te bepalen of mijn wachtwoord op site A hetzelfde is als site B
Door in te loggen op site B

Je eerdere reactie:
maar voorlopig.. werken ze nog steeds zonder iets mis te gaan
Het hele ding van hacking is dat je niet in de gaten hebt dat er iets 'mis' is... Er is een reden dat we alles tegenwoordig Zero-trust bouwen.

Als je het daar niet mee eens bent dan moet je even aankloppen bij de NIST , NCCoE of NCSC:
Het NCSC adviseert om wachtwoorden slechts voor één account te gebruiken. Door het hergebruiken van wachtwoorden kan een kwaadwillende die toegang heeft verkregen tot één account veel makkelijker toegang krijgen tot andere accounts die hetzelfde wachtwoord gebruiken.

https://www.ncsc.nl/binar...eefactorauthenticatie.pdf

Waarom?
Precies, jij komt nu met andere voorwaarden/factoren die ik simpel niet stel, ik stel slechts _in basis_ het niet slechter is. Dat deze daarna een 99% fout factor heeft door een 99,9% kans op breaches/diefstal is een secondair aspect, maar niet voor mijn stelling.

Precies, jij komt nu met andere voorwaarden/factoren die ik simpel niet stel, ik stel slechts _in basis_ het niet slechter is.
Je bent erg onduidelijk in je '_in basis_" argument. Maar dat maakt niet veel uit, je probeert de discussie te reduceren door in te zoomen op een enkel stuk, te zeggen dat het geen verschil maakt en aan te geven dat het niet je stelling is. Maar alle onderdelen van je argument zijn fout:

Ik heb diverse dezelfde wachtwoorden, puur als check/test als er ergens weer een breach is,
Gezien je (neem ik aan) niet dagelijk op het darkweb in user credentials aan het handelen bent, is dit een waardeloze manier om te checken of deze credentials gelekt of gehacked zijn.

maar voorlopig.. werken ze nog steeds zonder iets mis te gaan.
Dat komt omdat ze eerst jaren verhandelt worden op internet. Als je het misgaat dan ben je in 1x flink de sjaak. Ik zag gisteren nog een Youtuber hierom huilen. Het enige wat het zegt is dat je niet interessant genoeg lijkt. Pas nadat deze lijsten verouderd zijn worden ze openbaar gemaakt (meestal pas vanaf 3-4 jaar).

Fail moment is de server van de host,
Dit is slechts 1 van de mogelijke opties. De meeste incidenten vinden echter plaats op de client machine (de gebruikers computer). Ik insinueer nu even dat je een server hack bedoelt want 'server van de host' betekent niets. Een server is een host en een host kan een server zijn....

onderschepping in het midden
Dit komt zeer weinig meer voor en is bijna verwaarloosbaar met alle versleutelde verbindingen.

per default is jouw dubbel gebruikt wachtwoord niet slechter dan alles random.
Als iedereen het niet eens is met die stelling, dan moet je jezelf eens achter de oren krabben.

Ik ben alleen geen fan van single point of failure, de 'app'..
Die app kan anders ook gewoon gebackupped worden. Je weet wel, dat ding wat je toch al moet doen voor je belangrijke data. Als je er echt zo over inzit kan je ook cleartext export maken naar USB stick.

Maar goed, dit is allemaal ook al verleden tijd. MFA is de nieuwe standaard en met diverse initiatieven zoals Passkeys en WebAuth worden inlognamen / wachtwoorden toch verleden tijd. Raad trouwens eens waar die dingen op gebaseerd zijn? Random strings

Jij gaat uit van een perfecte situatie waar wachtwoorden goed zijn opgeslagen en dus niet direct kan worden gebruikt op andere websites, data breaches niet voorkomen of direct worden gevonden en gemeld, je wachtwoorden op andere sites direct worden aangepast na een breach (en je geen accounts vergeet), of je apparaat geen virus of keylogger heeft die met 1 login op twitter direct ook je paypal wachtwoord heeft.

Je wachtwoord hoeft maar op 1 manier naar buiten te komen, en vervolgens zijn er tal van scripts of personen die direct al combinatie email/wachtwoord uitprobeert op tal van sites en services. Waarom dat risico lopen?

[Reactie gewijzigd door Raphire op 7 februari 2023 14:18]

Maar in die 'vrijwel onmogelijke' (maar niet onmogelijke) situatie, klopt mijn stelling dan? Dat is enige punt hier.

Uit de praktijk weten we dat het hacken van accounts met wachtwoorden uit breaches van andere websites/services een dagelijkse aangelegenheid is. En dat de mensen die hun wachtwoorden hergebruiken over het algemeen ook erg simpele of makkelijk te raden wachtwoorden gebruiken. Dan kan je in jouw droomwereld nog gelijk hebben als je allemaal aspecten achterwege laat, maar wat hebben we daaraan?

Met een goede password manager kan je al die zorgen en problemen weghalen doordat die (vaak automatisch) unieke, sterke wachtwoorden maken. Google/Apple hebben prima oplossingen hiervoor, en als je hen niet vertrouwt, of dat niet veilig genoeg vind zijn er genoeg andere opties. Met een password manager als keepass kun je de gegevens lokaal houden, of met bijv 1password kun je zelfs met een relatief zwak hoofdwachtwoord nog veilig dingen opslaan mbv de secretkey.

[Reactie gewijzigd door Raphire op 7 februari 2023 15:47]

Noem eens 1 methode, zonder databreach, om te bepalen of mijn wachtwoord op site A hetzelfde is als site B.

Dat is simpel. Door in te loggen met dat wachtwoord.

per default is jouw dubbel gebruikt wachtwoord niet slechter dan alles random.

Huh?
Dit heeft toch wel uitleg nodig, hoe ik het ook probeer ik kan geen enkele mogelijkheid bedenken hoe het recyclen van wachtwoorden net zo veilig zijn als random gegenereerde wachtwoorden.

Jij gaat nu wederom uit van 'als het fout gaat', daar praat ik niet over. Ik praat over de simpele basis, stel nu dat elke database, elke server, elke hash/encryptie methode 100% 'dicht' zit, niet in te zien, niet te stelen, is dan hetzelfde wachtwoord 'minder' veilig dan random?

Natuurlijk, die situatie bestaat niet, maar in die basis maakt het tussen die 2 niet uit.

Het is niet 'als het fout gaat', je weet als Tweaker denk ik ook wel 'dat het fout gaat'.
(in je voorbeeld ontbreekt trouwens nog het probleem tussen de stoel en het scherm)

Dat is hetzelfde als zeggen dat je deur op slot doen onzin is, want als iedereen gewoon even niet steelt dat er dan niks aan de hand is.

Helemaal mee eens, SinergyX gaat uit van een perfecte situatie. Maar uit de praktijk blijkt dat er veel grote datalekken voorkomen. Daarom kan je het beste gewoon van Zero Trust uitgaan en jezelf zo goed mogelijk indekken. Doormiddel van random gegenereerde wachtwoorden een Multi factor authentication.

Als je zoals SinergyX uit gaat van de perfecte situatie heb je geen eens een wachtwoord nodig

[Reactie gewijzigd door Crapple op 8 februari 2023 10:10]

Duh, net als adverteren 3.0 waar ze nu mee bezig zijn. Google maakt zichzelf met groot geweld onmisbaar, als we niet oppassen. Ze hebben praktisch het hele WWW in hun controle (op een niveau waar een jaren 90 microsoft totaal niet in de buurt komt).

We blijven Google vingers geven, terwijl dat bedrijf aan marktmisbruik doet waar de olie of gloeilamp kartels nog een poepie van kunnen ruiken.

Interessant. Ik vraag me af of dit ook hardware security keys ondersteunt, zoals Yubikey, of Google’s eigen Titan Key

Het staat er niet zo expliciet in maar ik vermoed dat met de FIDO2-standaard dit wel ondersteund zal worden op diensten waar je met alleen zo'n key kan inloggen, zolang dat geen mfa-key is dan. Dat kan alleen vrijwel nergens op dit moment.

Het is een goede ontwikkeling dat er meer keuzevrijheid is maar ik hou zelf niet van inloggen met een vingerafdruk. Het tegen mijn zin drukken van de vinger op de scanner is legaal (als de politie dit doet) en dat zint mij niet.

Wat @kaasboer09 hierboven zegt, een hardware token vind ik zelf nog het beste maar dan wel in combinatie met een (sterk) wachtwoord. Dan heb je het beste van 2 werelden.

Het tegen mijn zin drukken van de vinger op de scanner is legaal (als de politie dit doet) en dat zint mij niet.

Telefoon unlocken en inloggen bij een website zijn twee verschillende dingen..

Nou... ik heb een bank app (niet Nederlands) waarmee ik met mijn vinger kan inloggen.

Dus als de politie wil en mag, kan de politie mijn vinger op de scanner van de telefoon leggen en zo inloggen in mijn bank-app.
Terwijl ze géén geweld mogen gebruiken of dreigen om mijn wachtwoord / pincode te ontfutselen.

Politie zal het misschien niet meer mogen, maar criminelen/overvallers zullen niet zo snel 'regeltjes' volgen die zijn opgelegd. Als je straks met 1 vingerprint werkelijk iemands hele 'internet bestaan' kan openen, zal ik niet zo 123 jou pakken, maar iemand invloedrijk genoeg.. mwah, laten we zeggen dat zulke methodes al eens gebruikt zijn

Ben ik nu gek of bestaat dit gewoon al vrij lang? Wellicht dat de implementatie nu versimpeld is, maar ik heb al vrij lang verschillende apps in gebruik waarmee ik in kan loggen met mijn vingerafdruk (of een gebruikersnaam/wachtwoord).

En wat betreft één locatie voor al je credentials; daar bestaan toch password managers (e.g. Bitwarden) voor? Ik zie om eerlijk te zijn niet heel veel "nieuws" in hetgeen waar ze aan werken.

Maar dan moet je op die betreffende pc waar je wellicht eenmalig op in wil loggen, wel een password manager hebben staan.

Maar voor al die apps heb je wel een username/wachtwoord. Wat ze volgens mij willen is in de toekomst enkel een vingerafdruk (en?).

Wat ik mij nou ook nog wel afvraag is welke informatie dan tusen de App en de Credential App worden uitgewisseld.
Naast de gegevens die de apps al zo uit de telefoon beschikbaar zijn vanwege de toestemmingen die je moet geven.
Kan de App terug halen welke mogelijkheden er allemaal zijn "Welke accounts je hebt" zou daar dan weer een profiel over gemaakt kunnen worden.
Daarnaast zou ik ook zeggen dat op het moment dat er iets mis is met de Credential App alle accounts die daaraan gekoppeld zijn gelekt kunnen worden.

Ik begrijp wel dat het inloggen hier makkelijker door word gemaakt.
Maar ik dacht dat we juist bezig waren het moeilijker te maken en niet meer met 1 factor in te loggen.

Maar dit is toch gewoon onderdeel van het plan naar Passkey? Wachtwoordloos inloggen maar met vinger afdruk.

Username/password is inderdaad behoorlijk achterhaald!
Zelf vind ik een manier als die van Digi-ID (nee, niet te verwarren met DigiD) wel een aardige.
Zie: https://www.digi-id.io/
Deze video op Youtube legt het ook goed en simpel uit: https://youtu.be/pLrQycud5GI

Geen username/password meer onthouden, enkel een QR code scannen vanuit je DigiByte wallet (blockchain technologie) et voila.

Wat biedt Digi-ID als meerwaarde t.o.v. WebAuthn, behalve "blockchain"?

Ik vermoed het feit dat je de sleutel kunt back-uppen (is een risico wat vaak wordt vergeten bij 2FA) en dat je met QR-codes werkt in plaats van lokale hardware tokens. Daarmee werkt multi-device zonder dedicated sync server.

Behalve dat de beschikbaarheid van die login natuurlijk afhankelijk is van hoeveel mensen de onderliggende cryptomunt gebruiken/verkopen want anders is zo'n blockchain natuurlijk heel duur.

Deze service is helaas enorm phishbaar vergeleken met andere wachtwoordloze methodes (iemand kan zomaar een valse QR-code tonen en op iedere willekeurige site inloggen!). Dit is effectief gewoon public key auth met blockchain als achterliggend netwerk tussen client en sleutelsysteem, met veel conceptuele nadelen van een certificaat in je browser inladen zoals al twintig jaar kan.

Ook weet ik niet of grootschalige adoptie veel kans heeft op een blockchain waarvan het netwerk 1000 transacties per seconde aan kan (in totaal dus). Nu kijken alleen blockchainfans er wat om te geven en dat is nogal een niche, ik betwijfel ten zeerste dat het schaalt.

Ik zie het voordeel van decentrale authenticate boven federated authenticatie zoals FIDO2 dit doet, maar ik denk niet dat dit hem voor mij wordt helaas.

FIDO is niet federated - je registreert een unieke public key per service. Eventuele federation/SSO die je na een WebAuthn authenticatie doet staat er los van.

Ik vind zelf van wel; je hebt één account bij welke service dan ook en kan daarmee inloggen op bijna elke service. Er zit geen sync tussen IdP-services, maar dat is niet hoe je het hoofdzakelijk gebruikt.

OpenID werd wijd gezien als federated, dan zou ik argumenteren dat dat met FIDO2 ook zo is. Momenteel zijn de enige partijen die FIDO2 aanbieden de grote browsermakers, maar ieder bedrijf kan daar een service voor opzetten als ze willen, de standaard heeft geen whitelist o.i.d.

Je verwart een account/user identity met een public key. Er is geen "één account", je hebt bij elke service unieke accounts en bij een account horen een of meerdere public keys. Een service weet niet of de bijbehorende private key(s) in een Yubikey, een password manager* of in mijn Macbook secure enclave is opgeslagen** of op andere wijze 'bij elkaar horen' (zie privacy considerations). Aangezien deze keuze bij de eindgebruiker ligt lijkt me dat decentraal te noemen

Een keypair voor service-a.com kan niet worden gebruikt voor service-b.com (ivm bescherming tegen phishing) dus daar is federatie met FIDO alleen mee onmogelijk. Natuurlijk kan je wel inloggen bij je identity provider met FIDO die je daarna toegang geeft tot andere diensten met OAuth/SAML, maar dat zijn twee verschillende problemen die worden opgelost met compleet losstaande protocollen.

*: oa 1Password en BitWarden hebben support aangekondigd
**: tenzij er attestation wordt gevraagd, maar dat is niet gangbaar en zelfs als het wordt gebruikt is het beperkt tot informatie over productiebatches en niet herleidbaar tot individuele authenticators

Momenteel zijn de enige partijen die FIDO2 aanbieden de grote browsermakers, maar ieder bedrijf kan daar een service voor opzetten als ze willen, de standaard heeft geen whitelist o.i.d.

Deze snap ik eerlijk gezegd niet helemaal - FIDO2 is een breed begrip, maar een rondje om de kerk bij partijen als Okta en Stytch zie je dat ze het ondersteunen en het niet alleen bijv Google of Microsoft zijn. Kijk op https://github.com/herrjemand/awesome-webauthn voor open source, ik weet uit eigen ervaring dat de Ruby library op die lijst wordt gebruikt door GitHub, Shopify en login.gov.

Maar goed, het feit dat je de link naar de site en een YouTube-video moet toevoegen geeft al aan wat het probleem aan dit soort oplossingen is: adoptie.

Als niemand het kent, gaat ook niemand het gebruiken en wordt het dus niet geïmplementeerd en kent dus ook niemand het...

Bovendien is het me niet meteen duidelijk, maar zit hier nu ook een of andere crypto-currency of platform achter? Dat zou voor mij al helemaal een red-flag zijn.

Klopt; adoptie is key!

Vwb je laatste vraag: Nee, Digi-ID gebruikt puur de DigiByte blockchain (eentje die al 9 jaar bestaat, dus al een staat van dienst heeft) technologie.DigiByte heeft dan wel een eigen token (DGB), maar staat hier verder los van.
Meer info over de DigiByte blockchain: https://learn.bybit.com/blockchain/what-is-digibyte-dgb/

Maar dan zit er toch een crypto-platform achter? Ik zie niet in waarom het bieden van deze dienst een blockchain vereist, dus dan ben ik al snel wantrouwend aangezien het vaker wel dan niet een hoog gimmick gehalte krijgt.

Al je wachtwoorden in handen van het grootste marketingbedrijf ter wereld. What could possibly go wrong.

Niks natuurlijk maar je koelkast staat in eens wel altijd magisch vol. Je bankrekening is steeds maar leeg.

dit is wel weer geent op Android dus een "app"
Maar wat als ik dus die app ook als website gebruik in mijn browser?

De huidige wachtwoord managers weten dat, en slaan dat op bij de entry (zeg maar deze username/pw combinatie is voor domain X maar ook voor App Y )