Okay, thanks very much for having me. I have three confessions to make before I start one, I come from the academic and research sector. So a lot of what's been talked about here in terms of business work is completely alien to me, two, I am a woman there aren't that many talking here. So again, I do apologize. And three, I work predominantly in the SAML area and Sam's been getting a bit of batching at this conference. So it might be good to do a little bit of a little bit of background about what has actually been going on in the Sam space and that's not working either. So will just, okay, so who am I? My name's Nicole. I have a lot of different roles and backgrounds. I work in, I come from the UK obvious from my accent. I also work for an organization in Europe called reeds.
And I'll talk a bit more about reeds in a minute, but it stands for research and education federations talking about identity and access management, federations. I project manage several projects for them, including the peer project, which I will talk about. I'm also the consortium manager for Shila. So reeds research and education federations have been about since predominantly 2005, they began to emerge. And this is the picture at the moment of how research and education Federation's working. They're predominantly Sam based federations, but not completely. And basically they're allowing students and staff members to use their academic username password to log onto the party resources. We're often talking about things like scientific databases journals, but it goes through everything, including wikis, blogs, student housing services, all of those kind of things. At the moment within references, we have about 27 different federations and operation globally. Plus two into federations, which I'll talk about in a bit more detail back in September, 2011, I actually tried to work out what the complete size of that was. And we came up with 4,753 entities within that Federation. So 4,753 identity providers and service providers, which break down as you can see there, we haven't refreshed that recently. I really should get around to doing that several other. Don't worry about it, obviously that doesn't add up to 4,753. We also reckon that conservatively that's about 60 million user accounts going on internationally. So for us Federation is working. We use it every day and it it's just something that's become a daily part of life in an academia.
One of the problems that we've got at the moment, though, is many of the entities that I'm talking about within these federations are exactly the same. Microsoft, for example, uses federations to help prove that someone's a student so that they can give them discounted software or even free software. They're in 14 of those different federations and have to register their entity data with each Federation every time else, severe massive provider of, of scientific journals. They're in 12 of those 27 different federations. Obviously that's not a particularly sustainable model. So it's all working, right? We've got 27 different federations. We've got all of these services working in them. Everything should be absolutely fine. Well, not really quite
The
Easiest way of putting it is that for our service providers at the moment, Federation with academic Federation pretty much sucks. And, and I know that cuz I'm the person who wrote the paper on why it sucked.
The reason it isn't easy is because for every single provider, they have to go out, find each and every academic Federation and register with it. They have to sign up to multiple different types of legal documentation. It's all written differently. Every single Federation has a different style of legal of legal documentation. You have to sign off to up to. And of course you've gotta register your entity data, your metadata with each and every one of those federations. So that in itself is a huge problem. If you can imagine being elsewhere, just doing that with 12 aspiring to get up to managing 27 different relationships, it's a bit of a nightmare. We're also very good at introducing geographically different one-off clauses. So for example, in, in the United States, there's a clause within their Federation agreement that you have to have an insurance level of a certain amount, which might not seem like something that's particularly problematic. But if you're a very, very small provider of a journal, that can be a difficult thing to agree to.
There's
Also everyone's favorite data protection. We all interpret it slightly differently. So even within the EU, while we have a common data protection da framework, we're all interpreting that D framework differently into our everyday practice. So for a service provider, trying to understand how to engage with all of these different federations, that's a problem. There are also other things. Some federations require you to have sponsorship letter from an academic institution, some charge fees, and there are technical barriers, for example, different federations accepting D different certificate authorities for the use of certificates. So there's an awful lot of barriers in place that we need to get through.
And it really shouldn't be like that because these federations are simple. Very, they're basically very, very simple things. They are managing big chunks of XML metadata, and they're wrapping it up with a legal document. Really shouldn't be that difficult, but this is how it kind of works at the moment. If you, if you want to register your data as a service provider with academic federations. So let's just look at three of them, here's me. I might be say science direct. So I trot off to Federation a, which might be the UK access management Federation. I register my data, I sign all of their documentation. I get all of that sorted out. Then toddle off to Federation B, which might be the German Federation again, go through exactly the same process. And then off I go to Federation C, which might be wa in Denmark. And I go through exactly the same process with them.
Then something changes. I might want to move some information on one of my machines. I might change my certificate. I might want to change my contact data and I need to give all of that information back to the people I've registered with. So offer to, and I change my data with, with, with the U access management Federation with Federation a, but then I get a bit bored. So I just leave it like that. I don't bother updating it with the other federations. And we've instantly got a problem where we are maintaining different and inaccurate data throughout our system. And it's just not working for that very purpose. So what we really need is a place where we can centrally register all of our metadata and this can be called upon by federations. We're starting to look into this. So we've gone through the process of diverse federations and we're starting to look at how we can bring ourselves together.
And one of the things that's doing that is one of the projects and I'm project managing, which is called PI pier is essentially a big bucket of, of metadata. It was originally called beer bucket of ind registrations, but they decided that we couldn't really get away with an acronym called beer. So it became beer. What this means is a service provider can choose to go and register their metadata at this central registry and go to the federations and say, Hey, well, if you want the metadata, you go and fetch it from this registry. I'm not gonna give it to each and every one of you, 27 of you. And then it's up to the Federation to go out and fetch this data and bring it in. So what does this allow us to do? Well, it allows for the one time registration of entity data, which is great means I'm not having to maintain it in all these different places.
It's up to the federations to collect it from the central pool, but they want that data to pass out to their users. So that's fine. The federations are free to transform and adapt the entity data according to their requirements. So if there was something within that entity data, which they couldn't process, that's fine, they can take it out. But peer provides technical trust. We can do several checks to make sure that when that entity data is registered, it's registered by the right people, but we can't provide the legal requirements are wrapped around by research and education federations at the moment. So we can't provide the rules of membership, the circle of trust concept, which we do still use quite strongly within identity federations and research and education. So that's great that's process, but couldn't, we actually do full into Federation. What do I mean by that? Well, I mean the ability of federations to exchange metadata about their entities completely freely across boundaries. What normally happens here is that you sign a legal agreement and you register your entity data with one Federation and then all the other federations agree that they can pass this on according to certain rules, which have been put in place. So what this achieves is full technical and policy integration, making life a lot easier for the end users.
And again, we're lucky because some of this work's been done. There's a, an organization called edge game, which is looking to achieve just this now edge. Game's a mammoth task, trying to understand how to make the legal framework and the technical framework so that service providers can only register once. But we're legally allowed to share all of that information in all the different countries that have identity federations. That's a massive task.
There
Are of course, some drawbacks with that kind of inter Federation. So at least one of the federations you're a member of needs to have actually signed up to game. Makes sense. And quite a few federations have still to take that step and sign up to game it's opt in. You have to actually ask to be included in the ed game metadata. We don't automatically do it, which doesn't seem that problematic, but it's quite a difficult concept for people to understand. Go ahead and put me in the ed game metadata for the average service provider that doesn't really make much sense.
And the other problem is it's not always clear which entities are actually into federated. How do I know that my customer in Denmark has actually been in federated? So I in over in the us can actually use their data without having to join the Danish Federation. There's lots of problems around that. However, only having a relationship with one Federation has got to be better than having a fed relationship with 27 different federations or all of the different countries that your customers happen to be in. And technically as an SP you can choose which Federation that is. So for example, if one Federation starts charging you, you know, you've got a bit of mobility there. So what's the value proposition of this? Well, at the end of the day, metadata exchange means a bigger pool of metadata for all of us. That's gotta be a good thing. I can offer connections to more services, to more of my identity providers, to more of my universities and colleges in my country. It broads broadens reach of the existing federations. It's quite a simple thing. It increases the value of federated login in general. In the last session we were talking about that difficulty of knowing which services have actually been federated. So we can provide them back to our customers. This helps us get over that barrier by providing more and more services than we've been able to provide, to make connections with
It reduces friction. It simply means that if I want to work internationally, I don't have so much friction to get through to actually achieve that goal. The cost of acquisition is down. I'd love to do some work on the actual cost of acquisition would be the, the way Federation in Denmark does some brilliant work on actually mapping out what the cost of acquisition of these kind of things are. But this has got to significantly reduce that for the Federation so we can run federations more effectively. But of course, that comes with a slight drawback that if you are a Federation, that charge is you you're gonna have less customers coming in. So there's gonna be a revenue loss there.
So that sounds absolutely great. And we've got services that allow us to register entity data in different ways. We've got services, which are allowing us to get over the legal challenges, but we all have federations which have been around for several years and how we actually gonna make all of these work together. One of the problems we've come across is things like, well, my entity descriptor doesn't look like your entity descriptor. Although we're working with predominantly Sam federations, of course, any implementation of any standard is done slightly differently. So any description of an entity in one Federation might look slightly different within another Federation. There's that, oh, not invented here. Kind of worry. You wanted me to put this strange foreign stuff that you've brought out into my nicely metadata. No, and quite often, when people start trying to export their metadata, they go ahead and put strange requirements on it. Like suddenly slapping copyright requirements on it. And that can cause real problems when we start trying to move this metadata around. So we have to look at the way we both export our metadata and import it to make this internationally advanced system work. So if I wanted to export my data, I could go, well, I could give you what I currently export our production aggregate with everything that I, that I currently publish in it. And you can sort it out, you filter out what you don't want, which isn't a great solution.
We could provide an export aggregate per partner Federation. So everyone that we partner with, everyone, we try and interf federate with. We can provide an export aggregate for you, but that really gets back to creating a new overhead that we're trying to reduce by bringing in this process. And finally, we can try and settle on a common export aggregate. So I have my production aggregate, which I provide in my country. And then I have them an export aggregate, which I send out to anybody that wants to federate with me. And that seems to be the most sensible way to move this forward. And then I've got import stuff. I've gotta make it available in my country. I've gotta make it available within my Federation. So I've gotta add something to our metadata and make all of my identity providers aware that these services are now there. So again, there's various different ways that we can do this. You could basically say to your identities, you go to the multiple federations, you load up, you sort it out, you could republish multiple export aggregates. So say, Hey, I've been getting all of this information in from different people. Here's a list of all of them. You go and get them. It'll be fine. But how would you know which one's a sensible one to consume?
We could republish a consolidated expert sport aggregate. Again, we're getting slightly closer to a solution here. I think in terms of how we manage our aggregates for people,
Or finally, we could just republish it within our production aggregate. So I'm already publishing metadata. Why change it? So we could just shove it all in and, and say to the customers, it's gonna be fine. You're only connect. And you connect to the people you're interested in anyway. Or as a hierarchical aggregate actually identifies stuff which has been exported into our metadata. So you can pause through the metadata file and sort it out. And again, I think that's gonna be the way forward for federations to start moving in this direction. We're gonna need new tools, things like the, the metadata aggregator. And I do have to put my hand up here. I do work for S so I'm not trying to sell it, but tools like this are gonna help us move forward and actually be able to pass metadata around internationally, in quite sophisticated way.
So to summarize, it's quite hard. It's taken us a long time to get these really mature access management federations up and running. And it's gonna be hard to move to this next level where we can make them truly international, but we're getting there. We're starting to put things in place. There are multiple ways we can do this, both technical and legal, and we're looking at all sorts of different ways to make this possible standards. Really aren't enough for us here. Excuse me. We need common practice as well. If we're all gonna be, get signing up to this, we all need to start behaving in the same kind of way. It's really confusing to explain to the people who need it. The identity providers and service providers who need to use Federation, as we heard in the previous session, don't really get what it is and don't really get, what's gonna make it how this is gonna make it easier for them. And finally, as federations, we're gonna need to adopt new tools to make this happen. I'm pleased to say though, that we're making really good progress on all of those points. Thank you for listening.
Yeah. Thanks.
And I think this was a really valuable input just to put everything we heard before into perspective. So Federation is really used. It's it's being deployed and widely used some organizations even overused. If I read that Microsoft has 14 different federations might be a little bit strange here, but what really scared me was that one little note, which said that people were putting copyright notes and metadata. So the Stranges never ends. Are there any questions from the audience to our practitioner here, then I'd like to have 1, 1, 1 closing question. You, you wrote that, or you just said that Federation definitely brought the organizations that participate forward, but that the solution that Federation provides also created some new technical and non-technical issues that need to be tackled. And that the answers to those are rather non-technical and very human. How do you think would be our best approach to, to tackle those human parts of that and keeping people from putting protection, a copyright protection notes in their metadata?
I think, I think one of the, the biggest problems in this is what I usually call the battle between usability security and privacy. And you've normally got people who will represent once. You'll have the people who are going out saying the user interface is the most important thing. We've gotta get that right. Our users have gotta understand, then you've got the privacy people going, no, no. What we need to be doing is protecting our users. We need to protect them from what's happening to them. And that's more important than the interface. And then finally, the security people who are producing wonderful and amazing code, but don't actually care about how that's interpreted in real life. And I think until we can get all three of those camps together and actually talking together about how to produce the best solution, then we're gonna still have these problems. So it's really that bringing in all of those three different areas together to provide the single solution. That's, what's really gonna help us here, I think.
Okay. So we need to invite all three parties, put them into a room, lock it from the outside and just come back one day later. Thanks so much for the presentation again, I'd like you to thank our presenter, Nicole. Thanks.
