 All right. Well, welcome everyone. I'm Mark Molovic. I'm the Oracle Senior Director of Blockchain Product Management responsible for our blockchain platform. And I also have a pleasure to introduce for this session Mike Vasey, the CEO of IDRAMP, an Oracle partner. And we're going to talk today about identity proofing solution that Oracle and IDRAMP have put together, combining the Hyperledger Indie platform with Hyperledger Fabric. We're going to explain why we're actually using two separate distributed ledges and why that makes the solution stronger. And we'll actually see a live demo as well that Mike will share with us. So we'll begin by talking a little bit about what ID proofing is and why it's important. We will discuss the solution architecture that combines Indian Fabric into a whole implementation running in Oracle Cloud and a little bit of the implementation details and the user experience in terms of getting through the onboarding and proofing and discuss some of the opportunities and use cases in the real world. And we have some time for Q&A at the end. So with that, let me ask Mike to talk a little bit about verifiable credentials and the importance. Perfect. Thanks, Mark. So throughout the presentation and demonstration today, we're going to be talking about identity proofing, why it's important, and more importantly, how we can use those proven identities to really transform existing processes as we know it. As Mark said, we'll get into a technical discussion of an architecture of how we developed this and why, and that's really exciting. Before we really talk about identity proofing, I want to break down and explain the verifiable credentials in a little bit because we'll be seeing that throughout the presentation and demonstration as well. So we are taking those, that proven identity and containing those within verifiable credentials to allow for the assertion of those attributes by individuals themselves, which breaks that centralized, predictable data store that is attackable. So through verifiable credentials, we're able to really transform these business processes and protect the privacy of data. And the really interesting side effect here is we're also making it more secure and easier to use for the end user, which is a rare combination. So why is identity proofing important? Go ahead and go to the next slide, Mark, and I'll set this up a little bit. So the first and foremost thing that we're going to talk about today is really the reduction in fraud. By going through a tight identity proofing process, we can eliminate bad actors and really try to strengthen those services. The customer experience is one that I just touched on, the identity proofing process when broken out into a verifiable credential and held by an individual is a repeatable process that they can go through to gain access to different services. And we're going to demonstrate that. It actually provides a much better customer experience by taking out a lot of the complexity of usernames, passwords, different interfaces for different systems. And we're going to show that in a government example that we put together. We'll show that through demonstration of how we can affect those multiple services. Complimenting that the consistent ID and process, obviously, identity consistent identities can be used to really help downstream systems gather information and make better decisions because they're not dealing with varying information as it comes in from different identity sources. So that's the last part that we'll touch on. And Mark, I think I'll turn it back over to you to go through the identity proofing. All right. Sure. Thanks, Mike. So, you know, as you saw, a lot of this focuses on requirements from government agencies could be, you know, local or city government state could be a federal agency. But equally, we think this translates into some of the enterprise requirements as well. And so working with, you know, a number of customers like that, certainly see a key requirement that is those agencies or departments that want to authenticate users against a single set of credentials for multiple applications. They don't want to help the users coming in and setting up identities for each application separately in its own silo. So there needs to be some sort of environment where a single set of credentials can be used across multiple applications. The idea is to enable, you know, city or state residents and members of a particular organization to enroll, submit some kind of verification documents, right, for proofing that in fact they have a particular residence or they are a member of a particular organization online or within a touchless manner. And then on the back end, there needs to be an administrative interface for tracking and managing the process. Some of those documents can be verified at the market. For example, if one of them is a driver's license, most of the state DNVs have in US at least have API based systems that allow for automated verification and other documents could be verified. But if it's some other kind of document, there may be manual verification involved and there needs to be certainly an administrative interface that allows for tracking and managing that. Once the identity is created, there is a KVC profile that's created for the user. And there may be a need to share that or desire to share that with related government organizations or other jurisdictions, non-profit organizations, etc. And in order to ensure that this is not abused, one of the key requirements is to make the setting self sovereign. Namely, is that the users are going to be asked to approve somebody accessing that particular profile and they can accept or reject that request. And of course, if they accept the request, then the tax is granted, but it's also logged in an immutable audit trail. So the entire process from the documents being submitted, verified and then the access to the credentials and a grant of permission to access those credentials all need to be logged in an immutable ledger. So this is sort of a collection of key requirements around the solutions that we've been working on. Now, if you look at how we implemented this, there is really requirements here that some of those are best addressed by Hyperlegia India and others are best addressed by fabric. And we decided rather than try to kind of fit in everything onto one platform, really the best in class solution would combine the benefits of both platforms. So on the top, you see here two key components of the applications. There is credential manager application. This is doing the proofing, the onboarding process. And then there's user wallet based on Aries, Hyperlegia Aries project. So they're using Indie to essentially maintain the DADs, decentralized identities and the issue identity status of the credentials. Of course, the keys that provides a cryptographic binding and verifiable claims. But there is also a need to maintain a lot of the subsidiary information. And what often happens with Indie implementations is that the information about the documents that are used for proofing or status of verification, private data, permission grants, all of that is maintained kind of in a database and that becomes vulnerable. And of course, it's not time for resistant and so on. So in implementing the solution, we decided to use a more general purpose distributed ledger, Hyperlegia fabric in order to maintain either documents, those records themselves or hashes. In some cases, you don't want the documents actually on blockchain, but the hashes could be on the blockchain to ensure that they can be verified. The status of the verification and then the log of the access permission grants, the users being asked to provide access and the granting it or rejecting it. And then of course, access records when the credentials are being accessed. So in the ideal solutions and this combination of the two ledgers, the more special purpose Indie and more general purpose fabric provides significant benefits. Now how we've implemented this in Oracle Cloud Infrastructure. So you see here that we have on top of some kind of a government portal, maybe for city state agency. And there's a number of services such as an employment services, health and human services, housing, court services, etc. that access through the portal. In any case, for any of those services, when the user is accessing for the first time, they're going to be asked to set up the credentials through the IDRAM credential application on the right here that does the actual verification and distribution. And it's connected to both fabric network and Indie network. So once credentials are verified, the central identity is established on Indie, but the documents that they use during the proofing and all of the statuses stored on fabric. And then at the end of the process, the identity is created in Oracle Identity Cloud Service that then enables password free login for a variety of the services using the user wallet, right? So credentials actually sent to the user's wallet and then verified users can access the applications through the portal directly with the wallet. And you're going to see that in a demo in a minute here being used to provide the QR code essentially that they're going to give them access. From a user perspective, the process is very straightforward. Initially, the user threw a mobile app, registers for verification, so they submit some data. This is very flexible. It could be driver's license, could be utility bills, whatever the data might be required. State or city, for example, might then go through verification. Some of those steps will be automated and others may require manual procedures. Once the documents have been verified, then the credentials are created and two things happen. Credentials are distributed into the wallet and there's also accounts created in the identity management system such as in Oracle Identity Cloud or maybe federated directory services, et cetera. And then when the users go ahead and want to access and login to the services, then the authentication basically is done by presenting that QR code and that enables backend authentication through that management. So that's in a nutshell what the user experience will look like. Now there's a number of benefits of this solution. Obviously, it can be deployed easily, leveraging existing investments. Most customers have some kind of a directory service or they could use Oracle Identity Cloud. It reduces the exposure of identity systems to public internet because all the proofing is done separately. Of course, we have the auditability and usability, you know, immutability of the proofing request and all of the status information. Users have more control, so there is greater trust in being able to actually share the data because they know that it's under their control. It's easier to add credentialification in any service pretty much, so it's very extensible. Standards-based, using couple of Indian fabric and an address-based wallet. All of the departments within the entity, city or state will be consistently using the same proofing practices. So for different types of accounts, you might require different types of proofing documents that could be flexibly configured as well. And of course, you could, you know, do some value-add services for some of the related jurisdictions. You know, here, for example, in the Bay Area, there are specific, you know, city services for each city, but then there are Bay Area-wide organizations, entities, agencies where they might want to also use the same identity. So with that, let me switch it back over to Mike to take us through the demonstration. Perfect. Okay. Thanks. Let me take the share. Okay, stop sharing. Go ahead. All right. Okay. You see in that, okay, Mark, I'm going to make that. Yeah, it's good. All right. Okay. So this is, as we went through in the illustrations previously, this is a resident services portal and we developed this for a POC and it's going to demonstrate everything that Mark just went through architecturally. And we'll pause throughout this recorded demo to explain how some of these pieces are moving through the system. So the first thing with this resident service that you can imagine, and when I'm sharing a mobile device on the right here that has that wallet up that we talked about, and we're going to show the process of onboarding basically into the resident services portal. And then we're going to show the ability to traverse a couple of these different services using that identity instead of creating a separate identity in each silo or stack. So let's get started with this and I'll pause it throughout so we can see the first thing we're going to do is we're going to come in and say we want to go to jobs and unemployment and we want to file an unemployment claim. Well, the first thing we need to do is get our resident ID. So in order to do that, we're going to start a new verification request and that's going to allow me as the resident to validate, to upload and validate some existing information. And from that, we're going to create a credential. So as we go through this process, we're going to require a driver's license, maybe a social security number. We're going to upload the information. You can see all of that information is prefilled, put in the social security number and submit it. Okay, so what happens here? So at this point, all of that information has been recorded. And as Mark indicated, we're pushing that out to a fabric based system, storing that information. And that information is going to be used then for a verification request. So as the resident, I see now that I have a pending request that is that that is proving out my driver's license and my address, and that is going to now be verified. So someone on the other end of this on the admin side is going to make the rules and determine how that verification happens. In this case, we're going to verify the driver's license through an API. As mentioned, we'll see that it's pending. If we go in here and look, we're going to see that the driver's license has already been automatically verified through an API call to the DMV. We can still look at the details of that if we'd like and see the information that was submitted, there's all the driver's license information. And now we can go and we can do the same thing with social security number, maybe that's a manual verification. So there I just provided a manual verification of that service. And now we have all of our required elements that have been verified. And it's and we're ready now to issue that resident ID or those set of credentials to the to the end user. So important thing to note here is the end users is they're not going through this process, right? This is the administrative process. The end user is done. They uploaded their documentation. We're sharing that end user wallet on the right here. And what's going to happen now is we're going to do a couple of things. The first thing we're going to do is push a message down this connection to that user saying that all their information has been verified and ready to issue that credential. So we'll send that message. It happens through the areas actually is what's delivering this. And it's sending that message now and saying that, you know, that all the credentials have been verified and you're going to receive some credentials here very shortly. So when we issue that same thing, we're going to use that connection. And we're going to deliver a resident ID street address. And an identification number resident ID number. And we're going to a driver's license, we verified that as well. So now we have three credentials that have been sent and issued into the holders into the resident's wallet here. You can see the street address identification and driver's license. Now, so we have all that information. Now here's the really cool thing about what's happening. As we go back to those city services to provide verification into those city services, our resident here doesn't really need to understand exactly what information is being asked. They don't have to go and search for that information. The wallet is going to figure out what information is being asked for by the verification process from the resident portal. And the wallet is automatically going to return the required or requested data with the user's consent when that happens. So through, so what happened here is we took all of that information that we put into the fabric system and we generated some credentials based on Indy and we and we pushed those out to the holder. So we're mixing those two technologies here. Now we're going to go back and look at a verification. And this will take us to like say on jobs and now we're going to go back to the jobs and unemployment that we were trying to get into originally. This time, now to log in, we just scan this QR code and you can see here what it's asking for to log into jobs and unemployment. It's asking for first name, last name and a social security number, right? So obviously a highly sensitive site and we're sending a social security number. So the wallet is figuring all that out. The end user has to say, yes, I can send, I want to send this information. And when they do, they will be logged in to file their unemployment claims so they can go to the, you know, uninsurance division or whatever. If they come back to the resident portal and say they want to access a court service, they can use the same exact process. So they don't have to change their process. They don't have to go look for a different username or different password. They go through the same exact process. This time when they scan this QR code, the Health and Human Services Department here is asking for a completely different set of information. They don't require a social security number. They require the ID number and a driver's license number and a date of birth. So again, the end user doesn't have to go and find that information or do anything. It's all been issued to them from the on-boarding request. All they have to do is decide if it's okay. They send the information. It sends it back to the court services and they're logged in to their court services site. So you can see how a little bit of identity proofing on the front end simplifies the process for the user as they move through these different services and really streamlines the process. At the same time, because we've distributed this the way that we have, there's no centralized identity stack to attack, right? There's no centralized predictable login process. The threat vector on this is very distributed because every holder is containing those individual credentials. So that is it for the demonstration. Mark, let me give you the share back here and let's see. I think I can't stop my share. There you go. You should be able to share back. All right. Thanks, Mike. Maybe you can also tell us a little bit about those related use cases in addition to identity proofing that you see. Certainly. Yeah. So using the same structure, if you will, really simplify the cross department federations. If you're looking at ways to get through different identity silos, identity stacks, this provides you a common way to traverse those. Passwordless login, obviously, is the biggest thing here that probably came through in this demo is that there is no password. We're not masking the password. There is no password. The password is your identity. So that's anywhere that you have those services where you really need a strong identity proofing and then a zero trust is getting kicked around. And my impression is this is where zero trust starts, right? Let's remove those passwords, not mask them. Let's remove them. And so this solution, this technology lends itself very well to that. Fraud reduction, we talked about a little bit building a system that is, you know, that does a better job of proving who we're talking to and better know your customer elements is going to reduce fraud. And then mixing and matching, as I mentioned, the IDP solutions, you really eliminate two factor solutions. You can integrate consent forms, all kinds of stuff on top of this technology using the same platform that we just talked about because you have a strong auditing capability as well as a strong identity data assertion. So, Mark, do you want to share? Well, I guess we just have two slides, really, just kind of an about slide talking about some of the projects we worked on. And then we'll move to Q&A if that works for you. Yeah, yeah, go ahead and if you talk a little bit about IDRAMP. So just a little bit about IDRAMP. Obviously, we're focused on decentralization of identity, really removing passwords and any kind of a zero trust implementation. We worked with American Electric Power, reduced Johnson 3rd party fraud reduction projects. PricewaterhouseCoopers is doing a zero trust webcasting solution using verifiable credentials to gain access. We're actually really excited about a platform similar to Hoppin here called KikoChat that is using passwordless self sovereign identity to log into their platform. So you don't have to register for an account. You just go in and use your verified email credential to log in. So it's really cool stuff. We're laser focused in zero trust solutions and really all things that are around the decentralized identity spectrum. The solution like we just went through and just demonstrated are things that our platform does very natively. It's an exciting time for identity for sure. Mark, I'll let you take over and go a little bit more on Oracle. Yeah, sure. Thanks, Mike. So a little bit about Oracle blockchain platform. Obviously, as you saw here, Hyperledge Fabric piece of the solution is actually leveraging Oracle blockchain platform, which is fabric based as a cloud service also available as an anti-presidiation on premises. It's preassembled. It's platforms that can interact with other fabric nodes. We have a number of deployments where Oracle fabric nodes are mixed in with IBM or Microsoft, Azure or others in various multi-cloud deployments as well as on-premise nodes as well. So it provides a lot of flexible topologies. A lot of enterprise-grade features. It's really focused on simplifying the whole experience of adopting blockchain from a deployment perspective through ease of integration with a powerful API gateway. It's easy to secure with membership management and fine-grained access control. Very powerful operational sets of tools and APIs and ease of sensibility, as I mentioned, as Oracle nodes or third-party nodes running fabric. In addition, we have released recently a number of new capabilities focusing on the application space. Making infrastructure and operations easier is great, but then there are people who are going to also want to understand how to quickly build applications or use existing applications. We have a number of ISV and Assize Solutions in our portfolio partners. Then we've released some development tooling as well, a blockchain application builder that speeds up the custom application development effort. It increases productivity and development and testing, but also can automatically generate chain code from declarative specifications. This basically provides a low-code environment and is in fact a session tomorrow morning at, I believe, 1.10 p.m. Eastern Center of Time where we're going to be presenting the blockchain app builder and low-code development platform for Hyperledge of Fabric. You might want to attend that if you're interested in development and low-code. With that, there's a lot of other information that you can access. We appreciate you participating in this session. On the left-hand side here, you see various links for Oracle blockchain information, our web pages, blogs that are very active, developer site and a number of videos available on YouTube and Oracle Tube. On the right-hand side, there's contact information for IDRAM as well. With that, let's go ahead and take some questions here. We'll be happy to answer anything that you have. I think we have about 10 minutes or so. I'm going through answering some, but is there a way we can promote for people to ask questions in person? I'm not sure if that's possible. I'm not sure if it's possible through audio, but I think we probably just have to read them as they submit them through the Q&A. Sure. A couple of them I've responded to already. I'm trying to keep up here. Indie users need to be online. I posted that in there. Basically, those messages will queue up and be pushed out when the device becomes active again. That is part of the area's communication inspect that the mediator will hold those messages and push them out. Hopefully, that answers that question. The credential schema that we showed is actually an indie-based schema. That's defined on the indie network, the schema for the credentials that go out. Fabric doesn't know about that. There's no correlation between those two, which is a good thing actually. At any time, the correlation can be severed by the end user at any time to basically basically break that connection back to that issuing authority. Let me read a couple more of these. Another question about areas, the messaging, all the messaging that we saw in there when we did that message out, the push notification message out to the wallet, that's all in areas of communication. That's handling that messaging protocol as well as the credential delivery. David asked a question about verifiable credentials being issued by a trusted issuer, and it's a great point, David. What is happening, what will happen in the very near future as states and governments? This is certainly moving a lot faster in Europe than it is here in the US, but the issuance that we're doing here is an issuance based on an endorsement agreement basically that we are putting in place between, say, the DMV and this example of our driver's license and our system or A system as the trusted issuer. We're issuing that driver's license credential on behalf of the state or that trusted institution. Obviously, as states and regions or countries come out with credentials, then that need goes away. We can trust those credentials issued by who they should be issued by instead of having to perform that endorsement process on behalf of some other organization. The demonstration here, we showed a couple different ways of doing that. We do have a trusted issuer in the state because we used a DMV API to automatically validate that the information on that uploaded driver's license was valid. Of course, that process is getting better all the time. Scanning physical documents require a liveness test, and all of that is baked in. We didn't demonstrate that on this because we're moving really fast, but there has to be a way to strongly identify the person is who they say they are. We're doing it here by cross-referencing, so we got the driver's license, we have the social security number, we can do a utility bill, we can do whatever, and we can cross-reference all of that information to make sure that we are finding that identity. As that evolves, there will be a lot more ways of capturing that information and doing that identity verification before it's found, and that's a very important piece of the process for sure. If I can add to that, Mike, as well, we have recently worked with the bank on basically a KYC, EKYC online process for account openings in EMEA, so they had specific requirements mandated from kind of central bank authorities and all of that, and they basically combined identity card scan with video capture of signatures, so somebody had to write like four times their signatures that was captured in a video, facial scan, and then the video call following that, where all of that was verified again by somebody from the bank. I mean, it took a few minutes, but all of that information was captured and was deemed sufficient by the banking authorities basically to allow somebody to open an account. And of course, you know, now that information is verified through some additional machine learning tools to ensure that the images are matching properly and they're trying to detect false images, you know, somebody is trying to falsify, you know, something on the document of the signatures, etc. So there is a number of verification means in the back end that can be applied to different documents and, you know, facial scans, etc. The frameworks that we showed here is very flexible and so it can easily be adopted to leverage whatever additional back-end verification might be necessary. Depending on where you're creating the identity, right? If you are, you know, opening a bank account, if you are going to getting a library card, there's all kinds of different requirements and each organization can decide the level of verification necessary and then plug in those mechanisms. Yeah, as you saw in our demonstration, we intentionally built that very flexible and very open to require multiple different ways of, or multiple different processes for verification. And as Mark said, it's really up to the business process to determine what level of proofing needs to be done before they, before they bind those credentials. And as we showed in the demonstration as well, each organization utilizing those credentials can define that proof request and ask for explicit types of information. So if they're asking for a social security number, that's coming from a credential that was much, much more tightly scrutinized on the front end. So the process will naturally make sure that the holder of those credentials has been through the required process to do the binding of their identity, you know, at those different levels. Let's see, what does it, there's a question here. How do you ensure that the data extracted from the scanned document is reliable? You might not want to share the scanned document entirely, only substitute the data. Well, again, there is techniques that can be applied depending on the document. Sometimes it involves some machine learning work. In other cases, you actually have the document verified through APIs with the issuer. So the idea then is basically you send the information to the issuer and get verification status from them. Yeah, and there's no one, there's not, there's not a single process that's going to check all of those boxes. The key is to be able to incorporate many of those processes to, to provide the level of assurance needed for them, for the credential that's being issued. All right, please post another questions if we have missed anything. So yeah, there's that question about, there's a question about passwords. There is no password. There's just the private public key. You're correct public or the private key is only held on the mobile device in the, in the credential demonstration that we showed. And if that key is lost, there are ways of recovering. So you can, as an end user, choose to back up, you know, or restore. So there are ways of recovering that. Or you simply go through the approving process again, right? That is a, you don't have to go through the whole process, but you can go back to the, you know, the credential manager, the application, if you will, and say, Hey, I lost my identity, they can go through a abbreviated identity proof and then just reissue through that same type of connection, right? You make the connection, push the credential back down. So it's, it's not, it's, it's actually no different than rebuilding your physical process today. You know, if you lose your driver's license, how do you do it? It's actually easier than that because you don't go through the physical process of going into to have an issue again. But, but it can be rebuilt that exact same way. Lots of questions about yeah, personal identities and binding, how do you know who the person is? And I think we answered that. That process is getting, getting better every day. And we incorporate multiple, obviously, to make sure that we can meet all the business requirements. There's a question here about elaborating on the fabric usage. In particular, we create certificate for each user. This one service account is used to store the flow data. So in these implementations, there is one service account. We don't create a separate certificate enrollment for each user being verified. The service accounts and basically, you know, stores information specific to the users and attribute and then all of the status, all of the other information we talked about that's stored around granting access permissions on request and then whoever's actually accessing the data that's all stored but with the user obviously as an attribute. There may be situations where it's beneficial to actually have a separate enrollment for each user so that they become actually like a client organization member in the fabric network in some rare cases. But in most cases, that's not required. All right. So Michael, this one's for you. There is a question about interaction from in the areas to private Ethereum, if that's possible also. Yeah. So, I mean, it certainly would be, it certainly would be possible. Yeah. There's no correlation between the, there's no dependency on those two networks. They're very separate. So all of the identity credentials and all of the credentials used for service access are indie based. All of the data, you know, accumulation data, I guess the identity data that provides the backing of those credentials is stored in fabric in this. So there's no reason it couldn't be used in another system. All right. And then there's a question now about any assurances against men in the middle attack, particularly between the credential manager application and Hyperledger. Well, there is on the indie ledger side, there's that endorsement capability I was talking about. So you build, you have your ledger and in order to make those transactions or call those transactions, there's a specific endorser agreement that has to be. So there's, it's kind of a governance question. If you put it on a ledger that you have to have a specific endorsement capability in order to write to that ledger. So there's no way that you could emulate that transaction unless that endorsement private key were compromised. That would be the only way that a man in the middle attack can happen there. So I don't think there is a very high likelihood that that could ever happen. What else do we have? There's another question about documents stored on chain in fabric if they're stored and how permissions are managed to allow access to the documents. So that's configurable. In some cases, you might want to store the documents. In other cases, you store documents offline. Well, you know, somewhere outside of the blockchain, not necessarily offline, but in some kind of repository and you provide a hash and URL for those documents in fabric so that they can be tracked with digital identity and then status information is recorded against the digital identity. As far as the permissions and if you're talking about the people who are doing the administration on the back end, the application will obviously enroll them as a client user. So those people will help certificates and they only allow access, assuming that they are in charge of verifying certain documents. If they need access, then they can be granted that access to particular documents. The identity is tracked as a client on the fabric network. Right. The really important takeaway from the presentation and the demonstration here is how is the mix of technologies to form a really simple to integrate solution, right? For the services, it's very easy to integrate and build this, build this dynamic verification system. And we're providing some significant benefit to the end user by making it simpler and easier for them to interact. So what really makes the project special and the solution special is that we're not trying to fix everything with a single tool. We're using the best of class solutions as Mark indicated earlier to really provide the best experience for both the data integrity security as well as the user friction, the user experience to make that solution. All right. Miss any questions? I don't think so. No. All right. So I think probably at this point, wrapped up all the questions. Let me just share the contact information one last time because somebody was asking. So you can find me on LinkedIn or you can email me just mark dot rick millovich at oracle.com. First name that last name at oracle.com will work and Mike want to. Yeah, sure. Actually, I've got a, do you want me to share this slide? No, actually, we have, we have it right here actually on this slide. You share. Okay. I'm sorry. I was not sure. Okay. Hold on. Let me share. Here we go. So there you go. Yeah. Okay. So here's Mike's contact info. And then my contact info is much you can find me on LinkedIn or my first name that last name mark dot rick millovich at oracle.com will work as well on email. Yeah. And same with me. You can find me on LinkedIn or find it at our website id ramp.com has a lot of other podcasts and stuff that we've recorded and some demonstrations of kind of different things that we're doing at the platform. So please reach out. We always love talking about this solution in particular because it's using such great technology in an interesting way. So yeah, reach out. All right. So I think at this point, thanks everybody for attending. The deck itself is available on the schedule app. If you go to the schedule and find the session, you will be able to download the presentation. And we'd love to hear from you if you have any follow up questions. Please reach out to Mike or myself. Thank you. Yeah. Thank you. Thanks everyone.