In 2005, Kim Cameron, the former head of Identity at Microsoft, defined seven laws of identity1. Today we can relate them to SSI (self-sovereign identity — explained in the first blog). They are:
1. Law of User Control and Consent — Identity systems must only reveal users’ information with their consent. Therefore, the identity holder controls their verifiable credentials within their digital wallet in SSI.
2. Law of Minimal Disclosure For A Constrained Use — The identity system discloses the least amount of identifying information and limits its use, similar to zero-knowledge proofs in SSI.
3. Law of Justifiable Parties — The system is designed to disclose identifying information within the parties relevant to completing a transaction. In the SSI ecosystem, it is the Trust Triangle, the issuer, holder, and verifier.
4. Law of Directed Identity — A universal identity system prevents correlation handles. For public entities, it supports “Omnidirectional” identifiers and “unidirectional” for private entities. The SSI ecosystem prevents the discovery and correlation of identity information.
5. Law of Pluralism of Operators and Technologies — A universal identity system must enable a “metasystem” of multiple identity systems provided by different vendors to work together with a seamless experience. Interoperability is one of the SSI principles.
6. Law of Human Integration — The universal identity system must protect against identity theft and be reliable in the communication between the system and the human. The SSI ecosystem with cryptography on a decentralized network reduces identity theft.
7. Law of Consistent Experience Across Contexts — The unifying identity metasystem must provide a simple, seamless user experience across devices, separating context through multiple operators. In the SSI ecosystem, experiences will evolve as we build more use cases.
The concepts of decentralized self-sovereign identity (explained in the first blog) apply to the enterprise at various levels. Consider the organization as an entity with a digital wallet (described in the fourth blog). The enterprise has attributes such as business licenses that permit it to stay in business. These are verifiable credentials (VCs, explained in the fifth blog). Responses to audits and regulatory requirements are automated using claims from the corporate digital wallet (presented in the fifteenth blog).
Automating these processes is more efficient and effective with identity verification within a workflow. Consider business processes that traverse organizations or departments and require automated authentication and authorization. What if we eliminate the use of usernames and passwords? What if intelligent agents execute SSI processes within business rules? Filling out forms with identity data is automated while reducing friction in the experience. Human interaction is minimized to areas that need analysis. It reduces complexity and costs, improving customer experiences with a foundation built on digital trust. An organization uses a white-labeled platform provided by a vendor to run its identity issuance, management, and verification. With self-sovereign identity, the enterprise does not need to store more data than is necessary for a transaction — only responsible data. It reduces the risk for the enterprise and the customer.
Let us explore two use cases:
Supply Chain:
During the lifecycle of building products and in manufacturing, there are several stages where following and reporting on their journey are regulatory requirements. Along the route in the supply chain, documents certifying different aspects of the product are produced by manufacturers and required by the verifiers. Depending on the degree of automation, some papers are auto-generated with information (claims) from verifiable credentials. Regulatory documents vary by jurisdiction. With the help of a location application, attestation proofs are generated depending on the step in the supply chain lifecycle. If there are forms to submit, they are auto-populated with claims. The organization that creates and sells the products has information about the product for its customers. Customers and regulators use the VCs to certify aspects of the development as needed. It builds trust in the ecosystem about the source of raw materials and the quality of products where it is relevant. In the above, data verification, security and privacy are built-in. All this makes auditing more straightforward while reducing complexity.
Some examples of live verifiable credential systems in the Supply Chain include Farmer Connect in Rwanda, Vietnam, Brazil, Columbia, and Costa Rica. It enables farmers to use data from the supply chain to obtain credit. In addition, GLEIF (Global Legal Entity Identifier Foundation — explained in the tenth blog) enables Digital Commerce. GLEIF allows businesses to assert their identity by establishing a root of trust for interactions between companies globally.
Event Management:
The SSI solution is white-labeled for event management and attractions like conferences where personal identity data may be required to enter specific locations. The whole experience is made possible via a smartphone. Consider a user purchases tickets to an event using their phone and payment financial instrument from their digital wallet. Upon purchase, they can get proof of purchase using a QR code. The user may show the ticket and a photo ID at the time of entry to the event. Using the minimization principle and zero-knowledge proof, the user presents the ticket and their name and picture in one compound attestation proof. It protects their privacy — sharing what is necessary to complete the transaction. Imagine that the location application on the smartphone predicts that the user is at the event and knows the claims required for entry. The application creates the proof and presents it to the user. The user then accepts and shows it to the verifier at the gate while entering the event. Overall, it reduces friction and improves the user experience.
The benefits to the organization include:
· Improved customer experiences; create a permanent, secure, and private channel to interact with each customer using DIDs (decentralized identifiers explained in the third blog)
· Automated business processes that require credentials; reduced time to fill out online forms
· Digitally signed verifiable credentials (described in the fifth blog) can be certified by anyone
· Simple login for all customers, without username passwords
· Reduce theft of customer data from a “honey pot.”
· Improved operational efficiencies with cost reduction
For details on organizational wallets and roles, refer to the tenth blog on Digital Commerce.
In the next post, I will cover Adoption.
To reference previous posts refer to this link. Again, I would suggest reading the posts in succession.
Glossary
Agent
A piece of code associated with a wallet makes secure connections with other agents and wallets to share and communicate identity information to complete a transaction. It enables an entity to take on one or more roles in an SSI model –an issuer, holder, or verifier. There are two types: edge agents that run on a mobile device or cloud agents that run on a server in the cloud.
Blockchain
A blockchain is a decentralized ledger, which can be public, private, or hybrid. In decentralized identity, it can store a public DID, DID document, schemas, and formal descriptions of a verifiable credential, revocation registries, and proof of data sharing — however, the blockchain stores no PII (Personal Identifiable Information).
Claim
A claim is an attribute within a verifiable credential. For example, the Drivers License number in a Driver’s License is a claim, whereas the Drivers License is a Verifiable Credential (see below for a definition).
DID (Decentralized Identifier)
Like a Uniform Resource Name, a globally unique identifier that somebody can universally discover a DID on a blockchain using a method. A DID is an interoperable, open-sourced web standard delivered by the W3C2. Each DID is associated with only one DID document.
Digital Wallet
A digital wallet is software used to digitally store (usually in a smartphone) the contents of a wallet, like IDs, loyalty cards, and financial instruments used for payments. In essence, it is a digital version of a physical wallet.
Entity
A person, organization, or thing
Holder
An identity owner and user of a Digital Wallet where their credentials are accepted, stored, and controlled using verifiable credentials. The holder approves attestation requests from verifiers and delivers the same.
Issuer
An issuer is a credible provider of identification documents; their signature (key) attests to the credentials’ validity. Governed by Governing Bodies or Trusted Anchors, issuers can belong to an ecosystem of trusted entities that issue documents/credentials with claims data. Issuers have the infrastructure to access a public blockchain to issue and revoke credentials. The schema and their definition of credentials are on the blockchain.
Presentation or Proof
The proof attests a claim or compound claims from the holder to the verifier to prove some form of identification to complete a transaction. All are achieved without making contact with the issuer.
Verifier
A verifier is an entity that wants to verify claims from a holder to complete a transaction or event. The transaction uses a QR code at the endpoints.
Verifiable Credential
A credential attests authority, competence, or qualification given by an authorized party (issuer) to an entity (holder). It consists of metadata, claims, and proofs and has one or many claims related to an entity’s identity. It is to respond to attestations for evidence of a claim. Claims from multiple verifiable credentials consolidated to respond to a request for proof is called a compound verifiable credential.
References
1. https://www.identityblog.com/?p=352
Contact
Linkedin https://www.linkedin.com/in/anitarao/,
Twitter @anitaprao,
Blog https://rao-anita.medium.com/
#SSI; #decentralizedidentity; #blockchain; #digitalidentity; #selfsovereignidentity; #identity; #dlt; #web3; #web3.0; #dApps; #digitalwallets; #distributedledger
