 Okay, why don't we go ahead and get started? And if people join us here in a minute, we'll just bring them up to speed. So thank you for joining. My name is David Boswell. I'm the senior director of community architecture here at Hyperledger. Before we get into Alexander's presentation, though, I did wanna share just a couple of resources around decentralized identity. If you're really interested in this topic, there are other places where you can go into the community. I'm sure we'll cover some of those in the presentation, but I did wanna point out just a couple of things. And here, let me share my screen. Just so you're aware. This hopefully is the start of a conversation. We invite you to get involved in the community. After the end of this meetup, that's not the end of the opportunity to talk to other people in the community about decentralized identity. There are a couple other places that you may want to consider checking out. And again, Alexander will cover some other ones, but didn't wanna point out a couple of things before we get started, just so you're aware. There is a regular meeting of the Identity Special Interest Group that is an open call where you can get involved. This is a really nice overview of everything going on in the space. It's an opportunity to meet other people doing things with the technology. So if you're interested in what Alexander shares today, please do consider joining the Identity Special Interest Group. And I dropped a link to that in the Zoom chat. And then if you're interested in some more of the technical details about what will be covered today, we do have a technical workshop coming up at the end of May that's gonna be talking about using the Hyperledger non-credits project to issue verifiable credentials. That's an open workshop. If you're really interested in the nuts and bolts and the technical details of some of this technology that we're gonna cover today, feel free to take a look at that workshop. So again, we hope that this is the beginning of a conversation that we will have with you on the topic of decentralized identity. So thank you for joining. And with that, let me hand it over to Alexander Sherbakov. He is the principal software engineer at DSR Corporation. Has a lot of experience with the technology, a lot of experience in Hyperledger around the different decentralized identity technology such as Hyperledger Indy, Hyperledger Aries, et cetera. So I'm excited to hear what he has to share with us today. And with that, Alexander, please take it away. Thank you. Thank you, David, for the introduction. So let me share my screen. Okay, can you see it? Yes. Okay, perfect. So thank you all for coming today. I'm going to discuss what I'm going to discuss today as a topic of decentralized identity or self-suffering identity. It's about kind of summarizing the years of development and this technology. And also one of the interesting things is how decentralized identity is related to the blockchain because it's quite interesting relationship. Before we start just a couple of words about us. I'm working at DSR Corporation. DSR, his main headquarter is in Denver, Colorado. And DSR has been serving the companies for more than 25 years since 1998. Last year, DSR joined the Hyperledger Foundation. DSR has about 11 technical departments like wireless embedded, web, mobile, computer vision, artificial intelligence and one of the important department is a blockchain and decentralized identity one. So David already introduced me. So I've been working with decentralized identity and blockchain technologies for more than seven years. And during this years, I had an opportunity to work and contribute to such important Hyperledger projects as Hyperledger India, Eris, Ersta. And my main goal today is to share my experience and hopefully describe what self-soring or decentralized identity is. What are the key technologies? What is the stack? We also are going to discuss some use cases and applications, frameworks, and as I mentioned before, what is the relationship between SSI and the blockchain technologies? Okay, so again, why we are talking about decentralized identity? I mean, DSR, we have a department devoted to decentralized identity and blockchain. And we've been working with these technologies for more than seven years. We contributed a lot in such projects as Hyperledger India, Ersta, and some other projects based on these technologies. Also, as I mentioned, we are the members of Hyperledger Foundation. And well, let's start with the basics. What is the digital identity? So we all have an identity in a real world, like we have NIC documents, we have ourselves, we have some physical stuff representing us. But nowadays, more and more processes go to internet and we are now more online than offline. Moreover, we have the whole internet of things. So it's not only about identity of persons, it's about identity of things, devices. By identity, we can understand a set of attributes related to an entity or to some agent representing this entity, which can be a person, organization, device, application. Basically, we can consider three models of digital identity. The first traditional centralized model is when we have a centralized organization which manages our identity, the data associated with us. Usually, the most common way to authenticate and authorize is to use some logins and passwords. And of course, it's usually a mess because we have to remember so many passwords, so many logins and we don't have almost no control about our representation of us within these organizations. So it's far from being perfect in terms of privacy, in terms of UX and so on. The second model is leveraging some identity providers. We can call it a federated identity. An example, when we have a provider and we have a way to sign in with the same credentials to multiple places, usually based on allows, open ID connect technologies. This is probably better from the UX point of view for the end users since we may not need to remember so many passwords, but still in terms of the privacy and control of our data, it's still not perfect, still not perfect because most of information about us, it's not controlled by us, it's stored somewhere on some services. And what is so unique about the third approach? We can call it decentralized identity or still storing identity. The core thing here that it's decentralized, it's usually peer-to-peer and there is no central entity which has a control about our data. So two persons to agents can communicate with each other and they have a full control of how the data is stored, shared, organized. And in order to still have some trust in verification, usually distributed ledgers and blockchain technologies can be used as a source of trust. And the core difference here that distributed ledgers, they are decentralized and it sounds like a nice way for putting a trust there, but still the whole communication, it's much more, much better in terms of privacy. Another picture comparing the non-SSI versus SSI worlds. In non-SSI, usually we have multiple representations of us, so basically on every service, on every website, we have different representation which is stored on this website. So it's not good from UX, from privacy points of view. In self-serving identity, we are at the center of communication, we control all the data and it's up to us how we use and share this data. And also what is important that the self-serving identity is a decentralized identity way, it's much better compliant to GDPR and other standards which are currently present in European Union, US, such as California and so on. As for how exactly it works and what are the concepts between these just magic words. There are two main definitions that should be familiar with, it's verifiable credentials and the centralized identifiers for DAG. Both of these standards have been developing for a number of years, but now they are part of that with 3CE and they are now a recommended standard. So I would say that the maturity this year has increased quite significantly. And let's start with the first concept, it's called verifiable credentials. Well, first of all, let's discuss what is credential itself. In this context, credential is a set of one or more claims about an entity made by some issuer. For example, for a person this claim can be like, let's consider passport, an ID, like a name, birth of date, date birth, address and so on. And basically we have credentials like a physical documents in the real world and you should have the same, but in internet, in online world. Then the next concept is verifiable credentials. Basically it's the same claim, it's the same credential, but with some tamper evident properties so that it can be verified that this credential is really true, it's really issued by a particular issuer and we can trust this information shared by the owner. And the second important concept here is the decentralized identifier, DAG. The centralized identifier can refer to any subject like personal organization theme. And the main difference that unlike some common identifiers, decentralized identifiers are the couple from centralized registries, identity providers and so on. Well, we'll discuss in more details what exactly it mean but in order to better understand how it will work together and what exactly is decentralized as an entity, let's look at the following picture. It shows these concepts in action. Usually what is important in decentralized identity is three actors, it's issuer, holder and verifier. The holder is a person like someone who actually owns that claims the credentials. Issuer is an organization or a person who issues these verifiable credentials and they're usually signed by some keys. And usually these keys are associated with some DID called DID1 here. So that's where we can see how verifiable credentials and DIDs work with each other. So the issuer has a DID, the DID has some metadata and keys associated with this. And these keys are used to sign some verifiable credential. And then this verifiable credential is sent to the holder and holder can store it, can process it. And usually the holder may also have another DID, DID2, this example and verifiable credential can be associated with this particular DID. And the verifier, the verifier, it's an entity who would like to know something about the holder and the holder can present the information from the verifiable credentials to this verifier. A verifier can do necessary steps and check that this information is correct. But it's important that it's not necessary that the whole credential is shared. It can be a different presentation. We'll talk a bit further. For example, some principles of selective disclosure can be used so that not all the information is shared or some predicates can be used in presentation. For example, the holder can prove that it's over 18 years old without disclosing the exact age. And in order to make this all work, in order to verify this presentation, there needs to be a place to store public keys and other metadata. And this place is called verifiable data registry. In many cases, in many cases, blockchain or distributed ledgers play the role of verifiable data registers. Part is important here that there is no link between verifier and issuer. So it's a process of presentation. The verifier doesn't need to communicate with the issuer in order to check this information about the holder. So it's kind of peer-to-peer, pairwise in these cases. Issuer talks with holder. It issues credential. Then holder talks with the verifier, presents the credential. And verifiable data registry as an independent source of trust is used for verification. Just another example, concrete example of these principles. Let's assume that the issuer is a university. The holder is a student, a future doctor. And the verifier is a hospital. Where the students like to be an employee. So the issuer can, the university can issue like a certificate, a diploma to the holder. And the holder can go to the hospital and present a valid diploma or certificate that's a real doctor and he can go there. No error between issuer and verifier, right? Because both of them just the issuer puts some public key to verifiable data registry, such as blockchain. And verifier can just read these keys from the registry or from the ledger from the blockchain. Okay, now let's discuss a couple of use cases and applications. Some popular applications, especially if you start looking at some demos or pilots for example, a very popular use case is to prove that you're over 18 years old. If you need to go to the store and buy something, it's one of the ways where predicate and selective disclosure can be useful. And for example, applying for a job, graduation, apply for a loan, you need to prove an employment, traveling. You can also show a valid ticket or proof of edit visa. There's a number of use cases which can be applied to multiple domain areas. For example, no customer use case. It's when these checks are done once and some credential is issued and then the same credential can be reused with another verifier without a need to redo these KIC checks again. Pass or less authentication it's one of the ways when you can just kind of skunk your code and use verifiable credentials, DIDs for this process. And the provenance origin of data. It can appear in multiple use cases related to IoT, manufacturing, whatever. Verifiable credentials and these principles can be applied not only to persons, not only to human but also to a thing, to a device for example and for example it can be used to prove that a particular part, particular device is verited, not counterfeit and can be trusted, can be used. One of the important places for adoption of these technologies is government based government related cases. For example, digital ID, digital passport it's one of the things there's a number of pilots in the world where these principles are being used. For example, in Canada one of the good references here where these technologies have been running in production. Business regulation certificates that's another thing where verifiable credentials can simplify the process of regulation to reduce bureaucracy. Proof of ownership. There can be a credential proving that you own this property and again it's good from the UX point of view from no customer point of view. Trial and transport. Part of use cases. Trial pass especially popular use case where the ticket can be actually verifiable credential and it's especially actual other checks which needs to be done together with this trial pass. For example, during pandemic time usually a vaccination certificate and proof of vaccination was needed. And it's using the sell certain density concept was a nice way to implement these principles and there were a number of real applications which implemented it. So you have one credential like a COVID vaccination and the second credential is a travel pass and it can easily be verified as an airport, gate and you can board. Healthcare. Yeah, again during the pandemic time vaccination it's important thing but it's not only about the vaccination medical prescriptions. It's also quite important information about the person that actually only the person should handle should control. So it makes perfect sense to use verifiable credentials for these kind of use cases. Medical records, again that's something belonging to the user to its identity and users should be in full control of these records. Delivery of medicine it can also be used. Then a set of use cases related to banking know your customer procedures loan applications authentication for example like ATM authentication business in a chart, business cards entrance passes prove that you're a real employee of some company that's all a nice ways to use verifiable credentials. Merchant use cases password less authentication when you go to the website and you can just scan a QR code and establish a relationship with this store. With this relationship it's possible to do secure chatting it's possible to integrate payments maybe to have some discounts proving that for example your employee of particular company and this company provides a discount for their employees. And IoT and manufacturing I already mentioned the device provenance origin delegation of access authentication and authorization of devices it's all also valid cases here. So now let's look at the SSI stack so we're going more details how this will work so we just previously discussed the concepts decentralized identifiers and verifiable credentials but let's see how these concepts work in more detail details. A very nice representation of this stack we can use a trust or IP stack with four layers on layer 4 on layer 4 we have the applications, ecosystems domain areas like healthcare, supply chains, whatever and real applications on layer 3 we actually have these credential exchange examples. It's where we have verifiable credentials it's where we have issuer holder and verifier where issuer creates issues, signs the verifiable credential holder owns and presents it to verifier and on this layer also there can be exact mechanisms and protocols how to exchange these credentials, what are the steps initiatives, what are the steps and verification, what are the formats of messages and so on. Okay, but layer 3 here these messages, these protocols these credentials they are transferred from issuer to holder and holder verify by some magic way and actually layer 2 answers the question how exactly what is this magic way of communication and as I mentioned one of the core properties of decentralized social identity that it's usually peer-to-peer and some peer-to-peer communication connection is established between the entities between the agents they consume this picture so usually between issuer and holder and holder and verifier they have to separate pair-wise connections and all the protocols all the messages they are sent on top of this connection and this is where actually the DITCOM DITCOM happens since we have two LEDs for example for issuer and for holder can be pair-wise LEDs or some other LED methods and authenticated encryption principles are used to make sure that the data through this connection is encrypted, is authorized and is properly secured and on layer 1 on layer 1 we have public utilities as I mentioned before in order to be able to do verification of signatures and proofs we need to have access to public keys shared by the issuer for example and that's where we may have these blockchains, ledgers which may contain this information like public keys the ID documents, the ID metadata and now let's look at every layer in more detail so we refabric credentials so we already discussed the main concept and this is a picture like the most famous picture from the W3C standard describing the workflow of refabric credentials we have these three entities again like issuer holder verifier issuer issues credential holder tours credentials and can present the presentation to the verifier and we have a refabric data registry as a source of trust which can maintain the schemas of the credentials and can maintain the identifiers and associated metadata like public in this W3C schema there is an error from holder that it can register identifiers that use schemas actually, especially in the indie and areas world usually a pairwise or peer identifiers are used so the holder is not necessary to write some data for example to the ledger to the blockchain but for issuers it's quite common that they use verifiable data registry just ledger or blockchain to put some TIDs and keys there so as for the refabric credential type so we have hyper ledger indie we have W3C refabric credential we have a number of various protocols and basically we can consider four types of refabric credentials, sometimes they are called credential flavors three of them are based on W3C standard this is JSON-LD with LD signatures like more or less common standard signatures JSON-LD with BBS plus signatures support zero-knowledge and GVT, JSON plus GBS which is also part of the standard and the fourth type, the fourth flavor of the refabric credentials is STL-ANUNCRATS for zero-knowledge and predicate historically STL-ANUNCRATS the first implementation was part of hyper ledger indie which is one of the main hyper ledger projects and these two standards were developed in parallel there are goals to converge them eventually but basically even now I believe for these four types they kind of established and every type has their own consent pros and depending on the use case, depending on the exact needs and requirements one of these ways can be chosen before we compare them in more details let's just discuss the concept of selective disclosure and predicates let's assume we have a credential we have some claims like ID of the holder name, address, date of birth some other metadata and we need to present something to verify what selective disclosure means that we are not forced to present and disclose all the data for example we can disclose only the nickname and that can be enough for the verify so the goal here is to disclose only the minimal required information which is needed to verify for this particular use case moreover predicates we can prove not just some data which is some value which is in the claim itself we can prove some predicates for example that the age is greater than 20 years like in this example and it's even better in terms of the privacy in terms of security and sharing really the minimally sufficient information this is the principle it's quite important, selective disclosure and predicates now let's look at this comparison table so we have these four flavors that we discussed just in LDLD proof just in LDBBS plus DUT and STL Anarchret as I mentioned before the first three are based on double S3C recommended standard STL Anarchret it's also mentioned there but basically there is now a separate Anarchret standard and by the way it mentioned there will be an upcoming webinar event devoted to this new initiative but historically it's not new as I mentioned the first implementation was done in Hyperledger in the later become part of Hyperledger ERSA so it's quite standard with major implementations and been used in many use cases so, selective disclosure and predicates are two concepts that we just discussed as you can see selective disclosure is available for BBS plus and STL Anarchret it's not available for common GUT or for just in LDLD proof in these two types you have to disclose all the information which can be a problem for some use cases but can be perfectly fine for other use cases predicates the only type of credentials that support it is STL Anarchret so for other types it's not available right now again if the use case requires a need for a predicate well, STL Anarchret is a good option if it's not needed which can be also true for some use cases other credentials may also work fine sterilization JSON LD is used for the first and second flavors and just the common JSON is used for GUT and STL Anarchret cryptosignature for JSON LD basically we can consider it like a more common digital signatures is an elliptic curve or like RSA and for BBS plus it's quite a new standard but very promising which allows to use selective disclosure and zero knowledge proofs GBS it's also quite common standard for devotee and for Hosea family of standards and for STL Anarchret it's quite unique it's based on zero knowledge proofs and its implementation now is available in Hyperledger URSA as part of Hyperledger URSA and it's leveraged by many other frameworks let's consider four more columns criteria here credential schema we discussed previously that credential is some set of attributes like name whatever but what exact set of attributes because it's pretty important in the use cases to understand what is the set of the attributes what are possible values what are restrictions it's important for interoperability it's important for the verifier to understand what to expect what data to expect it's important to the holder also to know what format of credential will be and for JSON JSON-LD we can say that JSON-LD context by itself provides some means, some set of attributes credential schema plus optionally JSON schema can be used as well in addition to this for JWC JSON based JSON schema can be used here and for CL Anarchret it's kind of the part of serialization but for CL Anarchret it's a bit different since there a dedicated a schema object needs to be created and the schema object defines a set of attributes for the claims, for the credentials usually the schema is put on the ledger, becomes public for example it can be put to hyper ledger in the ledger the next important criteria is how issuer shares the public key because as I mentioned in general any credential any claim needs to be signed can be more or less common standard cryptography or it can be more advanced, there are knowledge proof based cryptography but the main principle of need for a private and public key usually for all four types of credentials and is any asymmetric use cases there needs to be a way to share this public key and in standard JWC credentials usually it's assumed that the public key is the one associated with the DID to DID it's not just identify it also has the metadata like the document which may contain the public key which may contain the public key and in many cases usually these DID and DID docks are put on the ledger to make it public so that any verifier can resolve it can resolve it from the ledgers and do the necessary verification of features for CL and CRATS it's also a bit different there is a dedicated object which is called credential definition which contains a public key for the issuer which is used by the issuer to sign the credentials usually in addition to credential definition issuer should also have a DID and DID dock which both of these things usually put on the ledger for example in upper ledger indeed a third important criteria is we have a credential but it's pretty important to link this particular credential to this particular holder so that issuer needs to make sure that it's really issued to this holder and later on only this particular holder for whom it's issued can present it and in case of doublet we see credentials the first three flavors usually the holder creates a DID the corresponding keys can be either pairwise or it can be put on some public ledger and the holder can prove the ownership of this keys by some signature against this DID in the presentation so for example when the holder presents a claim to the verifier it needs to be two signatures the first signature from the issuer and the second signature is from the holder proving that the holder really owns the key associated with this very fabled credential and for CL Anocrates again it's a bit different the concept of the concept of linked secrets is used and this secret is just one key which is used during the issuance process and it links every particular credentials to this particular holder so only the person who knows a linked secret can create a proof, can create a presentation for the verifier and also it's important that it can create combined multiple credentials from even different issuers it can all link them all to a particular holder so that multiple credentials from different issuers can be used in the same presentation in the same proof and the last criteria it's revocation in many use cases the credential itself it should not be issued forever there should be a way to revoke it, for example a driver license is a good example that in case of some issues it can be revoked but in some credentials revocation can be achieved just by having the corresponding fields in the credential itself like a timestamp, for example after this timestamp the credential is not valid anymore but in many cases a real more advanced revocation which is initiated by the issuer of the credential needs to be present and for the first three types of credentials usually the status list standard is used for orientation for revocation it's non-anonymized basically basically it's kind of a list of indices of credentials that's revoked and the verifier can check it and make sure that credential is not revoked for CL and CRATS the anonymous approach is used it's based also on quite advanced cryptography, zero-knowledge proofs and accumulators and well it has some cons and pros for example it supports anonymous revocation as I mentioned but it's quite heavy for example it requires the holders to store quite significant amount of data on their side in order to be able to prepare these anonymized proofs of non-revocation and the next important point on this layer is exchange protocol for verifiable credentials because there is credential, there is some cryptography we know how it's kind of signed but properties are there but how exactly the issuer can give this credential to the holder how exactly the holder can give this credential presentation to verify this is very important for interoperability to define the standard so that the holder can work with multiple issuers, with multiple verifiers multiple implementations from multiple vendors so interoperability is pretty important here and hyperledger errors the first set of protocols one of the main goals of creation of hyperledger errors was actually the goal of standardization and creation of interoperable protocols which can be implemented, can be multiple implementations there is a set of areas RFCs which define these protocols and concepts and there is a number of implementations here we can distinguish errors, interoperability profile version 1 and version 2 so there is a set of tests which can prove the interoperability between various implementations and frameworks and this includes like issuers protocol presentation protocols protocols for established connections out of band protocols for mediators and so we can add a lot of them but with SWAT is important that as soon as protocols are implemented correctly and the test pass different implementations can work together in interoperable way the next family of protocols as part of destroyer identity foundation particularly did convit 2 has been developing there and there is a presentation exchange protocol and the corresponding issuers with three protocols and so on which is basically kind of advancing what is in areas is more details and the third way here is OpenID OpenID connect for refurbished credentials these principles has also been developed for quite a long time and now they are becoming more the main idea here is to let the users the business who got used to OpenID to easily smoothly integrate the centralized identity into existing use cases basically leveraging the same technologies right because there refurbished credentials can be issued as part of as part of usual OpenID or as workflows and refurbished presentations can also be shared into the same principles okay so now let's move to layer 2 of our trustworthy stack so we discussed the credentials we discussed multiple ways how credentials can be exchanged and now the channel how exactly it can be exchanged on this layer we have like agents and we have pairwise connections in Ditcom so basically on this layer we established a secure private communication channel which is built on top of DADs and Ditcom this picture shows what exactly this pairwise connection mean for example we have Alice and Bob as we hear as to peer to peer interaction and Alice and Bob create a new pair of DADs for this exact communication so for example if Alice would like to communicate with Carol it will be a different set of DADs and keys so usually it's peer to peer of course it can be extended to have like three parties participating in the same channel but in most of the cases it's usually just two and once these peers are exchanged Alice knows the DAD and the key which should be used to send messages to Bob and Bob knows the DADs and keys to be used to send the messages to Alice and they can establish a secure connection and start exchanging some messages during this channel during this channel so basically they are doing authenticated encryption so it's encrypted only by Bob only for Bob by Alice right and Bob can check it and as for what kind of messages are there it can be any messages for any protocols basically any protocols well in this case it's just game but in our use cases by protocols it can be the protocols for issuance and verification of credentials for example if Alice is a issuer and Bob is a holder then Alice can send messages for the issuance protocol like proposing a credential Bob can confirm accepting this credential then Alice can send the credentials itself and so there is some state machine basically which is defined as part of this protocol and finally layer one so we are talking about DADs quite a lot and now let's look in more details what exactly it is as I mentioned it's part of the level you see standard and basically usually DAD consists of two main parts it's DAD method and method specific stream like unique identifier this DAD method usually defines how exactly the DAD should be resolved and handled what are the set of rules what kind of verifiable data registry can be used and so what is important here that DAD it's not just identifier like UUID it's also a set of metadata we call it DAD document which can contain for example servicing points which can contain some keys for different purposes and this is the names this is the examples for example we can define the keys to be used for secure connection for key agreement key exchange we can define the keys used for authentication we can define the keys to be used for assertion we can define the service some endpoints so this is quite important the dockets set of metadata associated with the DAD which is put on some verifiable data registry and it can be used to establish pairwise connection to sign the verifiable credentials and so on just to summarize again where exactly DADs appear in our use cases for the issuer usually issuer has a DAD and corresponding D document contains a public key and the corresponding private key is used to sign the verifiable credentials indeed DDoC public key usually they are public and put on some ledger for the holder for the holder the holders DAD can be used as part of verifiable credentials so that these verifiable credentials is associated with these holders with this holders entity and the proof of ownership of this DAD can be created by signing using the corresponding private key of this DAD of some nouns so it usually is done during the presentation during the presentation holder can prove to the verifier that the holder really owns the DAD mentioned in the verifiable credentials right so credential is issued for particular holders DAD and during presentation holder can prove that he really owns this DAD this DAD can be public in some use cases so it can be put on the blockchain in some cases it's okay it's sufficient to use just a private DAD like pairwise pure key DAD so there is no need to put it on the ledger and DAD methods just a couple of examples actually the full is not the full is but it is most of DAD methods that can be found here in this specification and there are more than one hundred different methods for example DAD solve DAD indeed they they describe how the IDs can be created on top of hyper ledger in the solving networks or checked network it's also a ledger for identity use cases DIT key DIT peer in these entities usually the DIT dog this keys metadata it's kind of encoded into the DID identifier string itself so for DIT key basically there is no need to have a dedicated place to store DIT dog because once you have a DIT key you can decode it and you get the whole DIT dog you can get the whole public keys DIT peer is basically the same but DIT peer also has some strategy for updating this information like for key rotation making changes in DIT dog and corresponding metadata and basically there are DAD methods for maybe most of well-known distributed ledgers blockchain to root the corresponding DIT dogs and metadata on these ledgers and blockchains okay so SSI and blockchain again just to make it clear how these concepts are related to each other so what is the more important blockchain is basically optional in many SSI cases you can see that in this trust or IP technology stack blockchain appears only on layer 1 on public utilities it can be one of the implementations one of the ways for verifiable data registry what is usually stored on the blockchain what is usually stored on the blockchain for example in case of hyper ledger indie, hyper ledger areas issers, public keys issers, DIT, DIT dog it's usually put on the blockchain then credential schemas as we have seen in the case of sale and crash hyper ledger indie credentials there is a need for a dedicated object which can define the schema of the credential and it's usually put on the ledger and revocation registry it's also quite common to use a ledger as a source of trust for revocation for example in hyper ledger there is a number of transactions for this purpose what may be stored on the blockchain optionally holders, DIT, DIT dog public keys they can be stored on the blockchain but it's not mandatory in many cases just to per vice DIT is enough and finally what is never, never stored on the blockchain it's of course private keys link secrets and very fibrill credentials very fibrill credentials the very fibrill credential is never stored on the blockchain it's stored usually in the user's wallet like edge wallet mobile phone or maybe some cloud wallet properly encrypted but it's never stored on the blockchain since very fibrill credentials the whole concept of self-sorting identity that it should be owned by the holder only so it's stored only in the place where holder has access to it should not be public it should not be public public here is only like public keys, credential schemas some information which can safely be shared and well, the last section that we are going to look at today is frameworks the main frameworks in SSI world let's start with the SSI ledgers because as we have seen although basically the ledger, need of the ledger is optional but in most of the cases we do need a ledger as a source of trust to share in the public information and one of the most popular ledgers is Hyperledger Indie and for example the Sorya network which is based on Hyperledger Indie there is a number of other networks deployments of Hyperledger Indie not only Sorya like this service Sigaf and so on but they all use the same code from Indie the second well now ledger is checked Indie it's public permissioned ledger but checked it's public permission less ledger based on proof of stake with some crypto tokens involved it's based on Cosmos SDK and basically checked supports for example Ciel Anonkrat supports WFC credentials so all the main use cases and credential fliers are supported by this ledger then the next examples are like ledgers for example Ion Sytree protocol Bitcoin Ethereum network one of the concepts there that in many cases in SSI we don't need a full ordering of everything but it's sufficient just to have the order within the domain of particular DID user keys for example are rotated there and can be used to create quite efficient solutions which I just need to anchor to layer one blockchain like Bitcoin from time to time but don't need to have a global ordering of all the events there and as for SSI framework itself which implement all the building blocks for decentralized identity so it's not only the ledger corresponding to cryptography API wallets protocols and so on Hyperledger Indy was historically one of the first implementation it became part of Hyperledger in 2017 and later on in 2019 Hyperledger Ares appeared and last year a new grad initiative Anonkrat was also established Hyperledger Indy it's a gradated project but it's important it consists of two main parts this is the ledger and the client SDK Indy implements all three layers of the trust over IP models that we just seen the ledger the credentials the corresponding protocols the Indy SDK is written in Rust there is a number of wrappers for many popular languages including mobile the main and the only type of credentials that Indy supports it's CL Anonkrat sorry it was historically the first deployment of Indy ledger and well Indy SDK it's quite monolithic library that contains the code for communication with the ledger code for revival credentials, the wallet and so on and now a new generation of SDK SDKs have been created for example Indy VDR it's just focused on communication with the Indy ledger Ares Ascar it's a new wallet which is being adapted by many Ares framework Indy Shader Ares Anonkrat Ares it's also some implementation related only to CL Anonkrat's credential independent of the ledger independent of the protocol and so on so it's kind of the trend here to break this model and the many Hyperledger Ares projects already adapted to these new libraries then Hyperledger Ares it's as I mentioned is a graduated project as well and it was created in 2019s what is the core thing in Ares it's actually the specifications that RFCs the set of interoperable protocols concept and there is a number of implementations of these specifications in various programming languages for example ECAPI, Ares Cloud Python, Ares Framework Go Ares Framework JavaScript .NET, Ares VCX Rust Implementation also we have frameworks for creation of mobile applications mobile orders such as Ares MyFold Ares Mobile Legends React Native Ares Mobile Legends Semary and in order to make sure that the frameworks are interoperable important part of Ares is Ares Agents Test Harness many implementations are based on Hyperledger Indy under the hood and use Indy ledger as primary one now there is ongoing effort and trend to be ledger agnostic and to use the new ledger independent CL AnonKratz implementation and specification so we can see that this kind of feature from monolithic Indy to Ares and to AnonKratz it's been developed being adapted right now and I believe the community has a pretty good progress here and AnonKratz it's a ledger agnostic specification incubating Hyperledger project created last year AnonKratz Ares it's a Rust implementation with wrappers for popular efforts and there is ongoing effort to migrate areas many areas implementation to this new CL AnonKratz instead of Indy okay that's all that I have for today thank you digital identity decentralized digital identity decentralized identity okay thank you Alexander for your presentation I'm sorry Elvis are you asking something about decentralized digital identity okay please put your question in the chat so we can understand you more more clearly okay my name is Anton Verimyanian and I'm a PR specialist at DSR and now I suggest we will move to our QA session well first question about from Jimmy Dorsey what is new with AnonKratz David basically shared the link about it but maybe Alexander you can something to add yeah so as I mentioned AnonKratz historically was part of Hyperledger Indy and the corresponding cryptography is implemented in Hyperledger Ursa which is shared library graphic library Hyperledger and historically this implementation was coupled with Indyledger and Indyproject which is good on one hand since it provides a tool set of AZCAN tools for creation of decentralized identity as a site-based application so all necessary tools are there but on the other hand of course in terms of better interpreterability, better adaption it's good to support different ledgers it's good to support different methods and one of the goals for this initiative is to make it ledger agnostic there are kind of two generations of revival credentials the CL AnonKratz 1 which was regenerated as part of Hyperledger Indy RS and W3C credentials and of course it would be great to converge them eventually so that they're better interoperable with each other and can work together so this is also a goal and to make sure it's better addresses the current needs standards and converges this as for the implementation it's supposed to be more granular compared to what is in Indy so that it can be used as a independent of other parts of the ecosystem ok thank you Leksandr one more question from Benjamin this time how can an issue verify that the physician's diploma submitted online is not counterfeit in other words how can the DT issue verify if you're submitting a forged certificate for example a passport for a photo faked in Photoshop on the first submission yes yes but it's also important in these four layers this stack is kind of the governance procedure and the ways how to establish this trust so in particular for example let's assume we have an issuer right and the issuer can put it's DID to be used for issuance to a ledger and it's assumed that it needs to be a prestigious and trust to know that this particular DID belongs to this particular issuer and can be trusted there are some standards for example well-known DID which helps to associate for example a domain with a particular DID so for example there can be like GVT object assuming that this domain like example.com associated with this particular DID which can be used to issue refund okay thank you and I can see that Brett raised his hand maybe we'll have a live question right now Brett you can unmute yourself thank you this question may go toward Dave Boswell about the handbook is there a way to get the indie handbook you're talking about indie documentation yeah yeah that's what Daniela Barbosa said is a handbook let me get a couple links thanks here there's an there's a wiki for indie just like all the hyperledger projects have a wiki page with links to different relevant resources that may be what you're looking for if not just Brett Pingme and Zoom Chat I'm happy to share some other links as well okay perfect thank you thank you David and thank you Brett for your question one more question from Suresh what would be possible to access the slides after the session please yep sure we'll share the slides Jim Dorsey where are the public keys stored in the Aries mobile wallet where would I find them okay so if I think they're talking about the holder part since usually the mobile wallet is used by the holder like in this t-shirt holder verifier thing and it depends on the type of the refiable credentials but let's assume we use TL-Ironcrats indie types of credentials and they're basically here methods are used to establish that connection right so the corresponding public keys doesn't need to be stored somewhere on the blockchain they just stored in the wallet and exchange during the connection establishing process for the holder for TL-Ironcrats there is no need to store anything on the blockchain everything can be stored locally in the wallet including the private key secrets and the corresponding public keys are also just exchanged and stored there thanks, Alexander one more question right now from Suresh why is Hyperledger coming should Jimmy go ahead well I was wondering where the sorry is that two computer going so I'm just wondering since I'm running an instance of a VON network which is a chain to store the keys just wondering where can I find those keys as an issuer okay I'm talking about the issuer for the issuer the keys are stored on the ledger if we're talking about the VON network probably about TL-Ironcrats and Hyperledger indie then there is a dedicated transaction which is called credential definition createDef it contains the public key of the issuer which is used to sign the credentials okay there is another transaction in Hyperledger indie it's called NIM which can be used to store the keys associated with the DID keys associated with the DID which is needed in order to send a credential definition actually so usually the process is a following for the issuer issuer first of all creates a schema sorry first of all creates a DID and the corresponding public keys put it on the ledger on indie ledger then these keys the DID can be used to create a schema for credentials also put it on the ledger and then the keys needed to issue credentials should be generated and the public key can also be put on the ledger using the DID so you should be able to look up the public key given you have a DID and access to the ledger yes yes all formations public there is a number of well of course it depends on what kind of network you use but it's a public network usually there are some browsers like indie scan which can be used to look up the transactions and you should look for the bond network we're on the bond network so given the DID we should be able to look it up on the bond network thank you thanks for your question and I believe you have a question live questions from Amina Amina can you unmute yourself and ask your question hello and thank you for your presentation so I asked the question in the chat but I will repeat it I have a Mernstack project and I want to implement the ACAPI instance and I don't know how to run it locally on my machine so if you have an idea or recommend a tutorial to follow well I believe you can just look at the ACAPI repository it contains a number of pretty good tutorials how to do it also ACAPI it's one of the it's one of the key areas projects it's part of the basic SSI dense tutorial provided by Hyperledger so if you go through these steps I think it's called how to become SSI developer I followed this it's a course on Linux foundation I followed it but it doesn't have a step-by-step or clear information on how to run it locally on your machine so I've been running it since yesterday and I followed the official documentation on Hyperledger and Github but I actually always find problems so I don't know what to do my condition would be of course to look at the repository because I know that there are some Docker images but basically you can just run right so usually there is no need to just build everything by yourself also there is like a pipy version this is written in Python that you can also run so look at the repository and also there is a channel in discord for ACAPI you can I think you can reach the ACAPI community and ask questions there if you face any issues or yes thank you so much thank you one more question Suryash is interested why is Hyperledger coming up with separate credential type instead of leveraging W3C option actually Hyperledger didn't come up with a separate type historically still Anocrats was implemented before W3C standard was major enough so it kind of was in parallel historical process and as I mentioned part of Hyperledger in 2017 but W3C became recommended standard only in 2021 so 2022 actually so there was two separate processes coming in parallel but as for any technology usually it's not that straightforward there is a number of branches and like in any tree there can be multiple branches which can live together and it can be perfectly fine and also as I mentioned there are some constant pros in every of these approaches still Anocrats it's choice if you would like to have predicates but in some cases more simple cases maybe usage of W3C credentials is also fine and by the way many areas protocols support both types now they both support both W3C and still Anocrats okay thanks is having predicate the only advantage of Hyperledger credential type no it's not the only advantage predicate is one also revocation it's a bit more secure in terms of privacy it's anonymous then selective disclosure before BBS class signatures were created it was quite significant difference between a common JSON LD or DVT based credentials and still Anocrats now with BBS class of course yeah it's not a difference anymore but well if you need both selective disclosure and predicates and still Anocrats can be a very nice option so basically it's predicates and revocation one more question from Benjamin compared to using Polygon ID as a service basis how many advantages does our Hyperledger Indy have well I'm not the expert in Polygon ID to be honest but I'm not sure that actually Polygon ID provides all the principles of decentralized identity maybe I'm wrong but in any case the advantages for using Hyperledger areas Hyperledger Indy WC refabric credentials is that it's part of the standards interoperable standards which is really good for adaption of the solution which is really good to be able to use the solution with multiple vendors for example one party may implement the issuer another party may implement verifier third party the wallet and they can all work with each other since they support the same standards so it's pretty important about the standards next question can I use some Anocrats to support SII on an application that uses Hyperledger and Polygon yeah so one of the goals of new CEL Anocrats initiative to make it ledger agnostic and basically yes there is kind of an interface in Anocrats interface of this data registry like with the methods like write, read and so on and there can be multiple implementations of this interface Hyperledger Indy is one of the implementations checked ledger is another so basically now one prevents to create implementation based on polygon right so now with this initiative it should be quite straightforward to do it I'm not sure that there are any existing working implementations at least of part of Hyperledger maybe some wine polygon it is but yeah basically technically I believe it can be supported there is no reason why not and that's one of the goals of this data Anocrats initiative is to make ledger agnostic okay next question from YouTube can you share a scenario where only DLT is the only option in comparison to centralized ledger by centralized ledger what is meant because usually if I talk about distributed ledgers it's the centralized maybe maybe just a tip maybe the question is about advantages of kind of decentralized identity versus centralized identity right so the advantages that the user controls the data actually because for example verifiable credentials they usually belong they usually stored in the mobile wallet so the holder side they are not stored on some third party entity and every relationship between the holder and verifier it can be done directly in peer-to-peer fashion which is better in terms of privacy preserving the issuer part doesn't need to be involved like identity provider who issues the credentials it doesn't need to be involved there which is of course much better also Telos opens the way for example for password less and ways for like delegation and so on so it's better in terms of privacy in terms of security it can provide a very nice UX yeah that's the main thing okay next question what is the advantage of using a blockchain ledger to store the issuers public key over the issuer maintaining for verification as you said blockchain ledger is not necessarily necessary for SSI yes yes basically one of the advantages of using as a ledger since we are talking about decentralized identity then it's good idea to get rid of any points of centralization somewhere otherwise the whole concept can be broken and the distributed ledgers decentralized it's one of the centralized ways to establish trust right because the public key needs to be trusted so of course it can be stored in some central ledger if there is a full trust to the central entity but if there is no such trust then the centralized ledger can be a very good option for example even let's see this for example for example if the issuer will store its keys on its own company website what will happen if this issuer company organization is set down is not available anymore it will mean that all issued credentials won't be working because there will be no way to verify that the public key this website of the issuer won't be available but if you use the ledgers the decentralized ledgers it provides much better guarantee that the service will be available and in any blockchain even if a couple of nodes are down or malicious the whole service will still be functional and all the issued refiable credentials can be used even if the issuer is unavailable or not in service anymore or just get out of business so it's a very nice thing to really own the identity independent of some centralized parties Thank you, Alexander I guess that's it we don't have any more questions and if you still have some please feel free to ask them but anyway if you have some follow up questions you can reach our company on social media the links are in the chat or maybe by mail and whatever Okay Well I guess that's it for today Great Sorry go ahead Go ahead please I was just going to say thank you and thank you to Alexander as well and thank you to everyone who joined as Anton was saying if you have other questions again please feel free to reach out hopefully this is the beginning of an ongoing discussion and we're looking forward to talking with you more Thank you Thank you everyone Thank you Big thanks to all of you who joined us today Definitely thank you See you next time I don't want to line it up or maybe in person Sounds good