Formuläret har skickats in framgångsrikt.
Ytterligare information finns i din brevlåda.
Anlita oss
Om oss
TjänsterTeknikBranscherPortfölj
Du har förmodligen sett det själv: mata GPT med en selfie, be om ett passliknande dokument, och inom några minuter får du något som kan komma förbi grundläggande visuella kontroller. Lägg till röstkloning och syntetisk video, och “liveness” börjar se ut som teater. Det är den verkliga brytningen i digital identitet i 2026. Den fotobaserade KYC-modellen i sig är utsliten. Om identitetsbevis fortfarande är beroende av att bilder är svåra att förfalska bygger man på sand.
Så var står vi då? Med ett ganska uppenbart skifte: bort från lagring av identitetsdata och mot att verifiera påståenden kryptografiskt. Istället för att samla in en passskanning och parkera den i en annan databas ber systemet om bevis: är du över 18 år, har du klarat KYC, är du godkänd för den här transaktionen, och Kan du bevisa det utan att avslöja något annat?
Men vad är det egentligen som förändras? Varför pratar vi plötsligt om DID och verifierbara referenser?
För i en DID-baserad modell beror förtroendet inte på hur något ser ut. Det kommer från vem som har signerat det och om du kan bevisa kontroll över det. En deepfake-selfie hjälper inte om verifieraren förväntar sig en referens som är signerad av en betrodd utfärdare och bunden till dina kryptografiska nycklar. Du försöker inte längre “se äkta ut”. Du bevisar innehav av ett giltigt, signerat anspråk. Bilder slutar vara källan till förtroende. Signaturer tar över.
Och det är poängen med den här guiden: Jag ska visa hur den modellen fungerar, varför den håller på att bli den seriösa vägen framåt och var blockchain passar in i den.
En decentraliserad identifierare, eller DID, är en URI-baserad identifierare som är utformad för att kontrolleras genom kryptografiska nycklar snarare än att utfärdas och hanteras av en central katalog. Under World Wide Web-konsortiet (W3C) Enligt DID-standarden löser ett DID upp till ett DID-dokument som informerar andra system om hur de ska verifiera signaturer, autentisera den personuppgiftsansvarige eller upptäcka serviceendpoints som är kopplade till identifieraren. I klartext: en DID är inte din profil, ditt pass eller din kontopost. Det är den pekare som andra parter använder för att verifiera att du kontrollerar en specifik identifierare och nycklarna bakom den.
Det är här som folk ofta plattar till allt till “bara ett nytt ID”. Det är det inte.
En e-postadress är egentligen en lokalisering i någon annans system. Om leverantören stänger av kontot är identifieraren i praktiken borta. Ett SSN är en statligt utfärdad identifierare, men den har inget inbyggt kryptografiskt bevislager; vem som helst som får numret kan spela upp det igen. OAuth-tokens är annorlunda igen: de är inte identitetsidentifierare alls, utan delegerade åtkomstartefakter som utfärdas av en auktoriseringsserver så att en klient kan anropa en skyddad resurs. Användbart, ja. Portabelt identitetslager, nej.
En DID fungerar på ett annat sätt. Det ska lösas, inte bara sökas upp i en leverantörsdatabas. Kontrollen ligger hos ämnet genom nyckelmaterial och reglerna för DID-metoden, inte hos en e-postleverantör, SaaS-plattform eller identitetsmäklare. Den skillnaden är viktig i praktiken. Om du bygger återanvändbara referenser, plånboksbaserad inloggning eller verifieringsflöden som ska fungera över organisationsgränser, kommer ett e-postmeddelande eller appspecifikt användar-ID inte att ha tillräckligt med förtroende semantik. En DID kan göra det.
På syntaxnivå är W3C-modellen enkel: en DID har tre delar: DID-schema, ett metodnamn och en metodspecifik identifierare. Med andra ord did:metod:identifierare.
Ta gjorde:web:exempel.com som ett konkret exempel.
Med gjorde:webb, I en sådan domän mappar upplösningen vanligtvis till ett DID-dokument som publiceras på en välkänd HTTPS-plats på den domänen. Med något som gjorde:ethr, beror lösningen på Ethereum-länkade metodregler. Samma DID-syntax, olika förtroende- och uppdateringsmodell.
Det är den viktigaste punkten: DID-strängen i sig är bara handtaget. Metoden talar om för dig hur du ska lösa det. DID-dokumentet ger dig verifieringsmaterialet. När du har fått det kan du verifiera signaturer, autentisera en innehavare eller validera en legitimationspresentation utan att behandla identifieraren som bara ytterligare en rad i någons användartabell.
Hittills har vi tittat på DID:er och verifierbara referenser som datastrukturer: identifierare, dokument, signaturer. Men det är bara en del av ett fungerande identitetssystem. I verkliga implementeringar är det svårare problemet interaktion: hur referenser utfärdas, hur de presenteras och hur verifierare beslutar om de ska lita på dem.
I produktionssystem som t.ex. EU:s plånbok för digital identitet eller Amerikanskt mobilt körkort (mDL) piloter, plånböcker och verifierare inte bara “löser en DID” och stannar där. De kommunicerar genom definierade protokoll och referensformat:
Den viktiga skillnaden är att DID och verifierbara referenser definierar vad verifieras. Dessa protokoll definierar hur den rör sig mellan utfärdaren, innehavaren och kontrollören i verkliga system.
Utan detta lager förblir DID:er en lösningsmekanism. Med det blir de en del av en fungerande identitetsinfrastruktur.
Decentraliserad identitet är en modell där identifierare, referenser och verifieringsflöden inte styrs av en enda leverantör. Istället är identiteten förankrad i kryptografiska nycklar (via DID:er), och påståenden om identiteten utfärdas och verifieras oberoende av var de används. Ett användbart sätt att tänka på det: identiteten slutar att vara ett konto som lagras i någon annans databas och blir en uppsättning verifierbara uttalanden som du kontrollerar och återanvänder.
Låt oss bryta ner det mot de modeller som du redan arbetar med.
Centraliserad identitet är fortfarande standard överallt. En plattform äger användarregistret, lagrar dina data och fungerar som myndighet för verifiering. Om du vill ha åtkomst autentiserar du dig mot det systemet. Allt, inklusive inloggning, behörigheter och återställning, går via det.
Problemet är inte bara säkerhet (även om intrång är ett ständigt återkommande problem). Det är arkitektur:
Decentraliserad identitet vänder på detta. Systemet behöver inte lagra dina uppgifter. Det behöver bara verifiera de påståenden du presenterar. Förtroendet skiftar från “vi har dina uppgifter” till “vi kan verifiera det här kryptografiska beviset”.”
Federerad identitet (OAuth, SAML, OpenID Connect) försökte lösa fragmenteringen genom att införa identitetsleverantörer, som Google, Microsoft eller Apple, som går i god för användare i olika tjänster.
Det fungerar, upp till en viss punkt. Men federerad identitet har fortfarande ett centralt beroende:
Decentraliserad identitet tar bort det beroendet. Det finns ingen enskild utfärdare som måste vara online vid verifieringstillfället. Legitimationer verifieras via signaturer, inte API-anrop. Det innebär att
Det är närmare hur fysiska referenser fungerar: du ringer inte till passkontoret varje gång någon kontrollerar ditt ID.
Dessa termer blandas ofta ihop. SSI är mer av en designfilosofi: individen kontrollerar sin identitet, väljer vad som ska delas och är inte låst till en leverantör. Decentraliserad identitet är den tekniska stack som gör det möjligt:
Du kan implementera decentraliserade identitetssystem som inte är helt “självsuveräna” (t.ex. företagskontrollerade plånböcker eller nätverk med tillstånd). Och man kan prata om SSI utan att specificera infrastrukturen. I verkliga system konvergerar de två vanligtvis, men det är bra att hålla distinktionen tydlig när du utformar arkitekturer.
Plånböcker är där decentraliserad identitet möter verkliga begränsningar. I teorin kommer kontrollen över identiteten från kontrollen av kryptografiska nycklar. I praktiken skapar det ett problem som traditionella system inte har: Vad händer när användaren förlorar åtkomst?
Om en DID är knuten till en privat nyckel och den nyckeln går förlorad finns det ingen standardåterställningsmekanism. Det finns inget “återställ lösenord”-flöde om inte systemet uttryckligen är utformat för att stödja det. Förlust av nyckeln kan innebära förlust av kontrollen över identifieraren och de referenser som är knutna till den.
Det är därför produktionssystem inför modeller för återvinning och förvaring ovanpå DID-lagret:
Avvägningen är oundviklig: ju mer kontroll som flyttas till användaren, desto mer ansvar flyttas till nyckelhanteringen. Det är därför de flesta verkliga implementeringar balanserar självsuveränitet med användbarhet istället för att skjuta över hela nyckelägandet helt på användaren.
Det är värt att pausa här, eftersom DID-baserad identitet bara verkligen klickar när du separerar dess kärnprimitiv. Identifieraren är inte referensen, referensen är inte plånboken, och markören på kedjan är inte själva identiteten. Varje lager har en distinkt funktion, och den separationen är det som gör att modellen fungerar.
Dessa två komponenter utgör kärnan i den decentraliserade identitetsmodellen. I vissa system, särskilt i Web3-miljöer, används ytterligare mekanismer i kedjan för att genomdriva åtkomst eller roller.
Själsbundna polletter (SBT) är ett exempel. De är icke-överförbara tokens som är knutna till en plånbok och används för saker som KYC-gating, ackreditering eller protokollbehörigheter. Smarta kontrakt kan kontrollera dem direkt.
SBT:er är dock inte en del av själva identitetsstacken. De är ett valfritt verkställighetslager som byggs ovanpå identitetssignaler, och de kommer med kompromisser: offentlig synlighet på kedjan, begränsad portabilitet och utmaningar kring återkallande och nyckelåterställning.
Traditionella identitetssystem misslyckas eftersom de behandlar förtroende som ett lagringsproblem. Varje plattform samlar in samma råa bevis, till exempel passskanningar, selfies och adressbevis, och lagrar dem sedan inom sin egen efterlevnadsperimeter. Det skapar samma röra överallt: duplicerad PII, svag portabilitet, breda intrångsytor och onboardingflöden som blir tyngre utan att bli mycket bättre.
I den traditionella modellen ackumulerar identitetssystem risk över tid. Leverantörer av kundkännedomssystem, börser, fintech-appar, HR-plattformar och marknadsplatser lagrar alla ungefär samma bevisuppsättning: myndighets-ID, ansiktsscanning, adressuppgifter och metadata från själva verifieringssessionen.
Ur implementeringssynpunkt förvärras problemet vanligtvis av kopieringsspridning. Samma användardata hamnar i onboardingsystem, bedrägeriverktyg, CRM-lager, supportverktyg, datalager och efterlevnadsarkiv. Även om den primära verifieringsstacken är låst, hålls de omgivande systemen ofta inte till samma standard.
Traditionell identitet ger användaren nästan ingen kontroll över verifieringstillståndet. Plattformen kontrollerar registret, lagringspolicyn, schemat för omverifiering och reglerna för återanvändning.
Det innebär att användaren inte kan föra över förtroendet från ett sammanhang till ett annat. Att klara kundkännedom på plattform A gör ingenting på plattform B eftersom verifieringsresultatet är fångat inom plattform A:s efterlevnadsperimeter. Det underliggande påståendet kan fortfarande vara giltigt, men det finns ingen portabel kryptografisk artefakt som nästa verifierare kan förlita sig på.
Det är här som modellen börjar gå sönder ekonomiskt. Varje plattform betalar för att återuppbygga förtroendet från grunden eftersom identiteten lagras som intern data och inte utfärdas som återanvändbara bevis.
Den äldre modellen avslöjar också för mycket som standard. För att bevisa ett smalt faktum ombeds användarna vanligtvis att avslöja hela källdokumentet bakom det.
Det är ett dåligt integritetsmönster, men det är också ett dåligt systemmönster. När identiteten är knuten till kontobaserade register och upprepade dokumentinlämningar blir det enkelt att korrelera mellan olika tjänster, sessioner och motparter. Kontrollören får mer data än den behöver, lagrar mer än den borde och ökar ansvaret utan att förbättra förtroendekvaliteten proportionellt.
Detta är den operativa skatt som alla redan känner till. Samma person slutför KYC om och om igen eftersom varje plattform kör sin egen förtroendestack och inte kan konsumera verifiering som en bärbar referens.
Om du har arbetat med tokenisering, onboarding av börser eller reglerade plånboksflöden har du sett hur slösaktigt detta blir. Flaskhalsen är det faktum att förtroende inte kan flyttas rent mellan system, så varje institution bygger om samma verifieringspipeline runt sin egen databasgräns.
Och även verifierbara referenser fixar inte det i sig. En giltig signatur bevisar bara att ett anspråk utfärdades av en viss part. Det bevisar inte att denna part hade befogenhet att utfärda det kravet. Det är den del som många DID-piloter underskattar. Verifierare måste veta vilka utfärdare som är legitima, vilka referensscheman som accepteras och enligt vilka regler ett påstående kan åberopas.
I produktion hanteras detta genom tillitsramverk: eIDAS 2.0 förtroendelistor i EU, VICAL-stil förtroendekoordinering för mobila körkort enligt ISO 18013-5, OpenID Federation förtroendekedjor och nationella register över tillhandahållare av betrodda tjänster.
Utan det lagret får du ingen återanvändbar identitet. Du får referenser som verifieras matematiskt men som inte betyder något operationellt. Signaturen är giltig. Förtroendet saknas.
"Varför fungerar den decentraliserade identitetsmodellen? För att den ger varje part mindre att lagra, mindre att exponera och mindre att kontrollera igen. Användaren återanvänder pålitligt bevis, verifieraren får bara det påstående den behöver och plattformen undviker att bli ett annat PII-valv. På Innowise betyder det vanligtvis referenser utanför kedjan för portabilitet, intyg på kedjan för åtkomstkontroll och selektivt avslöjande för integritetskänsliga kontroller."
Blockchain-expert och DeFi-analytiker
Nog med definitioner. Det som är viktigt här är verifieringsvägen: hur en DID blir lösbar, hur en utfärdare binder ett anspråk till den och hur det anspråket kontrolleras senare utan att falla tillbaka på ett centralt register. Låt oss gå igenom flödet från början till slut.
En DID blir användbar först när den kan lösas. Den genereras med nyckelmaterial och publiceras enligt en DID-metod. Upplösning returnerar DID-dokumentet, som avslöjar de publika nycklar och verifieringsmetoder som andra använder för att validera signaturer.
När ämnet har en DID kan en utfärdare koppla ett signerat anspråk till den som en verifierbar referens. Utfärdaren gör först sina kontroller och signerar sedan en referens som binder påståendet till ämnesidentifieraren. Det som rör sig framåt är inte råa bevis, utan ett attesterat resultat.
Innehavaren förvarar legitimationen, vanligtvis i en plånbok, och visar upp den när bevis behövs. Beroende på stacken kan det vara den fullständiga referensen eller ett härlett bevis. Poängen är återanvändning: innehavaren presenterar ett redan verifierat anspråk istället för att starta om onboarding.
Verifieraren kontrollerar utfärdarens signatur, bekräftar ämnesbindningen och utvärderar legitimationsstatus, t.ex. utgång eller återkallelse. För att göra det löser den upp utfärdarens DID och hämtar den offentliga nyckeln från DID-dokumentet. Ingen återuppringning av utfärdaren krävs.
En DID blir användbar först när den kan lösas. Den genereras med nyckelmaterial och publiceras enligt en DID-metod. Upplösning returnerar DID-dokumentet, som avslöjar de publika nycklar och verifieringsmetoder som andra använder för att validera signaturer.
När ämnet har en DID kan en utfärdare koppla ett signerat anspråk till den som en verifierbar referens. Utfärdaren gör först sina kontroller och signerar sedan en referens som binder påståendet till ämnesidentifieraren. Det som rör sig framåt är inte råa bevis, utan ett attesterat resultat.
Innehavaren förvarar legitimationen, vanligtvis i en plånbok, och visar upp den när bevis behövs. Beroende på stacken kan det vara den fullständiga referensen eller ett härlett bevis. Poängen är återanvändning: innehavaren presenterar ett redan verifierat anspråk istället för att starta om onboarding.
Verifieraren kontrollerar utfärdarens signatur, bekräftar ämnesbindningen och utvärderar legitimationsstatus, t.ex. utgång eller återkallelse. För att göra det löser den upp utfärdarens DID och hämtar den offentliga nyckeln från DID-dokumentet. Ingen återuppringning av utfärdaren krävs.
När flödet är klart dyker de verkliga designfrågorna upp: hur identifierare används och hur nycklar hanteras över tid.
En offentlig DID är stabil och upptäckbar. Utfärdare använder det vanligtvis eftersom verifierare behöver ett konsekvent sätt att lösa nycklar och validera signaturer. En parvis DID, å andra sidan, genereras per relation. Samma användare presenterar olika identifierare för olika kontrollanter, vilket förhindrar korrelation mellan olika tjänster.
Det valet är inte kosmetiskt. Att återanvända en enda DID mellan olika tjänster gör kopplingen trivial. Parvisa DID:n bryter den kopplingen på identifierarnivå.
Sedan har vi nyckelhanteringen, och det är där de flesta system har problem i produktionen. En DID är bara så tillförlitlig som nycklarna bakom den, så du måste planera för:
I praktiken är det här komplexiteten finns. Verifiering av signaturer är enkelt. Att hålla identifierare användbara, återställbara och icke-korrelerbara över tid är det svårare tekniska problemet.
När man väl har kommit förbi flödet är nästa fråga hur identifierare faktiskt löses och underhålls. Det handlar om två saker: den DID-dokumentets struktur och den DID-metoden som definierar hur den skapas, uppdateras och löses.
Ett DID-dokument är upplösningsresultatet för en DID. Det talar om för verifierare vilka nycklar, styrenheter och tjänsteändpunkter som är auktoriserade för den identifieraren. I praktiken är det inte en användarprofil. Det är en verifieringsdeskriptor.
Kärnområden som du vanligtvis bryr dig om:
Och punkten för nyckelimplementering förblir densamma: en verifierare löser DID, väljer lämplig verifieringsmetod och kontrollerar om den nyckeln är auktoriserad för den åtgärd som utförs.
Hittills har vi mest talat om identitet som något som en person kontrollerar. I B2B-system är nyckelpersonen ofta en organisation. Banker, logistikleverantörer och RWA-plattformar måste verifiera inte bara som undertecknat något, utan om den personen var behörig att agera för ett företag.
Det är här som organisatoriska DID:ar blir mer komplexa. Kontrollen fördelas över roller, förvaringssystem, signeringspolicyer och delegeringsregler. I en produktionskonfiguration måste man definiera vem som kan signera, vad de kan signera och hur denna behörighet återkallas.
I praktiken kan detta innebära vLEI från GLEIF för identifiering av juridiska personer, företagsplånböcker med HSM-backad signering, och kedjor av behörighetsfunktioner, t.ex. ZCAP-LD.
DID-dokument är inte statiska. Nycklar går ut, enheter försvinner, infrastruktur för signering ändras och utfärdarens nycklar behöver roteras. En seriös DID-design måste hantera detta utan att bryta befintliga referenser.
Nyckelrotation innebär vanligtvis att en ny verifieringsmetod läggs till, att den nyckel som är behörig för en viss relation ändras och att den gamla nyckeln dras in. Men den detalj som är viktig är syfte. Vridning av en autentisering påverkar inloggnings- eller utmaningsflöden. Att rotera en assertionMetod nyckel påverkar utfärdande och verifiering av referenser.
Uppdateringsvägen beror på DID-metoden. Med gjorde:webb, uppdaterar du det hostade DID-dokumentet. Med gjorde:ethr, publicerar du en transaktion i registret. Den svåra delen är kontinuitet: verifierare måste veta vilken nyckel som var giltig när en referens utfärdades och om denna referens sedan dess har återkallats, löpt ut eller ersatts.
Och det för oss till DID-metoderna, eftersom metoden definierar exakt hur skapande, upplösning, uppdateringar och avaktivering fungerar i det verkliga systemet.
En DID-metod är implementeringslagret bakom den standardiserade DID-syntaxen.
Den definierar reglerna för:
Med andra ord, DID-syntaxen är standard (did:metod:identifierare), men metoden formar hela infrastrukturmodellen bakom DID.
Dessa tre metoder täcker de flesta verkliga användningsfall:
Nu ger tabellen dig mekaniken. Den svårare delen är att bestämma vilket felläge du kan leva med: DNS-beroende, kedjekostnad, ingen rotation, offentlig granskningsbarhet eller svagare portabilitet. Så här är min uppfattning om hur man väljer.
Innan du väljer ska du ställa de fula produktionsfrågorna:
I verkliga implementeringar blandar du vanligtvis metoder. Utfärdare använder ofta gjorde:webb eller gjorde:ethr; Innehavare använder parvisa eller efemära identifierare. Denna uppdelning håller förtroendet för utfärdaren stabilt samtidigt som den minskar korrelationsrisken för användarna.
Låt oss klargöra det här tidigt: du behöver inte en blockchain för att implementera decentraliserad identitet. World Wide Web Consortium DID Core-specifikationen kräver inte det, och många produktionssystem körs helt utanför kedjan.
Så varför är blockchain ens i konversationen? För att det löser ett specifikt problem riktigt bra: delad tillit utan en central ägare. Inte lagring, inte identitet i sig, utan samordning kring nycklar, identifierare och status.
I DID-baserade system fungerar blockchain som en offentligt, manipuleringssäkert register. Beroende på metod kan den användas för att:
Den viktigaste punkten: blockkedjan verifierar inte identitet. Den tillhandahåller en gemensam referenspunkt som verifierare kan förlita sig på utan att lita på en enda part.
Till exempel med gjorde:ethr, När DID:en är klar, löser DID:en upp mot data i kedjan. Verifieraren litar på kedjans tillstånd, inte på emittentens infrastruktur.
Det är här många DID-implementeringar går fel. Blockchain är användbart för delad stat, men det är en fruktansvärd plats för rå identitetsdata. Du lägger inte pass, biometri, fullständiga referenser eller personliga register på kedjan. Du använder kedjan för bevismaterial och samordningsdata, och håller sedan känsliga identitetsnyttolaster utanför kedjan.
En ren split ser vanligtvis ut så här:
På kedjan:
Utanför kedjan:
Anledningen är enkel: integritet och kostnad. Blockkedjor är offentliga, permanenta och kostsamma att uppdatera. Identitetsdata behöver integritet, radering, korrigering och åtkomstkontroll. Dessa två går inte att kombinera.
Blockchain används vanligtvis för förankring, inte lagring. Du överför ett litet bevis på tillstånd till kedjan, till exempel en DID-dokumenthash, uppdatering av utfärdarregistret, referens till legitimationsstatus eller nyckelrotationshändelse, medan de faktiska identitetsuppgifterna förblir utanför kedjan.
Detta ger verifierare tre användbara egenskaper:
Kompromissen är permanens. Om du lägger in fel data i kedjan kan du inte ta bort dem på ett enkelt sätt. Det är därför mogna DID-system förankrar hashar, referenser och tillståndsövergångar, inte fullständiga referenser, dokument eller personuppgifter.
Blockchain är fel verktyg när det inte tar bort ett förtroendeberoende. Om samma organisation kontrollerar utfärdaren, verifieraren och applikationen innebär det oftast bara avgifter, fördröjningar och driftstörningar att lägga DID-status på kedjan.
Hoppa över blockchain när:
Det är därför gjorde:webb fungerar så bra för många företags identitetsflöden. Den behåller DID-modellen, men använder befintlig webbinfrastruktur istället för att tvinga varje uppdatering genom en blockchain-transaktion.
Använd blockchain när oberoende parter behöver ett delat tillstånd som de kan verifiera utan att lita på din server. Annars ska du hålla det utanför kedjan. Mer decentralisering på papperet innebär inte automatiskt en bättre identitetsarkitektur.
I system som EU:s digitala identitetsplånbok eller mobila körkort (ISO 18013-5) valdes PKI främst för att offentliga L1/L2-nätverk inte uppfyller de viktigaste identitetskraven: integritet, datasuveränitet och myndighetskontroll. Identitetsdata kan inte replikeras offentligt, och jurisdiktioner behöver strikt kontroll över var data behandlas och lagras.
Men nyare arkitekturer introducerar ett tredje alternativ: Tillåtna zk-L2-system. Dessa kombineras:
Den viktigaste idén är att separera problem på infrastrukturnivå:
På så sätt undviks en av de största begränsningarna med offentliga kedjor, nämligen att data exponeras. Samtidigt undviker man en begränsning hos ren PKI: beroendet av slutna förtroendehierarkier utan delad granskningsbarhet.
En annan viktig egenskap är arkitektur med flera domäner. Olika aktörer - ministerier, tillsynsmyndigheter, banker eller regioner - kan verka i separata exekveringszoner med egna gränser för efterlevnad, samtidigt som de bidrar till ett gemensamt verifierbart tillstånd genom bevis.
Detta utökar designutrymmet för identitetssystem. Istället för att välja mellan centraliserad PKI och publik blockkedja kan nya implementeringar kombinera integritet, efterlevnad och delat förtroende i en enda modell.
Okej, så vid det här laget borde det vara tydligt vad DIDs gör annorlunda än standard KYC. Men den mer praktiska frågan är: vad innebär det egentligen för mig? Rättvis fråga. Enligt vad jag har sett i verkliga implementeringar beror effekterna mycket på vilken sida du är på, så det är värt att bryta ner det.
För användarna innebär den största förändringen kontroll över när och hur identiteten delas.
I praktiken innebär det att identiteten inte längre är något du ständigt skickar in på nytt, utan något du närvarande när det behövs.
För organisationer handlar förändringen mindre om UX och mer om risk- och kostnadsstruktur.
Det som förändras operativt är följande: du slutar vara en datavärd och börjar vara en verifiering av anspråk.
För utvecklare ligger värdet i hur identitetslogiken är uppbyggd.
Ur teknisk synvinkel är skiftet från “hantera användare och sessioner” till verifiering av bevis och upprätthållande av villkor.
Låt oss släppa teorin för en stund och bara gå igenom det här som vi skulle göra i ett riktigt system. Vad innebär DID egentligen känna sig som i praktiken? Var slutar det att vara ett diagram och börjar bli något som du skulle skicka?
Du kommer att märka något under resans gång: objekten förändras - examensbevis, jobbhistorik, KYC-status - men flödet gör det knappt.
Säg att du precis har tagit examen och behöver bevisa din examen för en framtida arbetsgivare. Den vanliga vägen är klumpig: ladda upp en PDF, bifoga en skanning, kanske vänta medan någon mejlar registrator. Det fungerar, men knappt. Hela processen är beroende av manuell tillit.
Med en DID-baserad legitimation utfärdar universitetet en verifierbar legitimation när du tar examen. Den ligger i din plånbok och är signerad av en nyckel som är publicerad i universitetets DID-dokument.
Några månader senare söker du ett jobb. Arbetsgivaren behöver inte kontakta universitetet. Du visar upp dina referenser och deras system kontrollerar:
Det är det som är det fina med modellen: universitetet signerar en gång, du återanvänder beviset och varje verifierare kan kontrollera det oberoende.
Hur mycket av ett CV litar du egentligen på? Titlar blir uppblåsta. Datum blir luddiga. “Leda ett team” kan betyda allt från att leda tio personer till att hålla i standups.
Nu vänder vi på modellen. När du lämnar ett företag får du en legitimation:
Nästa gång någon frågar “Kan du bevisa att du har gjort X?” förklarar du inte. Du presenterar. Och nej, det betyder inte att du måste visa upp hela din arbetshistoria varje gång. Med rätt referensformat kan innehavaren bevisa ett smalare påstående, som t.ex:
...utan att lämna över hela anställningshistoriken. Det är en helt annan hållning än “skicka oss hela ditt CV och dina referenser”.”
Här blir återanvändbar identitet uppenbar. Du verifierar dig en gång hos en betrodd leverantör: pass kontrolleras, sanktionsgranskning godkänns, jurisdiktion bekräftas. Leverantören utfärdar en KYC-referens till din plånbok.
Nästa plattform? Du visar upp dina referenser istället för att ladda upp samma dokument igen. Plattformen kontrollerar:
Vissa tokeniseringsteam använder också själsbundna polletter som KYC-markörer på kedjan: den här adressen klarade den nödvändiga kontrollen. Identitetsuppgifterna stannar utanför kedjan; kedjan bär bara på behörighetssignalen.
Användbart, men bara om markeringen är bred, återkallelig och inte innebär en permanent integritetsläcka.
Hälso- och sjukvård är ett område där DID-arkitekturen behöver hållas i kort koppel. Säg att en klinik ger dig ett vaccinationsbevis, ett laboratorium signerar ditt blodprovsresultat och din läkare utfärdar ett receptbevis. Du har dem i din plånbok istället för att låta varje post försvinna in i en annan portal.
Sedan byter du läkare. Väntar du på att ett system ska prata med ett annat? Jaga PDF-filer? Nej. Du delar med dig av den specifika legitimation som den nya vårdgivaren behöver. De verifierar utfärdaren, signaturen och statusen.
Och bara för att vara tydlig: inget av detta kräver att medicinska data läggs på kedjan. Kedjan är till för identifierare, nycklar och kanske statusregister. De känsliga sakerna stannar utanför kedjan. Om den gränsen inte respekteras är designen trasig.
Låt oss nu gå bort från människor. Plocka upp en produkt - säg en flaska olivolja. Förstklassig etikett, fin förpackning. Är den äkta? Istället för att lita på varumärket trycker du med din telefon på en NFC-tagg. Bakom taggen finns en DID som är knuten till produktpartiet.
Det du får tillbaka är signerad data:
Du kan bokstavligen följa produkten från källa till hylla. Löser det allt? Nej. Om den första datainmatningen är felaktig kommer allt efterföljande bara att bevara felet. Men nu vet du i alla fall som signerat varje steg. Det är en stor uppgradering från “lita på oss”.”
Regeringen är där DID-style-identitet lämnar kryptobubblan. En viktig referenspunkt är EU:s digitala identitetsplånbok under eIDAS 2.0, ett storskaligt initiativ som syftar till att tillhandahålla plånböcker till medborgare, invånare och företag i alla medlemsstater.
Men det bredare landskapet är mer varierat. Några av de största och mest mogna digitala identitetssystemen globalt är inte strikt DID-baserade, men följer ändå liknande mönster kring återanvändbara referenser och innehavarkontrollerade data:
Den gemensamma förändringen i dessa system är densamma: att gå från centraliserade identitetsregister till återanvändbara bevis som presenteras av användaren. Samtidigt är det viktigt att skilja på olika förtroendemodeller. System som eIDAS förlitar sig på federerad PKI och listor över betrodda tjänster, medan DID-baserade system förlitar sig på kryptografiska identifierare och verifierbara referenser. I praktiken samexisterar dessa modeller ofta snarare än ersätter varandra.
Hittills har allt fungerat bra inom ett enda system. Men vad händer när referenser korsar systemgränser? Det är där saker och ting blir strikta. Du behöver delade standarder så att data är begripliga överallt, och du behöver styrning så att verifierare vet vilka utfärdare de ska lita på. Här är de standarder och styrningslager som betyder mest.
Standarder gör referenser interoperabla. Styrning gör dem acceptabla. Utan standarder kan ingenting analyseras. Utan styrning är ingenting pålitligt. Riktiga system fungerar bara när båda lagren definieras tillsammans.
Standarder berättar hur ett DID-system ska bete sig. Produktionen berättar var det blir rörigt. Idag kommer de flesta riskerna inte från DID-syntaxen eller signaturalgoritmerna själva. De dyker upp kring plånböcker, nyckelåterställning, återkallande, interoperabilitet och huruvida tillräckligt många utfärdare och verifierare faktiskt kommer överens om att använda samma förtroendemodell.
I DID-system är identiteten beroende av nyckelkontroll. Det är kraftfullt, men oförlåtande. Om en användare tappar bort nyckeln sker återställningen inte automatiskt. Om en angripare får tag på nyckeln kan han eller hon utge sig för att vara innehavaren. Det är därför seriösa implementeringar sällan förlitar sig på enbart en rå seed-fras. De behöver vanligtvis MPC, social återställning, hårdvarubackade nycklar eller någon hybridmodell för förvaring.
Legitimationer åldras. KYC upphör att gälla, anställda slutar, licenser dras in. Verifiering kan därför inte stanna vid “är signaturen giltig?” Verifieraren kontrollerar legitimationsstatusen vid användningstillfället. Det innebär vanligtvis statuslistor, återkallelseregister eller kortlivade referenser. Om man missar den här delen fortsätter gamla referenser att se giltiga ut.
Standarder hjälper, men de gör inte magiskt alla plånböcker, utfärdare och verifierare kompatibla. En stack kan använda JSON-LD-legitimationer, en annan kanske föredrar JWT. DID-metoder. Presentationsprotokoll skiljer sig åt. Så ja, ekosystemet rör sig mot interoperabilitet, men verkliga projekt behöver fortfarande integrationsarbete och strikta profilval.
Den svåraste delen är samordning. Ett DID-system behöver utgivare som folk litar på, verifierare som är villiga att acceptera referenser, användare som kan hantera plånböcker och styrningsregler som alla förstår. Tills dessa delar stämmer överens sker antagandet i fickor: reglerad finansiering, tokenisering, personalrekvisita, myndighets-ID och slutna ekosystem först.
De flesta DID-system förlitar sig idag på elliptisk kurvkryptografi: Ed25519, secp256k1 eller P-256. Dessa system används i stor utsträckning, men de är inte postkvantsäkra. En tillräckligt kraftfull kvantdator skulle kunna knäcka dem med Shors algoritm, vilket gör signaturförfalskning till en verklig risk på lång sikt.
Det är viktigt eftersom identitetsuppgifter ofta lever i flera år. Diplom, licenser och juridiska intyg som utfärdas idag kan fortfarande behöva verifieras långt efter att kryptografin bakom dem åldras.
Standarderna rör sig redan i den riktningen. NIST har färdigställt signaturscheman för postkvantum som ML-DSA (Dilithium) och SLH-DSA (SPHINCS+), medan DID/VC-ekosystemet utforskar hybridsignaturer och kryptomobilitet.
DID-system bör stödja flera verifieringsmetoder, nya signatursviter och tydliga nyckelrotationsvägar från dag ett. Post-kvantsignaturer är mycket större än Ed25519- eller ECDSA-signaturer, vilket påverkar QR-presentationer, register och statusmekanismer i kedjan. Men för långlivade identiteter för myndigheter och företag är kryptomobilitet ett måste.
Det misstag vi oftast ser är att man behandlar DID som något man “lägger till” i en befintlig identitetsstack. I praktiken handlar det om en förändring av hur man modellerar förtroende, dataflöde och ansvar. De tekniska bitarna är sällan den svåraste delen. De flesta projekt lyckas eller misslyckas på grund av samordning, styrning och integration.
Börja med att identifiera var du lagrar identitetsuppgifter för att sedan verifiera dem: KYC-status, ålder, anställning, licenser, ackreditering och åtkomsträttigheter. Målet är att lagra mindre rådata och verifiera fler signerade påståenden. Det minskar ansvaret, förenklar efterlevnaden och gör identiteten portabel mellan olika system.
Innan du väljer verktyg bör du definiera förtroendemodellen i konkreta termer. I verkliga projekt resulterar det vanligtvis i:
Utan detta får du referenser som verifieras korrekt men som inte accepteras av verifierare.
Välj nu den tekniska stacken. Välj DID-metod, referensformat, plånboksflöde och modell för återkallande. gjorde:webb passar vanligtvis företags- och SaaS-flöden. gjorde:ethr passar smarta kontrakt och identitet på kedjan. gjorde:nyckel passar kortlivade eller lokala identifierare.
Välj inte det mest “decentraliserade” alternativet. Välj det som matchar din förtroendegräns.
Börja inte med “identitet för allt”. Börja med ett flöde där smärtan är tydlig. Bra piloter inkluderar:
Begränsa det strikt: en typ av referens, en eller två utfärdare, ett verifieringsflöde, tydliga regler för återkallande. Undvik att börja med:
Bevisa flödet från början till slut och expandera sedan.
När man går från pilot till produktion är utfärdandet av referenser bara halva problemet. Den svårare frågan är vad som händer när en legitimation inte längre går att lita på: en KYC-kontroll går ut, en anställd slutar, en licens dras in eller en plånbok äventyras.
Det finns inte en enda standardmetod, och varje modell innebär avvägningar:
Olika ekosystem använder olika tillvägagångssätt. Mobila körkort enligt ISO 18013-5 förlitar sig t.ex. på validering av utfärdare och förtroendelistor snarare än återkallelse enligt W3C. Utan en tydlig strategi för återkallande bryts modellen med “återanvändbara referenser”. En äventyrad legitimation kan fortsätta att presenteras om inte dess status aktivt kontrolleras.
Ett typiskt DID/VC-projekt genomförs i faser. En pilot tar vanligtvis 3-4 månader och validerar ett användningsfall från början till slut, vanligtvis i intervallet $150K–$300K, beroende på omfattning. En produktionsutrullning tar 9-12 månader och utvidgas till flera olika utfärdare, verifierare och typer av referenser, vanligtvis från $800K till $2M+, beroende på komplexiteten i integrationen och kraven på efterlevnad.
Ett typiskt team består av:
I praktiken ligger komplexiteten sällan i kryptografin. Det handlar om integration, styrning och användarupplevelse.
För att sammanfatta detta, låt oss zooma ut lite. DID-baserad identitet är inte en färdig stack. Den utvecklas fortfarande, mestadels kring bevissystem, plånboksinfrastruktur, interoperabilitetslager och regleringsintegration. Från vad jag ser i verkliga implementeringar börjar några riktningar bli tydliga.
Återanvändbar identitet är det uppenbara slutspelet, men flaskhalsen är inte signaturverifiering. Den delen fungerar redan. Det som är svårare är förtroendet för utfärdaren, referensscheman och acceptansregler.
I framtiden bör en KYC-referens som utfärdats i en reglerad miljö kunna återanvändas på börser, tokeniseringsplattformar, utlåningsprodukter och DeFi-gränssnitt, förutsatt att utgivarens DID kan lösas, schemat förstås och verifieraren accepterar utgivaren inom sitt förtroenderamverk. Det är där det verkliga arbetet ligger: inte att bevisa att en signatur är giltig, utan att komma överens om vad det signerade påståendet faktiskt betyder.
Idag visar många system fortfarande attribut. Framtiden är att bevisa villkor. Istället för att visa ditt födelsedatum bevisar du att du är över 18 år. Istället för att exponera fullständiga KYC-data bevisar du att du har klarat en definierad efterlevnadspolicy. Istället för att dela ett jurisdiktionsfält bevisar du att du är berättigad till en transaktion.
Tekniskt sett pekar det mot BBS+-signaturer för selektivt utlämnande och zk-SNARKs eller zk-STARKs för predikatbevis. Verifieraren kontrollerar beviset mot utgivarkontrollerade publika nycklar, medan de underliggande personuppgifterna förblir dolda. Det innebär att integritetsmodellen ändras från “dela mindre data” till “dela inte data alls när det räcker med ett bevis”.”
Interoperabilitet avgör om decentraliserad identitet förblir fragmenterad eller blir användbar infrastruktur.
De svaga punkterna är fortfarande bekanta: JSON-LD vs JWT-autentiseringsuppgifter, olika DID-metoder, olika plånboksprotokoll, olika presentationsflöden. Det är därför som produktionssystem i allt högre grad definierar strikta profiler: godkända referensformat, DID-metoder som stöds, betrodda utfärdare och accepterade presentationsprotokoll.
Med tiden förväntar jag mig mer konvergens kring flöden mellan plånbok och verifierare, presentationsutbyte och förtroenderegister. Utan detta blir varje DID-projekt ytterligare en identitetsö. Med det kan referenser flyttas mellan plattformar utan anpassad integration varje gång.
Reglering gör att decentraliserad identitet går från att vara ett tekniskt alternativ till att bli en offentlig infrastruktur.
I EU är eIDAS 2.0 och EU:s digitala identitetsplånbok den stora signalen. Medlemsländerna är skyldiga att tillhandahålla infrastruktur för plånboken, med referenser för identitetsattribut, licenser, kvalifikationer och användningsområden för den offentliga och privata sektorn. Detta skapar ett reglerat lager av referenser i hela Europa.
I USA håller National Institute of Standards and Technology på att uppdatera riktlinjerna för digital identitet (t.ex. NIST 800-63) för att ta hänsyn till kryptografiska referenser, säkerhetsnivåer och integritetsskyddande verifiering. USA kommer sannolikt att behålla en mer marknadsdriven modell, medan EU förespråkar ett samordnat ramverk för plånböcker.
Så vart leder detta? Mot färre dokumentuppladdningar, fler återanvändbara referenser, fler lokala kryptografiska kontroller och mer selektivt utlämnande. Vinnarna kommer inte att vara de system som lagrar mest identitetsdata. De kommer att vara de som kan verifiera rätt anspråk med minsta möjliga exponering.
En decentraliserad identifierare är en unik, upplösbar identifierare som pekar på ett DID-dokument som innehåller publika nycklar och verifieringsmetoder. Det gör det möjligt för enheter att bevisa identitet eller kontroll utan att förlita sig på en central myndighet. I praktiken ersätter den databasuppslagningar med kryptografisk verifiering.
Ett DID är ett DID-dokument med publika nycklar. En utfärdare signerar en legitimation, en innehavare lagrar den och en verifierare kontrollerar signaturen och statusen med hjälp av utfärdarens DID. Inget direkt anrop till utfärdaren krävs. Detta gör verifieringen portabel och oberoende av ett enskilt system.
Decentraliserad identitet är den övergripande modellen för att utfärda och verifiera anspråk utan central lagring. En DID är bara en komponent i den modellen. Det fungerar som det identifieringslager som används för att lösa nycklar och verifiera signaturer. Utan DID:s skulle systemet sakna ett konsekvent sätt att lokalisera och lita på verifieringsmaterial.
Inte nödvändigtvis. Vissa DID-metoder använder blockkedjor för upplösning eller förankring, men många, som gjorde:webb, förlitar sig på standardiserad webbinfrastruktur. Själva DID:n är en referens, inte en datapost. Det som kan lagras i kedjan är nycklar, hashar eller statusreferenser, inte identitetsdata.
De används för att länka identiteter till kryptografiska nycklar, möjliggöra verifierbara referenser, stödja återanvändbar kundkännedom, verifiering av arbetskraft, digitala ID:n och åtkomstkontroll i både webb- och blockkedjebaserade system. Deras roll är att göra identitetsverifiering portabel mellan olika system.
Du genererar ett nyckelpar och skapar en DID enligt en vald metod. Sedan publicerar eller registrerar du det så att det kan lösas till ett DID-dokument. Den exakta processen beror på DID-metoden (t.ex. webb-, blockchain- eller nyckelbaserad). Metoden avgör hur DID:n förankras, uppdateras och löses.
Blockchain-expert och DeFi-analytiker
Andrew översätter decentraliserade koncept till säkra, funktionella finansiella verktyg. Han navigerar i det flyktiga DeFi-landskapet för att bygga skalbara blockchain-infrastrukturer som adresserar verklig nytta, och går förbi buzzwords för att leverera tekniskt värde.
