 Let's see the presentation about the libraries for Selective to Clear the Jot that are in Open Wallet Foundation. It's being presented by Daniel Fett. Hello, and welcome to my talk about SDJot. I'm going to talk about SDJot and two labs projects in the Open Wallet Foundation. My name is Daniel Fett, and I'm here today for all of you. So in this talk, I would like to talk about SDJot itself. I'll give you a brief introduction if you're not familiar with SDJot. And then I'm going to talk about the reference implementation that we, as the specification authors and editors, created for the SDJot specification, as well as a Kotlin implementation that was created independently. So let's start. What is SDJot? Well, the SD stands for Selective Disclosure. So SDJot enabled Selective Disclosure for JWTs, and it's based on a very simple approach. In fact, we say simple as a feature for SDJot. And this approach is based on a concept called salted hashes. I'll get to that in a moment. SDJot enables Jots for the use as verifiable credentials, the term that I hope you're familiar with. But SDJot is a universal specification, so it does not define a format for verifiable credentials. But it can be really used with many use cases. OK. So quick primer on the ideas behind this. When we're talking about credentials, as in identity credentials, there's a traditional model that you will find, for example, an OpenID Connect. And in this traditional model on the left side here, an identity provider, when asked for the credentials or claims about a user, will create a signed document signed by the identity provider and will forward this document to a relying party. For example, in OpenID Connect, this is the ID token. And the ID token contains exactly those claims about a user that a relying party needs to know in this particular use case. But that also means that the identity provider will always be in the loop and will always know what exactly the data is that a relying party wants to have and always know the identity of the relying party. So this has various drawbacks, although it has been quite successful this model. That's now, when we're talking about things like decentralized identity or SSI or whatever you want to call it, that's the decoupled model, usually. So there the idea is that an issuer creates a credential, so signed document, that contains all the claims about a user it knows. And then the end user can decide for each time it wants to use the credential, it can decide which claims to release to a certain verifier, as the relying party is then called. So we need a mechanism that allows for a signed credential signed by the issuer with the option of reducing the set of claims that can be released or that is released to a verifier. And that is exactly the purpose of SDJort. It enables the selective disclosure feature for jobs. So for example, if you have a signed document with the user claims you see on the left side here, selective disclosure allows the holder or wallet or end user to essentially delete stuff from this credential and then release only the subset to a verifier. So how does this work in SDJort? So just as Jorts, SDJort operates with signed documents that contain JSON. So here on the left is the user data that we are talking about here. And now the issuer has to prepare this document for selective disclosure. And to do this, the issuer has to make decisions in particular, the issuer has to decide which of these claims will be selectively disclosed. And for those claims that things should be selectively disclosed, the issuer creates so-called disclosures. Disclosures are very simple JSON objects just consisting of an array of three elements. The three elements are a salt value that is unique for each claim, the claim name and the claim value. In this example, we only show strings, but the claim value can really be anything. So it can be an object, can be a number, whatever. Then the issuer removes the claims from the original document and replaces them by the hashes. So instead of the hashes, there's now a new element called underscore SD. So instead of the claims, there's now this new element called underscore SD that contains just the hashes of the disclosures. And obviously, when you just see the hashes, you cannot guess what the disclosure would be because there's this unique salt included in the disclosure. And that means that exactly is the salted hash approach. So the document that is now signed by the issuer is the one on the left, which doesn't contain the claim text values. So this has just turned into a job, just a standard job, so just a signed document with a JSON that we saw before. And then there are the disclosures, and those need to be encoded for transport as well. So those are base 64 URL encoded, so this is essentially plain text just encoded differently, and there's still a character as a separator. This whole thing that you see on the screen here is sent then from the issuer to the end user's wallet, or to the holder, as it's called. And the holder can then decide which parts of this it wants to send to a particular verifier. So of course it has to send the issuer assigned part on the left, but for the disclosures, it can just remove any disclosures it doesn't want to release to the verifier. And by that, of course, deciding which claim text claims to release to the verifier. That's the basic idea behind SD Drawn. There are more details. For example, we have a mechanism called key binding where the holder can also prove the procession of a certain private key to ensure that there's some freshness in the transaction. And other things, we have other encodings and so on. If you're interested in that, I suggest to look at the ITS specification for SD Drawn. Because now I want to talk about the reference implementation that we have. Our reference implementation for SD Drawn is written in Python and is an OpenWallet Foundation Labs project. So what does reference implementation mean? When we developed the specification for SD Drawn, we decided that it is probably a good idea to both write the specification and the reference implementation at the same time. So those were developed together to ensure that at every step that we make with the specification, we know that it's implementable and that it's easy to implement and that it makes sense also for implementers. So the reference implementation that we have always follows the latest developments of the specification. So it's always up to date. And there are many advantages to this approach. For example, we do have, of course, some examples in the specification. And we generate those examples from our reference implementation. So they are not hard coded in the specification, but they are from actual running code. That's extremely useful. So if you want to change something and say in the format, we can just change the implementation, regenerate all the examples and we're done. Very useful. And we know that there are no mistakes like typos or something in the examples. We also, as I already mentioned, use this for test driving. So if you have any new features or if you want to modify the syntax or anything like that, we can just do that in our reference implementation and see whether it works, whether that makes sense, get a feeling for the effort needed by implementers. Very useful. We also produce test cases. So we have some test cases defined in the reference implementation repository right now. We want to make those usable across projects so that everybody can test on the same list of test cases. I'll get to that in a moment. And also, of course, with this implementation, we wanted to demonstrate what a production-ready library interface could look like, how we think the NSDJOT library should work, so on what level it's operating and so on, what the input and output data is and so on. Just a word on the examples that we produce for the specification. What we did is we defined a very simple format. It's a YAML-based format. You can see an example here on the left. It is used to define essentially what a credential should contain and which of the claims in a credential should be selectively disclosable. So here in the example on the left, you can see that most of the claims are marked with an exclamation mark SD, which YAML is a YAML type. So by this YAML type, we declare that a certain claim should be selectively disclosable and our library consumes that. We use that, as I said, to feed that into our library. Our library will then produce the SDJOT itself. It will produce the format that is used for the issuance, the format for the presentation and so on. Of course, we can then put those artifacts in as examples in the spec. But we also produce something that we would not normally see in a library. It produces some markdown that explains some of the artifacts in detail. For example, the disclosures are, of course, not normally contained in plain text. So our library produces markdown that we can include in the spec to explain what is contained in the disclosures just for people reading the spec to get a feeling of that. So that is extremely useful. And when we're thinking about deploying SDJOT, of course we need interoperability. We already have something like seven independent libraries, seven independent implementations of SDJOT. We think that one next step could be to do interop testing between all those libraries, as it has been used quite successfully for other projects, like the grid project. We imagine that, for example, this could be hosted at the OWF, that libraries could be tested cross-implementation, so one library produces an artifact, the other one consumes it, and then we see whether everything works. So that could be one of the next steps. And if you have any ideas in that direction, if you have experience with that, your input would be very welcome. So what's the status of our reference implementation? It's called SDJOT Python in the OWF, currently has lab status, but from outside it's essentially feature complete, as I said, it implements all the stuff in the spec. It's tested, we have both the automated tests and people using this, and it's essentially production ready. For now, it was developed and maintained by us, the ITF draft editors, but also some external contributors. But if you're interested in using this, we would also welcome new contributors to this. As some work to do, for example, the library's internal API, the documentation could be improved on that. It's quite simple, but still it needs to be documented. We have those test cases that we want to externalize at some point, I already talked about that. And, of course, there are also overlaps with other projects, for example, the identity Python project, and we imagine that the cooperation there could be improved as well. This was the SDJOT reference implementation, but I'd also like to talk about another implementation, which is actually the first project that was in the Open Wallet Foundation, and that is the SDJOT Kotlin library that was developed and maintained by Fabian Halt. Just very briefly, the SDJOT Kotlin library also has the lab status in the Open Wallet Foundation. It is based on Connect2ID's Nimbus library, and here credentials are represented as type safe data classes, obviously something you don't have in Python. This library is up to date with the draft version 04 of the SDJOT spec. The current version is 0.5, so there's a small delta between those two, but nothing too bad if you're interested to bring that up to date. Feel free, otherwise I think Fabian will probably also do that soon. You can already use this library in your project via Maven or Gradle, there are snapshots available at the URL on the slides. And just as the Python implementation, this project is open for new contributors, there are already some external prerequisites by people wanting to use this library. I'm pretty sure this will be more even in future, so if you're interested in that, please ask Fabian or send a prerequest to the Open Wallet Foundation about this. That's all I have for you today. Thank you very much for listening today, and thank you for having me here at the Open Source Summit. If you have any questions, if you want to talk about a cooperation, please reach out to me, use my email address, my Twitter, my LinkedIn. I would be very happy to see even more implementations of SDJOT, I think that's a good sign also for the spec. And again, if you have anything you want to talk about, please reach out and thank you for listening. Thank you. As Daniel is in the YouTube stream, thanks a lot, and if there are any questions, please comment on the YouTube stream. Do we have any questions in the room to Daniel? Okay. So, thank you.