search

hypersign-protocol / whitepaper

2 stars 0 forks source link

Research on SSI #21

Open Vishwas1 opened 2 years ago

Vishwas1 commented 2 years ago

Linked Issues

Problems

Explaining SSI by various vendors

Vishwas1 commented 2 years ago

DID

DID is a new type of globally unique identifier (URI) that does not require a centralized registration authority because control of the identifier can be proved using cryptography.

Verifiable Credential

Verifiable Credential (VC) is the new format for interoperable digital credential being defined by the W3C Verifiable Claims Working Group. Verifiable credentials conform to the W3C’s Verifiable Credentials Data Model, and they facilitate interactions using a pattern called the triangle of trust

Digitally signed verifiable credentials can cryptographically prove four things to any verifier:

Hyperledger Indy & Hyperledger Aries

https://github.com/hyperledger/aries#relationship-to-hyperledger-indy

Aries grew out of the work in Hyperledger Indy to create technologies for managing decentralized identity. Indy provides a specific blockchain purpose-built for identity. The tools created in Indy for building agents are being migrated to Aries, and extended to be blockchain-agnostic. Functionality related to the Indy ledger will remain in Indy.

as per stackoverflow question

Initial Aries work was to move the agent work in Indy to Aries, and so the first working versions of Aries use Indy underneath for the decentralized identity components. Over time, those components will become pluggable, and additional decentralized identity components will be supported. Thus, major parts of the indy-sdk will be deprecated, as they are implemented in Aries.

For building solutions, you should always be looking at Aries to start. You will need to know what Indy does, but not the details. The only time you would need to dive into Indy is if you what to extend its capabilities to support your use case.

Aim of Aries, obviousely, is to build an interoperable communication layer that can be connected not only to Indy but also others blockchains framework.

Evolution

For building a decentralized identity solution, Hyperledger Indy project was started. Evernym has donated the codebase to Hyperledger community and thus Indy was born.

In initial architecture, Indy was supposed to provide governance (Consensus), Verifiable Credentials, DID, and DID Communication between different entities and Hyperledger Indy has provided all the above except DID Communication which later gave birth to Hyperledger Aries.

image

Now the question is why don't Indy itself provide DID comm feature rather than relying on Aries?

  1. Hyperledger projects support plug and play architecture, detaching DID communication is a good decision for Indy to focus more on core identity party and Hyperledger Ursa was created for same reason to detach all cryptographic features from Indy.
  2. Identity is a fundamental right of citizens, so in later times there would be thousands of service providers who offer Identity solutions and Interoperability would be a key factor. Keeping in mind, building a Ledger agnostic based clients is a good idea where Aries not only support Indy but it will support other Blockchain ledgers too.

So, Indy is providing a core identity feature where Aries is just one of the clients who is availing those services. It is the same as the relation between Ethereum (Indy) and Web3 (Aries). For a development perspective, we need to be more focused on Aries to develop client apps.

Hyperldeger Aries

Although Indy is an excellent implementation of core SSI capabilities (ledger, verifiable credential model), it is not the only implementation. In the long term, it’s likely that there will be multiple implementations that are used by different organizations and communities. What if we had agents that could use DIDs and verifiable credentials from multiple ecosystems?

Features

Initially, the generic interface of Hyperledger Aries will support the Hyperledger Indy resolver. But the interface is flexible in the sense that anyone can build a pluggable method using DID method resolvers such as Ethereum and Hyperledger Fabric, or any other DID method resolver they wish to use. T

Hyperledger Ursa

Hyperledger Ursa is a shared cryptographic library that would enable people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process. The library would be an opt-in repository for projects (and, potentially others) to place and use crypto.

Ursa was created because people in the Hyperledger community realized that it would save time and effort and improve security if we all collaborated on our cryptographic code. Since cryptographic APIs are relatively straightforward to define, it would be possible for many different projects to utilize the same code without too much difficulty.

References

Vishwas1 commented 2 years ago

Paper Credential

UserId/Password credentials

Verifiable Credential

Do you trust the issuer and the process by which the issuer decided to issue the credential?

To trust the information in a credential, it is necessary that the verifier trust the issuer and that the issuer’s processes are carried out with integrity. For an official government-issued identity document (driver’s license, passport, etc.) that might be an easy decision. In many cases, the verifier will require the holder to present credentials only from issuers known to the verifier.

But what about use cases when the issuers may be from anywhere in the world, such as a university transcript? For example, when you get a verifiable presentation from Faber College that says Alice has received a degree and you verify the presentation, you will know that Faber did indeed issue the credential to Alice, that Alice did not tamper with it and it’s not been revoked. But is Faber College an authorized (and by whom?) degree-issuing entity or an unregulated diploma mill? Does it show that Alice legitimately earned her degree or did she pay $100 to be issued that degree? These same questions come up with both paper and verifiable credentials. However, with verifiable credentials some interesting options become available for automating the research into the “should we trust the issuer?” question.

Verifiable presentation data is proven without needing to call back to the issuer. Just as when you use your driver’s license to prove your age without a call back to the government, there is no need to call back to the government when you use the verifiable credential version of your driver’s license.

Paper based VC

While digital credentials are appealing, there will be in every nation a proportion of the population that does not have access to digital tools such as a smartphone. To empower that population, one idea that has been proposed is to use a W3C standard verifiable credential in a form that can be printed onto a piece of paper that it is impossible to forge. Photoshop will not help you make your own Dark Web “proof of vaccination” verifiable credential!

VCs on paper can be done in a couple of ways. If possible, the credential is embedded into a QR code to be scanned. The “if possible” comes into play because the capacity of a QR code (especially a printed one) is limited to about 400-500 bytes. Any more than that and the QR code is so dense that it can’t be read by a mobile phone camera.

Alternatively, the QR code can contain just a URL to a web service that in turns returns the presentation. This gets around the size of the presentation issue, but there are drawbacks, including that the URL must be unique per credential and timebased, and the issuer of the credential knows each time a credential is used. Those issues can be mitigated, but they must be considered in any implementation.

Paper verifiable credentials to eliminate forged documents without requiring everyone to use a smart device is an appealing approach—but the privacy implications must be kept in mind.

DID

Most identifiers that you use today are created or controlled by someone else.

User Control

If a central authority decides to take that identification away from you, they can remove your ability to use it. Since you created a DID and hold the private key(s) for it, only you can “delete” the DID. A DID (and DIDDoc) on a blockchain can never be removed, so “deleting” a DID really means no longer responding to requests for proof of control of the DID. Technically, you can update the DIDDoc to delete the public key(s), but assuming earlier versions of the DIDDoc are on a blockchain, those earlier versions are still available.

Provable

There are no easy, trusted ways for you to prove your control over commonly used identifiers today. From the list of identifiers above, the only ones that you are commonly asked to prove control over are your email address and phone number, and those have become prime targets for hackers, often by attacking the central authority that gave you the identifier. The association of public/private keypairs with a DID makes ongoing proof of control trivial.

Using the DID, the verifier can retrieve the DIDDoc and public keys to verify signatures and (if necessary) connect to the issuer and get information about who the issuer is, such as (likely using verifiable credentials) their authority to issue credentials.

Non-Correlatable

One of the problems with the common identifiers that we use today is that it is often necessary to reuse them. On almost every site we visit, we provide an email address so that the site can send us notifications. That means that many sites can share information about us just by correlating our email address. Since we create our own DIDs and choose how we want to share them, we needn’t have just one DID, but rather one DID for every service to which we connect.

image

The expectation is that you will have many DIDs—one for each relationship you have on the Internet. Note that both sides of a relationship provide a DID for the other to use to communicate with them, as shown below.

Secure Communications

If you think why everyone (services) needs our email/phonenumber? they want to communitcate with us , they want to promote their business. They want to notify about their services. Butthe problem is, they sell these emails to some other services without letting me know and now I start getting unwanted emails/calls from these services.

DID can also be used to send messages. SErvices can use my DID (which I had created specific to that serrvice) to send me promotion or notification and all. And say if they shared my DID with other services, and if they start messaging me unwantedly, I have ability to delete that DID and not use it ever again which I can not do in case of Phone number or email easily.

As described earlier, a DIDDoc contains public keys and service endpoints for the entity that controls that DID. This enables a powerful capability: a secure, end-to-end encrypted messaging mechanism. Given a DID and its corresponding DIDDoc, an entity can encrypt a message for the controller of the DID (using the public key in the DIDDoc) and send it to the designated service endpoint. Upon receipt, the DID’s controller can decrypt (using the corresponding private key) and process the message

Public vs Private DID

Public DIDs

A public DID is one that is intended to be widely available - visible to anyone that is presented with the DID. Since anyone can both resolve the DID and contact the owner, if the DID is used many times, it is correlatable. In this case, correlation isn’t a bad thing.

A company or government, for example, will often use public DIDs.

A prime example of a public DID is the DID of a verifiable credential issuer. Public DIDs are usually put on blockchains so that they can be globally resolved.

Private DIDs

On the other hand, an important use case of DIDs is that they enable two (or several) parties to connect with one another. In this case, it’s not important that everyone in the world be able to resolve the DIDs for the parties—just the parties themselves—and private DIDs (often called pairwise DIDs) are used.

Instead of publishing the DIDs on the blockchain for anyone in the world to see, the entities create the DIDs and DIDDocs and then send both directly to the other party(ies) to hold.

If they need to update the DID, such as to change the endpoint, the update is sent directly to the other party(ies) to update their copy of the data.

Why are private DIDs important? There are two reasons:

        1. First, since the DIDs are only intended for use by a small, specific group (usually just two), the DIDs are not shared beyond that group.
        2. Second, writing to a blockchain is expensive and by not writing DIDs that don’t have to be public to the blockchain, the costs (resources, time, transaction fees) are reduced.

When DID and VC are used

  1. DIDs are used to establish secure, point-to-point messaging channels between the agents of the participants.
  2. In this use of DIDs, there are no verifiable credentials involved, just messages encrypted and sent to participants using the information in the DIDDocs (notably, public keys and endpoints) to allow a sender to encrypt (using the recipient’s public key) a message to the recipient and send it (using the recipient’s endpoint). The recipient must have the associated private key to decrypt and process the message.
  3. Second, with a verifiable credential, DIDs are used as the identifier for the issuer. The issuer DID is used to uniquely identify the issuer and is resolved to get a public key related to the DID.
  4. That public key is then used to verify the data in the verifiable credential did indeed come from the issuer—to check the cryptographic signature using the public key of the DID.

image

ZKP vs non-ZKP proof

In the non-ZKP model, the DID of the holder/prover is included in the credential and hence any verifiers of the credential know a common, globally unique identifier for the holder/prover, which is a privacy concern as it is a point of correlation.

A ZKP still exposes the data asked for (which could uniquely identify the prover), but does so in a way that proves the prover possesses the issued verifiable credential while preventing multiple verifiers from correlating the prover’s identity.

image

Selective Disclosure

Claims from verifiable credentials can be selectively disclosed, meaning that just some data elements from credentials, even across credentials can (and should be) provided in a single presentation. By providing them in a single presentation, the verifier knows that all of the credentials were issued to the same entity.

Combined, ZKPs and selective disclosure enable a massive reduction in the data exposed during an identifying process.

Vishwas1 commented 2 years ago

image https://dev.to/jakubkoci/hyperledger-ssi-ecosystem-4j2p

Vishwas1 commented 2 years ago

HL-Indy

Hyperledger Indy is the core component of Hyperledger’s identity system. Indy provides code that implements the public distributed ledger technology (DLT) and the code to build applications that interface with the ledger.

Indy-sdk

The indy-sdk consists of a series of modules written mostly in the programming language Rust that are compiled into a "C-callable" library (called "libindy"). C-callable means that the library components have a standard interface such that they can be called from a majority of languages (Java, C#, Python, JavaScript, etc.), eliminating the need for an implementation in each language.

Core to the indy-sdk is the code that enables an Indy agent to interact with an instance of an Indy network. The newer indy-vdr component does just that, leaving secure storage, verifiable credential handling and so on to go into other components.

A surprise for many that are new to Indy is its ledger does not support any form of querying by value or discovery. For example, you can’t just make a single query on an Indy ledger to get a list of all of the DIDs on the ledger. Use IndyScan as explorer (https://indyscan.io/home/SOVRIN_MAINNET)

In the common cases, the agent must know about the transactions of interest on the ledger either because that agent wrote the data in the first place, or because the agent is configured (“hardwired”) to know about the transaction.

Setup Indy SDK in linux

Indy-vdr

As noted, the only feature of the indy-vdr component is to provide an interface (can also be called resolver) to read and write to an Indy ledger. Having it in an isolated package makes it easier for an Aries agent to use it to integrate with an Indy ledger alongside resolvers for other ledgers.

Storage

In the “next generation” of Indy components, there is no secure storage at the Indy level. Instead, an Aries component called aries-askar implements secure storage for Aries agents, handling both Indy and non-Indy data.

Both aries-askar and the Indy wallet sub-component of the indy-sdk provide a pluggable API for data storage, meaning a capable developer can create another storage implementation should they need one.

Indy-shared-rs

Indy verifiable credentials (“AnonCreds”) handling is currently built into the indy-sdk, and is the major subsystem of the new indy-shared-rs software. In both, the code is used to create credentials to be issued, generate presentations to be provided to verifiers, and to verify those presentations upon receipt.

indy-node & indy-plenum

Putting all these together

image

Vishwas1 commented 2 years ago
Vishwas1 commented 2 years ago

Aries

How do all those different agent makers build agents that will work with all the other agents in the world?

Further, what if you decide you want to switch from the agent you have now to a new one that is even better?

You must be free to take your credentials and related data, move them to another agent and continue to use them.

Those are the challenges that started the Hyperledger Aries project. Aries is about collaborating to define and share the message exchange protocols, an agent architecture and tests that enable organizations to independently build agents that work together.

Since there are other verifiable credential ecosystems being developed in parallel to Hyperledger Indy, Aries is also intended to be “verifiable credential-agnostic”—the architecture of Aries should be able to support different verifiable credential implementations within a single agent

Agents deals with messages

Interoperability

Indy is not the only game in town when it comes to DID and verifiable credential implementations. With a goal of global use of verifiable credentials (and all the goodness that it brings), it’s crucial that interoperability across different Aries, DID and verifiable credential implementations be a goal.

The Aries architecture defines how different implementations can be plugged into an agent to support Indy and other DID and verifiable credential implementations at the same time.

The goal is to bring developers from these communities together to extend Aries to enable verifiable credential interoperability.

Vishwas1 commented 2 years ago

Hyperldeger Indy Blockchain

Since Indy is focused only on identity, it does not support the concept of assets being exchanged nor any sort of smart contract capability.

It does have multiple, (largely) independently operated nodes that write transactions to the ledger. The nodes communicate to agree (reach consensus) on what transactions should be written and in what order.

Although assets are obviously not the purpose of an Indy ledger instance, there is a capability in Indy to support a pluggable implementation of a payment token.

What type of ledger is Indy?

Permissioned public ledger:

image

Indy is designed to be operated such that everyone can see the contents of the blockchain (public), but only pre-approved (who are these guys?) participants, known as stewards, are permitted to participate in the validation process (permissioned).

Indy steward nodes reach consensus collaboratively, while monitoring each other for faulty or malicious behavior.

Although Indy is designed to be run as a public network, an instance of Indy (or any other public blockchain) could be run as a private network accessible only to those using the network.

Consensus

Indy uses Plenum, an implementation of a Byzantine Fault Tolerance (BFT) algorithm. BFT algorithms are designed to achieve consensus when many of the nodes are not operable or accessible. The number of faulty nodes (f) in a properly operating BFT network is f = (N -1)/3, where "N" is the total number of nodes in the network.

Plenum implementation has been found to be useful enough to be separated out from the core Indy code base into a separate repo that is used by Hyperledger Indy—and can be used by other blockchain implementations.

Stewards

Stewards: the nodes of the network that have permission to participate in the validation process

The validation process needs enough stewards to be robust in the face of faults, but not too many as to degrade the performance in reaching consensus. Interestingly, those testing the performance of Indy have found that the sweet spot is 25 nodes—robust, able to survive the failure of eight nodes, but fast enough to support the expected number of write transactions on the network—on the order of 10s of transactions per second.

Vishwas1 commented 2 years ago

Course

Vishwas1 commented 2 years ago

What goes on blockchain? & cost

When you present claims for a credential to somebody in a proof, you don’t want the verifier to go to the issuer to ask, “Hey, can you confirm this information?” Just as when you go into a pub and have your driver’s license validated, you don't want the bartender calling the government to ask, “Can you confirm this person is over 18?”

So what goes on the ledger?

Cost of writing the Sovrin ledger

image

image

That’s a total of $105US for an issuer to begin issuing credentials, plus an ongoing annual cost of $40US for DID updates and revocations.

Cost of using some Indicio network

https://indicio.tech/indicio-testnet/ image

Networks similer to Sovrin

Vishwas1 commented 2 years ago

image