 Welcome to everyone. We are now starting with our talk on decentralized identifiers. Decentralized identifiers is basically like your email address in the digital world. You have one unique identification item. Okay, many of us may have a lot of email addresses or specified email addresses. But here we're talking about the one main email address, which is the one you use for communicating with your telecommunication provider, with your hosting provider. So the one unique address you use for all your important stuff, if you do it that way. And that is a unique identifier you could use. And Attila is now talking about different methods on decentralized identifiers, which is corresponding to the talk we just had on self sovereign identity. And we will see each other here in a couple of minutes after the talk for our Q&A. Hello, my name is Attila from Chainstep, and I would like to present to you the topic of our math thesis, which was about creating a DIT method for the SSI ecosystem. I hope you like it. And let's start. The title of this presentation is a DIT method for Blober and describes it pretty well. It is about a DIT method that is part of the Blober project. So let me start with the short agenda. The presentation is split in four parts. At first, I would like to tell you what the motivation behind creating the BBA DIT method was. In the second part, I would like to discuss SSI from a more technical perspective. The third part is about the key characteristics of DITs, and the last part is finally about the BBA DIT method. So let me tell you something about the motivation. The motivation behind the Blober DIT method was to make the Blober project SSI ready. Blober is a hobby project and investigates authentication mechanisms based on blockchain. Blober stands for blockchain-based authentication is an open source project. The source code is hosted on Github. In its current state, it only uses the hardware blockchain. Further information are available on the website and on Github. So to enable Blober tracking the SSI ecosystem, the BBA DIT method was created. And what actually is their self-serve-in identity model? SSI was first described in the article, the path to self-serve-in identity by Christopher Allen. The key idea is to grant an entity full control over its digital identity. To do so, it utilizes blockchains as identity provider for digital identifiers. Even though blockchains are not the only option to store these identifiers, they are the most prominent ones. Another key aspect of SSI is the separation of identifiers and attributes. Identifiers are represented as DIT's so-called decentralized identifier. Attributes, on the other hand, are wrapped in so-called VCs, which stands for verifiable credentials. An identifier in general identifies an entity, like an email address identifies the person who is in control of the address. Attributes are special aspects of an entity, like a postal address, birth date or credit card number, but also permissions to do something or statements from other entities. The combination of identifier and its associated attributes creates an increasingly accurate image of a digital identity. Let me show you an example how authentication works in SSI. At first, a user's self-surrainly creates one or more DITs on an SSI-enabled blockchain. If one then wants to authenticate, one represents one's DIT to the service, one wants to authenticate too. To check the authenticity of the DIT and to ensure that the user is indeed the controller of the DIT, the service initiates a challenge response workflow. To verify the signed response, the service resolves the DIT and gathers the public key of the signature from the blockchain. With this mechanism, the user is able to self-manage one's identifiers and does not need to register to a third-party identity provider. If one then wants to add additional information, like a postal address, one forwards a VC to the service. The key thing is that VCs are not stored on blockchain and can be managed everywhere the user wants, preferable in the user-owned domain. To standardize the authentication authorization workflows, the Trust Over AP Foundation published a general SSI architecture, the so-called Trust Over AP Stack. The Trust Over AP Stack is a four-layered dual stack which separates human trust from technical trust. Human trust is about trust that cannot be achieved by technology. It is about governance topics and questions like how can they be sure that this implementation is doing what it is supposed to do? Or how can they be sure that this provider is trustworthy? In general, it is about certificates and seals from trustworthy entities. Let's focus on the technical part. The technical stack is about technical trust. Technical trust represents trust in the mechanics of cryptography and mathematics. The bottom layer is all about identifiers and public keys. It serves as the root of trust in which debts are being registered and managed. The second layer is about connecting SSI agents in a secure way. Agents are the pieces of software that represents entities in the SSI ecosystem. The DITCOM protocol initially developed by the Hyperledger Areas Project is a peer-to-peer protocol and acts as the carrier protocol to achieve secure and reliable connection with the SSI ecosystem. The third layer is all about VCs. This is where the so-called VC trust triangle consisting of the VC issuer, VC holder, and the VC verifier lifts. The VC issuer is the entity that creates VCs over the VC holder and signs them with its DIT. The VC holder is a subject that the VC is about. He manages VCs self-surrender and presents them to the VC verifier whenever he wants. The VC verifier is then able to verify the presented VC without the need to create a technical connection to the VC issuer. He only needs to know the DIT of the VC issuer. Of course, to accept the presented VC, the verifier needs to trust the VC issuer. As an example, a bank as a VC issuer issues a VC about the credit trustworthiness of the VC holder. The VC holder then goes to a car dealer to buy a car and presents the VC to prove that he can afford the car. The car dealer proves and accepts the VC and the VC holder buys the car and drives home with his new car. The top layer is about ecosystem. This is where standards of VC schemas or schemes come into play. Every entity following and accepting a specific VC schema is part of a specific ecosystem. So let's focus on the bottom layer and have a look at what the DIT is actually about. A DIT is a resolvable, decentralized identifier. It is backed by a verifiable data registry, which in most cases is a blockchain. A DIT identifies the DIT subject, which can be of any kind, person, a process, company, a cat, etc. A DIT is controlled by a DIT controller, which in many cases is the same entity as a DIT subject. Only the DIT controller is able to modify the DIT document. Every DIT is resolvable into a cryptographically linked DIT document. A DIT document contains public, accessible information like public keys and service endpoints. The DIT resolver is responsible to resolve a DIT into its corresponding DIT document, similar to a browser that resolves an HTTP link into an HTML document. A DIT is always generated by a DIT method. A DIT also follows the generic DIT schema. The schema always starts with the prefix DIT followed by a DIT method identifier followed by a DIT method specific identifier. The Blober method schema, for example, looks like this. It contains the prefix DIT followed by the Blober DIT method identifier, which is BBA, followed by a Blober DIT method specific string. Let me show you how a DIT document looks like before we have a closer look into the DIT methods. A DIT document may look like this. It always contains a link to a schema that provides information on how to interpret the DIT document fields and the DIT it is linked to. In most cases, it also contains public keys for specific context and service endpoints for further interactions. So let's talk about DIT methods. Avery DIT method follows its own specification, which describes how to implement a specific DIT schema to function with a specific verifiable data registry. Each specification has to fulfill some basic requirements, including the following three key requirements. It must be adequately detailed to be implemented independently so that a third party is able to implement a resolver based on this specification only. It must include a method specific DIT schema, and it must also include the method specific CRUD operations, which describe how a DIT can be created and read or resolved, how the DIT document and the DIT controller can be updated, and how the DIT can be deactivated. So let me finally present you the DBA DIT method. Instead of showing you the whole specification, I would like to present you some key characteristics. The BLOBA DIT or BBA DIT utilizes the ADO blockchain as its verifiable data registry. It uses two transaction types of the ECS child chain. ADO is a multi-chain architecture in which child chains are secured by the ADO parent chain. The first transaction type is called account property and is used to manage DITs and DIT controllers. An account property transaction lets you attach arbitrary data to a blockchain account in the form of a property key value pair. The second transaction type used to store DIT document templates is called data cloud. With this transaction type, it is possible to store bigger chunks of data within the blockchain. A DIT document template is a DIT document without a DIT. Filling the corresponding DIT into the DIT document is part of the resolution process. A DIT controller is always an ADO account. DIT controller and DIT document management are split. This makes the BBA DIT method capable of extending the DIT document handling and to enable additional storage options. It is, for example, possible to add IPFS support so that the document template is stored on IPFS and IPFS address is then linked to the DIT. An ADO account as a DIT controller can also control multiple DITs. So let me show you how the BBA DIT schema looks like. The BBA DIT schema starts with the prefix DIT followed by the BBA string to indicate that it is a Blober DIT. The BBA method specific identifier itself consists of two substrings. The first part indicates the network type and can be M for mainnet or T for testnet. It can also be omitted which then indicates the mainnet DIT. The second part consists of the transaction hash of the first account property transaction related to the DIT. So how can this information be used to resolve the DIT document? The basic workflow to resolve the BBA DIT is the following. The first part is to gather the account property transaction identified by the transaction hash included in the DIT. This transaction provides the following information. The property name contains an internal DIT identifier which is used to track the DIT within the ADO blockchain. The property value contains encoded information about the DIT following this schema. The first three characters indicate the BBA DIT method version. Every data field is separated by the pipe character. The next information indicates the state of the DIT. It can be active, represented by an A, inactive, represented by an I, or deprecated, represented by a D. In case of deprecation, which indicates that the DIT is no longer controlled by the ADO account this account property belongs to, the redirect account data field holds the new DIT controller account. Otherwise, it is filled with zeros as its default value. The storage type field indicates the storage method that was used to store the DIT document template. C stands for ADO's cloud storage. The last data field is the DIT document template reference. It is filled with the pointer that can be used to retrieve the DIT document template. In case of the ADO cloud data method, it contains the transaction hash of the data cloud transaction with the template is stored. After retrieving the template, the only missing step is to include the DIT into the template and to return the DIT document. So, enough theory, let's see a reaction. There is a web page available to easily play with the PVA DIT method operations, which is called PUPCO and stands for PAP UI for PVA CRUD operations. So, yeah, let's create it. We will use, we will create a DIT on the ADO test network and with the DIT document key in the form of elliptic curve, which is used for authentication. And we will also create a dummy service with this kind of information here. So, let's create it. And that's it. We've now created a DIT on the ADO blockchain and we can see the information here, which is the DIT document we just created and the key for the DIT document key. You can also save the DIT and download the information here. So, yeah, you can see now the transactions create, yeah, issue to create the DIT. This is the official web UI from ADO and if we now, for example, copy the transaction hash and search for it. We'll see the DIT information here and as a second step, we can copy this transaction hash and find the data cloud transaction here and the DIT document here. So, this works. Cool. We can also resolve this DIT with the DIT resolver here. So, let's copy the complete DIT and input in this field. Now, we get this information as well in a more comfortable way and the BBA DIT method is also resolvable by the UNI resolver. So, you can probably see, yep, there it is. The UNI resolver is a project from Decentralized Identity Foundation and is there to provide one unique resolver for a lot of best case all possible DIT methods. Yeah, but that's it. Cool. I hope you liked the presentation and got a better understanding of what SSI is about and how the BBA DIT method works. If you're interested, check out the BBA DIT method repo where you can find the complete specification and everything related to the BBA DIT method and SSI and also have a look at our ChainStep website. Thanks for your attention. Question and answer option in IRC. So, please send over your questions in the IRC. So, we have a chance to answer them here together with our speaker. Our signal angel Autanaser is waiting for you at the moment to give us all your questions over. Attila, you were just talking about the Decentralized Identifiers. So, what is the special thing about the identifier you use here compared to others? Yeah, I think the only special thing is that I've created it for the ADO blockchain, which hadn't Decentralized Identifier before. So, you know, hardware is one more option for using a survival data registry in the SSI ecosystem. And all right, so we are currently still looking at the pad from the signal angel. At the moment, there are no questions which came in for now. So, if you just have everything so clear that no one has any question to ask for that, I can thank you in this moment very much for your talk. Thanks for the great time. And when I don't see anyone coming up here, I would say we close this talk for now. And I wish you lots of fun in the 2D worlds to run around a bit. Maybe we find you in the one or other hallway. And great to see you. Also, on a physical event of the year, you can never have it again. Yeah, thanks for having me and hope we'll see you again. Bye, Attila. Bye.