 end of the presentation is to start off on the user side and then we should just go back into the contact. So the goal of this web app was to create a UI that was easy to read, clean, fairly simple to navigate. And for that, we decided to use the React web framework, which allows us to use reusable components or parts of the web app that we can use in other parts of the web app if, for example, we wanted to scale up or make the web app more complex. So we've taken that into account. I know it does touch on that on the players and applicability. So that was the reason behind using React. So here what we have is the home page for when a user logs in and one thing that they see first is the sidebar that lists different sections and the way we decided to organize these sections was based on what kinds of user actions we'd expect. So for this case, we'd expect documents and claims to be the most important types of things that would require a user's attention or action. So by going to the documents page, which actually we're already on to the home page, we see a table with listing all the different documents that have or haven't been signed. And you can see what date they've been added, who they've been signed by, their status. And we even have some functionality here that if you hover over, oh, that's really funny, Chromecast isn't actually showing me. I can show you. Yeah, when you hover over these, it actually gives you a snippet of information. So you don't actually have to go through the process of opening the file. But when you do click on one of the files, let's go to mortgage application, it'll give you parse JSON data, which we're receiving from the back end and it displays it. It gives you content, it gives you the text content of the document. And what's not being shown here is the PDF or a review, which would be on the right-hand side or somewhere that's easily accessible. So the user can evaluate both the written content as well as a PDF version of it. So once the user goes through the document, reviews it, and they decide they want to sign it, we've added a button that lets them sign. And obviously, we'd have something a little bit, oh, you can't see the pop-up side there. Just a pop-up asking them to confirm. And the idea is that we walk them through the process, maybe possibly a series of windows that would kind of hold their hand while getting them to confirm the document signature. So once you complete that, you'd be able to go back to the documents table and see an updated column for date signed, signed by. And that would complete the flow for the document section. Now, for the claim section, if you go to the claim section, you see the same thing. One new thing that we've added here is verified by column. So for example, for verification of insurance, we have the date that it was added, who signed it. So in this case, Alice, our user signed it. And we see here that it was verified by DCU. If we were to click on any one of these, we'd be taken to an individual claim section. We'd be able to see, again, parse JSON data, as well as an important section here, statement of intent that would require users to check off different statements of intents to ensure that they understand what it is that they're signing or sending. So this one's like the consent-oriented, the consent to share the employment information. To share it out. In that case, yeah. And then it's a little different for each context. And so this is very customizable and extensible to the context that you have. In terms of the notice or alert that a consumer would be expected to have seen and agreed to. So in this situation, they would be certifying that they're going because they know they want to share this. Do they have to share it explicitly or are they sharing this to a distributed ledger where that can be retrieved from there? Well, I can say in this, the thing that you're seeing right here, the way that the assumptions were for this demo. First of all, you could do any of that. The assumptions we have here for purposes of showing you something that would work and that requires no other things to, like the ledgers that don't yet exist and so forth, is that to leverage the existing components you have for file sharing and for file storage for mortgage application lending. So like, show me the title of the house, show me the list of that, like all the stuff that you ask for. This assumes that you're leveraging maximally everything you currently do and layering this better capability on top of it and doing the right sort of like flow and integrations in the back. And I'm satisfied between me and Jason and Dan interrogating all the people and my goal and the technical people and then now Sandbox Banking and understanding that little bit better about ways to get in and out of FISERV systems. I think this is realistic. You could do a great deal more than that. So it could be more than a consent basically to go back to the lender that you're seeking a loan from to Verify Employment or the other things. They could absolutely put it onto a shared ledger and get bids or you could do you could do routing, other stuff that we want. Some of that will come out of when you see the technology demo with Christian and Cornell. I think you'll see some very exciting possibilities. Cool. OK, the last thing I wanted to show was a feature that would allow a user to create a document or create a claim at a station. So here we have a feature that lets us just quickly add a claim here or we can add for redundancy. We added also a create claim section. So when you go there, you can pick between many different claim types. And the idea is that once you click one, the form that will show will switch depending on the type of claim type that you choose. So here this just gives you, for example, which use address. We would see the address form that will allow the user to just put in the street town and choose their state and then save that. And once that gets saved, do you expect it to show here in the claims table? And that's that's about it, I think. And may I just so it's probably the first time you're seeing this. So just to play out the address one. So you have an existing workflow and home banking for people to update their address after you've done. First day on boarding and account activation. If some things like address, you know, in addition to like, I don't know, email preferences or other stuff, like you expect so important, so reusable and valuable that you might want it to be verified by. So that's where you're going to be sending the statements. If that's now like your confirmed address of the member being able to make that a verified claim, as well as one of the members signed, who's reusable at least across DC, but then also PC partners or other parts of their life, we believe could be helpful. And that's actually the value of competition driving this whole very wide claim and secure being DIF and on and on markets for the sum. Reusable aspect of like financial digital assets for that you can put in the hands of people. You help me understand that a little bit more so like verified by, I would suggest that it would be USGS. Sure. So we would amend that, I just asked, right? Yeah. Agreed. May I offer it on that one though? So I hear that a lot on address and I know the people there pretty well and like several projects with them over the years on identity and the GSA and other folks and PKI and now blockchain and a lot of SAML work and a lot more recently on and on and on and stick. Sure. And like if and when there's other parties external to you that can verify things and natural figure and we're assuming that absolutely for the employer when it is in TCU. For example, that would be the workflow when you're the lender. Any of that would adopt this like ADP is the one that we selected because after your chat with Christian Cornell and I, we were talking about more like a B2B being a really sweet spot. We kind of talked it over a little bit and I've recomposed some of the assumptions so that we can imagine verification employment could be payroll company and you want to create many individuals there. But what's the thing I want to point out is that you don't have to wait for and hope for the USPS ever figuring this out or doing it or doing it this way or well or ever in order to indicate this is the address that we send a member of our credit union their statements at every month and that we have this address for them. And one of the things that we think is to be proven in terms of like extended value of a blockchain which we should get into in the discussion is in addition to reducing cost containing risk and potentially having some new revenue for your existing business functions. The first adjacent business function out there and the only one that's sort of part of the scope of I'm showing you would be the potential of reusability of some verified claims because everybody thinks it's going to be big to let people reuse information about themselves period but then information has been confirmed to verify by a third party and you are a trusted third party in the relationship here. So this only assumes that you would be stamping it and that it would conform with where you send the statement and then but it's a tailor made for other people as well that could confirm it or military or other people that have the current authoritative source of address for a person. Does that make sense? Yeah I'm just trying to see that through in regards to what the consumer does with it after it been verified as an example. We're starting to do a lot with Amazon now on another different blockchain thing and apparently they're so they certainly are hooked up with USPS and a lot of other folks in terms of address for SHIP2 and fraud but I'll double check this but my superficial understanding is if there was a structured blockchain like a verified like a verified modern verified claim way of like allowing like almost like a one-click integration from Amazon customers to indicate with their SHIP2 address that they would be very happy about that and that it would be in tune with where their spend is right now to reduce fraud and to increase usability of the site so that you're not retyping stuff so that would be one example. So it goes to the notion of if a consumer could share their attributes out to a distributed ledger and make those accessible to others right as long as they're verified then that's the power in it. That's basically that's the underlying idea for the verified claim to third party companies but none of that has to be true you don't have to accept any of it I think for the for the fundamental value proposition that we're doing but it doesn't go without saying because like that's the bottom of the idea for distributed identity foundation a whole bunch of stuff going on now so I thought we should at least show you how you could explore that if you wanted to I don't think you need to explore that to have a better experience and reduced cost using the technology just to do precisely what you're doing today. Do you have more? No that was it. I wish you kept going because I love this work so this is so that's the UI and the UX and it's understandable and I was I don't know speaking also as a TCU member I would certainly use it and so now are you ready for technology? Yeah and then I get stuck so that left nav and you have the carrots that point to the right like for whatever reason our carrots and our online bank can go to the left. Oh you're kidding me. Is that economy? Oh that's a very quick UI. So you prefer this way? I just I I've gone back and forth with developers on this and you know I don't know really is that. Actually I didn't really talk about it but just one quick thing so they point to the right but ideally when you click on them if there are subsections like for example if you wanted to create document section and click on that and then have that arrow turned on. Sure you can see that yeah that was that was it works. What a handsome hue of green you have there too. It looks very familiar. Delightful okay you're welcome are you ready ready for the for the technology? I am. All right aka the good line here come the goods capturing this so you'll get it later. So on the left we have the application running on my machine and on the right side there's the application running on Christian machine it's a screenshot. So I'm going to focus on my application at this point this is the initial state of the application after you log in to provide your identity and you have the possibility and in order to to go through the entire flow we're going to start by creating a new document. So just sorry the left is yours I get is it is this a user or is this a back office person? This could be anyone anyone this is a general document signing application okay. And the fundamental basic idea the way that we've gone back and forth many times is you could assume when there's only two there's a DCU staff person and a DCU member when there's three there's like a DCU member probably a second DCU member and a DCU staff person or possibly a non DCU member. Yeah okay I just want to get my mind in the right place okay. So at this point we have only two options when creating any document but I'm going to show you the option where you provide the application with an industry standard such as a form standard or actually schema it's a schema where you provide the fields and types and the forms are getting generated automatically so basically you can take any industry standard provide a schema and everything will be generated automatically. This form is a proposal for vehicle sales agreement and we're not going to focus on it we just wanted to emphasize the fact that you can you can add any type of documents in a standard way in this application. So you can think member agreement I'm starting out. So we're going to to go with a generic option of adding any documents so for this option we have the possibility to enter a name I'm going to call it DCU demo remember the name because we're going to take it in our application and we have the recipients. So the recipient you can enter as many recipients as you wish our commercial predictive values for this demo purpose I'm going to add on encryption and the point of interaction is going to happen continuing in here. Idiot so I'm going to add two attachments I have generic PDFs so nothing already pre-filled and I have a PDF sample and I have a bill of save. After saving this document you'll notice that it appeared in my pending folder my drafts sorry not pending and I can expand and see the complete summary of this document and I can see the to whom I addressed the document the attachments I think that I can open and view it so and the payload which is a marker route of the of the attachments. Okay so from my point of view I think this is okay I'm going to send it to Krishan and you'll notice that on the right side the document was passed to Krishan so at this point a copy of the document was sent to his machine. Probably won't see this in the screen sharing because I'm only sharing one window but I actually have the document that he sent. And now I might want to sign this document so that we have can further along the transaction and so I've reviewed it and everything looks good and I'll click on sign. So notice that the signature was automatically propagated over to the Cornell's app and what you can see here I'll explain this to Krish that's probably not the best way to present it to a human but it helps for the demo to explain the moving parts here. So we have a signature and this happens to be signed with a set of blockchain keys with blockchain keeper and the key this what's a public key this is actually a JSON based certificate of the public key that is certificated by a party presumably a financial institution or a credit. I'll show you some more on that when we start talking about it. So we're covering the verifying you know who's the wow it's really written who's actually the owner of this key and so now Cornell has this but we need him to sign it too. Okay so you'll notice that at this point the document on my end it's on pending because I'm the issuer of the document and there is only one there is only Krish's signature and for Krishan he's in inbox because he's not the issuer and there is only one signature so I can verify they can see that Krishan already signed it and the next step in this process is for me to sign it so after signing it the document disappeared from my pending folder and now it's in the signed documents and we have two signatures on it scrolls out oh yes two signatures if you put them side by side you will notice the information is the same but we're not done yet because so much more because um yet we have this signed document but there's no record of it anywhere on a ledger and so we have this ability to finalize there's a little lag with my mouse sorry about that and so once I click on this this is actually this is going to add this thing oh it's in the size of the document yep okay this just logged this thing on Ethereum so we've hashed the document and we put it into a blockchain transaction so this could be part of a financial transaction over blockchain or it could be just recording it as a log entry um hashed it put it on the blockchain hash the document yeah or actually hashed the we hashed the uh the signed not the pdfs themselves but we have we have a json data structure that is signed um and we've hashed that thing and put it on the blockchain and so and part of the so to be complete yes um there's a hash of the pdf and plus the other metadata in the json web document um so that you could absolutely confirm um the a pdf like here or litigation in five years or an audit or something you could rehash the pdf and then plus the value other values in the json web document i'm token by and compared to that on the blockchain and confirm its validity exactly as we said we would do in the use case presentation proposal so the the principle value of doing that there's two two real values of doing that one of them is that um you have verification of a sequence of events so like a time stamp and effectively a time stamp um so you can say when did this thing happen um you can't get that without using some kind of a ledger just us signing the documents i mean there could be clock skew or there could be um people uh changing the time stamps or things like that but if you're logging it um onto the ledger you'll have you'll have a reasonably accurate um ordering of events trusted time yeah uh the the other thing is that you can find the document or the the signature off the chain to a transaction on the chain so if there's a dispute over what the payment was for um you'd be able to say um yes this payment was really for uh to satisfy this contract and you know imagine um say the purchase of a vehicle and money changes hands and there's a signed document but um the the seller is saying i didn't receive the money the money that i got was for something else it wasn't for the car so um putting this into the transaction uh gives you a way to verify yes this is really what the transaction was about and there is really one thing to mention here is the activity grid good so yeah speaking of evidence every action that happens between in the interaction process is logged in a activity grid and at this point we display a really brief summary of what is happening like the date the time the name and the first that that exchange the information but you can add as many information as as means to this to this block this is and it's local and decocts were replicated back to uh the pds or shared yeah tada everybody so the ui that alex shared would be overlaid on this or yeah we didn't actually have time for that we came into it too late and i think um what would be great is if we could get i'm gonna just stop right