m SSI / DID / VC - Self Sovereign Identity
- jim mason
- jimm1
- Jim Mason
Key Points
- SSI - the user ( principal ) controls the use and information about their identity
- SSI issued by an IP ( identity provider ) which may be: independent org ( Sovrin ) or government ( eg US ) or another org
- Just like today, you may have multiple SSI and multiple digital wallets that need to be aware of each other and interoperate potentially
- SSI are not fully interoperable at this point, related interoperable standards will continue to evolve
- The primary location for SSI is a smart phone so many people can't access SSI today meaning existing identity systems must remain in parallel now
- SSI should be well protected in many ways
- SSI should be FULLY recoverable easily upon MFA proof of ownership and loss
- SSI identities and credentials need to integrate to existing Identity and Access Management systems that will remain operational for a long time ( see OIDC interfaces for authentication etc )
References
SSI / DID concepts
Christopher Allen article on SSI Concepts ***
http://www.lifewithalacrity.com/2016/04/the-path-to-self-soverereign-identity.html
Key principles
- Existence - the SSI ( DID ) makes a digital id for an existing asset ( person, org, thing etc )
- Control - users control their own identity data
- Access - users have access to their digital identity
- Transparent - the systems and algorithms managing identities must be open and transparent
- Persistent - the identities must be long-lived
- Portable - user must control his identity existence so it can live on any identity network, not depend on a single outside agency to keep it alive
- Interoperable - should be able to be widely used in any context in theory
- Consent - user controls access to identity and credentials
- Minimization - user discloses minimum information to 3rd parties for authentication and authorization
- Protection - protection individual's identity on networks and systems securely
TrustOverIP Concepts ***
SSI basics
https://en.wikipedia.org/wiki/Self-sovereign_identity
Drummond Reed - SSI book
DIDs enable digitally signed verifiable claims
SSI - The Future of Identity: Self-Sovereignity, Digital Wallets, and Blockchain paper 2022
self-sovereign-identity concepts article - 2024 -identity.com **
SSI / DDI Specifications
W3C DID Standard
https://www.w3.org/TR/did-core/
https://www.w3.org/2020/12/did-wg-charter.html
W3C DID Use cases doc
https://www.w3.org/TR/did-use-cases/
W3C DID Test Suite Implementation doc
https://w3c.github.io/did-test-suite/
W3C DID Primer
https://w3c-ccg.github.io/did-primer/
DID points to DID document
A DID document is a valid JSON-LD object that uses the DID context (the RDF vocabulary of property names) defined in the DID specification. This includes six components (all optional):
The DID itself, so the DID document is fully self-describing.
A set of cryptographic material, such as public keys, that can be used for authentication or interaction with the DID subject.
A set of cryptographic protocols for interacting with the DID subject, such as authentication and capability delegation.
A set of service endpoints that describe where and how to interact with the DID subject.
Timestamps for auditing.
A optional JSON-LD signature if needed to verify the integrity of the DID document.
See the DID specification for several examples of DID documents.
Should a DID be shared publicly?
https://sovrin.discoursehosting.net/t/public-facing-dids-vs-private-pairwise-dids/243/7
First, I agree that, from the standpoint of the Sovrin ledger itself, there is really no difference between a “public” DID—one intended to be widely correlate-able, and “private” DID that will only be used in a single pairwise relationship. The difference all comes in how the identity owner shares the DID. The public DID will be shared widely (similar to a website address), whereas the private one will only be shared with the other party to the relationship.
Secondly, Andy mentions that you could put public info into the DDO associated with a “public” DID. While that’s possible, it’s not best practice. Better to make public claims (claims anyone can access) available through the agent endpoint for a “public” DID. Essentially you want to publish public info via the agent associated with the DID rather than the DDO associated with the DID. All you want in the DDO is the public key and agent endpoint for the identity owner.
Lastly, just to make sure everyone has the current links for the DID Data Model and Generic Syntax Implementer’s Draft 01 spec:
- PDF version 68 (static)
- Google docs version 20 (accepts comments)
Private DIDs in wallet not ledger
To update this thread and avoid confusion, the technology has been evolving, and pairwise DIDs are now not typically written to the ledger. They are known by and held only by their respective endpoints.
Understanding DIDs, URIs and routing agents
https://sovrin.discoursehosting.net/t/did-documents-and-uris/1289/3
did-uri-agents-sovrin.discoursehosting.net-DID documents and URIs.pdf
W3C DID Identity Workshop
https://www.w3.org/Security/strong-authentication-and-identity-workshop/report.html
W3C Verifiable Credentials Overview
https://www.w3.org/TR/vc-overview/
W3C Verifiable Credentials Use Cases
https://www.w3.org/TR/vc-use-cases/
Verifiable Credential Type Differences - Kaliya **
https://www.lfph.io/wp-content/uploads/2021/02/Verifiable-Credentials-Flavors-Explained.pdf
Verifiable-Credentials-Flavors-Explained pdf
This paper explains the differences between various VC flavors for the technically inclined readers. An important goal of the paper is to present a clear path forward that can end the interoperability trilemma that has emerged between three different VC flavor choices, and points to the adoption of the newest VC format to satisfy all stakeholders.
Why does this matter? Without convergence to a standardized VC format, there won’t be functional interoperability across the ecosystem. If application builders process diverse cryptographic calculations using incompatible libraries and methods, and the underlying data has varying readability properties, then interoperability will not be achieved.
What different methods have in common is issuers use them to package up claims about an entity. The issuing entity then uses cryptography to seal the credential. This sealing provides a mechanism for other entities (the verifiers) to check the cryptographic signatures to see if the credential has integrity based on the issuer’s public keys.
What is different is how issuers format claims inside the credentials and use cryptographic signatures suites to sign the information and seal the credential. These methods also have processes for sharing Verifiable Presentations (VP or VPs) to a verifier and conducting the cryptographic verification.
There are advocated variations of these types, but they are less common.
- JSON-LD family with LD Signatures or with BBS+ Signatures that enable Zero Knowledge Proofs (ZKP or ZKPs)
- JSON with JSON Web Signatures, precisely in the form of a JSON Web Token (JWT)
- ZKP with Camenisch-Lysyanskaya Signatures (ZKP-CL)
There are essentially two different “types” of VCs that are unique from one another because of how they elect to express the VC data model, including the associated cryptographic material
(e.g., digital signatures).
- VCs expressed in JSON-LD using Linked Data Proofs (JSON-LD)
- VCs expressed in JSON using JSON Web Signatures (JWS), precisely in the form of a JWT (JSON-JWT)
These two formats support a range of different digital signature algorithms - a vital property to ensure VCs are cryptographically agile, enabling them to move with the constant evolution of cryptography. With both of these formats, users can implement a whole host of different digital signature schemes.
It is important to note that not all digital signature algorithms are the same. Security and capabilities can differ. Some support novel properties such as selective disclosure and anticorrelation techniques via ZKP technology. BBS+ Signatures is one such algorithm that developers leverage with the JSON-LD data format. The third credential format and signature scheme mentioned in the VC Specification is “Camenisch-Lysyanskaya ZKP [CL-SIGNATURES],” however this format is not explained in the specification. This format is a bespoke data expression format coupled with a particular digital signature algorithm.
The company Evernym and then the Sovrin Foundation originally developed this format as part of the Indy codebase which they contributed to Hyperledger, a Linux Foundation project hosting many different open source enterprise-focused blockchain projects. This codebase was forked into the Hyperledger Indy project for ledger code, Hyperledger Ursa for cryptographic libraries, and the ledger-agnostic Hyperledger Aries codebase for agent, wallet, and credentialing code.
Two of these credential formats leverage JSON-LD. In recent years this format has garnered a lot of interest for good reason. It supports semantic clarity and discernment by verifiers about the issuer’s intended meaning for particular attributes in the credential. This format also has a handy feature supporting translation between languages on the fly. It is also new, and because of this, fewer developer tools support it than JSON. Last year, a new format JSON-LD ZKP with
BBS+ Signatures came forward to bridge the gap between JSON-LD and ZKP-CL. MATTR, a New Zealand-based company seeking to bridge the differences, introduced this method of
packaging and expressing VCs. It uses the simplest, widely available cryptography to support selective disclosure. MATTR shared the new format with the VC community as an open
standard. Both the ZKP-committed groups and the JSON-LD community have expressed interest in adopting it. According to its designers, JSON-LD ZKP BBS+ should not be seen as a
different format of VC. It shares much of the processing logic for JSON-LD, even though it supports a new set of fundamental types that enable new functions like derived proofs.
A Metaphor for the difference between JSON and JSON-LD
The second main format JWT is a part of the JOSE framework. It provides no means to support semantic disambiguation but has the benefit of being simpler for assertion format implementations. “JOSE is the rice and beans of cryptography standards. It’s got everything you need to survive and is easy to make, but its extensibility model guarantees you will be eating rice (base64url) and beans (JSON) forever. That might make you “fat” because base64url inflates JSON.
On the other hand, Linked Data Proofs, as seen in Verifiable Credentials and Verifiable Presentations, are like a pharmaceutical drug - really hard to build, but capable of solving all kinds of problems and formally described by an information theoretic model (molecular formula ~= RDF). Linked Data Proofs are capable of working with other bases, other structured data formats (base58, CBOR), and the extensibility model is anything that you can model in RDF. Context determines the relevance of either model. Most people don’t go to a pharmaceutical lab to make lunch, but most people who make drugs in their kitchen also eventually end up sick.”
Anoncreds - Anonymous Credentials - VC with privacy, ZKP concepts
anoncreds-20221121-stppa4-anna-lysyanskaya--anonymous-credentials.pdf link
anoncreds-20221121-stppa4-anna-lysyanskaya--anonymous-credentials.pdf. file
signature verification on AC
attribute verification on AC
is is practical ? 2019
TOIP DID Messages spec
https://identity.foundation/didcomm-messaging/spec/
DIDComm Messages Draft 2x - IIW
https://identity.foundation/didcomm-messaging/spec/
Contributors: Sam Curren (Indicio), Tobias Looker (MATTR), Oliver Terbu (ConsenSys), Kyle Den Hartog (MATTR), Baha Shaaban (SecureKey), Drummond Reed (Evernym), Steve McCown (Anonyome Labs), Troy Ronda (SecureKey), George Aristy (SecureKey), Vyacheslav Gudkov (DSR), Alexander Shcherbakov (DSR), Alexander Martynov (DSR), Daniel Buchner (Microsoft), Devin Fisher (Evernym), Orie Steele (Transmute), Brian Richter (Aviary Tech), Juan Caballero (Centre.io), @liormargalit, Timo Glastra (Animo Solutions), Andrew Whitehead (Government of British Columbia), Nader Helmy (MATTR), Markus Sabadello (Danube Tech), Patrick McClurg (SICPA), Stephen Curran (Government of British Columbia), Daniel Hardman (SICPA), Moe Jangda (Block - TBD)
Example of DIDComm messages
To understand how DIDComm Messaging works, consider a situation where Alice wants to negotiate with Bob to sell something online. Because DIDComm, not direct human communication, is the methodology in this example, Alice’s software agent and Bob’s software agent are going to exchange a series of messages.
Alice may just press a button and be unaware of details, but underneath, her agent begins by preparing a plaintext JSON message about the proposed sale. The particulars of selling are irrelevant here, but would be described in the spec for a higher-level “sell something” protocol that uses DIDComm Messaging as its foundation. Alice’s agent then gets two key pieces of information from Bob, typically by resolving Bob’s DID Doc:
- An endpoint (web, email, etc) where messages can be delivered to Bob.
- The public key that Bob’s agent is using in the Alice:Bob relationship.
Now Alice’s agent uses Bob’s public key to encrypt the plaintext so that only Bob’s agent can read it, adding authentication with its own private key. The agent arranges delivery to Bob. This “arranging” can involve various hops and intermediaries. It can be complex. (See Routing in the DIDComm Guidebook.)
Bob’s agent eventually receives and decrypts the message, authenticating its sender as Alice using her public key. It looks up this key in Alice’s DID doc, and captures an endpoint for her at the same time. Bob’s agent then prepares its response and routes it back using a reciprocal process (plaintext → encrypt with authentication → arrange delivery).
That’s the essence, in the most common scenarios. However, it does not fit all DIDComm Messaging interactions:
- DIDComm doesn’t always involve turn-taking and request-response.
- DIDComm interactions can involve more than 2 parties, and the parties are not always individuals.
- DIDComm may include formats other than JSON.
CHAPI - VC credential handler protocol overview
The Credential Handler API (CHAPI) was originally described in a draft report for the W3C Credentials Community Group. It is being developed now as a ready-to-use API, libraries, and as integration documentation.
CHAPI defines a method for users to designate trusted Web applications as handlers for credential requests and credential storage. When the user visits a website that asks to present or requests Verifiable Credentials, the user is informed and consents to the transaction, and the designated handler responds to the request.
DIDComm messages Over CHAPI protocol is an option for some use cases
https://iiw.idcommons.net/101_Session:_Verifiable_Credential_Handler_(CHAPI)_and_DIDComm
iiw-didcomm-chapi-101 Session_ Verifiable Credential Handler (CHAPI) and DIDComm - IIW.pdf
DIDCOMM 101
Q&A - Some requests for more explicit definitions:
From the charter of the DIDComm WG at DIF: “Produce one or more high-quality specs that embody a method (“DIDComm”) for secure, private and (where applicable) authenticated message-based communication, where trust is rooted in DIDs and depends on the messages themselves, not on the external properties of the transport(s) used. The method must be usable over many means of transport, including those that are asynchronous and simplex, and ones that do not necessarily use the internet. It must support routing and relay through untrusted intermediaries, not just point-to-point delivery. In addition to the communication and protocols described above, the protocols for exchanging DIDs/keys to bootstrap such communication are within scope. These protocols can be the foundation of higher-level protocols such as credential exchange and higher-level authentication protocols.”
DIDComm in layman’s terms: http://www.windley.com/archives/2019/06/did_messaging_a_batphone_for_everyone.shtml
From Geovane Fedrecheski and Oliver Terbu, in the chat: “DIDComm is a standard way to exchange DID-aware encrypted messages, regardless of transport (e.g., unlike TLS, which is limited to TCP) - a set of subprotocols and related messages, such as those used for credentials exchange”
Other Q&A
Sam Curren: explicit ACKs allowed (but not forced at this level), threading (see RFC [1])
VON Use Case - BC Gov Verifiable Organizations Network
Key Concepts
Updated SSI information wiki - indentosphere - Kaliyah
https://newsletter.identosphere.net/. << All things Digital Identity. <<. https://identosphere.net/
https://newsletter.identosphere.net/p/identosphere-167-retrospectives-eidas2
Everything related to decentralized identity and verifiable credentials including standards and development: updates, walkthroughs, from the enterprise to web3, real world use, policy and research.
SSI Book - Drummond Reed
Self-Sovereign_Identity_v10_MEAP.pdf
SSI Trends & Challenges - 2022
https://cheqd.io/blog/understanding-the-ssi-stack-through-5-trends-and-challenges
From our deep dive survey we have drawn 5 distinct trends across the layers four of the stack:
- Trend 1: (Layer 1) Hyperledger Indy is still the most supported Layer 1, but there are signs it may be losing its dominance
- Trend 2: (Layers 1, 2, 3) Aries-based SDKs are dominant, correlating with Indy at Layer 1
- Trend 3: (Layer 2) OIDC SIOP may be starting to catch up with DIDComm in terms of a peer-to-peer connection layer
- Trend 4: (Layer 3) The lack of harmonization on Credential type/exchange standards is more stark than ever
- Trend 5: (Layer 4) Ecosystem adoption could be driven by stronger commercial models and payment rails
All five trends culminate in one main challenge:
Interoperability and harmonization is lacking at each layer of the stack, which is a barrier for adoption
Digital Trust Seminar Series
sessions, materials, use cases, methods, tools, technologies, self assessments for orgs, users
Session 1 - Digital Trust Primer
Session 2 - Digital Trust Foundations in Hyperledger
Session 3 - Digital Trust in Action: Verifiable Organizations Network
Session 4 - Digital Trust Interoperability
Session 5 = Digital Trust Assessment
Session 6 - Digital Trust Road map
DID Solution Design Implementation Concepts
Most companies already have identity, security infrastructure solutions in place.
Potential Advantages for DID solutions
DID ( Decentralized Identity ) designs ( aka Self-Sovereign Identity - SSI ) offer potential benefits over existing identity alternatives:
- cryptographically secure identities and credentials
- more user control over their identities with consent management
- more control over their own user data with consent management
- automated digital trust for verification of identity and credentials using issuer, holder, verifier model
- better privacy with selective disclosure and zero-knowledge proofs under user control
- more efficient management over many existing identity solutions
- real-time validation authorizations using verifiable credentials
- real-time revocation of authorizations when required using the DID-comm protocol
- integration options with identity infrastructure: digital wallets, vaults, blockchains, services
Keys for DID Solution Design and Delivery
Key 1 - Common Service Layer to Encapsulate DID Service Providers
Key 2 - Common Integration Service for Multiple Authentication Services
Key 3 - Common Integration Service for Multiple Authorization Services
Key 4 - Validate DID Infrastructure Dependencies
Key 5 - Privacy and Personal Identity Information ( PII ) Management governance
Key 1 - Common Service Layer to Encapsulate DID Service Providers
What?
Create a common service layer to encapsulate DID services.
Why?
Larger organizations have many different business groups, solutions and communities to define the right solutions.
Typically, larger organizations can't usually standardize on a single database solution forever.
The same concept applies to identity management solutions.
The common DID identity service layer makes it easier to add, replace or remove specific DID vendor solutions over time.
How?
Work with business, IT architects and vendors to define a useful common interface for DID solutions.
Look at the DID standards and a first DID service to define what capabilities a common DID service should deliver client applications
When?
Large organizations that may use multiple identity service providers or don't want to bind all applications to a single vendor should consider the service layer
Key 2 - Common Integration Service for Multiple Authentication Services
What?
Provide a common authentication service API for applications
The authentication service can map to different authentication systems
Why?
Organizations usually have existing authentication systems based on LAN-ID, SSO ( Single SignOn ), OAUTH2 ( Open Authorization )
In addition, omni-channel architectures connect Web, mobile, event messaging front-end protocols to common back-end APIs
Rolling out DID for authentication and authorization usually can't replace all other authentication solutions initially
With a common authentication service, changing the authentication implementation on the backend for an application is simpler
How?
Adding the authentication integration service allows flexibility on when applications can change configuration to a different authentication service
Key 3 - Common Integration Service for Multiple Authorization Services
What?
Provide a common authorization service API for applications
The authorization service can map to different entitlement systems on the back-end
Why?
Organizations usually have existing entitlement systems
In addition, omni-channel architectures connect Web, mobile, event messaging front-end protocols to common back-end APIs
Rolling out DID for authentication and authorization usually can't replace all other authorization solutions initially
With a common authorization service, changing the authorization implementation on the backend for an application is simpler
How?
Adding the authorization integration service allows flexibility when applications can change configuration to a different authorization service
Key 4 - Validate DID Infrastructure Dependencies
What?
Do the key infrastructure dependencies for DID services exist?
Have they been validated for use with the specific DID solutions?
Why?
DID solutions depend on many infrastructure services: cryptographic, Certificate Authorities, Digital Wallets, Vaults, SIEM, blockchain networks, data services etc
How?
Identify the requirements for a specific DID solution stack
Work with service providers, vendors and implementation teams to identify stack options and define stack strategies
Key 5 - Privacy and Personal Identity Information ( PII ) Management governance
What?
Privacy Regulations continue to increase everywhere: GDPR in Europe ( General Data Protection Regulation ), CCPA ( California Consumer Protection Act ), NYPA ( New York Privacy Act ) and more. In addition, companies have added more data privacy compliance policies to govern their operations.
Why?
Organizations often have multiple regulations and privacy policies to manage they are liable for to stakeholders.
Some organizations ( not just companies - NGOs, governments ) have misused consumer private data in many different ways.
While DID solutions offer many opportunities to improve data privacy protections for all stakeholders over existing solutions, each organization must determine the regulations and policies that apply and define how to protect and manage those rights.
How?
Management committees and compliance departments need to work with customers and other stakeholders to define the appropriate privacy policies for the organization. Business, IT architects and 3rd party service providers need to work together to define what the options are to implement privacy controls and the priorities to roll those out.
Secure Key One Time Password Tokens issued by Financial Firms
I think this question lends itself to a very high level overview of how multi-factor authentication (MFA) works. Of course, we have to skim over lots and lots of technical detail.
In short, here is what happens:
The bank programs the token with a unique encryption key. (In this case your Digipass token is made by Vasco, but there are many other companies that make similar tokens, which are "something you have" with regards to multiple factor authentication).
The token will generate a series of characters that are derived from the encryption key, current time, and (optionally) other various factors.
Since the bank knows the (unique) encryption key, and all other other factors that the token uses, they can reverse-engineer the input to find out who "owns" that token. If the owner of the token matches the owner of the bank account that is being logged-in to, then the login is authentic.
There are many variations on this central theme, but in general they always involve "something you have" (a physical token, or a smartphone app), a secret key stored within the token, and a mathematical algorithm to produce the output.
Often, time is a critical factor in generating the output. Depending on the algorithm, the output may be different every single time (in your case), or it may only vary occasionally (e.g. Every hour).
Potential Value Opportunities
Potential Challenges
Candidate Solutions
France delivers Digital ID app using SSI linked to ID card by NFC - 2022
France announces a new system for proving digital identity via a smartphone
The official announcement describes the details of the new app. SGIN will be based on the biographic data held in the new French ID cards launched in August 2021. It will only work with the new credit card-sized CNIe
It will not access the card holder’s biometrics, in France’s case images of two fingerprints. It is also not compulsory and allows card-holders to be selective as to what data fields they share for any transaction:
“The application allows the user, in particular, to generate electronic certificates comprising only the identity attributes which he considers necessary to transmit to third parties of his choice.”
The decree also stipulates how long data can be kept. It has been developed in light of EU regulations on digital identity and the free movement of data.
SSI - the best solution for CeDeFi
Centralized Financial services track data for KYC, AML supporting privacy regulations
SSI is the best answer to integrate with centralized financials services providing a solid identity foundation
enables regulatory compliance with the best identity, privacy protections
Think CBDC and data tracking
Add JVS - Jim's Vault Service - BYOR - You control your vault recovery design
Decentralized Financial services - Uniswap etc
Don't support regulatory compliance, KYC, AML well
SSI provides some level of privacy protection here
SSI benefits in financial systems
- NFT: SSI can solve the provenance issue with NFTs regardless of the ledger.
- Content: fully decentralised content consumption with payment and identity, i.e. consumption of media / content directly from the creator without a distribution channel. A possibility for creators to receive fair payments for their work and interact with audiences directly.
- InterPlanetary File System (IPFS) for controlled decentralised storage: SSI can be implemented to manage the data of participants and store distributed files with decentralised access control
- Payment verification: the risky nature of CeDeFi transfers has been holding back many users. There’s no way to further verify the identity of the payment receiver beyond the wallet address.
cheqd - a decentralized, permissionless payments framework with authentic data
cheqd, are building the payment rails for authentic data*. We want to make it as easy as possible to create authentic data ecosystems through customisable commercial models and governance structures, all built upon a public permissionless network with a dedicated token for payment
Why SSI needs a token for decentralized payment systems
https://blog.cheqd.io/why-self-sovereign-identity-needs-a-token-an-expanded-version-46e93e9f519f
traditional rails don't work when issuers and receivers of credentials are unlikely to have a direct contractual relationship since the user is at the centre.
SSI DID Services Providers
Sovrin
Trinsic.id
https://docs.trinsic.id/docs/tutorial
Trust.id
Verses
Civic
Uport
Step-by-step guide for Example
sample code block