3. The Evolution of Digital Identity
Identity Model Centralized Federated Decentralized
Technology
● ID/Password
● Multi-factor Auth
● SSO
● OAuth
● OpenID
● SAML
● Secure Personal
Storage
● SIOP, Web5
● Cryptographically
driven auth
Characteristics
● Identity fragmented
across many service
providers
● Corps have full control
of user data
● Centralized data
providers at risk for
attack
● Rely on a single/set of
centralized identity
providers
● Identity information
fragmented between IdPs
● Centralized data
providers at risk for
attack
● Identity portable across
ecosystems
● User controlled data
on-device or
user-controlled cloud
● Users are in control of
their data
4. 4
SSI Principles
● Existence – Users must have an independent existence
● Control – Users must control their identities
● Access – Users must have access to their own data
● Transparency – Systems and algorithms must be transparent
● Persistence – Identities must be long lived
● Portability – Information and services about identity must be
transportable
● Interoperability – Identities should be as widely usable as
possible
● Consent – Users must agree to the use of their identity
● Minimalization – Disclosure of claims must be minimized
● Protection – The rights of users must be protected
7. W3C Verifiable Credentials
(VCs)
A Verifiable Credential is a W3C standard
mechanism of expressing claims about an
individual on the Web in a way that is
cryptographically secure, privacy respecting,
and machine-verifiable.
A VC is inherently independently verifiable –
which means a verifier will never need to go
back to the issuer to conduct or complete
verification.
7
Claims can include, but aren’t limited to, the same
claims in traditional credentials such as health cards,
passports, university degrees, or business licenses.
8. Holder
The entity controlling a VC. This entity is
usually the subject of the VC, though not always.
There are scenarios where the entity may have been
issued a VC, but is not the subject of the VC.
8
Issuer
The issuing entity of a VC. This entity asserts claims
about the subject of the VC and issues it to a Holder.
Verifier
The entity to which a VC is presented to as proof
of a claim or set of claims. This entity might
request a VC, and then verify that the VC satisfies
their requirements.
Actors in Decentralized
Identity Systems
9. W3C Decentralized Identifiers
(DIDs)
A Decentralized Identifier W3C standard for a
type of user- or business-controlled
identifier that enables verifiable,
decentralized digital identity on the Web.
DIDs are URIs that associate a DID subject
with a DID document allowing trustable
interactions with that subject. DID documents
contain public keys and other data.
9
A DID can refer to any subject, including a
person, organization, thing, data model, abstract
entity, etc.
12. Decentralized Identity:
In the Numbers
60+
Public & private companies
building in the space
40+
Countries using some form of
Decentralized Identity
12
3B+
Verifiable Credentials
Issued
14. 75%+ of the world
will be using
decentralized
identity tech
within the next 5
years
14
15. “
“Decentralized identity is important for confirming user identities
and securely storing them. It offers numerous advantages separate
of the greater identity autonomy it delivers to customers.”1
“…passkeys do not protect our privacy or give us complete control of
our online identities. For that to happen, we need to look at
self-sovereign identity (SSI).”3
“Individuals can own and manage their own tamper-proof credentials
for applications such as personal health, education, and voting
records in an encrypted digital wallet on their personal devices.”2
16. Attack Surface
16
Service Providers Networks User Agents Individual Entities
Companies like
Microsoft, Ping
Identity, Okta, MATTR,
Trinsic, and more.
Their service offering
= your opportunity!
EBSI, Velocity,
Sovrin, Indicio,
Cheqd, and others.
Networks are forming
to standardize,
monetize, and
facilitate identity
Your phone, your
computer, your
applications.
You thought being your
own bank was hard, how
about being your own
IdP?
You, your mom, your
dog, your employer,
your trustworthy local
politician.
In a world of
decentralized trust,
each entity is an
entrypoint for
exploit.
18. 18
Vuln #1:
Gimme That
Data!
●
In a world with verifiable data, any data can be
requested by anyone at any time…
○ Why is this data being requested? Is there
other less sensitive data that would
suffice?
○ Is the requester who they claim to be? How
do you know?
○ Is the requester the right entity to
receive and handle this data?
○ What can be done with this data in other
contexts? What’s protecting the data from
unauthorized usage?
19. Attack #1: Abuse of Trust
19
Alice goes to the store…
1. Store requests proof that Alice is
over 18
2. Alice scans a QR code with her digital
identity app
3. Alice selects which credential matches
the request
4. Alice has an option to submit
20. Attack #2: Confused Trust
Alice goes to open a bank account…
1. Alice navigates to a bank’s website
and clicks “sign up”
2. Alice is asked for a few pieces of
information
a. Government issued ID
b. Proof of employment
c. Proof of funds to open the
account
The website appears legitimate, and her
app thinks so too, does Alice send over
the data?
20
21. 21
Vuln #2:
You thought
distributed
systems
were hard…
●
In a distributed systems, usually…
● You’re aware of all nodes in the system
● Consistency ensures that all nodes in the system
have the same up-to-date view of data
In a decentralized system…
● There is no one method of decentralized
consistency
○ Strongly consistent (BTC)
○ Eventually consistent (IPNS)
● Even with consistency, you may not always know
if you have the latest state
22. Attack #3: Data (Un)availability
Bob goes to verify a credential
22
23. did:jwk
(+) Self-resolving key that
always has the latest state
(-) No updates
(-) No way to signal
compromise
did:web
(+) Domain based method
(+) Supports updates
(-) Relies on TLS certs
(-) Relies on DNS / domain
registrars
(-) No historical state
resolution
23
did:ion
(+) Supports any DLT and
Content-Addressable Storage
(+) Permissionless + full
featured (update, recovery,
deactivation)
(-) Complex architecture
(-) Uncertain if you have
the latest state / pinning
risk
Attack #4: DIDn’t I tell you?
33. Mitigation #1: Smart Agents
Digital Bodyguards = Freedom
Centralize When Necessary
● Trust needs to start somewhere
● Trusted issuers/verifiers →
centralized trust registries
○ What are they trusted for?
○ What have their last x
interactions been like?
○ Are there transparent reviews?
● Trusted vendors
○ Agents/wallets
○ Personal data stores
Take Privacy-First Stances
● Are you disclosing as little as
possible?
● What rights do you enforce after you
share?
33
34. Mitigation #2: More than a
green checkmark
Establish Trust; Minimize Disclosure
● Alice’s smart agent has a built-in Trust
Registry, and can now verify that requests
are legitimate
● Alice’s smart agent is able to advocate for
a privacy-preserving presentation mechanism,
selective disclosure
● ZKPs are coming!
● Make sure to authenticate, always
Is this enough?
34
35. Mitigation #3: Start From
First Principles
Decentralize where it matters most
● DID Method → If your DID method
isn’t decentralized and feature
rich, you’ve boxed yourself in
● DIDs → Use a mix of
public/long-lived and
private/ephemeral DIDs
● Providers → Make sure your data
isn’t locked to a single provider;
beware of single vendor solutions
Assert your rights
● Is it clear what you’re signing?
● What could go wrong?
● What are you giving up?
● Is there another path? 35
36. More Mitigations
● Build flexible, privacy-promoting standards
+ software
● User-defined terms of service/use to
enforce fair data usage
● Decentralized trust scoring mechanisms
(verified Google Reviews/Yelp)
● Use of open source software
● Use of open networks and ecosystems–say no
to walled gardens!
● More interactive protocols that enable user
negotiation & optionality
36
I
m
p
l
e
m
e
n
t
e
r
s
Individuals
O
r
g
a
n
i
z
a
t
i
o
n
s
43. ● What is Decentralized Identity anyway?
● That vulnerability is just my type
● Showing some real vulnerability
● Is nothing safe?
● Deployments
● Fin
44. What is Decentralized Identity Anyway?
● SSI Principles
● Verifiable Credentials
● Decentralized Identifiers
● Why would I even want that?
●
45. That vulnerability is just my type
● Private key compromise
● Validity vs verifiability
● Fake News!
● Blockchain problems
● Key management is hard
● Lack of Review
46. Showing some real vulnerability
● Some examples of attacks in the real world
● Ledger data breach
● How attackers might exploit vulnerabilities in decentralized identity systems
● The potential consequences of successful attacks
● Examples of real-world attacks on DIDs and verifiable credentials
47. Is nothing safe?
● Cryptographic techniques and key management practices to strengthen
security
● Best practices for designing and implementing decentralized identity systems
● Examples of successful mitigation strategies
49. Fin
● The importance of addressing vulnerabilities in decentralized identity systems
● The potential impact of successful attacks on individuals and organizations
● The need for continued research and development to improve security and
resilience in decentralized identity systems