What is a Verifiable Credential, and Why Does it Matter?
https://identiverse.com/idv2022/session/841421/
"A verifiable credential (VC) is an assertion with a secret weapon – called a verifiable presentation (VP). VCs and VPs are unique in that they enable users to directly hold and present claims about themselves, issued by many different authorities. This is an important addition to the domain-relative credentials that are presented today as part of federated sign-in or SSO contexts. You may ask – why is that direct presentation important? Kristina Yasuda will talk through how VCs and VPs work, what makes VCs different from common federated credentials, and what VCs could change about how we interact with data in the future."
9. #identiverse
Issued to Me
Physical Wallet Digital Card
Cards are issued to me (owner of the
wallet)
1. Physical wallet and emerging digital wallet
+
10. #identiverse
Issued by the Authoritative Issuer
Cards are issued by the authoritative
issuer
Plastic Card Digital Card
1. Physical wallet and emerging digital wallet
+
11. #identiverse
Cards are Portable
I can carry the cards with me (for
example, in a wallet)
Physical Wallet Digital Card
1. Physical wallet and emerging digital wallet
+
12. #identiverse
Multi-Use of a Single Credential
I can use the same card multiple times
Physical Wallet Digital Card
1. Physical wallet and emerging digital wallet
+
13. #identiverse
Combine Multiple Cards in One Transaction
I can show multiple cards at the same
time
Physical Wallet Digital Card
1. Physical wallet and emerging digital wallet
+
14. #identiverse
Issuer Might Not Know When and Where the
Card is Used
Issuer of the card might not know
when and where I use the card
Physical Wallet Digital Card
1. Physical wallet and emerging digital wallet
15. #identiverse
Similarity in the Experience and Features
Issued to?
Issued by?
Portable?
Multi-Use?
Combining multiple cards?
Issuer knows?
Yes
Yes
me
the authoritative
issuer
Might not
Yes
Physical Wallet Digital Card
1. Physical wallet and emerging digital wallet
+
17. #identiverse
Use-Case: Digital Driving License*
Everything is moving
into the phone
Reducing human error
during verification
Unlocking online Use-
Cases
* Same value propositions will apply to the other credentials such as University Graduation Credentials for example
1. Physical wallet and emerging digital wallet
20. #identiverse
A new artifact introduced in the “Digital
Cards” model*
* Some “Digital Cards” use-cases do not require user signed artifact.
Issuer-signed Card
(what is issued)
User
Signature
User-signed Card
(what is presented,
only in digital cards model)
- Claims about the
User
- User Identifier
- User’s Public Key
Issuer
Signature
- Claims about the
User
- User Identifier
Issuer
Signature
Not Bearer! Owned by a user who controls
the private key tied to a public key.
Claims inside can be about another user, if
delegated
21. #identiverse
Not everything changes,
but some important differences
Issuer
(Website)
Verifier
(Website)
Holder
(Digital
Wallet)
Federated Sign-in Digital Cards model
Identity
Provider
(Issuer)
Relying
Party
(Verifier)
Issuer-
signed
Sign
Issuer-
signed
Sign
User-signed
Sign
User
Agent
22. #identiverse
Issued to?
Federated Sign-in Digital Card
Cards are issued
to me (owner of
the wallet)*
Issuer signed
card is issued to
the Relying Party
(via the User
Agent)
*Issuer only has limited technical means to control at which verifier the user is going to use a digital credential. Not
talking about delegation/guardianship scenarios here.
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
23. #identiverse
Issued by?
The authoritative
issuer (Identity
Provider)*
Federated Sign-in Digital Card
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
* Ratio of the Issuers to the Verifiers varies, too.
24. #identiverse
Portable?
(Identifier is what would allow Card portability)
Globally unique
identifier - not
namespaced and
is portable.*
User identifier
namespaced to
the Identity
Provider
Federated Sign-in Digital Card
* Depends whether the Verifier accepts non-namespaced identifier brought by the User.
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
25. #identiverse
Multi-Use?
Same card can
be used multiple
times*
ID Token is one-
time use
Federated Sign-in Digital Card
* Same Issuer-signed credential, different user signature per presentation
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
26. #identiverse
Combining multiple cards from multiple
issuers in one transaction?
I can show
multiple cards
from multiple
issuers in one
transaction
RP receives one
ID Token from
one IdP in one
transaction*
Federated Sign-in Digital Card
* IdP can aggregate claims from multiple issuers, but authority of the original issuer is gone
* Focus is on the deployed features of the Federated sign-in
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
27. #identiverse
Issuer knows about my usage?
Depends on the
use-case whether
Issuer of the card
knows when and
where I use the
card*
Issuer of the ID
Token knows
when and where I
used it, always
Federated Sign-in Digital Card
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
* Some use-cases require the Issuer knowing where the card is used.
28. #identiverse
Certain Differences
-> can address different use-cases
Issued to?
me
Relying Party
Issued by?
Authoritative Issuer
Portable? (Identifier)
Possible
Within IdP
Multi-Use?
Yes
One-Time
Combining multiple cards?
Yes
Not used
Issuer knows?
Depends
Yes
Federated Sign-in Digital Card
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
32. #identiverse
Use-Case: Supply Chain
Scale across
thousands of
organizations
+ independent from the
Issuer Availability
+ Ad-Hoc Trust* Possible
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
3. Use-Cases when digital wallet is useful
* When decision whether to trust a source of a request/response can be made when receiving that request/response (at a runtime)
33. #identiverse
Beyond Technical Integration:
Legal Agreements, Compliance, etc. (not a new problem)
Digital Cards
model
Issuer
(Website)
Verifier
(Website)
Holder
(Digital
Wallet)
Legal
agreement*
Legal
agreement*
Legal agreement*
Federated Sign-in Identity
Provider
(Issuer)
Relying
Party
(Verifier)
End-
User
Legal agreement
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
3. Use-Cases when digital wallet is useful
* Can be ad-hoc trust or a legal agreement.
34. #identiverse
Use-Case: Digital Driving License
Public Perception
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
3. Use-Cases when digital wallet is useful
35. #identiverse
Benefits of Digital Cards
Public Perception
Scale Cross-
Organization
Trust
+ independent from the
Issuer Availability
No Account Creation
(e.g. Authentication
at the Edge)
Attribute-level
Attestation
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
3. Use-Cases when digital wallet is useful
37. #identiverse
Meet Verifiable Credentials
The idea of Verifiable
Credentials is to design
components and
mechanisms necessary
to use “Digital Cards”.
Multiple design choices
possible.
38. #identiverse
Data-Models and Credential Formats of
Verifiable Credentials
* ISO/IEC 18013-5 mDL provided by Zetes Industries S.A.
Verifiable Credentials
W3C Verifiable Credentials
Data Model
JWT-VC LDP-VC
AnonCreds mDL data model
CBOR-
encoded,
COSE
signed
JSON-
encoded,
JSON
signed*
SMART
Health
Cards
…
…
39. #identiverse
Standards that enable Verifiable Credentials
Component Standards
Exchange Protocol OpenID for VC Issuance, OpenID for VPs
Subject-Signed
Authentication
Self-Issued OpenID Provider v2
Credential Formats W3C JWT-VC, W3C LDP-VC, ISO mDL, IETF SD-JWT, etc.…
Entity Identifier DID methods, Raw keys, X.509 certs, etc.
Cryptography EdDSA, ES256K, etc.
Revocation Status List 2021, Revocation List 2020, Accumulators, etc.
Trust Frameworks Trusted Registries, Ledgers, etc.
40. #identiverse
How to find your peaceful spot for your use-case
inside a Verifiable Credentials ecosystem?
- Scope
- Enterprise / Consumer / Government
- Market
- Established / Emerging
- Use-Cases
- High Assurance / Low Assurance
- Identity of
- Individual / Legal Entity / Machine
Key Slide
41. #identiverse
Food for thought
- Attestations to prove security of a digital wallet?
- Usage of the Cloud components?
- Will Verifiers request digital cards more often than needed?
- Attributes of each user in one place – higher risk for hacking?
- Maturity of the Trust Frameworks?
…
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
3. Use-Cases when digital wallet is useful
4. Verifiable Credentials: Pros and Cons
42. #identiverse
What we did not talk about
- Revocation
- Selective Disclosure
- Refresh
- Delegation / Guardianship use-cases
- Unlinkability
- (Web3 – digital cards are possible without blockchain/DLT)
…
1. Physical wallet and emerging digital wallet
2. Federated sign-in and emerging digital wallet
3. Use-Cases when digital wallet is useful
4. Verifiable Credentials: Pros and Cons
43. #identiverse
Now that you know what
verifiable credentials are good for…
Where in a verifiable credentials
ecosystem does your use-case belong
to?
What aspects need a deep-dive to realize
your use-case?*
* Business? Legal? Technical? Standards? else?
44. #identiverse
* Session may be called “Building Secure, Trusted and Interoperable Self-Sovereign Identity with
OpenID Connect” in some parts of the Identiverse website.
*
49. #identiverse
Why these two are moving forward?
mobile Driving Licence Vaccination QR Code
• One large Verifier – TSA
• No usage of Advanced Cryptography for
Selective Disclosure or Predicates
• Not doing Holder Binding
• Make choices across technical stack to ensure interoperability (e.g. exchange
protocols, credential format, data model, crypto suites, etc.)
• Finding a verifier that does not require account creation
• Focus on the existing ecosystems
Mutual to both