and start recording. Okay. And with that, we are good to go. All right. Welcome everybody to the Hyperledger Anoncred's workshop using ZKP Verifiable Credentials everywhere. We'd like, on behalf of Hyperledger, we'd like to thank the creators and organizers of the workshop, Stephen Coran, Rodolfo Miranda and Patrick San Luis. We really appreciate all the hard work that went into this. Hyperledger, as some of you may know, is a global ecosystem for enterprise-grade blockchain technologies. We host the software projects and the communities that build things like an Hyperledger, Anoncred's, Indie, Aries, Fabric, Sawtooth, as well as projects, Bezu, as well as other projects like Cacti for blockchain interoperability, Bebel and others. So we'd like to thank everyone for joining us. We are live streaming this. I'm gonna post the link to the live stream if you wanna share it with your colleagues. This meeting is being held under the Linux Foundation Antitrust Policy. If you have any questions about these matters, please contact your company council or if you're a member of the Linux Foundation, feel free to contact Andrew Uptigrub of the firm, Gesmer Uptigrub LLP, which provides legal counsel to the Linux Foundation. And this meeting is also under the Linux Foundation Hyperledger Community Standards. Everyone's welcome here. And as the chairperson of our technical oversight committee says, be excellent to each other. I am going to stop sharing and turn it over to Stephen Roto and Patrick. You guys have it. All right, welcome all. I am gonna share screen and I'm gonna start. There we go. Let me adjust a little bit more. The things move to where they need to be. All right. Okay. Welcome to the Hyperledger and Non-Preds Workshop. We've got a lot of things to share with you. And so we'll get started pretty quickly. I think Sean's giving us a good introduction covered the question of who Andrew Uptigrub is and whether he is actually just a chatbot, but he could exist. The goals of this, that we came up with as we started with this is listed here, understanding verifiable credentials in general. So we'll do that quickly at the beginning because I think a lot of people here will know that. Go into the unique capabilities of an On-Preds and what makes them different from other verifiable credentials. We're gonna use a thing called traction to experience using an On-Preds and we set out some prep information and prep information is available for those who wanna join in and participate in that or we'll just walk through it and you can see it. Hopefully understand a bit of the cryptography. I hope to do a time permitting. We're gonna balance that, but high school math session on what anonymous credentials are, what zero-knowledge proofs are in particular and how that works. See how they're used today in a variety of contexts, how they're used not just with historically as they've been used with Hyperledger Indie ledgers, but actually in a number of places. Some new capabilities available and sort of a future. And so we want you to come away with this to be able to say, how can you use an On-Preds in your app, build frameworks that use it, either open source ones that we also participate in or proprietary ones that your organization builds and makes available to others. Use of an On-Preds in all sorts of other contexts, other ledgers, other VDRs as they're called and we'll talk about what VDR means in a bit. For those that are into cryptography and actual deployments contribute to an On-Preds, both the current version and the future version and what we're going to talk about is the future version. So those are the goals, just moving one thing around. So let's get into it. Part one is going to be more or less about an On-Preds. Part two will get into the cryptography zero-knowledge proof ledger agnostic An-On-Preds. An-On-Preds in the W3C Verifiable Data Credential format, which is new and kind of interesting. We're going to see a demo of that with An-On-Preds used with a W3C API known as Chappy. And then talk about making credentials beautiful with the overlay captures architecture and finally finish on An-On-Preds V2 and what's coming in what we're working on in a working group here at Hyperledger. So with that, I'll get started with online identity with Verifiable Credential. So a quick refresher or intro for anyone who's new to this. Verifiable data is necessary in huge numbers of business use cases. Business relies on being able to get trusted information shared between many parties. So you've got things like personal identification issued by the government, passports, birth certificates, driver's licenses, using those in a variety of locations, including when you're copper speeding or other such nasty things that this police officer is so angry about. Other things like travel, even being certified to work, being an engineer, being a doctor, being a lawyer and being able to prove that. And then this other one, certificate of incorporation, organizations are people too. And so organizations need identity and they need to share verifiable data. So that's the context we're talking about. The paper credential model has been around about 2,000 years. It works like this. Some issuer provides a piece of paper that has identifier information, identity information, some sort of information, and they give it to a holder. That's one transaction that occurs. The holder holds onto it. They might put it in their wallet. They might put it in a filing cabinet. They just might put it on their desk, but they keep it, sometime later, the verifier, a verifier, and could be many, want to see that piece of paper because they want to do some interaction with the holder.  Does it come from the place that they want it from? In theory, it proves who issued the credential. It's got some marking on it who issued the credential. It has some binding to who's holding the credential. It might have a picture of the person on it. It might just have their name or their address. And some other mechanism is used to prove that, oh, that name is the same as this name of this person. And that the claims are unchanged, that it's not a forged piece of paper. And so mostly in that, the verifier knows who they want to have issued the credential, but they want to look at the person in the paper and sort of see, is this forged in any way? Trust comes mostly from, do they trust the holder?  But they also are making sure that they know who issued that credential or that piece of paper. I'm gonna underline here that these are, there's two parts to this, credentials and protocols. Credentials, we don't really think of protocols when we talk about a paper credential model, but it really is included, which is somehow the issuer gets the piece of paper to the holder and somewhere there is, the holder gets the piece of paper to the verifier and that's the protocols involved. There is a link to the slides. Yes, sorry, it is on some of the slides. Yeah, bit and non-cred slides. And also you can go to the wiki page on the links I just shared, I'll share them again in a minute and the slides as well as the lab documents are all up there. Yeah. I'll jump to that quick question that I had asked. And non-creds does, it is usable in the Hyperledger Identity Staff areas in India, that's where it started, but the extraction of a non-creds into its own project allows it to be used in many other places. So that's partially what we're talking about in the introduction today. Okay, when you present a paper credential, the verifier is making trust decisions. They're looking at the technology, the paper, the words on, does it look forged? Does it look like a legitimate representation of the credential they asked for, the piece of paper they asked for? They're also looking at governance. What is the source of the data, British Columbia in this case, for this driver's license? And do I trust British Columbia? That tends to be obvious when it's things like banks, Bank of Canada or the government of British Columbia, but there's tons of use cases where the paper comes from some other source and you've got to decide, the verifier has to decide, do they trust the issuer? Do they trust the processes the issuers have? So paper credentials in the digital world or just generally credentials in the digital world today are scanned, scanned in email. So that's the normal way to do it. So you take a picture of it. These are actual instructions from Google of how to send your ID to Google.  Looks like you cover some of the information and only showed a photo, I don't know. And there you go. So this is obviously not a sustainable, useful approach. So this is where verifiable credentials come in. Basically, we have more or less the same actors, the issuer, the holder and the verifier. We add this thing called a VDR, Verifiable Data Registry that we'll talk about. And we go through the same two ceremonies, the same protocols that we saw before. The issuer issues it to the holder and the holder presents it to verifiers as necessary when they want to. Who issued the credential was proven so that there's again a tie to the issuer of the credential and the credential itself. And that's done through cryptography. The claims are unchanged again through cryptography that there is a signature to use the term, a signature on the credential that the verifier can verify. Who holds the credential is sometimes proven. And we'll talk about that in terms of non-creds and other credential models. And that the claims have not been revoked. This is a new one that is added by the ability to use digital credentials that you can check revocation of a credential in real time as a verifier. Remember, these are two transactions issued to holder and then the holder holds on to it, holder to verifier sometime later or as often as they want as a separate transaction. Still required is do you trust the issuer? You, and not necessarily required as a holder because of these things that are built in, it's almost impossible for the holder to forge the credentials. So the holder is of less concern. Now the verifier's focus goes over, do you trust the issuer? So you got to know who the issuer is and whether you trust them. Credentials, presentations and protocols are all involved. So in this case, the credential and the presentation may be different. So a credential comes to the holder. In some cases, the holder presents a derivation of the credential called a presentation to the verifier. So we add that to this, but protocols are completely involved. How the issuer gets the credential to the holder, how the holder gets it to the verifier, all of that is there. Okay, I do want to point out that VCs are different from OpenID Connect. So OpenID Connect is the login with Facebook model. You have the same parties, user in the OpenID Connect model is the holder in the VC model. The issuer is the same, the relying party is the verifier. But what happens here is there's a single transaction. The issuer is asked by the relying party to coordinate the conveyance of the data of the credential. The user asks the issuer, contacts the issuer and the data is passed directly from the issuer to the relying party. This is all done in a single transaction and the issuer is involved in every interaction and that's one of the things we want to get passed. We don't want the issuer to know when the user is interacting with any given relying party. And so you can think of that obviously in government terms. Is that enough that Facebook is able to monitor all of the things you do? But government oversight of that, things like the government being able to see every time you buy cannabis or you buy alcohol or whatever interactions you're making is not a good thing. You do need to show you are abiding by the laws.  And so that's why the OpenID Connect model is not sufficient for this and why for that and a number of reasons, scaling being a big one, but that we want to move to something different. The Verifiable Data Registry, I talked about that through this, where that comes in is what allows the presentation between the holder and the verifier to occur without involving the issuer. And basically what happens is the cryptographic material used to identify the issuer and sign the credential is put onto a registry. The issuer, when it issues the credential, issues them to the holder, to as many holders, a million holders, a billion holders, based on the key or keys that go onto the registry. And then when a holder presents data to the verifier, the proo, the verifier reads from the registry and uses the information they read, the public key that they read to be able to verify the provincial. And so that eliminates the issuer from being involved in the actual proof, the presentation transaction that occurs. So hopefully that all makes sense. I always like to underline this over and over. When a credential is issued, it goes from the issuer to the holder. No part of the credential goes on to the Verifiable Data Registry. No transaction occurs when the issuer issues to the holder. The only thing that happens is that is done as part of a setup as we will see, and then the issuer issues to the holder, the credential. Wanted to talk briefly about Verifiable Credential Ecosystems in 2023. Basically there's coming down to four and perhaps a few others that are four major communities that are coming together on Verifiable Credentials. And these are starting to merge. These are sort of forming over various times. The initial two were primarily in this area, the W3C Verifiable Credential Data Model, the standard W3C Verifiable Credential Model, signed using data integrity proof. So that's the Verifiable Credential Type. The exchange protocols that you'll hear about are CHAPI and VC API in that community. Hyperledger, where you are today, has primarily focused for the last six, seven years on and non-creds with zero knowledge proof, as well as VCs with JSON-LD. So again, the same credentials that are here. So Hyperledger, things like Aries supports both of these things. The primary exchange protocols are called DITCOM, DITCOM Messaging, and then Aries Data Exchange Protocol. So that's the protocol there. Relatively new in the VC field is OpenID Foundation, which has been using JOTS and Selective Disclosure JOTS. We're gonna talk about that a little bit later. And possibly other formats, they're again, OpenID is attempting to be agnostic to the protocol type. The protocols they use are called OpenID for VCs. This is not the same as OpenID Connect. So they aren't using OpenID Connect, but they are using the foundations that underlie OpenID Connect for these. And then there's the ISO working group and in particular the Mobile Drivers License Working Group. They have a thing called MDL, which is literally a Mobile Drivers License, which is built on the concept of MDocs, which is the Verifiable Credential format. And they are developing various standards for how presentation primarily gets done, but also protocols around issuance and working on those. So those are the VC ecosystems that are happening. With that introduction to Verifiable Credentials, let's jump to what hypernature and non-creds is. So the big thing that a non-creds adds is zero-knowledge-proof technology. And this exists in four enhancements over the basic Verifiable Credential model. The first one is selective disclosure. And this is one that is now appearing in all of the other communities and the one that you'll see more and more. This will become the absolute minimum that a Verifiable Credential format type will have to support. So this means that when I present something, I get a credential that has all of the data on it, but when I present it, I only wanna present some of it. So in this case, I present that it was, I have a credential that was issued by British Columbia, but I'm only gonna show you my picture. So selective disclosure is absolutely crucial for minimizing how much data you're sharing and increasing the privacy. Because the data is now cryptographically signed and the verifier can do more with it, they need less data. They just need the minimum data for the actual transaction, not data to collect for other purposes. So that's selective disclosure. Second one are called predicate proofs. This is only in a non-creds from the major types and predicate proof basically says, I can prove something based on data in my credential but without disclosing that credential or without disclosing that attribute. So in this case, I'm walking into a bar, I present my credential, I show that it came from British Columbia and I show that I am old enough based on my date of birth to purchase alcohol, but I don't actually give you my date of birth. And again, this is a data minimization approach. It allows you to do not share more than is necessary for the transaction needed. So those are called predicate. Predicates have limited usage. They have to be based on numbers and things like that. So we'll get into a bit on that as we talk more about a non-credits. Predicate proofs. Third one is derived presentations with unlinkable identifiers. This is a, that's a handful, but what that means is basically when I present this credential to a verifier, there's no in the presentation, the wrapper of the presentation, there is no unique identifier for either the credential or the person presenting. There may be a, and if the verifier asks again for the same data, they get a completely different credential. Now, the business transaction may require that a unique identifier be given in the attributes that are shared. So for example, I may have to, as a result of the transaction, share my name, but that's not required by the presentation process. So where it's possible to use essentially anonymous presentation, that can be done. So no correlatable identifiers is another word for unlinkable identifiers. Unlinkable is becoming the common term used in the VC community. That also means that when one verifier gets some data, they can't correlate it with another verifier, either previous credential they also receive or other ones, or other ones received by others.  And finally, multi-credential presentations. With the non-creds, you can present multiple credentials at the same time and show that they were all issued to the same holder, to the same, what's called link secret, and we'll talk about that a little later, but there's a proof that all of the credentials were issued to the same holder, the same wallet, if you will. So those are the unique capabilities of a non-creds that we're gonna get into. What is a non-creds? It's a project at the Hyperledger Foundation. As mentioned, it is the same technology that was previously in the indie project and then extracted out and moved into a specific, into its own Hyperledger project. It consists of a specification of the 1.0 specification of the non-creds sort of mixture of data models and protocols and a working group to evolve that. There is a full open-source implementation in Rust of the non-creds specification. It's basically the give or take fourth implementation of a non-creds derived from Hyperledger at indie and a thing called IDMix from IDM that had been around for a number of years, heavily used for the past seven years in the Hyperledger's self-sovereign identity stack. So that's the indie Aries-Ursa stack that we've talked about that was mentioned in chat already. The new implementation is verifiable data registry agnostic. This is the new thing that we wanted to accomplish in doing the specification, which is previously it was very tightly tied to use of indie and Hyperledger indie ledgers. It now, as we'll show later in the presentation or in the workshop that it can be used with a variety of data registries. And then finally, there's a working group defining in on-creds v2.0. So that's the next generation and we'll talk about what that means. Basically, it means that we want to retain or expand on the capabilities. And so it's the capabilities of a non-creds, those things that I mentioned on the previous slide that matter and not so... And in doing that, we will adjust and modernize, for example, the underlying crypto signatures that can be used and things like that. The important thing is not so much the precise details of what is implemented today, but rather the capabilities in making sure that we're retaining those capabilities, those privacy-preserving features that make a non-cred so important. These are the things that I talked about mostly, all of the cryptographic features of any verifiable credentials format. So for the W3C, and we'll talk about this a bit, the only thing that are verifiable credential, the two things that a W3C verifiable credential tells you is there is a tamper evident issuer attestations about a subject. So you've got a subject in there and you've got an issuer involved and you can detect if you know who the issuer is and you can detect if there's been tampering forgery done on the credential, that's all. So things like who it was issued to, revocation, other things like that are sort of outside of the W3C spec and it sort of left to others around the W3C spec to use that. And non-creds is actually opinionated on that and includes these features that I've talked about in the previous slides. I would add this no-correlatable identifier is very helpful for governments because it means that there is no new identifier introduced for people. And for those who have experience in government adding new identifiers and the rules around using it. If you think about in the U.S., the SSN or the SIN in Canada or national identifiers, there's all sorts of legislation rules and so on about how to use that identifier and how it can be shared. Without introducing any identifiers, or any new correlatable identifiers, we avoid that problem. I would add no other popular verifiable credential technologies offers all of these capabilities. And in particular, the only one they do offer and we're delighted to see it as selective disclosure. The rest of these are non-creds only features, if you will. I'm gonna talk about a lot of these things over the course of the workshop where we are. Overall basis of a non-creds V1 is CL signatures. So there's a link here to that and RSA-based cryptographic suite. Canonicalization describes how you convert a credential, a bunch of JSON that is a credential into a signed object that can be presented. That's known as canonicalization. It's very simple in a non-creds basically signatures are applied to 32-byte integers. So basically everything, every piece of data, every attribute in a credential gets converted into an integer and signed. And basically the rules are if it's an integer in the data, in the raw data, it remains that that if it's not, it gets strewnified and converted into a hash which is an integer. So if you've got a picture, if you've got a date in text format, those types of things, those gets converted into a hash, hashes basically and get signed. Integers remain integers throughout and that is why predicates work only on integers. They don't work on, for example, string values. Predicate use a thing called bulletproofs which I will leave to others to figure out and understand. Selected disclosure, no correlatable identifiers based on a thing called blinded signatures. They've been around for, I believe, late 70s, I think, when the first idea of that came about but commonly used. The link secret which we're gonna talk about is a Pedersen commitment. So again, link in there to what that might be and you can understand it, but we'll also talk a bit about how that happens. And finally, revocation is based on proof of non-revocation. You're actually proving your credential has not been revoked and we'll talk a little about that in the course. So now we get into the meat of what a non-PREDS is and how to use it and that's where we're gonna get into some demonstrations and presentations. Answer to the Dave's question, could a non-PREDS be used on Ethereum-based ledgers? Yes, and that's the idea we're going for a non-ledger agnostic non-PREDS, which is you can still use a non-PREDS as defined in the specification, exchange them with others, but resolve the objects, resolve the data you need onto other ledgers, including I think Ethereum would be a great use case. I don't think it's been done yet.  So what happens? There's basically four parts to using a non-PREDS setup, which is where data gets published from the issuer to the verifiable data registry, publishes the public information they want everyone to be able to get to to be able to see it. Commonly we use the term, we say, oh, it gets published to the ledger, but the correct term is verifiable data registry. So you'll see me cross that I would put in VDR there because it can be a lot of things that does not have to be a ledger. The holder creates a link secret. We'll talk about that in the setup section. During issuance, there's a back and forth between the issuer and the holder. There's actually three steps and offer from the issuer to the holder, a request from the holder to the issuer, and then the issuer creates and signs the credential and passes it to the holder. Presentation, once a holder has the credential in their wallet, in their secure storage facility, whatever that might be, the holder may present it to any number of verifiers through any number, through transactions with each verifier. During that, it's a two-step process. The verifier requests a presentation from the holder. The holder constructs a presentation with revocation if necessary, with proving my credentials not been revocated if necessary and provides that to the verifier. And then the verifier verifies the presentation by pulling the public data that the issuer published during setup and uses that to verify what the holder provided. And finally, there's revocation and that sort of happens in a couple of ways and we'll talk about that. But basically when necessary, the issuer publishes a list of credentials that are being revoked in a way that's not correlatable to the holder. And the holder uses that to prove as part of the presentation that their credential has not been revoked and the verifier again can use the information to do that. So, an on creds, data and processes. So this is the next set of things we're gonna talk about in the presentation. So we're gonna go through the setup of the setup stack. We'll go through the issuer and staff and we'll go through the presentation stack. Okay, so publishing objects involves the issuer writing things to the verifiable data registry. So holders not involved, verifiers not involved, no verifiable credentials, no proofs. We're just writing some things, including public keys to the verifiable data registry that we want everyone in the world to see. No private data at all. That's gotta be super clear. No private data. It involves two objects we're publishing. A schema object. So the schema object is a list of attributes. And I've got an example and I'll jump over to it. Hopefully that'll work. Okay, good. So this is, I'm looking at a ledger browser on the Sovereign mainnet. And here I've got, I just randomly found a link to a transaction that is a schema for a credential. And those are the list of attributes in this schema. That's all you know about them. So that just this list of names and these list of names are totally set by the publisher of the schema. There's also two other things, the name of the schema and the version of the schema. So that's all of the information that goes into the schema object. It's technically not needed for the cryptography to work. So what you'll see is the next object called the credential definition that gets created actually is based on a schema object and imports into that object all of the attributes, the list of attributes and the reference to the schema object. So for the cryptography, for the actual signatures, it's not actually needed, but it's more for governance. It allows the sharing of common schema and the idea is to minimize the different schemas being used in the world. Basically to make the life of the live, okay, the life of verifiers easier. We want to have the verifier able to accept a credential, say, from any university and it be in the same format. Almost no prescribed metadata in the schema. So for example, in the WQCBC data model, you must have the issuance date as a field in it, but there's no prescribed metadata in a non-cred schema object. In 2.0, we may adjust that. We may make changes, but in 1.0, there's no prescribed attributes. Right now, and implementation so far, it is a simple list. There's no complex JSON, not even nested data structures and so on. Nested data structures could be supported by flattening the data structure. So that is possible, it's not been done, but certainly would be possible. However, dynamic arrays cannot be supported and so that is something to understand. So the requirement is that the number of attributes in a credential is defined at setup time. So that every credential has exactly the same number of attributes in it and that results in you cannot support dynamic arrays. If you do need to support dynamic arrays, there is a way to do it, which is you basically stringify the JSON array, you convert it into a single element and use a data URL for the data in each credential. So those that need to worry about this, the key thing is you can't have dynamic arrays in a non-cred scheme objects, but there is a way to pass such data if that's totally necessary. And if you need it, ask the non-cred community and you'll get help on that. So that's one object that has gone been published. The issuer has said, this is what my schema is gonna look like and they may, the next thing is they create a credential definition. This is done by the issuer. The credential definition inhales the attributes from the schema. As mentioned, it could be the issuer that publishes the schema object or it could be someone else entirely and the issuer is simply creating their credential definition based on somebody else's schema. And that would be a good thing because it shows that people are sharing schemas and reducing the effort of verifiers. So list of attributes. Let's go to a quick example. Again, this is that same, this is based on that same schema. So it's got a reference to the same fields. It's got a reference to the same name, the same schema version. And the actual data is some cryptographic data. And you know that because you've got all these really long numbers. This is the actual public information that the verifier will need to pull in to be able to be able to verify the credentials. So they will actually pull this credential definition in when they receive a presentation. They will use this data in here, data associated with each element and cryptographic specific cryptographic values pass that into an anonymous algorithm and they will get back a verified, not verified answer. So this is the actual meat of what will be used to verify a credential. For those with eagle eyes, you'll notice that these fields are mostly the same but there's an extra one in here that we're gonna talk about in a moment called master secret. Everywhere else it's called link secret because we wanted to get rid of that but it has not been eliminated yet in the actual published data structure but the link secret is added to the credentials. It is the only extra thing that's in here as far as the list of attributes that are in a credential. This example actually had revocation supported. So this is some information related to proving revocation. So there's some extra data on there. So there's keys, public keys involved for the issuer and involved as well for revocation. With a published credential definitions, millions of credentials can be issued. Again, nothing goes on the ledger at issue time. Hope that's clear. So no credentials are stored in the VDR, no credentials. This is what gets stored in the VDR, the schema and the credential definition and also revocation information but no information about the credential itself goes on the VDR. Okay, set up the last step is the holder creates a link secret which is gonna lead to our digression. The link secret identifies the holder and it is put into all credentials they receive. And so this is how, well, we'll get to this. The link secret is simply a unique identifier, a UUID. So a very long unique identifier. It is handled as a blind identifier and this is what allows us to have no correlatable identifier. So we have an identifier but we're blinding it which is a cryptographic term that makes it so that it is not presented to the verifier as the identifier itself but rather it's blinded but the holder can prove that they know what the identifier is, that they uniquely hold the knowledge to know what that link secret is. And so that's how this occurs. So it is unlinkable both for issuers and holders. So there's no linkable identifier shared with issuers, no linkable identifier shared with hold, sorry, that should say verifiers. Gotta fix that with verifiers. So now I'm gonna get into the holder binding issue and briefly go into that. So the verifiable credential holder binding issue is the following. So this is a bit about aggression. We're talking about setup, we're talking about the thing called the link secret and it is this piece of data that is known that is known by the, that is put into the credential from given to the, from the holder to the issuer and then put into the credential and used to identify who the holder is. So holder binding issues and basics. Excuse me. When verifiers receive presentations, they wanna know the relationship often wanna know the relationship between the holder and the credential they are presenting. So if you have a driver's license and you're presenting a driver's license, it's obvious to everyone that the verifier is expecting that the subject of the driver's license is the one presenting it. And so there needs to be some way to bind the credential being presented with the person or the entity that is presenting it. In W3C terms, they talk about a subject. The credential is about a subject. The credential is held by a holder. So what is the relationship between the subject and the holder? That's known frequently as the holder binding issue. I talked about it earlier is you wanna prove that the credential was issued to the holder. So one of the things that Oncreds does is it's very deliberate to say that a credential is issued to a holder and only that holder can present it. In the W3C VC data model, holder binding is currently out of scope. The issuer makes temper evident attestations about the subject and that's it. So we know who the issuer is. We know that the attestations have not been tampered with when they're presented. We know the subject identifier, but we don't know the relationship between the holder, the subject and the credential. And that's the bigger issue. This is a picture figure 10 from the W3C Verify or Credential Data Model and it basically shows this that an issuer issues to holders, holders can transfer amongst holders and any or all of them can present a credential. And so in the data model itself, it's not to say that it's impossible. I'm just saying in the data model itself, there is no binding between the holder presenting the credential and the credential that they're presenting. Anyone and basically anyone can present any verifiable credential. It's up to the verifier to do that binding, to do that extra verification if it's needed. There are cases where holder binding is not even needed. Just possession of a credential is good enough. Money is an example of that. If you present money, you don't need any binding to you, you just need to present money. So it's proof of possession is all you need to show in presenting it. Not that you wanna use verifiable credentials for money. So don't let me add that. So there are other techniques and this is commonly what's done in other, for example, open ID for VCs. The idea is the holder has a did, which contains a public key. They on issuance, the holder provides that did and proof that they control that did to the issuer. And when the issuer verifies that signature and inserts that did into the credential. So they basically request proof of control of some identifier and then they use that. And then on presentation, the holder adds a proof that they can control the subject ID did that is in the credential. And that way the holder proves that they control the did. It is in the did signed by the issuer and on presentation, they prove binding to that. There are other ways that it could be done as well. Some mechanism that the issuer creates, you might call back to the issuer to prove it. You might have to present another piece of ID. So this was commonly done with the COVID credentials, which is you would present your COVID credential that would get verified. It would show what your name is and show your ID, your paper ID as a way to prove that you are the same, the subject as identified in the credential. The VC could include a picture of the subject. It gets presented and then that could be compared on an in-person event. So that's another approach to doing that. But there's gotta be in often, again, I underline often. And again, I think it's a very, very high percent of cases often the verifier does need to know the holder's relationship they're binding to the credential they're presenting. So that's the general issue of holder binding and non-creds takes a very opinionated approach to that. It provides a thing called a link secret and that formally defines exactly how holder binding works in non-creds. So unlike the three secret credentials, the data model where there is no formally defined way to do holder binding, all holder, all in non-creds are issued to the holder's link secret and only a holder that knows that link secret can present the VC. A holder's link secret for all credentials they receive. In theory, they could have multiple link secrets, but whenever they create wherever they present credentials, multiple credentials together, they must use the same link secret. So if you get a credential from two different link secrets and try to present them together, it will be rejected. So there's a verification that any credentials presented together must have used the same link secret. If you go through and think about how the link secret works, it is pretty much exactly the same as what we talk about here, but instead of it being a did with a public key associated and you prove a signature on issuance and presentation, basically you blind the link secret from the issuer and then you present proof from the holder to the issuer that you know what the link secret is without sharing the link secret, classic zero-knowledge proof. You prove that you know the link secret without sharing the link secret itself. And then the issuer inserts the blinded identifier into the credential when the holders present that presentation based on that credential, they do the same thing. The presentation includes proof, the same link secret was used for all the source VCs and that the holder knows the link secret without sharing the link secret. Again, zero-knowledge proof. So hopefully that makes sense about holder binding, the importance of it, and be how the non-credits handles it very in an opinionated way, which is somewhat different from other credential methods. This accomplishes exactly the same thing as the link secret does, except that it shares a correlatable identifier, a linkable identifier. Every verifier that receives a proof, a presentation, from this credential gets the same did and gets the same proof, and that is correlatable data. Okay. So, lab one. Now we're going to take a break from slides and we're going to go into lab one and sort of walk through that. We're going to use traction, as I mentioned. Hopefully, those that are joining did some sort of preparation. So all of the links in here are hbsbitly, v-i-t dot L-y slash the non-credits. There's a prep one. There's a labs one. And then the other labs are like that. So in this, we're doing the setup stack that we just covered. Define a schema. define a schema and you're welcome to define multiple, publish the schema and then publish the credential definition for that schema that you create. So that's what we're going to do now. I'm going to do this. So those who didn't do the prep or anything can just follow along, but I'm going to walk through the steps. Hopefully, I don't often use a wallet on my device, but hopefully that's there. So I am, yeah, good. So this is the traction product. So traction, we didn't want to bury people down and using a command line interface for doing this or getting spinning up their own Indy or Aries agent or anything like that. So this traction is a multi-tenant instance of an Aries agent that provides a user interface and an API for managing multiple agents within a single instance. So everyone is using the same instance of traction to this URL. Then everyone that's done the setup has a tenant within it, and that gives them this interface that allows them to do a bunch of things related to setting up, issuing, and verifying presentation. So that's what we're going to use for this. Over here, I have my wallet, I have my smartphone, and I've got the BC wallet, I've got Orbit wallet installed as well, and so I'm going to go through and do this. Now, in this case, I don't need the wallet because we're not going to get involved in that because we're just doing setup right now. So I don't know why I just activated that, but I did. So the way we do this is so we have a setup. By the way, I have connections created. So I've got my BC wallet connection and my Orbit connection. And I'm going to do a configuration. I'm going to set up a new schema. And so there's instructions in the lab what to do. I recommend following along for the first one, using exactly what we provide because it makes doing the presentation easier, but feel free to make whatever schemas you want and however you want to do it. So I'm going to do a schema name called student ID. I'm going to use 106 because I can't remember how many times I've tried it in the past, just to make sure. And I'm going to use a handful of fields. I'm just going to create four fields. So I'm going to have a given names, family name, click the plus. I'm going to add a date of birth, which is going to be what's called a date int and I'll get into that. And I'm going to have an expiry. So date int is if you recall, I said that if I'm going to use predicates and date of birth and expiry are things that I definitely want to use predicates on, they need to be integers. So date int implies that the date of birth I'm going to put in is not an ISO spring, but rather it's an integer of the form year month day. And this is talked about in there. So when we present, I'll be showing the format of that expiry is the same sort of thing.  So I can look at the details of that. So I expand down here and view the raw content and I can see when it was created the schema ID. This is the did of the issuer me. Here I've got my student ID name and the version. Again, I've got the same sort of information in here. This is the actual schema on the ledger and there's my list of four attribute names. And then I can also see this that I have a sequence number, which is the transaction that occurred. Now, this is this was written to a thing called B sovereign test, which is a ledger that a sandbox toy ledger that BC operates. So traction is was developed by the government team at the government of British Columbia. I didn't mention that. So and and they are operating this instance of traction. And then they also operate the hybridizer in the network to which these objects are being written. And we can look at those those are available. So I've now created that the thing I need to do now is so that's step one. I've created the object I published it step two is to create the credential definition. That's kind of funky. But I'll click on that to create the credential definition here. I'm going to use the student ID schema. So it's referencing the particular schema. And here I'm going to call it you have Stephen three because I think I've used one and two just to be sure. I'm not going to invoke ad revocation, but this is how you would do it ad revocation. You would also be asked the number of credentials. We'll talk about that per revocation registry. We'll talk about that in the revocation section. So for now we'll create without revocation and we'll hit create. This is actually the most intense part of the definition.  So that credential definition has been created by the non credits library. And now it is being published to in this case in indie network. And if I look over here now I have it published on it and I've got a link in an identifier for it. So I've published my credential definition. I can actually look over here and see I've got that credential definition I created at nine o'clock today. So that's it. We now have those things are going to take a look at the raw data. Not much to see here. We'll see more of this later in the definition. This is not the actual credential definition. It was more like what I showed earlier. This is just the traction information recorded to find where it is. Sean, can you put in that an on credits the bitly address for the slides? It's bitly slash an on credits slides with the S in capitals. Okay. That's it for this. That's all we're going to do for now. That is what it takes to prepare to issue a verify the credential. There's a bunch of stuff going on here. The biggest thing here is you need an interface to whatever VDR you're using. We're going to you've seen now an example of using Indy for that. Later on, doffo is going to present using Cardano. After that, Patrick is going to show using did web. So using just a web server to do that. So there's all sorts of places that these objects can go. But we've basically published two objects to this. One is the schema itself, which is just the simple list of attributes, the name and the version, and then this credential definition. And with that, we've wrapped up this section of it. I will leave say two minutes or any questions that we might want to go over and let people run the lab themselves, walk through those simple steps and ideally create a second one, a second schema so that when you come time to do a presentation request, you can build your own that has multiple credentials involved. Any questions that we should talk about now? I've been seeing the chat hopefully following up and thank you for all that are both adding and answering the questions. Thank you, Sean for that. That's the slides link. Yeah, I was having an issue with not capitalizing credits. And yeah, thank you again to everybody who's in the chat asking questions, but also for the great folks who've been answering them. Wade, Daryl, Patrick, everyone who's been pitching in, we really appreciate it. Okay, Ed, in answer to your question, I think the decision to separate credential and schema was this idea that a schema can be shared. And the idea is you want communities to coalesce around a particular schema and then all of them issue the same schema. They would have their own data. They would use the schema in the way they found needed. But they would use a common one to make it easier for verifying credentials that come from all of the issuers in a community. So for example, in Canada, we did a lot of work is actually Dave Bigsby's on this call. I've seen him comment, did a ton of work with the folks from Quebec and Ontario and some people up there that came up with a common person schema with the idea that it would be used across Canada. All of the provinces would issue a person credential. And then, and so there's a set of rules on what's, you know, there's the fields that are in the common schema and there's the values. And then each issuer can have separate rules on exactly how they would use it. Okay. So hopefully that's there. Asking for trouble their way. Okay, I'm going to move on to the next section. So couple of schema, a couple of notes. Generally, and credit depths must be on the same VDR as the schema. It's not really enforced in an on credits. It is for enforced more by the ledger or the VDR. It is required at least for hyper ledger and the reason for that is Indy does some verification of the object before it writes it. So it wants to know that you're doing a valid credential definition and you're using a valid schema. And so that's why it's done. Other VDRs may take a different approach and may not require that. And there's potential across the way that we could have a schema written down one ledger and credential definitions in other ledgers be used. There's not a particularly technical reason from a, from a verifier or a holder from, you know, from a client perspective, but it is sometimes required by the ledger itself. So a schema must have an associated publisher ID, which is usually a dead, certainly on Indy, it's a dead. And, and that is usually checked. So again, the permissioned writing rules of Indy requires that the, the, the publisher have be allowed to write to the ledger. And this has to be a dead associated with the schema. There must also be an ID associated with the credential definition and this is how you know who the issuer is the ID associated with the credential definition used for the credential. So again, that is often a dead. It has to be, but as often it did must be a unique identifier for that credential issuer. And this is a lot that subtlety that I've got in there of often it did and things like that. The non-crit spec hasn't a way to enforce that. So you're, you're, it's just following along with what you're providing it, but the communities, the ecosystems around it enforce rules like that. So we've got our, our, our process here. We've now completed the setup. Our issuer has written all of the information to the Verifyable Data Registry to enable the next two steps of the process. So, good on us. Let's get into issuing. So we're back into a new one. Now we've got a new thing we're going to do. We're going to take the issuer and the holder are going to interact and issue a Verifiable Credential from the issuer to the holder. So we're actually going to construct some data, use that credential definition that's on the ledger to, or use the private data associated with that that the issuer holds the secrets that the issuer holds to provide the Verifyable Credential. So it is actually a three step process in, in the non-creds, which is slightly different from things like OpenID for VCs, which is, it's a two step process. Here it is a three step process. So for those that are jumping into you, you know, we are going to be having parts of the community that develop OpenID for VCs using in on-creds. That will be an interesting component of it is getting that three step process. So three step process is called an offer. It goes from the issuer to the holder. And it says, here's the type of credential I'm going to issue. And here's a key correctness proof on that. And here's a nonce, a thing to prevent a reply attack for the issuer and that can be used for non-correlatability. So an offer provides a cryptographic material from the issuer to the holder to say, here's what I'm going to present for you. The holder does a request to the issuer. This is where the blinded link secret is passed and a key correctness proof about the link secret is passed so that the issuer knows that the holder knows the link secret, that the blinded link secret was derived from the link secret, and while there doesn't tell the link secret to the issuer, they keep it secret. No one ever knows the link secret is the holder needs to keep that secret. They also provide some entropy for the credential, some randomness for the credential. And finally, there's the actual issue staff. The issuer to the holder, the verifiable credential that has been signed, constructed inside and is given to the holder. So obviously, there's a three step process and noncreds itself defines how to generate an offer, how to process a request, or to generate and process a request and how to issue the credential. So the noncreds code simply executes these steps when asked, given the proper inputs. It has to be a way for the various inputs to be passed between the issuer, the holder, the holder to the issuer and the issuer to the holder. That's the protocol step of this. ARIES uses a specific issue credential protocol, which encapsulates all of these steps. It is in fact a general purpose protocol. It can be used for noncreds, but it also can be used for any other format of credential. It has been used for W3C credentials, for VBS plus credentials. It can be used for any format of credentials. We are looking forward to, we've got a thing on the roadmap to try it with MDocs and see about getting that. So it is built on top of Didcom, so it's using a messaging protocol called Didcom. Hopefully, most many are aware of that, but again, that's not a focus of this workshop, so we won't go deeply into that. But Didcom basically allows two parties to send messages back to each other, back and forth. So similar to Signal or Telegram, it is a messaging protocol. It is a dense-based messaging protocol, hence the name Didcom, and it provides end-to-end encryption. It does not have any central server involved in processing, looking at, and forwarding messages. There may be a need for intermediate areas to pass messages along, but it's not inherent in the Didcom protocol, and all of the messages are end-to-end encrypted. The RFC 453 has some additions to it that aren't the go beyond the three-step process for non-creds. There can be a proposal that allows the holder to initiate the process, so the holder sends a proposal, which is followed by an offer, request, and issue. It also allows for negotiation. The issuer sends the holder an offer, and the holder says, hmm, that's interesting, but I'd rather you issue me this. And so it sends back to the issuer a proposal, and then the holder goes forward with that. And then the offer also includes other things, so the offer may include the actual data that will be issued. So if the holder, if prior to issuance, the issuer wants the holder to see the data, they can pass that in the offer. And that's not needed by non-creds, but it's useful as part of the user experience in doing that. So this is what a verifiable credential, a non-creds credential looks like. So good to have Jason to look at, but you've got a scheme ID, a cred def ID, you may have revocation information. In this case, it's all null, but you've got revocation information above and below. These are the actual values. So this is a credential with a single data attribute. It's got Alice Jones and encoded. And then there's signature data, cryptographic data in these two places. So that's what a credential looks like. I'm going to show you a transition of this information into a W3C formatted later. So we're actually going to take this data model and convert it to match exactly the W3C data model. But this is what was defined seven, eight years ago in the initial non-creds work of what a credential would look like in the non-creds data model. So that's for interest. Notice we had raw and encoded values here. And all that I said that the raw values are the actual attributes. So that's what's being shared. Alice Jones is what the end user cares about what they want to see. The encoded values are canonicalized attribute values as integers. So remember what I said that what actually gets signed in a verifiable in a non-creds credential is encoded. The encoded value is a number. And so what we've got to do is represent the raw value as a number. And that's what gets signed. So Alice Jones never gets signed. It's the encoded value that gets signed. The rules are dead simple. If it's an unsigned integer or an integer string, it's left as is. If it's a number, it's left as is. Everything else is stringified and shot 256 hash into an integer. So this is Alice Jones converted into an integer. That's why only integers, this is why only integers could be used as predicates.  It's not sortable. So therefore anything that's not an integer cannot be used as a predicate. Currently both raw and encoded values are included in the credentials and presentations. What if the issuer uses, so that causes problems. It's it wasn't an ideal choice by the original designers. It allowed the issuer to define the canonicalization method they used. So they could use other rules here. And that's not ideal because the verifiers have to know what rules they're following to be able to use the credential. And the verifier must check the encoding, the coded values are properly encoded. So this actually is a an issue that the holder could exploit a folder could put Dave Jones in here. And if the verifier doesn't check that the encoding has been done properly they might see that the signature is correct on the encoded value but not might not notice that the raw value is different from what was encoded. So there is a verification that the encoding is done properly. So in a future version we will eliminate the encoded values as part of the credential or presentation. And so that those get generated on the fly, according to very strict canonicalization rules and that will eliminate these sorts of issues. So, little sideline there. That's issuing. Again, we've got another lab. Again, it's going to be very simple to do. Lab is is followed in here. This time I am going to use my wallet so I guess I better activate that. And let me get back to seeing my wallet and seeing my traction. So I've got my instance of traction I'm going to go to the issuance, and I'm going to offer a credential. The other credential in this case is I have I have a connection so actually let me jump back to that so I've established connections previously to my BC wallet into my orbit wallet I could use either of them orbit is from northern block. So I've got a connection previously I established that by creating an invitation, giving an alias to it and then generating a a QR code that can be used to connect to it. So that established a connection between the wallet and traction. So I now have a relationship I've used did come to establish a relationship between this enterprise application and a particular wallet my particular wallet. So I've got that connection I'm now going to do an issuance so I'm going to offer a credential. I'm going to use my you have Stephen. I'm going to send it to the BC wallet here I can enter values in here but I can use this to show the data. So I'm going to put an expiry date it's now a date it looks like this. 2026 1001 so it is a date in why why why am MDD format I think I said three what four wise should be. And I'm saying that this credential expires in September, no October 1 of 2026 so sometime in the future. So my date of birth as everyone knows is in 2001. So again I'm using this format. I'm a young university students. I'm going to put in my name. Obviously, this is not how you would normally issue credentials so traction or any other application enterprise application you use has an API that allows you to interface with back end systems that contain the information you want convey so you know you establish a connection you do some verification of who the person is, and then you issue a credential and that's going to be done through some program that uses an API to send out this data it's not going to you're not going to type it in yourself but you can. So I'm now going to look at that so my data values are entered they look like that I can adjust them if needed and then I'm going to send the offer. I'm going to jump over. I got a new credential in my wallet. So I've been offered a credential. I go in this is the user interface that's available. If you want this credential up here is kind of ugly we're going to show about later how to make that prettier and make it more useful. So these fields are pretty ugly do be capitalized date and not nice but we're going to show a way to make that much better. But we'll get to that later, but the data is what I suggested I would be offering I keep wanting to use the most to move that but I've got to do this on on screen so I have the option of accepting or declining. So I accept and now I've got my credential in my wallet. So there's my list of credentials I can look at it, I can scroll down I can show all of the data for it. I can see who issued it. I've got the most friendly name again so again these are the types of things that can be cleaned up so now I've got my credential, and that is issuing. So what happened, as I mentioned was there was a back and forth the offer went that triggered the pop up, and the decision to be made in the wallet of what I want to do with it. And as I said, except it fired over the request for the credential traction this traction instance signed the credential prepared and signed the credential using the private key associated with the credential definition so they use the private information to sign it, they fired it over and that credential is now sitting in my wallet. So again we'll take a little break and let people carry out that lab and look for questions, questions or comment anything that I can respond to. So yes, you can't have slashes you can't have those things but we can make that look good. But it has to be an integer a little literal integer so think of where the commas would go on that and you can see how it's there. Revocation and things like that good we're getting into good questions but I'll leave those on the call, the folks that are helping on the call to deal with that there's lots of good stuff there. Okay that's issuing. Yes, did con v2. There's a lot of work in did con v2 going on, maybe someone on the call can answer that that knows more detail of the did con v2, but I think there is. Yes. Yes. So how many dbs and networks are you using for this so everyone is sharing the same instance of traction. Whoops, that's not going to do it. So this, everyone has everyone that's running this is using the single instance of its running areas cloud agent Python underneath and this traction UI and API on top. And then we're using a single ledger that be sovereign ledger. Okay, all right, we've got two more brief parts to go and then we'll have a break I'd like to get going on that so we've done issuing so now we've taken care of writing. We've taken care of issuing we have to verify the credential as noted when we did that. It was strictly an issuer to holder interaction there was no nothing written to the ledger as as a result of issuing that credential and that is definitely what we want we want no data associated with holders to go on the verify the data registry. We only want public information, non correlatable public information that you want everyone to see to be able to do it. There is correlatable data about the issuer, and that gets into some interesting things like what if this issuer is a person that does get into the potential of of how you would do that and where you would want to do that that would give correlatable identifier if this issuer is a person or sorry it gives correlatable identifier regardless of who the issuer is but the issuer wants that because they want verifier should be able to read that data. Okay. So now we get into the next step of presentation. Again, very straightforward. Now we're, we've eliminated the issuer from the picture don't care. We've got the holder prover, and we've got the verifier involved in this, the verifier is going to read off the verifiable data registry in order to verify the credential but they are not going to contact the issuer. They may trust the issuer but they're not going to contact or have any interaction with the issuer. So, this is again where a protocol gets involved so the issuer sends a sorry the verifier sends a presentation request, and the holder sends a presentation so the verifier to the holder is this is what I need from your request. We're conducting a business transaction and I need some data from you. And this is the data I need it might be one credential it might be data from one credential it might be data from multiple credentials. This is some sort of we want to convey from the verifier to the holder what data is needed, ideally the verifier is respecting privacy and requesting only the absolute minimum they need. And, and so, and, and again because they're receiving verifiable data they're motivated not to collect toxic private data they don't want to collect any more than they need to. In this back and forth that I show here. The red are sort of outside the realm of a non creds the black pieces are inside the non creds. And the red are outside, which is, which means, you know, let me keep going through that and I'll get to that I think I jumped ahead a bit. So, the request response model verifier ask what they need holder constructs a presentation based on what credentials they have and the cryptography is verified looks like I screwed up in adjusting this and you can't see all the words I'll fix that but the holder constructs a presentation based on the credentials that satisfy what the verifier is asking for. And then, after it the cryptography is verified in the presentation by the verifier. Note that the verifier credentials are not given the presentation is derived from the source credential this is different from other some other credential methods. In the basic and up until Monday in the data integrity proofs that are used by the W3C community. The actual credential is passed from the holder to the verifier along with some extra information. And the case of a non creds that is not the case the verifiable credentials are held by the holder and not given to the verifier what's given is a derivation of those verifiable credentials unique for this presentation only. And that is that is what is sent to the verifier. The verifier is slow, the verifier creates a request, the request is sent to via some protocol some interaction to the holder. The holder uses the presentation request to search through their wallet to find the credentials that satisfy that proof. In those credentials, they pass the credentials plus the presentation request to an on credits which generates the proof it does all of the math and so on. The presentation is then sent over to the verifier, the verifier processes that using an on credits code so again it passes the presentation plus the request over to to the non credits library which processes it and verifies it. The verifier should do business rule validation after so there might be some additional so this all this does is says that a cryptographic verification, checked out the cryptography that was included in the presentation work. However, does this meet the business rule validation and we'll talk about why that may or may not be the case. Outside of the realm of the cryptographic verification. So that those are the steps. Hope that makes sense. Okay, let's talk about the resident request presentation components this is the trickiest part of the lab I've made we've the folks that the implement traction made it easy for us if you use the same credential that I used and suggest to use a lab one it would be easy to do a presentation request but we don't have a builder a presentation request builder at this point so you got to be playing with Jason. So requested data you can request attributes which are groups of attributes from a single source credential. So you can request multiple sets of attributes and each set must come from a single source credential. You can request predicates and each predicate is a true vows true false numeric expression on a single attribute. So, built from a combination of an attribute a value and an operator that checks the relationship between them. The only operators that can be used are these ones. So, predicates. I'm now sort of lowering the bar what you can do with predicates must be an integer and must use relationships like this. So there, there are relatively limited use cases for them but the big one is a crucially important one which is older than dates, you know, expiry amount of say amount of money in a bank account so there are a bunch of ones the date ones are crucial because dates become quickly become correlatable identifiers if you can combine a date of birth. And any almost any other personally identifiable data you wind up getting a unique identifier for a person and so that's why these predicates well limited in function are pretty important. So each of these requested attributes and predicate there are restrictions and restrictions are and an or logical expression about the acceptable source credentials so this is what's saying, I will accept a credential from this issue or or this issue or or this issue were, but that's it. I will accept a credential using this scheme up from any if you were, and we'll talk about what that involves. And then finally there's revocation involved and we'll talk about that later, but basically revocation allows you to request a proof of non revocation for some or all of the source credentials so you can put revocation on a certain set of attributes that will be satisfied by a credential or across all of them. And you can use a time period for those you can say, Hey, was your credential valid on June 26. When the accident occurred so this is a back in time proof that your your credential was valid. I'm offline. Another one is the offline use case I'm offline as a verifier so I can't go check the the the the VDR right now but I do have these sets of of revocation registry so as long as you give me one of these it'll I'll be able to check yours. So this is an example. This is the example you're going to see in the in the tool to traction tool. So we've got a name we've got a nonce. Those not familiar a nonce is for preventing replay attacks, so that somebody listening in on a conversation between a holder and a verifier can grab the presentation request and then use it as their own by doing by putting a nonce in a nonce. It makes the presentation from the folder completely unique and can't be reused requested attributes these are the arrays so I'm saying I want student information to be given name and family name. I have multiple of these when I'm requesting multiple credentials. And then the restriction is where I specify what credential I'm permitting it to come from. And then a predicate here I'm saying I want to check on expiry, and I want. I'm using today essentially a few days ago when I wrote this and the, and the relationship is greater than so. And again I'm going to use this same restriction so I'm going to pull an expiry date and I'm going to check that as of today it is not expired. I won't get too deeply into this. The restrictions allow you to restrict on all of these eight items so you can restrict on a certain schema publisher a certain schema itself this shouldn't say did this is the schema identifier. The publisher identifier should be the dead. You can have a certain schema name and you can have a certain schema version so you can use any combination of these. And then likewise so that's all based on the schema. You can restrict it to a specific identity issuer, a specific credential definition, so you can restrict it to the certain issuer of a certain schema. You can also say this, the credential must have a given attribute name, and a credential must have a given attribute name and it must have this particular value in it. So you can do something like saying, Oh, you know, a passport that has a credential attribute province and value British Columbia so you can say oh I only want to allow people to prove using their passport and and and that are from British Columbia, for example. So the ends and the ores are here. You've got ends across the group and you've got an or here so you can use that for reference if you need it later. data predicates as mentioned I've gone through this a few times, either date int is the common way to do dates. So this, and there's your comma representation of that, or you can use Unix time is a good way to do this as well. So, this is the Unix time is the number of seconds that have passed since January 1, 1970. So that is when this workshop shop started this. This was the value of Unix time at that. This is what it actually looks like. And again example. Here's an example of not expired here's an example of older than it just shows you which, which expression to you so both of these represent this represents 19 years ago today this represents today. And then this tells you what, which p value which p type which expression which logical expression to use does not work with a string date. I think I've said that enough. So, once the presentation request has been provided the holder generates the data, they receive it via some protocol. They search in their secure storage their wallet for credentials to satisfy the request so there's basically a mechanism that is not officially part of an on credits that can be used but basically it's up to the implementation to find all of the source credentials that satisfy each attribute group and predicate. So you can come from the same credentials so you may have multiples coming from the same credential that's perfectly valid. If you have not found. If there's none found or if multiple credentials are found business logic would dictate what to do so you could automatically send the latest. So you've got two credentials that satisfy send the latest one. Or you could pop up a message the user saying hey you've got two credentials that satisfy this which one do you want to use in this case. So business logic would dictate how you deal with multiple credentials that deal with it. You may need to get credential definition and revocation registry data in case the presentation has to prove non revocation. So all of that data in hand you pass it to an on credits library and you generate a presentation from the request and source credentials. Basically it creates one proof for every source credential one presentation for every source credential. And then after it does that it would it includes that includes a proof across all the encoded attributes. It shares the raw values that are being revealed the to the verifier, a proof of non revocation is generated and then a proof for predicate is produced from the source credentials so if I have a data birth and an expiry both of those would be generated and attached so you may have up to four proofs, or, you know, up to you may have many presentations across this one for all of the attributes one for the non revocation proof and then one for as many predicates as are being asked for. And that's each source credential and then finally there is an aggregate proof across all the credentials that verifies that the same link secret is used for all of the source credentials that have been provided so that's one extra proof that is included in the presentation. Okay. And then there's verification. So verification, I put down as four levels, cryptographic verifications do all the proofs verify so I hand this presentation over. And we make sure that all of the cryptography matches that we pull the data from the VDR we make sure that all of the zero knowledge proof predicates, the non revocation proof the aggregate proof all of them work. Next, we verify again in a non creds was the presentation request satisfied so cryptographically they may have given us a totally different presentation unrelated to the presentation request so we want to make sure that all of the groups were satisfied the revocation intervals were satisfied and so on so this is more a logic check the cryptography has been checked. Now we're checking that the presentation request was adhered to. Next, we may have more verification done in particular in the agent framework verification of the presentation against the request unrevealed attributes raw values, other things there. Finally, the thing I wanted to underline most importantly business logic. I've done cryptographic verification but is the presentation sufficient for the business purpose and the most common one there is do we trust the issue work. In the presentation request we said only I'm going to only accept from these issuers, which is typically what we do in a paper credential more world, we say oh I want to see your driver's license. So we only accept them from a certain issuer. If we specify if we want to get a education credential from any university in the world, we're going to request certain a certain schema or certain attributes be included. So we are, we are, we won't know until we get the presentation who the actual issuer is. And as a result, we may then want to find out oh have I ever heard of this university and do I trust this university. And so that's where we wind up with a business logic decision. Do we accept this presentation for the purpose of the business. And so for handling. Oops, I just did all this pre verification by putting it into the presentation request or post verification. And that may be done through a local list built into the application. It may be based on a trust registry you're going to contact a service that says, Oh, here's the issuers you can trust. Or it could be done dynamically so when you get a new user you pass it to a human and you say hey can you check out this issuer and see who they are. And then they would do some research and decide and update either the local list or a trust registry so tricky issue here and one that certainly needs to be covered in any verifiable credential usage, whether it be a non creds or any other. Trusting the trust trusting the issuer is a interesting issue when you want to accept credentials from a wide variety of sources. So the last lab we have is issuing credentials. Lab three is presenting sorry about that. Another typo in the instructions but anyway we'll get there. Again instructions are here. Get the non creds lab three so take a few minutes and give it a try. Let's get my things up here so this time in we're going to the verification we're going to create a presentation request. I made it so that this default one that it shows here matches exactly my example so I've got a proof request I'm going to put a nonsense I'll change it. Put a bunch of numbers in I want its version one of this proof request again that's just a user setting. I'm going to want student info attributes called this and it's got to come from a schema with a schema named student ID. I'm going to check an expiry date. I'm going to make sure that the credential has not expired as of today so I'm going to change this value to 0531. And again it's going to come from the same credential. I'm going to pick a connection to send it to I'm going to send it to the BC wallet. I guess does anything yet this is being worked on right now and by the BC gov team but I'm going to add a comment to it workshop. You are presentation request. And now I'm going to submit that. And over here up pops a notification that I have a present a proof request. Whoops says I don't have one available. What happened. I'm sad. So not much I can do but to decline that. So I'm going to decline that. I'm going to get a status here. When I refresh saying this was abandoned so I got a note back from the wall saying hey, I'm not going to present. I'm going to take a quick look at my credential definition. Let's go to the schema. Student under student space ID. What I suspect this is not going to help but what the heck I'll try. So I'm going to reuse this proof request I'm going to copy this existing one by doing that. I'm going to. Oh I wonder if it's this I'm just going to remove this predicate. Oh this is fun. Okay there we go.  Try to see if that's what it is. I better pick where I'm going to send it first. Nope, I'm still not able to so I don't know what I'm doing. Oops I sent it. Okay that's interesting so I did send it anyway. I must confess I haven't done that before so. In this case, it does allow me to look at my presentation. I've got my requested attributes. I've got my presentation. This is what I did want to show this is what a presentation actually looks like so I'm revealing family name and given names. I've got a bunch of cryptographic information here and then I've got the the the value of related to the revealed to the other attributes that are not revealed. This is the aggregated proof which is very very long. And then finally I've got my revealed attributes my raw and encoded. I'm not sure. I'm not seeing immediately where it's saying the status of it, but normally you would see a status of it being verified or not verified. Okay. Not ideal but hey, we keep rolling. We've presented the proof we've done this the holder provided it to the verifier they did reading. So you get to play with it. You get to pull the data in and verify the proof. And that's it. I was going to do this before the break I think I will do this, but why don't I do this after the break why don't we take 10 minutes, and we'll come back at the top of the hour to continue on, and I'll go through that. So, the question from Stefan about why does the presentation include the not share data. That is to show that is a blinded verifier so there's no way to to derive the data from that, but it shows that the signature is valid so it is used to verify, you basically are sending enough information to verify the entire credential, but you're only revealing certain attributes. So you only provide the data that you are actually revealing. So it allows the full verification of all of the credential, but, but revealing only the attributes that you want to reveal or were asked to reveal. There's actually a feature in an on credits where the holder can choose to not share a piece of data so the presentation request comes across the verify or the holder generates a presentation and says I don't want to or sorry, gets the presentation request because I don't want to reveal my last name generation is done, and that's not revealed but it's still verified so that data still goes back to be verified. That is another reason for the business level verification suppose the verify or it's got to the holder chooses not to reveal all of the data. Okay. So let's take a break. And we'll be back at the top of the hour I'm going to turn off my mic for a bit and be back in a moment. We're going to take, I believe a seven or eight minute break and we'll see everybody at the top of the hour. Also, we are live streaming this and it will be on the hyper ledger YouTube if like Dave Bixby has to split. He can catch up with what happened after he leaves. It'll be on YouTube a little bit later today. And all the decks, the lab documents are on the wiki page and I'm going to post the links again in a second. Let's see. Steven we have a question. Yep. Why does the presentation include information on the not shared information parentheses example date of birth. That's from Steven. Yeah, so fun. Yep. So that is to enable verification of the full credentials so make sure that you're sharing the proper credential that the signature can be verified across the entire credential, even though you are not revealing the actual value there's no way to use the information that is shared to, to derive the value so that is not a hash of the date of birth or something like that it cannot be derived from it. So it's purely for verification purposes. If we can get started about another minute. Get back. And for folks falling along. Marco asked about chat history. I will post the chat with workshops but the questions we've had here have been pretty amazing. So what I will do is when we post the video to the wiki page, I will put a link to it to a PDF or a text file of the Q&A and chat. Questions and the answers are fantastic and thanks again to all the folks on the workshop who've been pitching in and helping out answering some questions for folks who are new or getting up to speed on non creds this has been great. So Marco I'll try I can't do it right now live we're not using the webinar features to zoom today but we will get that posted to the wiki page and the link to the wiki page is right above your comment. Okay, whenever you're ready buddy we're still recording you're good. Okay, let's go. Okay, I'm going to talk about revocation brief briefly first as the next topic. So there's no lab associated with this book we'll just go through it so revocation involves a couple of things one is the issue or deciding it needs to revoke a credential so it's issued a credential. It decides hey I need to revoke it for some reason, and it writes revocation data to the registry. During the holder verifier holder verifier event the presentation request in the presentation. A proof of non revocation is generated the holder reads the revocation data off the registry for its for the credential type it's been issued. And it generates a presentation, sorry, a proof as part of the presentation to go to the verify. Again, the reading is done by the verifier to do the verification of that proof. So, why would an issuer decide to revoke a credential main thing. A very common use cases the data is no longer accurate so automatically you think the easiest and most obvious is something like you've got an address in the data and that you've changed the address anything in the credential has changed any material data has changed according to the issuer. They decide they want to revoke and possibly reissue the credential so that's one. The holder's authorization to use the credential has changed this is the one people automatically think of because they think of revocation as somebody's done something bad we need to take things away from them. So, if it's a driver's license and the driver is no longer allowed to drive, they've lost the driver privileges, the issue or would revoke it. That actually is just an example of the data data change. If it's a broader category then you've done something bad and we need to take it away. And then the other one that is interesting that people forget is, we're not always perfect we don't always issue the credential correctly. And so this is one. I got made aware of this by a government person that basically said well sometimes mistakes happen and we always need a way to correct them. They said almost any credential needs this ability to be revoked. However, expiration can be handled separately without revocation put in an expires attribute as we did in that example one and you don't have to revoke for expiration. The verifier has to know they need to request a check on verification. This is a unilateral action by the issuer there's no, there need not be any involvement of the holder. The issuer just says I'm revoking this end of story and they revoke it they take the action. There may be a notification to the holder there may be even a notification that says hey you can get a new credential. And, and then you go through that process to issue a new credential to the holder. The way that can happen, a notification to the holder is if there is a relationship somehow between the issuer and the holder and this is where did calm, we think did calm is so important. Did calm becomes a trusted channel between the issuer and the holder. So, if the issuer today sends an email or an SMS to the to notify the holder hey we revoked your credential click here to get a new credential. Nobody is going to trust that nobody trusts email and SMS for those types of things with did calm you actually have a trusted channel for messaging between an enterprise and their customers. And we think that's a really important part of did calm separate from the non creds in the topic but that is this is one really good example of why having a lasting connection a relationship between the issuer and the holder can be helpful. revocations are published somewhere accessible to parties needed them that's the the VDR. In some cases the verifier can detect revocate verifier can detect revocation in subsequent presentation so the revocation is published by the issuer, and then the verifier goes to present a credential in the future. In fact, the verifier can detect can see that the revocation has been made that the credential does no longer a valid credential. The verifier, the holder can still produce a presentation and can pass it along, but the verifier will know it's been rebuilt. That's the key. The revocation scheme. And I'm talking in general across a non creds and other verify the credential formats a verifier may be able to monitor revocations and this is a bad thing we think we think this is a bad thing some. It could feature in some use cases but in general it's a bad thing which is, I give you my identifier for my credential, you then monitor the revocation to see if it ever gets revoked. And so ongoing monitoring occurs by the verifier and on creds does not allow that. And that's the difference between the non creds and some other revocation schemes, but just be aware of that difference. It's not possible for the holder to revoke a credential, they can delete it, they can decide not to present it but they hold or cannot revoke a credential that is the domain of the issuer from a cryptographic perspective. That was a question. For non creds revocation, this is the most complicated part of an on creds oddly enough it's the add on feature that you think of oh yeah by the way can we do revocation. Yes, but it's, it is complicated. The one oh scheme works, but it's not scaled very well for huge use cases for nationwide use cases it's not ideal. For the for the holder and verifier it's basically built into an on creds library and there's not much to be done, but it is a lot of work for the issuer. This gets into how it so basically that feature that I mentioned. I hand over a credential from the holder to the verifier and then the verifier can monitor it and on going basis. So that's what we want to avoid. And so what is done is a, an accumulator based non revocation zero knowledge proof is generated. So, there's a little bit here about how that happens. I'm not going to get into that I don't think in this, in this situation glad to go over this in. I want to ask me questions later and want to have a follow up or something on revocation and then one other topic that I'm going to mention, we can get into it but basically this is the, the gist of how the zero knowledge part of it works. For revocation activities for issuers, the frameworks are crucial in simplifying the activities in areas by Asian Python, for example the one BC God uses a lot and did a lot of the initial creation. A lot of the complexity of managing this from a issuer perspective is handled within the library. And so it's not a big deal to use what a credential deaf when creating a credential definition member in the setup we did we create a credential definition. We click the we use the flag use revocation, and we specify a rev registry, a revocation registry size. That's going to be a number between 1000 and 10,000 something like that. On issuing credentials. Every time we issue a credential we have to record the revocation ID of the credential and associate it with who we issued it to. When needed, we revoke a specific holders credential by using the revocation ID we invoke a routine it says revoke credential 17296. And then, at some point, we publish those revocations, either as they happen so as soon as we announced we're revoking it we immediately publish them. Or we do it periodically if the use case allows for it, we might only do it periodically so a particular, you know, DMV driver's license manager might say I'm going to publish all the revocations of driver's license once a day. So anytime an address changes, it'll, it'll be triggered the day, you know within 24 hours so that may be enough. That cuts down on the number of published operations reduces the load on a ledger. But it's a business use case you can decide to do it immediately as it happens or periodically. Those are the steps the issuer does for holders when they retreat when they receive a credential, they retrieve what's called a tails file in a non credits. So that is related to the revocation registry their credential group exists in when they create a presentation they retrieve the state of the rev of the revocation registry from the VDR. So basically the state simply says, here's the list of credentials that have been revoked out of all of the credentials that have been issued. Here are the ones that have been revoked and it's just an index it doesn't say who's it is. It's just simply an index, the 7th, 9th, 12th and 3000 credential in a registry have been revoked and all the other ones are still valid. Once they have those two pieces of information and on credits does the rest and generates and non revocation proof to include in the presentation. So pretty easy. The tails file is a static file created at credential definition creation time. They only need to download it once, and it just sits there. Finally, for the verifiers. The holder retrieved a particularly particular entry the particular state, usually the state as it exists when the presentation was created, the verifiers would retrieve that the one the holder used. They would retrieve that from the VDR and then an on credit and just handles the rest they pass in the proof they have passed in the revered entry and the verification is done. They get no correlatable identifier and they have no way in the future to monitor if that credential happens to be revoked sometime in the future. If they want to know the credit if the credentials been revoked in the future. They have to ask for another proof from the, from the holder. So it's a consent issue, and why we don't think being able to monitor revocation state is a good thing. The frameworks hide the complexity so there's a whole pile of complexity complexity I said that a revocation registry have limited size a size means the number of credentials you can issue. When all the credentials in a registry are used up you have to create a new one. So if you've got a revered side of 10,000 you can issue credential 10,000 times and then when you hit 10,000. Oh, you've got to create a new revocation registry and then track issuing through that. Acropy keeps track of usage detects when a revocation registry is used up and creates one ahead of time so that there's no stopping when you hit 10,000. So basically at the start it creates two revocation registries. As soon as the first one is consumed. It creates a third one and starts consuming the second one and so on. So you never have a point where the issuer has to stop issuing because there's no revocation registry you stay ahead of that. The tails file for revocation registry must be published for the holder to download. So acropy handles make putting it to the place specified by the issuer, usually some using something called the tail service. And then finally acropy, when you publish a revocation batch for a type of credentials so given a, you know, student ID credential you say okay I want to publish the batch publish the revocations, you might have 10 revocation registries because you've issued 100,000 credentials acropy takes care of walking through all of them and publishing all of the transactions necessary to publish those revocations. So, all of that. When we first implemented this, the, the end user that the issuer that had to do all of that work. That now is all embedded in the framework and so that's a crucial piece of simplicity and using it. Yeah, the tail server is kind of interesting. The tail server would would could be either hosted by the issuer or could be hosted on a shared service. There's no correlation so the issuer, it's not, it's not what you would call a call home factor where the, the holder has to call back to the issuer to get something because they were the whole the issuer already knows they've issued it to the holder so there's no extra knowledge gained. So the issuer holding it is fine. You can't simply update a record with expired or revoked so the question so you can't update the credential itself the credential has been signed out by the holder the holder keeps it and so on so you can't simply update the credential itself. So, you could update a record and make it available, but then that has to be queried somehow. And, and so that gets back to a call home that verifier has to call the issue or hey has this credential been released and now we've entered, we added the issue or to the whole verification process we want to keep the issuer out of that process so that's that's why you don't use that type of mechanism. The limitations of an on creds 1.0 revocation. The tails file basically holds a set of prime numbers for the revocation registry one for every entry. The problem is is that the size of that increases linearly early with the number of credentials so with 1000 credentials it's a 250 k file with 10,000 credentials is a 2.5 make file. That becomes too large for a mobile, you know your limitation is your, your, your mobile wallet commonly, your, your app that's on your phone, obviously if it's a enterprise holder, a business that has its own business wallet that's on a server well that doesn't matter. But if you're dealing with a, you know, a phone. 2.5 make file is getting large you don't want anything larger than that and so that constrains the size of it so practical limit is about 5 to 10,000 credentials for revocation registry. You can have many revocation registries for credential type. So it's still unlimited number of credentials. It's just they have to, you have to have a new registry every time you hit the limit of the registration size and so that's, that's where that limit comes from. Additional details. Handling of the presentation. So I'm just going to highlight these and request that if you want more details of these note this slide and ask me what you need to know. Revocation interval is provided. There are semantics about it and there's best practices that should be followed. So that's a little tricky to understand. And so presentation request interval is is an interesting topic. Then there's one other thing which is when you have revocation you, you request revocation, but the source credential doesn't support revocation, or you don't request revocation. How is that handled and the basic answer is that the presentation should always work. So if, if you're requesting two credentials. Sorry, you request revocation for both of them, but only one supports revocation that presentation should still work. And that's the way it is designed to work. So those are some tricky subtleties that you can get in. I'm going to jump into and and happy to have that happy to share more on that if people are interested. There you go need more information, let me know feel free to follow up back up with us with, you know, on discord or whatever to know more about that. This is where I plan to take the break.  I'm not going to do this section. So this is another really fun section and I really wish I could have done it because it could have added some interest and maybe at the end, if people are interested, we could do it or I'm happy to do another session. I have a link here to slides for this, and I recently did this at a conference, the open source summit for Linux foundation. Basically what this does is it uses high school math to do to explain how zero knowledge proof works, and it quite, you know, a very accessible way as long as you've completed high school math and you did reasonably sort of remember it. How zero knowledge groups work and why they are valuable to you so it's it is a quite like this. This was first presented by another professor I saw and I've adapted it and adjusted it and I think it's a pretty good presentation, but we don't have time for it. I included this in case we did so we'll see. Stephen what we might do is get you on the identity sig calendar to address. I didn't get to see Vancouver I'd love to see it. So we'll work that out and we'll let folks know when it's going to be. Yeah, the recording from Vancouver is posted this link actually goes right to the cart on on this section so. Okay. So the hyper ledger agnostic and on credits. So, historically hyper ledger. So, and on credits began as a tightly integrated stack. All within the hyper ledger indie project so the work evolved from IBM did ever nim and sovereign did a pile of work on it donated indie as a whole into hyper ledger. And the Linux foundation. There's a whole bunch of instances of indie that have been spun up publicly under various governance policies. Indie was an all in one it included the ledger, it included the VC format and on credits and included agents. The agents were extracted out essentially in 2018 and that became the hyper ledger areas project. In 2022, and on credits was extracted out of indie and made into the hyper ledger and non credits project so indie is the ledger and an interface to talk to the ledger permission to write open to all public to read. So when we were doing the specification where we determined that in the hyper ledger and on credits group we just determined that there was almost nothing tying in on credits actually to indie. It is more a a. It was more a that it was convenient to put it in there and the library is used it. And in fact what what I was really surprised to discover was people would come to me and say hey by the way we're using an on credits but we're using it with fabric. And we're using an on credits but we're just using a database. So all sorts of people already had just taken an on credits as it existed and put some shims around it to make it independent of indie to use it with different ones so when the on credits specification work evolved a little we decided that that was the goal of the 1.0 was to make an on credits completely independent of in of in. And so that's where the concept of the term ledger agnostic came from turned out. There was one data element that was completely in the specific but could be easily eliminated. There was a little bit of work around revocation that had to be cleared up but other than that, making it ledger agnostic was rather easy. Basically, for those familiar with did the mechanism is the same. You basically have various vdr's and you have a registration method and a resolver method and so when you have an identifier in an on credits for a schema. You pass it to the resolver it looks at the at the identifier type and then figures out which register which vdr it's on retrieves the object and passes it back and on credits has no idea whether it's on an indie network and check network or dana network doesn't know it just passes the identifier over and the resolver figures it out. Likewise, register a registrar is the same registering this is writing publishing to the vdr. You pass in the data with where you wanted to go with an identifier for an indicator where you want published and it gets published to the vdr so that's the architecture. And with that. The legendary Rodolfo is going to take over and lead you through a demonstration of that and the use of it. So I will stop sharing. You are there to offer right. It was a second ago. I didn't expect that. As I scroll through five pages of names. He got bounced. Let me. He doesn't say anything on discord. Well, that's wild. Hang on, he might be done back in. Let me. Yeah, he's out. Okay. Well, that's fine. That's all right. It's, it's, it's a workshop. We'll router. Oh, he's back. Okay. Hang on, we're gonna make you a co host. Okay. Okay, sorry for that. I think I lose all my internet connection. I'm on the mobile. So let's see how it works. All right. Yeah, I'm ready to go. Yeah. So my name is Rodolfo Miranda. Can you hear me? Yeah. Yeah. So my name is Rodolfo Miranda from roots ID. So I've been in that self sovereign space for around two years. And I come from a blockchain community. In my case is the Cardano blockchain community. That's why I'm going to talk a little bit about how you can use and on credits in a different blockchain than than Indian. So I say blockchain, but actually I should say BDR because you can use any, anything, any storage asset as a BDR. Let me share my screen because I like to, to see go to the source document that is the spec. When I show that my desktop. Can you see that? Okay. This is the spec. Great. So this is the main document. I think everything that Stephen mentioned is reading here all the technical details, how they are no credits work, how you should implement this is here is a huge document. I won't go over that, but I'm going to point to the introduction, whereas this is this nice plot here, this graph, because I will try to explain and why we need a BDR, why we need to maybe replace the BDR. So, in this plot, you see the issuer holder and verifier, the nice three participants of the of the identity solution, and you have the BDR. Roughly speaking, really simplistic, we can say that in the issuers and holder we store the private information. And on the BDR we store the public information. So since we are dealing with cryptography, you know that every time we talk about the key, we're talking about the key pair. The key pair is composed by the private part of the key, plus the public part of the key. So in this scenario, the private keys go to the issuers and to the holder in the link secret. And the public part represented in with a lot of information and posting in a specific format goes to the BDR, right, you have the private and the BDR. So we know that the private part is really critical. So if you lose, if you lose your keys or if your keys are compromised, you know that you maybe the holder lose the keys, they lose the identity, maybe the issuer lose the or compromise the keys. Maybe all the potential that the issuers have issued are compromised as well because some malicious actor can create an issue new issue new new credentials so the value of the other credentials, maybe became to zero. So, and because of that we tend to make minimize the importance of the BDR because BDR only have the public information we try to make available. But actually in order to verify a proof or a claim. We need two things right we need the signature and we need to the public part of the key. So if one of those are missing or incorrect, the proof is not going to be valid. So, in order to that one of the key features of the BDR is that the, the public key should be always available right and also should be the correct public key. So, these are the two main characters that the BDR need to have to be to have all the objects or the public information always available and to the disinformation cannot be modified in time so always have to be the same. So, as you see, the, the, the BDR have a critical is a critical component as well right and you need to decide which BDR you want to use. For example, if we also call that the BDR is like a trust storage, right, because the members of the of the user of that system need to trust that that storage. For example, if you want to, I think on the, on the chat today someone mentioned the Ethereum blockchain. So if you want to build a system for the Ethereum community. You should totally send to, to use the, that blockchain, the Ethereum blockchain as a, as a BDR because the member of that community already trust that blockchain. However, if you go to maybe a government and you start explaining that you're going to use Ethereum, maybe that one, that won't be a nice option right because the government not decide to trust that, that option. That can also be a database and you may find use cases that database is, is really the option. So that's why selecting a BDR was making a video as an option on this aspect was one of the, the principal goals, instead of using only using the, the, the in the option, right, how the spec deals with different BDRs. I think they, in the spec, there are three things to deal with, to make the spec agnostic to Indy, maybe are agnostic to any VDR, specific BDR is defined three things. The first one is a video need to implement two, two, two operations. One is to write into the BDR objects, and we call write or we also call publish offset to the BDR. And we also need another operation that is read from the BDR. We need mentioned an operation to read objects from the BDR or we also call resolve objects from the BDR. The second, I think that is defined on the spec is the objects itself. So there are four type of objects, one is the schema, the credential definition, the revocation registry with all entries. And the spec is real, is really specific in how those objects should be formatted. And if we go to the spec, we can see, for example, for the schema, that the schema need to have this specific format, and to have an issue ID, a name, a version, and all the attributes that the schema is going to have. And if you go to the, maybe the credential definition, you want to have also all sorts of different properties that the schema have to have, that the credential definition have to have, like this one issue ID, type tags, values, the primary, all the fields that are on the schema and so forth. So there is specific details of how you need to format a credential definition and each of those options. And the third thing that is defined on the spec is a registry. And this is a registry of Anon Kretz method. Anon Kretz method is a definition of how to use a specific BDR with Anon Kretz. So for example, in this, in the registry currently, we have several methods defined. In this case, for example, the didindy is how you use Indy with Anon Kretz. That's how it has been forever implemented. But you also have how you can use a web server, like a web server to store those objects. So in this one, Patrick's going to give you a demo on how to use the web server as the Anon Kretz method. We also have, for example, the check team implement, check is a platform, identity platform that use the gosmot blockchain. So they implement, I think it was the first to implement the Anon Kretz method in a different lecture. So they build a full spec, I'm going to point to that. So they build a full spec of how to use check D as an Anon Kretz method. You're going to find all the links on the slides and on the Wiki after the workshop. And we also have the Cardano that is, I'm going to explain a little bit how it works for us to build the Cardano Anon Kretz. But if you want to build a new method, you just need to define how it's going to work for your VDR to meet the PR in that repo. The working group of the Anon Kretz is going to review the PR, it's going to update that it's complied with the spec. And when it's matched, your method is going to appear here so everybody can see and use it on your ecosystem. So let me show now, as my experience, what I experienced with ID in building a new method for a particular blockchain that is the Cardano. So that's going to give you, for your reference, how it takes to build a new VDR that is not really complex. So if you go to the Cardano, you're going to find a link to our method. I think it's here. So what we did in our case is we meet with several players in that community that works with identity solution. And we try to meet periodically to define this specification that is how we should write objects into the Cardano blockchain. And try to build this spec. The first things that we need to define is how we're going to store the objects on the blockchain. Cardano is a public permission less blockchain. So we know that in every transaction of, you know, this is a cryptocurrency token that already runs on the blockchain. So in any transaction from a token from one wallet to another wallet, one address to another wallet, we're allowed to put an extra information on the transaction. So once the transaction is validated and minted in a block on the blockchain, all that information also goes to the blockchain and is anchored on that. So now you're going to have this transaction metadata on the blockchain that is going to be public available and also can be verified that is mutable, right? They cannot be changed. So we decided to use that option to store the object, the Anoncret object. We also need to define how we're going to reference that object. We use one spec, one format that is called DID link resources. That is a way to link some resources to a DID. That case takes the form of this one that says that says you have the publisher DID. In our case is the issuer DID. You have the path of resources and an object ID that is a unique identifier of the object. Since we are using a transaction to store the object itself, we decide to use the transaction ID as an object type. So that's going to be really easy then for query for those transactions. After that, we define how the object is going to be composed. We're actually going to use the Anoncret object that is defined on the spec, but also we are adding extra information such as the type of the object. Who is the issuer? And this is really important is the publisher signature. So we have an extra step of validating that whoever submit that transaction is also the owner or the controller of the issuer DID. We did that for all the objects, the schema, the credential definitions, the revocation registry. And also we have to deal with some nuances of the blockchain because, you know, in the blockchain, you have to deal with the latencies. We have to deal with transactions, with fees, with how the consensus protocol works. So we define everything on this document. And then we put the hat of developers and implement some reference implementations in code. We did that on Python, on TypeScript. What we wanted to go further that and have a real implementation. So we pick one of the frameworks, ADS framework, that allows us to use the new Anoncret specification that is a natural agnostic. So we went through them and using the ADS framework Shavascript. And I'm going to show you right now a piece of code. You don't need to understand the code. Let me clean that a little bit. I'm going to show you a little bit of code, how it takes to use. Once you have a framework that allows you to use different BDRs, it's really simple to port one BDR and use a different BDR as in that case. As I mentioned, we use the ADS framework. We implement, we import that framework into our code. We also import our reference implementation, the Cardano Anoncret specification tree. We port it to the code. And then when we launch the agent, this is the ADS ancient, it's a command to land the ancient. We tell that the Anoncret that the Asians should use is the Cardano Anoncret. That's all that we need to do to use the ADS framework with Cardano BDR. The rest of the code is just the same for any BDR. This is a script that what it does is create a LIM secret. It's also create a DID for the Israel. So everything is mixed here. It's just a sample. Create and publish the schema. And the publish means it's going to be published into the real blockchain. Create some part of the credential definition into the blockchain. And then it's going to wait for some blockchain confirmation that I need it. And it's going to resolve those. I'm going to go and read those objects from the blockchain. Let me show a little bit that. The example may be a little bit silly, but I want to show you what it does. You see creating the LIM secret. Creating the Israel DID. And then creating and registering the schema and the credential definition. If you see the ID of the credential definition. This format that is the DID of the Israel. So, that is the data. And it is a large. Large resources on this long identifier that actually stay. I did identify of the transaction that we used to. Uncore the, the data on the blockchain. So you see the now that is waiting for the blockchain confirmations. That's neat to be done because. blocks periodically. In that case it's every 20 seconds. So you need to wait for some blocks after the one that you mean to make sure that this one is really validated by all of the nodes of the Cardano blockchain that are doing this consensus protocol. So now you see that the minute pass and we have this we are able to resolve all the options. This is as Steven showed today. You can see all the details of the objects like this number of big numbers. This is actually a weight of according to all the public keys of the credential definition of the credential itself. So if you go to that, this is the scheme ID. Let me show, I'm going to show you credential definition ID. As I mentioned, this identifier, this string, is actually the idea of the transaction that was ported into the blockchain. So if we grab that, I'm going to copy that. If I go to a blockchain explorer, blockchain explorer is actually a service run by any party that go and query the blockchain to see what's there. You may find blockchain explorer for Ethereum, for Cardano, from Bitcoin for any blockchain. So if I paste this ID here and I'm going to search, I'm going to find all the details on the blockchain. This is a real blockchain. It's a testnet. It's free, but it's a real blockchain that is over there. So you're going to see timestamp. You're going to see actually the fees out that cost because every transaction has a fee. And this is 40 cents of ADA. This is like 10 cents of US dollar, but you also can go and see the metadata. And if you look at the metadata, you're going to see all the details of the credential definition with also the extra data like the signature of the issuer. So just to give a little summary of what I'm trying to explain here is that now you can use any VDR, the VDR of your choice to in a system that with AnonCrets. So how you choose the VDR, you need to choose the VDR to really provide trust for the members or for the users of that system. You have a registry with many AnonCrets already available, but if not there, you can go and build one because it's not so hard to build one. So thanks and fast back to you, Steven. Thanks, Roto. Thank you. Steven, you're up. I am. All right, let's keep going. We're going well. We've got a few things left to go. I should highlight I didn't really introduce Roto legendary in the community. He does awesome work and Patrick same thing. Patrick just keeps coming up. The two of them just keep coming up with new and interesting things that just others hadn't even thought of and boom, we're able to use them. We're demonstrating both of them today and I'm super excited about that. Okay, let me get to my presentation. Where did it go? Did I close my browser? I never closed my browser. What? Well, looks like I did. Hang on one sec. Sorry about that. There it is. It's in full screen mode. Okay. We're going to jump to a topic that for insiders in the community is quite interesting and controversial for a long time and yet pretty weird. Anon creds in W3C VC data model format. So long controversy, controversial in the verifiable credentials community. Anon creds does not use the W3C VC data model. Several initiatives were started over the years. As mentioned, both the VC data model and the Anon creds goes back of six, seven years. Several initiatives were started to align the models. ZKPs are specifically mentioned in the W3C VC spec. Anon creds had some work to align the models and it turned out that the most significant one, which was a thing called Rich Schema, fizzled out because it just added lots more complexity, made things much more complicated to use. That's where we were back in October and what was discovered at Rebooting Web of Trust, and I am happy to say I had some things to do with it, is we found out that they actually work really nicely together. And in fact, there isn't a lot of need for this controversy because actually you can use Anon creds in W3C credential. So it turns out putting it into the credential is pretty easy. There's only here the proof of concept with code and examples, and basically what that does is it takes an Anon creds credential, converts it into a W3C verifiable credential data model, and converts it back if necessary, and when necessary. And then likewise takes a presentation and Anon creds presentation, puts it into the W3C VP data model and converts it back. And so what that means, you've got this two-way transformation, what that allows is you can issue a credential in the VC data model format. For processing it within Anon creds, you simply swap the model back, process it, and do what you need with it. And that's all you need to do, basically. And the way we did this was simply by moving around JSON. We took the signature on the VC VP, made it contain identical data in the Anon creds presentation. Everything else about the Anon creds credential, the canonicalization and presentation, the canonicalization, the signing, creating presentation, verifying, all stay the same. So there's no difference in the processing. All features of an Anon cred are supported. So kind of cool. I'm going to quickly go over this and then pass this over to Patrick, who's going to show some cool stuff he's done with this idea. But basically, the cred def ID becomes the issuer ID, the schema becomes the schema. So it's referenced in the credential schema type. There's a type of Anon creds. We've got the idea of the schema in here. And then our credential subject, our raw data goes into here. The encoded data does not go into here. Remember, I mentioned that it would be better if the encoded data wasn't actually in the various Anon creds object share. In this case, we don't put it in. We use the canonicalization approach. So that's not encoding auto, meaning, oh, just generate it yourself. You don't need me to pass it to you. You can figure it out yourself. The signature, all of this data in here simply goes into one big long, and yes, it is a very long base 64 string, which can be converted out of base 64 and back into this. That's the back and forth. We have a JSON LD context, which defines everything like CL signature 2022 and things like that. And then we have a second component. And this is those for those who need to know about JSON LD. This allows the definition of all of the fields within here generically, so that we get generically a way to specify in a JSON LD what these items are. And this could be replaced by an issuer specific context. Again, this is JSON LD inside our info. So only if you understand JSON LD will you understand this. But we could introduce a new concept in an on creds that allows an issuer to specify an actual JSON LD remote context that would allow definition of the credential subject values in it. And that would make it fully aligned with the data integrity. This also allows us to use some sort of what's called crypto agility. So crypto agility can be done by adding multiple signatures to a credential so that you have both flexibility and long-term vulnerability protection. So the idea there is you would put a NIST approved, an ED 25519 and a quantum safe signature on the same credential. And so we've carried out proof of concepts with an on creds where basically down here, this can be basically a list of proofs. So you have the an on creds proof, but you could also have a data integrity proof, a traditional W3C proof. Both of them would be on this. If you use the data integrity proof, you would basically share with the verifier the entire credential. But if you use the CL signature, you would have all the features of an on creds. So hopefully that makes sense. You've got a VC that can be presented using an on creds or not, and it enables by just generating the two proofs as you issued the credential. So with that introduction, I'm going to turn it over to Patrick Sainoie, who's from the Digital Identity Lab of Canada, who is doing some phenomenal work at crossing over the communities. Remember that communities that I showed you earlier on, that slide with the four different communities that are happening. This guy is doing a fantastic job at jumping across them and figuring out stuff that's happening across them and trying to find synergies between them and doing a really great job. So with that, I will turn it over to you, Patrick. All right. Thank you. Thank you for the brief introduction, Stephen. Let me share my screen real quick. So this is the one here. So in my presentation today, there is going to cover many different topics. So I won't go into detail and too much of them because we could be here for a long time. But it's going to cater directly to the last section that we saw using an on creds and WHVC data model format. And also, when we were talking about different methods, this is going to use the did web method, which is a very convenient way to understand these topics because it takes away the blockchain and the ledger side of things and focus on the different elements and the portability of an on creds. So an overview of the technologies used in this presentation. So there's a few links here. I can share this presentation after no problem. So this is sort of the way I see it. This is a kind of mix and matching different specification. I did not directly create any of these. I participated in the did web an on creds method with Ariel, which is another member of the community. Where I stand, where I come from is at the lab, we sort of keep track of everything happening in different spaces. So by doing that, we participate in many different communities on a weekly basis, attend different calls and see a bit what is happening. And from my side, I like to just take different solutions and try to mix and match it a bit like some form of alchemy, if you could think so. So yeah, I put a few links here of all the different protocols, standards, specification, whatever that are used here. They're mostly in the hyperledger space and the W3C credentials community groups space. So the first question is why would I bother using chat and the VC API to issue an on creds? So the key here is interoperability. So interoperability is always at the core of a good ecosystem, especially with digital ID. And when you can demonstrate interoperability, which is a whole different thing, well, it attests how frameworks are built with a solid foundation, right? And they meet their goals. Because you don't want to pigeonhole your solution and lock it in a specific space, right? You want to be able to move around and create a great ecosystem. So this demonstration will show two things. We'll show how by design, what you see at the model is very adaptive and that was one of their core principle. And the second way is to attest of the majority portability or the ledger agnostic side of the new an on creds library. Before I start, I just want to put a special notice to this page here. So this is the contributors page for the unencredg