a Andrew Stephen 5 éve
456
Még több ilyen
Wallet
Connect.Me
Infrastructure
Hyperledger Aries #blockchain #interoperability
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
Hyperledger Indy #blockchain #ledger
Self-Sovereign
Source: Evernym
Self-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 Credentials
SSI 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
that can cryptographically prove four things to any verifier:
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 Connection
To 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
(ZKP) derived from a credential (explained below).
Real Self-Sovereignty
You 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.
Contrary 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” SSI
Two common (and contradictory) misperceptions about SSI are:
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:
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 SSI
As 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 Anonymity
SSI 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:
Other Benefits
SSI has many other benefits for people, organizations, and things. Some of the biggest are:
Each of these benefits deserves further discussion and consideration, which we’ll provide in future posts and papers.
Several 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 —
— 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.
Implementations
Veres One
Jolocom
uPort
Decentralized Identity Foundation
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.
Working Groups
Storage and Compute
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.
Claims and Credentials
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.
Identifiers, Names, and Discovery
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.
What
Technical Specifications
Industry Coordination
Reference Implementations
How to Own Your Identity on the Internet in 2019
A Gentle Introduction to Self-Sovereign Identity
Self Sovereign Identity — a guide to privacy for your digital identity with Blockchain
Self-Sovereign Identity Stack
Oliver Terbu, January 27 2019
https://medium.com/decentralized-identity/the-self-sovereign-identity-stack-8a2cc95f2d45
The intended goal is to outline the different layers of compatibility that have been discovered which could break interoperability and eventually portability of SSI.
While 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.
This 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.
The 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 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.
This 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 the
.
With 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 encrypted
might be Base64URL encoded and embedded in the URL. Alternatively, if the message is being sent through an HTTP request, it may be passed as a
structure. Some other options that may fit in this layer are
,
, and
.
The 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 the
specification. Cases that would fall under the cipher suites part of this layer would be XSalsa20-Poly1305, AES-GCM, XChaCha20-Poly1305, etc.
This 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.
The 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
which 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.
In 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 the
W3C draft DID method registry document
.
Storage 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
or could be built directly into the Anchor layer as is the case with
and
.
The 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,
,
,
,
etc.
Self-Sovereign Identity
Subject Controlled
Web of Trust
Rebooting Web of Trust
Zero-knowledge proof
Decentralised identifiers
W3C Verifiable Claims Data Model
Understanding Decentralized IDs (DIDs)
W3C DID Specification
Source: Evernym
Model #2: Third-Party IDP
The 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
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
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.
In 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.
The 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. (
) and the U.K. (
), 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).
Social Login e.g. "Login with.. Facebook, Google"
Protocols
SAML
The 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
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
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.
In 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.
The 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: Evernym
Traditional, “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.
The 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.
From 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.
Examples
Local login
Description
Characteristics
Solid POD
Personal Online Data
Tim Berners-Lee @timbl
Demo
WebID-OIDC
Based on OpenID Connect
WebID-TLS
TLS + certs without PKI
How DIDs, Keys, Credentials, and Agents Work in Sovrin
Sovrin: A Protocol and Token for Self-Sovereign Identity and Decentralized Trust
Sovrin Network: What Goes on the Ledger?
Sovrin: Digital Identities in the Blockchain Era
The 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.
Compliance
Trust Assurance Framework
This document defines criteria and processes for assessing conformance of different Sovrin actors to the policies of the Sovrin Governance Framework.
Legislative
Controlled Documents
Trust Mark Policies
Covers use of the Sovrin Trust Mark by stewards, agencies, and developers.
Economic Policies
Covers economic incentives, fees, and regulatory compliance.
Steward Technical Policies
Covers the security, node operation, node selection, and reporting requirements for Sovrin stewards.
Steward Business Policies
Covers qualification, application, activation, operation, suspension, and termination of Sovrin stewards.
Ledger Access Policies
Covers reading and writing to the Sovrin Ledger.
Governing Body Policies
The governance policies that apply to all of the Sovrin Governing Bodies.
Glossary
A comprehensive glossary of over 200 terms used throughout all the SGF V2 documents and all of Sovrin infrastructure.
Consitutional
Steward Agreement
The legal agreement between the Sovrin Foundation and [each] Sovrin steward.
Governance Framework Master Document
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.
Informational
Web of Trust Model
Accreditation and Onboarding
Usability and Accessibilty Requirements
Technical Integration testing Requirements
Service Operations Testing Requirements
SAML 2.0 Profile
Risk Management Requirements
Protective Security Reviews
Protective Security Requirements
Privacy Requirements
OpenID Connect 1.0 Profile
Identity Proofing Requirements
Fraud Control Requirements
System Governance Interim memorandum of Understanding
Authenticaiton Credential Requirements
Attribute Profile
Accreditiation Process
Overview and Glossary
Model
Draft Recommendation
Papers and Submissions
Digital Identity Ecosystem Principles
Overview
