Digital Identity Research Notes

Only one level of assuranceOnly applies to individuals, not businesses or organisationsDoes not allow delegation orintermediaries.Each "account" is tied to a single IdP.Still only being used for interactions with central government.

OverviewThe Sovrin Governance Framework is the legal foundation of the Sovrin Network as a global public utility for self-sovereign identity. It is developed by the Sovrin Governance Framework Working Group (SGFWG), currently chaired by Sovrin trustee Drummond Reed. Each new version is approved by the Sovrin Foundation Board of Trustees (BoT) to become the official set of governance documents for the operation of the Sovrin Ledger and the Sovrin Network.The first version, the Sovrin Provisional Trust Framework, was approved by the Sovrin BoT on 28 June 2017 and has been operational since the launch of the Sovrin Provisional Network on 31 July 2017. The second version, now called the Sovrin Governance Framework V2, has been under development by the SGFWG for the past year.

The “constitution” of the Sovrin Network, this document defines the purpose, core principles, and core policies, and also references all other documents in the SGF V2, including all the Controlled Documents listed in Appendix A.

The legal agreement between the Sovrin Foundation and [each] Sovrin steward.

A comprehensive glossary of over 200 terms used throughout all the SGF V2 documents and all of Sovrin infrastructure.

The governance policies that apply to all of the Sovrin Governing Bodies.

Covers reading and writing to the Sovrin Ledger.

Covers qualification, application, activation, operation, suspension, and termination of Sovrin stewards.

Covers the security, node operation, node selection, and reporting requirements for Sovrin stewards.

Covers economic incentives, fees, and regulatory compliance.

Covers use of the Sovrin Trust Mark by stewards, agencies, and developers.

This document defines criteria and processes for assessing conformance of different Sovrin actors to the policies of the Sovrin Governance Framework.

Source: EvernymModel #1: Siloed / TraditionalHow it WorksTraditional, “siloed” identity is the simplest of the three models: an organization issues to you (or allows you to create) a digital credential that you can use to access its service.Trust between you and the organization is typically established through the use of shared secrets, usually in the form of a username and a password, but sometimes extending to other “secrets” such as your birthday, mother’s maiden name, PINs, and so on. Sometimes shared secrets are augmented with additional factors such as physical tokens or biometrics.At least some of your personal data, whether shared by you or obtained from other sources, is typically stored within the organization’s data “silo,” a scenario that repeats for every organization, app, or website you log into. As a result, this model requires you to create and manage separate credentials for each relationship.This is the oldest digital identity relationship model and by far the most commonly used today.ProsThe primary advantage of this model is that it is widely established, well understood and straightforward to use.It helps the organization manage compliance, liability, and other risks by “keeping subjects close,” keeping data in-house, and directly controlling all the actors and workflows, which reduces risk when compared to relying on a third-party identity provider (Model #2 below).More advanced, FIDO-compliant implementations of siloed identity can eliminate the need for passwords by registering specific devices, which can then be used with a biometric or PIN.Siloed identity also enables pairwise (unique) credentials for each relationship, which enhances both security and privacy as long as usernames and passwords are not reused.ConsFrom Gartner:“Organizations require these digital identities before they can offer their services or allow any access to their resources. It is common for people to lose track of their siloed digital identities or not even have the ability to control their identity profile in many of these organizations. Both people and organizations increasingly feel the pain, and learn that this model is neither scalable nor sustainable as the use of digital services become more pervasive.” (emphasis added)As the Equifax and other hacks clearly show, the breach of an organization using siloed identity can be catastrophic, exposing the personal data of millions.The siloed identity model has the worst customer experience of the three identity models. It forces you to maintain dozens or even hundreds of credentials — one for each app, service, or relationship — resulting in forgotten passwords and, worse, reused passwords, which lead to further security lapses. It also requires organizations to treat customers like strangers at the beginning of each interaction.The siloed approach to authentication is one-way (open to phishing) rather than mutual, session-based rather than persistent, and doesn’t work well for the Internet of Things because it was designed for people.With siloed identity, each organization must become somewhat of an identity and security expert, which can be a challenge for churches, local governments, schools, credit bureaus, and, frankly, most organizations. The result: over $4 trillion in annual fraud-related costs worldwide.

Source: EvernymModel #2: Third-Party IDPHow it WorksThe IDP relationship model adds a third-party company or consortium to act as an “identity provider” (IDP)¹ between you and the organization or service you’re trying to access. The IDP issues the digital credential, providing a single sign-on experience with the IDP which can then be seamlessly used elsewhere, reducing the number of separate credentials you need to maintain.It works like this: you log in to the IDP, which then “federates” your login to the service you’re trying to access using protocols such as OAuth, SAML, or OpenID Connect. Trust between you and the IDP is maintained in the same manner as in siloed identity — typically through shared secrets — and may be fortified with additional factors to provide a higher level of assurance to the organization. Identity data is centralized in the IDP.A common example of the IDP model is “social login” on the Web using your Facebook, Google, Twitter, or other social ID to access a third-party service. With social login, one of these tech giants serves as your IDP, but this option is acceptable only in lower-trust environments such as e-commerce, and not in high-trust environments such as banking.ProsIn lower-trust environments, IDP-powered social login enables users to access many applications with a single credential, simplifying authentication, reducing usernames and passwords, and improving customers’ experiences. In high-trust environments the IDP model has the potential to do the same — if it can garner more widespread adoption.ConsThe primary downside of the IDP model concerns high-trust applications, because a third party is inserted into the middle of every interaction, saying “Trust me.”The ceding of control and transfer of liability required in this three-way trust model is quite thorny. This is why, despite years of ongoing government efforts in the U.S. (NSTIC) and the U.K. (Gov.UK Verify), this model has not achieved significant adoption for high-trust, cross-context applications, such as using a bank credential at more than one bank.²This model often forces users to create a new relationship with a potentially unfamiliar IDP, separate from and in addition to the organization with which they’re trying to interact. The IDP becomes a large trove of personal information, storing credentials and other data for all its clients’ employees and customers. The IDP also determines the limitations of data structures and schema and must maintain direct connections with all network participants, inhibiting flexibility and scalability. And as we’ve seen in the recent Facebook scandal over Cambridge Analytica, it is the IDP that sets the policies and goes about enforcing them (or not).As with the siloed approach, authentication in the IDP model is one-way rather than mutual (doesn’t prevent phishing), session-based rather than persistent, and sequential rather than parallel; and it doesn’t work well for authenticating organizations or things (needed for Internet of Things applications).

Model #2: Third-Party IDPHow it WorksThe IDP relationship model adds a third-party company or consortium to act as an “identity provider” (IDP)¹ between you and the organization or service you’re trying to access. The IDP issues the digital credential, providing a single sign-on experience with the IDP which can then be seamlessly used elsewhere, reducing the number of separate credentials you need to maintain.It works like this: you log in to the IDP, which then “federates” your login to the service you’re trying to access using protocols such as OAuth, SAML, or OpenID Connect. Trust between you and the IDP is maintained in the same manner as in siloed identity — typically through shared secrets — and may be fortified with additional factors to provide a higher level of assurance to the organization. Identity data is centralized in the IDP.A common example of the IDP model is “social login” on the Web using your Facebook, Google, Twitter, or other social ID to access a third-party service. With social login, one of these tech giants serves as your IDP, but this option is acceptable only in lower-trust environments such as e-commerce, and not in high-trust environments such as banking.ProsIn lower-trust environments, IDP-powered social login enables users to access many applications with a single credential, simplifying authentication, reducing usernames and passwords, and improving customers’ experiences. In high-trust environments the IDP model has the potential to do the same — if it can garner more widespread adoption.ConsThe primary downside of the IDP model concerns high-trust applications, because a third party is inserted into the middle of every interaction, saying “Trust me.”The ceding of control and transfer of liability required in this three-way trust model is quite thorny. This is why, despite years of ongoing government efforts in the U.S. (NSTIC) and the U.K. (Gov.UK Verify), this model has not achieved significant adoption for high-trust, cross-context applications, such as using a bank credential at more than one bank.²This model often forces users to create a new relationship with a potentially unfamiliar IDP, separate from and in addition to the organization with which they’re trying to interact. The IDP becomes a large trove of personal information, storing credentials and other data for all its clients’ employees and customers. The IDP also determines the limitations of data structures and schema and must maintain direct connections with all network participants, inhibiting flexibility and scalability. And as we’ve seen in the recent Facebook scandal over Cambridge Analytica, it is the IDP that sets the policies and goes about enforcing them (or not).As with the siloed approach, authentication in the IDP model is one-way rather than mutual (doesn’t prevent phishing), session-based rather than persistent, and sequential rather than parallel; and it doesn’t work well for authenticating organizations or things (needed for Internet of Things applications).

Source: EvernymModel #3: Self-Sovereign / Peer-to-PeerHow it WorksSelf-sovereign identity is a two-party relationship model, with no third party coming between you and the organization, now considered your “peer.”SSI Wallet and Verifiable CredentialsSSI begins with a digital “wallet” that contains digital credentials. This wallet is similar to a physical wallet in which you carry credentials issued to you by others, such as a passport, bank account authorization, or graduation certificate, except these are digitally signed verifiable credentials that can cryptographically prove four things to any verifier:Who (or what) is the issuer;To whom (or what) it was issued;Whether it has been altered since it was issued;Whether it has been revoked by the issuer.³You can also carry self-signed credentials in your wallet, such as your preferences, opinions, legally binding consent, or other attestations you’ve made about anything.Verifiable credentials can be issued and digitally signed by any person, organization, or thing and used anywhere they are trusted. SSI is as strong as the credentials it contains, strong enough for even high-trust industries such as finance, healthcare, and government. Organizations can choose to trust only credentials they have issued, credentials issued by others, or some combination, according to their security and compliance needs.Out-of-Band ConnectionTo exchange digital credentials securely and privately, one peer — any person, organization, or thing — can establish a direct, encrypted connection with another peer. This connection can remain persistent (as opposed to session-based) at the option of each peer. Trust is mutually established when peers use this connection to exchange credentials and verify the digital signatures on received credentials using a distributed ledger.⁴ ⁵ You control what you share with others, whether an entire credential, part of a credential (called “claims”), or zero-knowledge proofs (ZKP) derived from a credential (explained below).Real Self-SovereigntyYou are literally the sovereign owner of your SSI wallet and the credentials inside: No one can “turn the lights out” or take them away from you without your consent. As in the real world, issuers can revoke credentials they’ve issued, but you’ll still possess them and they can continue to be useful, just as an expired driver’s license can be used to prove your age. With verifiable credentials, however, a new recipient will know when you present it whether or not it has been revoked, without needing to contact the issuer.SSI is becoming standardized and interoperable, and it is portable, with no vendor lock-in. Real SSI is not dependent on any particular company or other entity, as apps and agencies are modular and replaceable. Switching from one service provider or agency to another does not result in losing one’s credentials, relationships, or history.ProsContrary to popular belief, we don’t have to wait for SSI to be ubiquitous before gaining a large chunk of its benefits. As we’re learning from most of our clients and the use cases they have brought to us, we can begin benefiting right now, with “Single-Source” SSI.“Single-Source” SSITwo common (and contradictory) misperceptions about SSI are:It only involves self-asserted claims;It only involves third-party claims.What many critics miss is SSI’s powerful ability to operate between those extremes, for relationships between just two parties, where the only credentials an organization will accept are those it issued in the first place.This is precisely how most identity interactions work today: you can only use your bank login at the bank, your student ID at the school, your Costco credential at Costco. Surprisingly, most of the benefits of SSI still apply to these, the most common identity relationships:Stronger authentication: Because shared secrets can be replaced with cryptographically secure, digitally signed credentials, you can exchange far stronger credentials, and more of them.Great user experience: Because authentication can occur out of band, you can open an app and already be signed in, or call your bank’s customer service without answering silly questions about your birthday, mother’s maiden name, SSN, and other personal info.Phishing prevention: Because authentication is mutual, when you get a suspicious call or message from someone, you can know for sure who it is, because you can authenticate your bank as strongly as they can authenticate you.Private communication channel: Because the out-of-band connection between SSI peers is private and secure — no intermediaries, encrypted end to end — it can be used for communication of any kind: text, voice, video, data sharing, and more. (Great for millennials, who hate email.)Better relationships: Because authentication happens passively behind the scenes, customers can be recognized and no longer treated as strangers at the beginning of each interaction, enabling a rich customization of each and every touchpoint.Same liability model: Because a bank, for example, can choose to accept only digitally signed credentials it has issued, SSI is no different than siloed identity from a liability perspective, meaning financial institutions and companies in other high-trust industries can utilize SSI without legal or compliance concerns.Of course, once you have credentials in a self-sovereign wallet they’re yours to keep and use with anyone who trusts them, whether that’s one verifier or many.Multi-Source, Multi-Verifier SSIAs remarkable as it would be just to regain control of our identities within distinct relationships, the most exciting version of SSI goes much further. It envisions a world where any person, organization, or thing can issue any kind of credential to any other person, organization or thing (“multi-source”), which can then be shared with any other person, organization, or thing, and the authenticity of which can be immediately and easily verified (“multi-verifier”).The advantages of such a world cannot be easily overstated. With everyone having a wallet full of cryptographically verifiable credentials, simply having someone’s personal information would no longer be sufficient to impersonate them, raising the bar quite high for account take-over, phishing, fake news, or most forms of fraud; even spam becomes much more difficult. Add on top the benefits of having authenticated, peer-to-peer connections with every person, organization, or thing with whom you have a relationship, literally forming a newly decentralized web, built on open-source protocols and with no tech giants needed as intermediaries. It would improve almost every digital interaction.Obviously, there is a massive chicken-and-egg problem to overcome — an obstacle between our world and that one called “network effect.” Network effect is your friend and accelerator as a new technology gains momentum, but your nemesis at the beginning: imagine having the world’s only fax machine versus working in the only office without one. We got over that hump with important new technologies like the telephone, the fax machine, and most crucially the internet, and we’ll get there with SSI. Based on the activity we at Evernym are seeing around the world, we’ll get there more quickly with SSI than most believe, because our world is more connected than ever, and the pains SSI addresses — fraud, security, privacy, compliance, user experience — are reaching a crescendo.Legal Identity, Pseudonymity, and AnonymitySSI has the important ability to strongly prove legal identity when desired, or enable trustworthy pseudonymity or anonymity when preferred. SSI that uses zero-knowledge cryptography opens up an entirely new world of powerful, private interactions, including:Websites and other services can verify that patrons are of a legal age, without needing name, location, age, or even birthday;Individuals can prove that they are employees of a certain company, or citizens eligible to vote; that they have a certain credit score; that their anonymous tip or whistleblowing is credible, etc., all without revealing their names, addresses, or other personal data;Pharma companies can have direct, private connections with patients who have verifiable prescriptions for their medications, without knowing who or where those patients are;When privately selling a car or other property, owners can prove their legal ownership without revealing any personal details;Internet users can participate pseudonymously in gaming, social, or other online communities.Other BenefitsSSI has many other benefits for people, organizations, and things. Some of the biggest are:SSI simplifies and strengthens compliance with GDPR, KYC, AML, HIPAA, COPPA, and other regulations by eliminating intermediaries and ensuring cryptographically provable verification and consent.SSI can prevent unwanted correlation by third parties, and even among colluding second parties, by incorporating pairwise identifiers, powerfully addressing this known privacy problem common to blockchain technologies;SSI provides participants in witness protection programs and intelligence operations with cryptographically strong credentials;SSI can work offline as well as online, creatively utilizing smart cards, QR codes, NFC, Bluetooth, and other technologies.Each of these benefits deserves further discussion and consideration, which we’ll provide in future posts and papers.ConsSeveral of the capabilities discussed above aren’t necessarily exclusive to SSI. Verifiable credentials, zero-knowledge proofs, and even mutual authentication, for example, could theoretically be built into non-SSI solutions, though I have never seen or heard of any such solution. And while, as footnoted, not all SSI solutions include all of these capabilities, at least one SSI system —Sovrin— was designed from the ground up to include all of these capabilities natively.SSI is new and different than the way things are currently done, and that alone creates friction. There are switching costs of several kinds, including: modifying internal systems to issue claims and credentials and verify the same; upgrading user interfaces to replace usernames and passwords with the exchange of claims and proofs;⁶ slowly replacing email as a means of communication; and educating and training staff, customers, and others.Then there’s key management, potentially the Achilles heel of all blockchain technologies. With bitcoin, for example, if you lose your private keys you lose your money, period. There is no “forgot password” option. SSI solutions will need a crutch analogous to password recovery if they are to become widely adopted. SSI systems that use pairwise identifiers, such as Sovrin, will generate hundreds or even thousands of private keys for people and organizations to manage, magnifying the need for comprehensive key management.

Oliver Terbu, January 27 2019https://medium.com/decentralized-identity/the-self-sovereign-identity-stack-8a2cc95f2d45The intended goal is to outline the different layers of compatibility that have been discovered which could break interoperability and eventually portability of SSI.UsagesWhile this document outlines these layers as being decoupled, it is possible that layers may be coupled to achieve simplicity, scalability, or usage of other standards. Whatever the reasoning may be, it is possible that an SSI stack can be achieved while coupling these layers. An example of how this may occur is through JWEs. If JWEs were used, they would define the Encoding and Encryption layers by adapting the specification that is already outlined. Additionally, DID method specs could stretch over the DID resolution, DID operations, DID storage, and Anchor layers. This is acceptable assuming that it allows for interoperability and portability still.Application LayerThis layer intends to provide real-world value to consumers. This layer should be the integration of a UI layer, implementation interfaces, and payload structures. Additionally, the “message flows” or “subprotocols” are optionally open-source or proprietary message protocols which will define how the implementation interface and payload will be used in combination with a UI/UX layer to create an application or extension that relies upon SSI.Implementations LayerThe Implementations layer is a way to wrap the layers below in an easy to consume library or service intended to run “standardised” interfaces. Underneath the standard interfaces may be different optimisation strategies for synchronisation and communication, while still allowing for interoperability and portability of data and applications. Examples that are being worked on are DIF Hubs, Indy Agents, and the uPort app which encompass many different aspects of the layers below. Implementations will be extensible through the creation of non-standard payloads that can be used by a developer to easily integrate SSI into their projects.Payloads LayerPayloads are intended to be standardised or proprietary message families (a set of standardised or proprietary schemas) which will be used to pass data between identity owners. Payloads enable the richness of applications to exist like they do today while being able to strongly identify users through the other layers. It’s expected that payloads can be either proprietary or open source standardised formats depending on the needs they’re serving. For example, a standardised admin payload would be open sourced to remotely control an implementation which is hosted on a different device. On the other hand, a rideshare service could develop proprietary message flows to develop their ridesharing service on top of SSI. Additionally, the structures of the format of the schemas must be considered at this layer. Currently JSON-LD, JWT, and CWT (COSE web tokens) have been options that have been discussed.DID Authn LayerThis layer is focused on proving control of a DID based on verifying ownership/access to keys listed in its corresponding DID Document. It aims to address how two DIDs using different key suites can negotiate proof of control and authentication. Within the community, many different methods for proving ownership of a key have been discussed. These are described in theSpring 2018 DID-Auth document.Encoding LayerWith the encoding layer, the purpose is to focus on how data at the encryption layer and the payload layer will be encoded. It is likely that multiple encoding schemes will be required depending on other layers. For example, to send a message through a URL, the encryptedJWEmight be Base64URL encoded and embedded in the URL. Alternatively, if the message is being sent through an HTTP request, it may be passed as aJSONstructure. Some other options that may fit in this layer areProtoBuf,Cap’n Proto, andMessagePack.Encryption LayerThe encryption layer determines how messages, data, and other related payloads are encrypted between two or more devices owned by an identity owner. Additionally, this layer determines the method in which two identity owners can encrypt messages between themselves to create an end-to-end encryption model between two or more devices running either the same or different implementations. This layer should also define the cipher suites that are used and how the cipher suites are agreed upon. Some current examples of standards that currently cover this (and other layers) are theJWEspecification. Cases that would fall under the cipher suites part of this layer would be XSalsa20-Poly1305, AES-GCM, XChaCha20-Poly1305, etc.Transport LayerThis layer is intended to outline the different types of transport layers which are supported. In some implementations (e.g., uPort, Indy agents) it’s been discussed that the transport layer should be transport agnostic (supports any transport protocol) whereas, in other implementations, it may be limited to one or a few transport layers. This layer is important to consider as it will affect the ability to send messages between two identity owners. Some examples of transport layers which have been considered are QR Code, HTTP, BLE, NFC, FTP, SMTP, and Avian Carrier.DID Resolution LayerThe DID resolution layer is intended to cover how a piece of software or a developer who is writing software can convert a DID into a DID Document and ultimately get the cryptographic keys, service endpoints, and additional metadata that describe usage of the DID. Currently, there’s a few ways that resolution can occur. One of the ways that has been worked on recently is the Universal Resolverwhich is a service that can be locally ran or queried through a HTTP service. Additionally, an SSI stack could use a native method of DID resolution that is defined in a DID method specification.DID Operation LayerIn the DID operation layer the concerns focus on how to perform CRUD (Create, Read, Update, Delete) functionality on a DID Document. This is something that is defined in a DID method specification, but without a standardised method of operation it will create challenges an implementation developer to achieve portability. Some examples of where these are being defined can be found in theW3C draft DID method registry document.DID Storage LayerStorage of DIDs and DID Documents are sometimes handled in this layer. Typically, this is used when a DID method has separated the storage of the DID Documents and DIDs from the trusted network which resides at the DID Anchor layer. Examples of this may be the sidetree protocolor could be built directly into the Anchor layer as is the case withVeres.Oneand Sovrin.DID Anchor LayerThe Anchor layer is focused on the network which provides the environment where DIDs live. It is usually used to validated the DIDs onto the ledger to give a state of the DID to those who have access to the ledger. The differences in this layer typically come from a difference in architectures of the network. Examples of different anchor layers would be Bitcoin,Ethereum,Veres.One,RChain,Sovrinetc.

DIF represents a diverse, international collection of organizations and contributors working together to establish an open ecosystem of decentralized identity that is accessible to all.

A key piece of the decentralized identity equation is how people, organizations, and devices can be identified and located without centralized systems of identifiers (e.g. email addresses). DIF members are actively working on protocols and implementations that enable creation, resolution, and discovery of decentralized identifiers and names across decentralized systems, like blockchains and distributed ledgers.

Secure, encrypted, privacy-preserving storage and computation of data is a critical component of decentralized identity systems. As with identifiers and names must be self-sovereign to the owning entity, a user's identity data must remain private, only accessible to the entities they allow. DIF members are actively developing specs and reference implementations for provider-agnostic, run-anywhere solutions that provides these features.

The ability to verify the claims and assertions of identities is key in establishing trust among entities on a decentralized system that lacks a centralized hierarchy. DIF has recently begun work on defining the specs, protocols, and tools it can provide to the ecosystem to help ecosystem participants and their customers easily integrate DID-signed claims into their apps and services.

As Agent work continued with the development of message encryption standards, extensible message typing, and common protocols, interest grew in applying these concepts and practices to systems based on other ledgers. It became clear that the right future for Agent work was to extract it from Indy project and add support for other ledger technologies to make that integration easier and more powerful. That work is now known as Hyperledger Aries.In addition to being able to support more ledger technologies than just Indy, Aries can work with multiple ledgers at the same time. This allows Agents to use each ledger according to the unique power offered by each, instead of requiring anchoring to only one ledger. In the future, Agents will be able to integrate not only with the recently announced Ion DID method, but also Ethereum, Hyperledger Sawtooth, Bitcoin, Hyperledger Fabric, and others.-- Sovrin Blog