 Hi, everyone. So I'm from the Gulf Tech Singapore. Our mission is to engineer digital government and make lives better. So today I'll be sharing an open attestation. This is an open source document endorsement and verification framework using the blockchain. So I know I'm the only thing standing in between you and probably your post conference drinks or dinner. So I'm just going to get straight into the meat of it. I'll just say that I think in the public consciousness and we hear about the term blockchain, most people think about cryptocurrency and we've definitely heard a very fascinating presentation earlier on Bitcoin Ordinals. I'll just say that for open attestation, what we are interested in is how the key attributes of blockchain can be applied to document endorsement and verification. At the same time, there are limitations of the technology, but we think that the way that we are designing open attestation can help us to either get around this or to basically make it less of an issue, I think, for how we are using blockchain for open attestation. So I'm just going to get into how it works. So for open attestation, what this is is an open source framework to endorse and to verify documents. We have two key components. The first, we look at verifiable documents. So these are temporary evidence documents that could graphically prove the authenticity, the source of the document. So you can think of credentials like academic qualifications, proof of identity, proof of employment, etc. We also look at transferable records similar to verifiable documents, but these are documents that can have an owner. Usually such documents confer ownership of assets. So we are looking at documents like title deeds or a bill of lading. What I think is interesting about open attestation, it allows for decentralized issuance of credentials. And I think we really do believe in the power of open source software. And that's why all of our code is open source. So the verification can of course be distributed. Anyone can set up a verifier based on our technology. But depending on the use case, we can also centralize the verification process in terms of directing people to a particular verifier. And that's just for perhaps a better user experience or for certain government use cases, just for better public comms in terms of how to use the documents. So earlier I mentioned that a double-edged sword or like one of the, I guess, points of blockchains that the data stored is public, right? So you may be thinking, hey, you know, some of these credentials are confidential, it may be personal. So should we really be putting that on a blockchain? So what we are doing in open access in open attestation is to design in a way that upholds data privacy because we're only publishing a document hash on the blockchain, but not the data itself. So I'm going to get into basically how we are doing the verification. And this is essentially premised on three critical steps. So when we look at the verification tech, which is the core of open attestation, we are trying to provide three critical steps. The first one is to verify that the document has not been tampered with and that it has been issued by the issuer. We want to verify that the document has not been revoked. And we also want to confirm the identity of the issuer. So how does this work? When we issue an open attestation document, we first take the raw document in JSON format and we put it through a process that we call wrapping. So the end product of this wrapping process is a unique hash that represents the document. And of course, if the document is tampered with, then it will not be possible to derive the same hash and we can prove that it has been tampered with. So the flow is pretty simple. For each property, we salt to prevent rainbow table attacks. We then flatten and encode the properties as a string. Each view is hashed with the value and salt. And then we store all the output hashes in an array. Finally, we hash the array of hashes to produce a target hash. So I think to put it simply, it would be a hash of hashes. What this allows us to do is also to perform selective reduction on the document. So if we want to, say, redact a particular field of the credential, for example, it's not necessary to disclose this, right? And people would naturally want to minimize what they are sharing. Then it's possible to redact the particular document property by removing it from your credential and storing the hash under a different field that we call obfuscated data. However, this still does not invalidate the target hash because it doesn't invalid the target hash of the document because we are computing the target hash out of all using all of the hashes that have been stored in the open attestation document, including those that were moved to obfuscated data. So after performing the wrapping process, this is an example of how it will look like. So as you can see, the document properties have been sorted and we now have a target hash that represents our document. Okay, so now we have found a way to wrap the document. Next, we need to verify that the document was issued by the issuer. We have two ways of doing that. So the first one would be via a smart contract. The issuer basically deploys a smart contract that acts as what we call a document store. This keeps a record of the issued documents, the issued hashes of the documents. But I do know that this involves an on-chain transaction and does consume gas, but we'll come back to this later. So this allows anyone to check if a hash which represents a document has been issued. And then when we are doing the, during the verification process, what we are doing is to first check that the target hash of the document is in the document store's list of issued hashes and we are also checking that it has not been revoked, that it is not in the list of revoked hashes. So I would say this was probably the first iteration or the first version of open attestation. Another newer method that we developed would be to use decentralized identifiers to issue documents. And currently we're using DID Ethereum. So when we, after signing the open attestation document, basically it would contain the issuer's DID and the signed target hash. Then when we are doing the verification process, what we do is to compare the Ethereum address from the DID document with the address that is returned by verification. If it matches, we know that the signature is valid, the document has been issued, and that it has not been tampered with. Okay, so earlier I did mention that issuance does consume gas, and this can potentially be an issue for users if you're issuing documents one by one and you have many documents to issue. So what we also developed is to allow issuers to batch transactions using Merkle trees. So each document target hash is a leaf in the Merkle tree, and we compute the Merkle root, which is then stored in the open attestation document along with the proofs needed to ensure that this document is part of this Merkle tree. Of course, for a single document that doesn't need to be batched, then the target hash and the Merkle root are the same. All right, the final, the final area that we, the final area of our step of verification would be on the issuer identity. This is an, I guess it's still an area that we are still working on and developing. Currently, we leverage on the domain name system. We use the DNS text records to publish the document store address or the DID. And then this is then checked against so that we know that the credential is issued by the entity that controls this domain. Okay, so now I'm going to get into the perhaps more exciting part of my presentation, which is to talk about the products that are currently powered by open attestation. And this is by no means an exhaustive list. And we are always looking out for more ways that the open attestation can be applied. And so that's partially why we are here today at FOSS, at FOSS Asia. Really interested to hear if there's any ideas for how this technology could be applied. So the first one I will talk about is called open, open certs. Basically, it started as a proof of concept to improve productivity. Basically, schools were spending a lot of time and effort on verification of the certificates. So you would have people, maybe employers who want to confirm that the graduates paper certificates were legitimate. So they might say call the school and ask the school to check and verify. Schools were also spending time on replacement of lost certificates. So this was consuming I think up to at least seven men months in a year. So with open attestation, which powers open certs, so graduates from Singapore institutes of higher learning can receive their degrees or certs in the form of an open attestation document. And then these can be easily verified by employers on the open certs.io verifier. Yeah, I'm not sure if we are able to open the link here or when I'm able to switch out to a browser. Oh, okay. Fantastic. So this is the open certs verifier. So if you look at the demo, this is how the user would go through it. You can just easily drag and drop your cert into the verifier. This will load up our decentralized renderer. It will render the cert, for example, we have this demo. And there can be multiple views of the same open attestation document. Another thing is, earlier I mentioned that we allow for selective redaction of credentials. So for example, we are able to say redact certain info that's not required. So for example, if you're only focusing on the CS on the CS courses and the grades, you can redact let me grab this. So you can redact the details and download the file. But it will still remain verifiable. And then you're able to download it. And if I try to verify it again, maybe a bit, oh, down. So if we verify it again, you can see that the redacted fields have now been removed. But we also do mention that it has been redacted, just not what was redacted. And earlier when we were going through the verification steps, this is how we would provide the assurance to verifiers in terms of it has not been tampered with, it's not been revoked, and it is issued by, say, this particular entity in this case, Gavtech. So that's one of the, I think, first use cases of open attestation. The next one is a bit more recent. So if I'm just going to toggle back to, sorry. So this is probably a bit more recent. So during the COVID-19 pandemic, it was really important to be able to prove that, you know, vaccine certs and test results were legitimate. So to eliminate the existence of fake COVID-19 test results, and also to support the opening of borders and resumption of life as normal. So given the decentralized nature of the assurance and the need for a way to attest to the documents in a cross-border way, so open attestation was adopted as a solution. And this powers the health certs that basically Singaporeans use to prove that they have been vaccinated, for example, or that they have passed like their pre-departure COVID tests. So users could go to this notarized platform to apply for notarized health cert for travel, and then cross-border immigration authorities could easily scan the QR code of a health cert to verify it. So I'm sharing this example because I think it also shows the strength of the free and open source movement. Because OA was open source, because it had been used for other applications, there were providers out there that were able to help perhaps less tech-savvy medical clinics to onboard the health cert solution, and for them to quickly issue vaccine certs in the open attestation format. So we were able to adopt this solution quite quickly, and I guess in a scalable way. And the last use case that I'm excited to share about is called Trade Trust. I'm the product manager for Trade Trust. We are basically looking to accelerate the transformation from paper-based trade documents to digital documents. When we look at the current state of cross-border trade today, it's largely paper-based. One shipment can involve many parties across different sectors, many exchanges of information, many siloed systems, and this is very inefficient and costly. At the same time, when you have manual handling, it can be vulnerable to fraud. I can take the same document and use it to take out two different loans from two different banks who are an underweiser. So Trade Trust is a framework to accelerate this transformation, and we look at it in two ways. So for trade, we have verifiable documents, so these are perhaps things like an invoice or a certificate of origin that tells me, okay, this shipment comes from this country is eligible for certain preferential tariffs, for example. The second is to find a way to allow electronic bills of lading to be transferred between parties along the supply chain. So a bit of background, what is a bill of lading? In trade financing and international trade, the bill of lading acts as a receipt of goods, and anyone in possession of this bill of lading can claim the goods at the destination port. So for example, in this case, if I'm trying to sell something to someone in a different country, I might enlist a carrier or a ship to help me transport it to them. The carrier will issue me a bill of lading. I will then courier this bill of lading to the buyer, and the buyer can produce this bill of lading at the destination port to claim the shipment. So this is really a very simplified version of how this flow works in international trade and trade financing, but sometimes it's not as smooth, because you can imagine sometimes a bill of lading will go through multiple parties who are financing this trade. So it's even possible that by the time the cargo arrives at the destination port, the bill of lading is still being couriered around the world, and the cargo is just sitting in a port waiting to be released. So I think that's where we see a lot of potential for electronic bills of lading, because the transactions can be conducted on a chain, it can be really fast and instant. So what we do in trade or in trade trust is that we represent the bill of lading as a non-fungible token. We bind the NFT to what we call a title as scroll smart contract, which then controls changes to the ownership of the token, as well as who is allowed to change the ownership status of the token. And this setup mimics the current process for paper-based documents in terms of who is allowed to change the holder and the owner of the bill of lading. So I hope I've given a brief overview of how open attestation works. What are some of the use cases that we've applied it to currently? And here's how you can get started with open attestation. You can learn more about our framework over here. And please come to our GitHub and explore our code. Feel free to open issues with us and talk to us. And I'm really happy to take questions and to figure out what other use cases we can have for this technology. Thanks, everyone. Thank you very much, Kani. Thank you. Thank you. Great, great project here. I love it. Question on the bill of lading example we just gave. So the bill itself is issued as an NFT and it's verified using the open attestation smart contracts, right? So two contracts involved in this use case. It's not verified with the open attestation smart contract, but it is verified with the open attestation signature and proof method. So I guess it uses the same cryptography that takes the document and digests it into a target hash. And then we're using the NFT to deal with the transactions. And regarding use cases you mentioned, which chain are they using? Which EVM chain? Are any of them actually using Ethereum as that's quite costly? I'm just wondering if any of them have adopted a side chain or L2? Yeah. So for our users, they're using Ethereum as well as Polygon. Roland, I had a question on the rationale for the use of a blockchain in the first place. Given that, at least for the examples you gave, the person relying on the credential, the employer or whatever it is who's trying to evaluate the credential, is relying on both the signer having a working verification function. If there's no working verification function then there's no way to know whether fraudulent certificates have been issued and not cancelled. So the organization has to exist, it has a working verification function. And further, that you're using the DNS to deliver the authenticator, the public key that's used to validate the signature, that's a real-time service dependency. So technical service has to be working in real-time. I'm wondering what value they're using a blockchain at all versus a more conventional web service because there must be an organization, it must be responsible, and it must have real-time services available otherwise your mechanism won't work. So what have you gained by using a blockchain at all? Going through your first question was on there being a way for the issuer, the signer, to hash the document, right? And this should be... Well, let me sort of make the counterpoint. If you rely upon the organization having the ability to revoke, then I would suggest that a blockchain is useless. If you're relying on the organization presenting a service that's available to you in real-time, then a blockchain is useless. Blockchains are only useful, I would suggest, if both of those things are false. In this case, both of them are true. Why would I use a blockchain? Why would I just ask your web server to tell me that this certificate is a risen valid? A few things. I think when it came to this situation of, for example, if you're looking at academic certifications, I think what ended up being the case was that verifiers would want to go to, say, the Ministry of Education and ask them to verify, for example, these documents. And that was assessed to take quite a lot of manpower, a lot of efforts. So the idea of this was, is there a way to... I understand why, sorry, we should probably take this offline. I understand why take away the human process. I'm asking why use a blockchain. It seems to me it would be simpler and more reliable to use a web service. It's DNS. You've got a real-time service. If it's down, you're out. And I think we acknowledged that. I think DNS is probably not the best way to look at the issuance and... Any more questions? Yeah. One more from Harish up there. Gonna make me go up the stairs. So thank you. This guy. Next guy, sit down there. I got a question about how do you, when you have the assert issued by an institution, what if the institution merges with something else? How do you ensure that these things are sustainable 100 years from today? What is the mechanism for something like that? Including the DNS portion, right? There's a lot of dependency that requires that this entity exists, that there's a way for me. Where it's a piece of paper, it's a piece of paper. I can fake it, but yeah, it's still a piece of paper. So I hear this is something which I've been struggling with trying to find out, how does this even make sense from a sustainability perspective? Thanks. So I would say that in the situation where maybe the institution merges, or maybe they moved to a different domain, I mean the document store, so the smart contract on the blockchain would remain, and it might just be a method of linking that document store to the new domain, for example. So that's, I think, maybe one way to address that. Yeah, also I suppose if, for example, you have institutions merging, I don't think that would invalidate the, or it should not invalidate any certificates that were issued by the old entity, and operationally they may not want to re-issue the search under the new name because it was issued at a time when that institution was a different entity. So I guess with the immutability of the blockchain, that's one way to ensure that even after the entity has maybe closed down or moved on, the records would still be there, although admittedly you need to find a different way of tying the issue identity to the document store on the blockchain. Yeah. Yeah, just to add on to the answer to his questions, like, if you guys ever, in the early days of doing cryptography, if you guys ever went to signing parties and X509 certificates and dealt with all the complexities of that, compared with the ubiquity that Ethereum and these things offer today, it's just, it's just night and day difference from a practical basis. From a theoretical basis, yes, it's not perfect, it doesn't do everything, but from a practical perspective it's just so much easier to use and it's just common how everyone is using it. My question was, so I was kind of surprised that, you know, I thought we were describing that this was just a protocol, but in fact you guys have actually developed and released software. What is the scope of that software? Like, if I'm an organization and I want to build to do verification of my own documents and stuff, is that what this is on? Is that what this is going to provide? Also, I guess what I would call these reference implementations, and we also do release the code for that as well. So, for example, for traittrust.io, the verifier is open source and implementers can refer to that to spin up their own verifiers and to use our CLI to help users to issue documents. So, there's underlying framework, those are the applications that we have built on top of that, and to the best extent possible, we do try and make it open source. This is very forward thinking stuff for you guys in Singapore, so I hope it catches on outstanding. All right, we go. More questions there? So, I was curious when you did your research on how to implement this, if blockchain was a winner, which was number two option that you rejected? Okay, so I think the two, one question that we do get asked is why not just use docuSign or a similar, like signing a PKI based digital signature that you can easily open up a PDF, and you can also have that sort of verification that hasn't been tampered with and just issued by a certain entity. I think the two benefits of open attestation would be in terms of replication. It's a lot easier to revoke, as opposed to trying to revoke the signature of a digital document that you've already signed a PDF and sent out. And the second one, which I think has a lot of potential, maybe hasn't been realized yet, is that, I mean, the open attestation files, it's in JSON format. I think it's more machine readable, as opposed to a PDF, docuSign, PDF, for example, that is maybe harder to integrate with systems. So, I guess that was one of the other options that we considered, and eventually decided not to go ahead with. Right. Hi. I only have a question. I just want to add a bit of color to this great presentation. And I actually happened to work with the protocol a bit because I was working on a software that actually utilized this, it's called NextID, and it utilizes this as you're really, really great. And also, I just want to add a bit to Roland's question just now on that there's no need for a blockchain, which I actually agree in this case because it's basically just everything's just a mocha tree. So, you need to, it just ties into the mocha root because all the search is actually not published on change. Every search has a hash, this dash of that, and then you just build that tree, and then you just have the root that you refer to somewhere. So, you can see that on the DNS or you can actually see that on the blockchain itself. But blockchain itself is actually not used in this case, but there's one fundamental of blockchain that's actually adding some value here, which is the immutability part. So, it helps when assert is, let's say that seed is changed someday through DNS, and you cannot see that it is changed. So, the blockchain part actually adds that seed or that root is changed. So, you can actually see that it is changed. So, everything else is just cryptography, just PKI. So, there's no need for a blockchain or smart contracts, but that blockchain part actually helps to make sure that it is unchanged. And you can actually track that it is changed or it's being added and all that. Correct me if I'm wrong. It's something that I want to add there. Thanks. All right. Thank you very much. And I think with that, we close our session today. Thank you very much, Kali. They give you a round of applause. Thanks for taking the time. And I think just responding to what Yuzin mentioned, I think we don't see there's just a pure blockchain thing. I think it's wider than that. As we look at verifiable credentials, and that's not something that is necessarily tight strictly to blockchain. And I think we are so interested in seeing, perhaps, what are the different links and between the different ecosystems now.