 Good morning, everyone. My name is Craig Lee. We're still waiting for Dave Chadwick to show up. But until he does, I'm going to go ahead and get started. And I'll do the best that I can talking to his slides as well. In his inimitable way, he took the briefing and he's stuck in a whole bunch of new slides at the last minute and whatnot to try and get across the notion of attribute mapping and those kinds of things that we're going to be talking about with regards managing federated authorization across different clouds. So I come from a place called the Airspace Corporation. That is a nonprofit federally funded research and development corporation. And Dave Chadwick, who is just coming in right now, is a professor at the University of Kent. So while he's getting mic'd up, I'll just go ahead and charge into the talk. So the challenge here in why we were thinking about all this stuff is because we had some use cases. And I had one specific project where I needed to securely manage resource sharing across different sites. This dynamic IT environment where these collaborating organizations could come and go sort of on demand. So I'm going to show some use case drivers that show you why that's important. And specifically, the first disaster response, I just finished up a funded project where we implemented VOs, did a very quick and dirty proof of concept demonstration for being able to use virtual organizations to manage container access and Swift. But that same kind of way of managing data access in other contexts are also applicable to GEOS and also feature front production. I'll talk a little bit more about that. So what this really requires, how to address this is the first step is the federated identity management capability that David has been working on. And if you're following the Keystone project, he's actually had a lot of input about how they're actually going to manage a federated identity management and how to manage the attribute mapping given that you have an identity from some other identity provider and how do you map those identity attributes to what you're going to understand locally given that you could have different users coming from different sources that have different identity providers. And so related to that is that once you establish identity in a local context, a VO is sort of like a security and collaboration context that's not exclusively associated with any one particular organization. And so again, the notion there is that once you become a member of a VO, you have another set of identity attributes or authorization attributes that are given to you that allow you to do certain things, gives you specific capabilities or authorizations within the context of that VO. And so we'll go through how all this is supposed to work. Okay, so we're going to go through just a few examples. This is the disaster response scenario that we went through. So the NGA and the NCOAC, which is a Network-Centric Operations Industry Consortium, so it's another nonprofit organization, wanted to demonstrate this thing that they called a geo-int community cloud prototype for disaster response. And what motivated this is the Haiti earthquake back in 2010, all these government agencies, they couldn't figure out who had what material or where material actually needed to go. They had very limited knowledge of how to get material into Haiti. So the idea is that they wanted to have this capability where they could share data on demand among different government organizations, different non-governmental organizations, also get data from the people that were on the ground, they had mobile devices. So the idea is that you have any number of these stakeholders, which could include people that have satellite imagery, you can compare it before and after to see where civic damage is taking place or where earthquakes or tsunamis, all that kind of stuff to get an idea of where damage has occurred. And also things from terrestrial sources, civic information like engineering blueprints or whatnot, then also people in the field. And you either populate that on a map or you have some sort of way of sharing this information dynamically between these different stakeholders that have different infrastructures and different rules for how to share information and be able to do that on demand. OK, because you don't know when a earthquake is going to strike or who might need to be involved in that kind of disaster response scenario. Another example that I can come up with is this Global Earth Observation System of Systems or GEOS. This is a very large international project. They have this 10-year plan of how to build out this infrastructure for sharing geospatial information, earth observation data across all the different members, Asia, Europe, the North and South America, and so forth. And again, they have this set of nine societal benefits that they actually want to demonstrate. And of course, disaster response is one of them. But there's also climate change, water. You can read them all here. But those are the kinds of motivating factors for being able to manage the sharing of data. Another one that is actually quite interesting is this notion of cloud-based feature film production. And there's actually another small nonprofit called the Entertainment Technology Council that's hosted at the University of Southern California. And what this is, is it's a consortium of the technology providers like Amazon and Google. But it's also the feature film producers like Warner Brothers and Disney and so forth. And they're all trying to figure out how to adopt technology to do feature film production. Of course, it's a business. And they have to think about budget and doing things effectively. But the notion here is that a lot of films that are produced today are completely digital, even if they're not just action sci-fi films, that they will have a lot of effects that are done in post-production, in just digital format. So in a film production, you have a lot of different production houses that would participate in actually taking the raw data assets and producing the feature film. And so using a virtual organization could actually be used to manage which production houses get access to which data assets in which order to produce this final film. And of course, once it's done, you revoke everybody's access for those data assets and away you go. So again, this is another instance of being able to dynamically manage the sharing of data across different organizations. OK. So that's interesting. There we go. OK. Now, so this is probably where I'm going to let David take over, because we're going to talk about the initial technical capabilities that we need for doing this. And that starts with this notion of federated identity management. Yeah, I mean, the common feature in all of these is that all these multitude of partners, they already have their login IDs. They already know how to log into their own system. But login into multiple systems, you don't want to be giving people new sets of credentials every time. So the concept of federated identity management is you use your existing credentials to log into all these new systems that are dynamically created. So that's it. Now, in order to do that, you need to have three things from a service provider's perspective. If I'm now no longer going to be giving out credentials to my users, where am I going to get those credentials from? And the answer is I have to trust other entities to do it. And I have to trust other entities to authenticate the users. And I have to trust other entities to give the identity attributes of users. And then I'm going to do the authorization myself. I'm still not going to trust other people. Although there are models where we can also give out, delegate, trust in the decision making as well. And there are models where you can actually have external PDPs that will make the trust decision for you. And then you don't do anything yourself. You just farm the whole of the security decision making out. Now, the thing is, when you've got these dynamic organizations and you're now going to use your own credentials with your own organization to log into these other service providers, you need different attributes to give you different permissions at these different places. But if you go back to your organization and say, I want you to add me, member of VOX, into your corporate LDAP service, what are they going to say to you? They're going to say, on your bike, right? There's no way that your organization is going to start adding attributes into its back end systems so that you can log on to these remote systems. And that's where the VO concept comes in. We need to have some other mechanism to do that. Now, the trust, as I said, is indispensable. And when we build federated management, one of the important things is to add the trust in. We've done that in our federated Keystone. We have these three levels of trust which we can configure in. And I said, the problem is we can't get the IDPs to assert the attributes that we need. So we need the virtual organization. So this VO, then, is the security context. It's someone who is in charge of the VO who's going to actually give out the attributes to you and all the other members of the VO. So there'll be lots of these VO managers for all the VOs that you're a member of who be giving you attributes. And now we've got the problem, which is sometimes known as attribute aggregation. How do I get the attributes from your IDP that's logged you in and from the virtual organization manager who said what your role is in the virtual organization? Aggregate these attributes together in order to give you authorization on the particular service provider. So that's the particular issue. And there are a couple of ways. Actually, there's another example to say, this is not a new idea, okay? It actually originated from the grid well. So virtual organizations as a concept have been around for, I would guess, eight years. More than 10. Oh, more than 10, okay. And they already have a well-worked out infrastructure which they call VOMS. VOMS is the virtual organization management system and they set it up. It actually has a back-end LDAP and they run it as a separate service and the VO managers will add the attributes for the people in the VOs in it. But then they have this problem of attribute aggregation. So it's not a new concept. So we were looking at how can we put VOs into clouds once we bring clouds in? And what's the different granularity between federations and clouds? Because the grid well didn't have the concept of a federation as such. In the grid world, you had a PKI and everybody had PKI certificates and you use your PKI certificate to log in. But federation is somewhat different to that. Now what's the granularity between these? Well, a federation can have many VOs. So in the UK, we have the UK Academic Federation. It's got 100 universities that are joined in. It's got multiple service providers. There's actually over 800 partners in this federation. You can imagine there can be thousands of VOs within a system like that where a couple of universities and service providers get together. So that's one common scenario. But another scenario is you might actually set up a federation of VO which is actually the same and the same people organize it and the VO is the federation. You can have that. But thinking further, you can actually have a VO that can span multiple federations. So within, again, the academic community which I'm familiar with, we have the federation in the UK. There's the federation in America. There's federation in Norway. There's federation in France. These are now actually being spanned together through the giant project into a federation known as Edugaine where they're linking all these different federations together and then you can imagine that a VO can actually span multiple federations. So we could actually have a VO which comprises people from an American university, people from a Belgium university and people from a UK university as service provider and maybe in Greece or something like that. So they're separate concepts in terms of domains and they're not limited. So you're not necessarily limited in the span of a VO. Now, when we came to do it in OpenStat, we looked at it from a different perspective. Craig looked at it as a perspective from, okay, VOMS exists in the grid world. How can we utilize that? So actually the way, the perspective that I took is what's the simplest, quickest? Yeah, a quick and dirty thing that I can just demonstrate a prototype capability. And so that's why this notion of having an external VOMS where you have all the VO state in one centralized place is obviously the easiest way to implement this. But the notion of having the VO information replicated across the different keystones is obviously another approach because there's a database on the back of the VOMS where you store this information. So you could either have a centralized database or you could have a distributed database where the VO information is replicated. And of course that brings in all the traditional replication and consistency issues. But I mean, depending on your situation, those are two different viable approaches. Yeah, I mean, my viewpoint was, I didn't want to baggage the people who are running OpenStat with the VOMS infrastructure. I wanted to actually say, well, can we get away from running VOMS? And can we actually do VO management actually within Keystone? So that's what we were looking at doing the VO management actually within Keystone because you're already running Keystone and OpenStat. So can we actually do away with not having VOMS? Okay, so I'm gonna describe a little bit about what we actually did for this geo and community cloud prototype. And this is just an example of how it might work to give people the idea. I'm gonna go through some stuff that is a little bit more anatomically correct. But obviously you have some number of OpenStat clouds there with Keystone and Swift. Okay, the first capability that we were getting towards is how to manage access to Swift containers because Swift containers have ACLs on them and so that's gonna work into this. So obviously, what happens is that we modified the Keystone such that when you log into a VO project, the Keystone knows to consult this external VOMS, which has the database in it. And if you do a successful VO login, then that user up there on the upper left, when they actually make a request to Swift, they automatically get authorized to access all those other containers that are being contributed or are part of this distributed virtual organization. Now the user up there, they're just logging in with their regular credentials. They know that they're a member of this VO but in terms of the authorization process that goes on underneath, they don't know anything about that. All they know is that they get back a list of containers from the list operation that they can subsequently do, upload and download operations on. Okay, so in terms of when Keystone knows to do a VO login, what we did is we added this VO offstage to the command pipeline. And again, this is a very simple way of doing it but we extended the Keystone project concept to a VO project by just putting a capital VO dot prefix on it. So if your project name is VO dot, Keystone knows, okay, I have to go consult the VOMS and see if this user is a member and if they are, then they actually get mapped to a role account that's part of that VO. And also there's a number of sites that are recorded that are participating in that particular VO. So David wanted to make some more comments about this notion of attribute mapping. Yeah, so this now is using an approach where you don't use an external VOMS but you actually use your existing Keystone. So this is an example of two users from different domains, different IDPs, could be a user from Kent, could be a user from Aerospace and we've got a common VO where we're using some open stack service. And how can we actually guarantee that we can both access the same resources because we're members of the same virtual organization? So what we've added into Keystone is an attribute mapping functionality which takes the identity attributes which come from the IDP and we map them into the same domain project and roles so that two different people from two different organizations who have got different sets of attributes which are coming from their IDPs, nevertheless, using the mapping functionality they end up getting the same permissions in open stack. So they become essentially members of the same group or members of the same virtual organization. So that's the approach that we took in ours so that you would manage it by not managing an external VOMS and saying this user has this group and then it gets sucked in to the pipeline as in Craig's model but you manage it by saying this user has this project domain, et cetera. So that's the approach that we took and both of them, we've shown both of them can work. Moving on to, oh, sorry. Okay, so the actual attribute mapping that we do is it's rather complex, it's based on sets and it's mapping sets of sets but by mapping sets of attributes to sets of attributes you just get the most generic form of mapping possible because in the simple case, a set consists of one attribute and you map one attribute into one but of course you can do one to many and you can do many to one. So we made it sets to sets just to give us the most generic capability. Now, what if you've got, as in Craig's case, multiple keystones and multiple service providers you either have to repeat the mappings in each keystone and that's what you talk about peer to peer and replication, et cetera or if you devise an attribute mapping API which is externally callable you would only need to set it up in one keystone and then any external keystone will be able to call the attribute mapping functionality and say, I've got this user with this set of identity attributes, okay, coming in give me the attributes that they map into and then that external keystone can also use that mapping. Okay, so in that way, in that way you could actually use the same mapping functionality by multiple classes and in fact, why you could go further you could actually turn attribute mapping into a separate open stack service. So in effectively, you're creating a VOMS as a cloud service. So you now have your VOMS as a cloud service and then anybody can actually make use of it. So that would be taking the mapping functionality extending it further. Now, there are multiple ways you can do user authentication. In Craig's way, they use their existing keystone authentication. The grid way is to use external PKI and they're authenticating users using PKI and then you can use federated authentication. We need, when we do virtual organizations to support all three, we don't want to limit ourselves to just one, we have to have a mechanism that can support all three ways of user authentication. That's an important thing to bear in mind. Okay, I think this is back to your... Yeah, so just to give you another example of how this worked in what we did for the G1 community cloud. I mean, obviously, we have these two different clouds here and we have this external VOMS, which is implemented as a simple MongoDB. So what happens first is that when the user requests a Swift operation, the keystone client will authenticate with keystone. And the keystone, since this is a VO project that the user is logging into when they want to get that scoped token, the keystone will actually go off to the VOMS. The VOMS will authenticate them as a member of that VO. And what happens is that they actually get authenticated as a role, as a role account. So the user gets mapped to this role account and then what the one keystone will do is it takes the list of all the other participating sites and it actually logs into all of the other keystones using that role account. And ultimately, if all that goes successfully, returns all that information back up to the Swift client. So that means that after the successful login, the successful VO login, they have all the service catalogs in an off token for all the sites that they're authorized to talk to as part of this VO. Okay, now when we actually talk about container access, the Swift client will do a list or an upload or download operation. And obviously what happens is that depending on what they do, you just have this typical sequence of operations, but the user at cloud A can access whatever containers on their local cloud that they're on, I'll read or write Ackle for, but they also have all the authorizations to go off to these other clouds based on their authorization. So we just had to add an extra argument to the Swift command line tool to be able to specify which cloud that you wanna go to based on your authorizations within the VO. But the user doesn't know anything about how they were actually authorized. The role accounts and the passwords that are used for them are not known to the users. And this was just simply the simplest way of demonstrating this for our customers in the US government, as opposed to having to do a full of PKI implementation or actually getting to the point where we could integrate the attribute mapping that David had been working on. Okay, and then also the local admins at each site, they have control over the Ackles on the storage container. So each site, each local admin retains control over how they're actually making their data assets, their containers available to the different roles within the VO. So that's important that the local admins, local site retains complete control over their data assets. They can grant or revoke access at any time. And the way that this was used in the disaster response scenario is on the left, you have all your different members from all your different sites or whatnot. And what the VOMS does is it maps them into specific roles, like something like medical staff or civic engineers or people that are first responders. And then at each participating site, the local admin will put those roles on the different Ackles for the different containers that they wanna make available within the entire disaster response effort. So that's basically the model that we use just to demonstrate this VO concept within something like federated open stacks. So the biggest lesson that I had from this is that we actually need to support other methods of data access beyond just simply storage containers. I mean, doing it for storage containers is certainly useful. But the Boeing guys came to me and said, well, this is great, but can we use the VOs to manage access to databases? And I said, well, no. The Telos guys came to me and said, this is great, but can we do it to manage RSS feeds? Because all of our disaster management tools that we've built are built on RSS feeds. So it got me thinking in the issue is, well, how can we use VOs to manage access to arbitrary application level services? So one possible way of doing this is that you have some sort of application service owner. And what they do is that they build their application and they have this VO PEP, policy enforcement point that they put in front of their service and they instantiate that as a machine image. Once they do that, they can register that endpoint with the Keystone service catalog. And of course, this is all just quick and dirty. We're piggybacking on the Keystone service catalog in some operational sense. You might not want to ever do that, but it certainly works for demonstration purposes. But so at that point, the Keystone has the endpoint and also whatever required VO roles or attributes that you want to associate with access to that particular application level service. Okay, so later on, when a user wants to use that service, they do the typical thing of authenticating the Keystone. Keystone asks the VOMs, they get mapped into their VO role. And so Keystone will return, what Keystone will do is it'll return the off token and also the service catalog, but it will also have the appropriate application service endpoints that that particular user is authorized to use within the context of that VO. So there could be scads of different application level services in that particular catalog, but the user only gets to know about the ones that they can actually use. Okay, and so then when the user actually uses that endpoint, the VO PEP, authorizes it with Keystone, they get the authorization back and then finally the call completes. But so this would be one way of at least demonstrating how things like database access or RSS feeds could be managed using the VO concept. There's also this capability called geosynchronization. In the geospatial world, there's this notion of, well, you have all these data producers that are producing maps and features on maps and they want to push all this data to people that already have maps. So it's called this geosynchronization and all that is based on RSS feeds. So we're hoping that we can demonstrate this in the context of the standardized geospatial function called geosynchronization, where whoever, only the people within a VO actually get the right data at the right time. Okay, so there's certainly a number of important but ancillary issues around VOs. One is how do you just create and terminate a VO? How do you join or leave a VO? Who gets to be the VO admin? Who gets to be the VOMS administrator? And just the semantic interoperability of VOMS. What are the resources, roles, and attributes mean? How do you do data publishing and discoveries? This inherent semantic interoperability problem. For people that are actually using this, the granularity of resource protection will be an issue. What we demonstrated with Swift containers is just access at the container level. What if you wanted to do it at the object level or at something smaller? At some point, the granularity of access is gonna become an issue. There's gonna be a trade off point where it's just gonna be too much overhead to protect small grain data. There's also this notion of trust federations. In the grid world, there's this thing called the International Grid Trust Federation. And that's this human organization whereby they specify how all these PKI certificate authorities are supposed to be operated. And once you demonstrate that you're doing things correctly, you get the stamp of approval and everybody else trusts your certificates. The same kind of thing could be done in something like a disaster response scenario where there's some international disaster response trust federation. And that's where all these agreements that need to be hammered out ahead of need could be done in terms of what are the roles mean? How do you authenticate certificates? Or how do you manage different credentials that have different activities from different sources? And of course that's where the federated identity issue comes in. So those are sort of ancillary issues. There's also a number of key design issues for views and open stacks. So we did this very basic prototype just to demonstrate the issue. And part of it is, well, okay, just using that as a driver to understand the design space for virtual organizations. If it hasn't become clear yet or not, the notion in OpenStack is that, well, we took the project concept and we added this other property to it such that we actually could be calling this virtual projects or distributed projects. So the question becomes, well, what's the right abstraction to present to the user for managing these collaborations across sites that need to be dynamic in nature? Then they can come and go, you can grant or revoke authorization. Okay, so how to store the VO attributes? Do we wanna have separate user entries with the VO attributes or having these general mapping rules? How to integrate VOs from multiple clouds? Come in on that first point. I think there's an interesting thing in scalability here because with the VOMS concept, you have one entry per user, which is fine for small VOs, but if you've got VOs of hundreds of thousands of users, you have to have a VOMS of hundreds of thousands of entries. If you go for the general mapping rules, you need one rule per class of user. And if you have whole groups of users that are in the same class, for example, everybody from this department in this organization, you only need one rule. You need one entry to cover that entire class. So there is difference in scalability there that if you go for the general mapping, in the worst case, you'd have one mapping rule per user to map the user's attributes into the VO ones. But if you've got a whole bunch of users that have got the same identity attributes, then you wanna need one rule to map a whole bunch of things and you end up with a smaller thing to manage. Yes, and that's actually the scalability bullet down there. Yeah, that's part of the scalability issue. Out of all these things, the scalability and implementations are gonna be important once we actually start running these in a particular size. Okay, again, the notion of an external VOMS database as opposed to this peer-to-peer Keystone database, typical thing that centralizes easier to implement, it's also easier to do a revocation of authorizations if you have everything in one place. If you go to a peer-to-peer approach, you don't have to rely on this third-party VOMS. It's not a single point of failure, but it does introduce the issues of having to do replication of data in consistency. Whether the check whether a user is a member of a VO or not, that has a particular overhead to it. Do you wanna have to check that every time or is there some way of only checking that when you need to? Again, if you're using the peer-to-peer internal approach, the overhead of doing a quick look up on a mapping table is not so big, but if you're making a call-out to an external VO service that's running in some external system, you don't wanna be making call-outs to that for people who are not actually part of the VO because that would actually put a lot of overhead into the actual login process of the user. Right, right. And then, as we mentioned already, that there's this notion of using VOs for arbitrary application-level services. So I mentioned databases and RSS feeds. There's other standard geospatial tools like web map server, web feature server, these kinds of things that we might be able to look at. There's another project that I'm starting on that might be able to use these things. Also, this notion of what should be at the application level as opposed to what should be at the infrastructure level. What should be in Keystone and what should stay, perhaps, up at the clients or actually in the application? That's another issue. We're running out a little bit out of time here, so I don't wanna go into excruciating depth. Who manages the VO? Again, are the administrators distributed or is there someone centralized? Again, I keep on hammering in this thing of infrastructure-level federation versus application-level federation. We can talk about federating containers or even federating NOVA's that if you're in one virtual organization, can you get authorized to spin up images at different sites? Or if you just request an image to be spun up locally, but somehow NOVA knows how to schedule it over there if it determines that's the better thing to do. And of course, scalability is important for all these issues. I think this is the last slide that I think that we have. So David's described the attribute mapping in Keystone and if you're following the Keystone project, I mean, that is a significant contribution, I think, to the direction of Keystone being able to support federation. We've got this. Aerospace has its external bombs. It's a very simple implementation, but the value of it is that, certainly has driven our understanding of the entire VO design space. And the question is, as a community, how would we want to pick where we put our resources further? What are the drivers that people are actually going to need for these things? Also, the European Grid Infrastructure, EGI, they've also have a group that has an initial OpenStack VO implementation. They actually can piggyback on their existing PKI infrastructure where when you log into a VO, you actually get a proxy certificate that has your VO attributes in it and that's how they manage these VOs. Currently, they don't actually have any roles or things like that within their concept of VO. If you're a member of a VO, you get access to everything within that VO. But I'm sure they're gonna be building out these capabilities in the not too distant future. I talked to them last in September, so they're probably working away on that. And then this Open Geospatial Consortium, Open Mobility Testbed Project, is just got kicked off recently and that's where I'm hoping to be able to use the VOMS notion to manage access to geospatial data in a standardized way by managing access to what are essentially these application level services. So with that, is there any other comments you'd like to make? No, I think it's any questions really if we've got time for none. One, two, yes? I'm sorry, could you speak? Well, we're not talking about any federation, we're talking about federation as a generic concept. So when you install your Keystone, you actually configure in the federation that you want it to be part of. So there are multiple federations existing in the world today. You can make your Keystone service part of that federation by contacting the federation provider and saying this is a new service to add to your federation. Sorry? Yeah. Yeah, yeah, our code, it's actually part, it's actually, you can actually download our code, but it's not part of the core Keystone. It will be in the next release of Keystone, there's going to be, federation is going to be part of the core release of Keystone for Icehouse. So what we've been doing this week at the Design Summit is just scoping how much of the stuff that we've done which is all additional and you have to add in yourself will be core. But certainly, you can see over the next two releases or so, full federation will be becoming part of the core release of Keystone. At the moment, you have to take the Havana release and you have to take our stuff and plug it in. It's actually in GitHub under the name of my developer. So I can give you the URL if you contact me. It's Christie, it's GitHub something slash Christie. She just created it with her own name when she created the store. Oh, yes? I used to work with VOMS people when I worked in the grid world about five years ago, people from GAR actually, but not in the last few years. In fact, I thought that VOMS had more or less stopped its development, but maybe I'm wrong there. Right. Yeah, well I was in touch, yeah. Yeah, I was in touch with those people. We both used to go to the OGF and we were in contact with them then. Yeah, and I was at the EGI technical forum in September and talked to the folks that were doing the VO work right now. And actually, one last comment before this, but when I started this project, I was gonna do all this stuff. I was gonna take David's stuff and put that in the front and I was going to use this VOMS at the Texas Tech University that's part of the Open Science grid and do all this stuff, but as we got into the project, it's like it got descoped smaller and smaller and smaller till all that we, you know, the really core thing was just putting the extra stage in the Keystone pipeline and then being able to manage access to the storage containers, you know, in a very specific way just based on the notion of mapping a user's identity to the roll account. And, you know, just being able to demonstrate that actually, you know, sort of got the idea across to a lot of folks, you know, the demonstration went quite well. Then there was the US government shutdown and blah, blah, blah, blah, but... But I mean, you find that actually, when you talk to most people in OpenStat, they've not heard of VOMS anyway. Yeah, they don't. Yeah, but most of them don't know about VOMS, so that's why I came from the approach of, okay, ignore VOMS, let's see if we can build it into OpenStat without actually needing to invoke all of VOMS infrastructure. Yeah. I can speak off-linked with that. Have you looked at stuff you're not going to get? We're going to have to go and talk outside.