 Thank you for attending this session on sliced bread and libraries, putting the federated identity pieces together. For many of you, you've been following the story of federated identity for the last twenty years and slowly but surely the pieces are coming together to deliver the type of integrated user-friendly service that we'd like to have. This session will cover that. In particular, we're going to look at some of the problems that are out there today, the issues with proxies, some missed opportunities for privacy-preserving personalization, and finally the increasing sets of requirements that privacy regulations are putting on access. We'll put the pieces together now. We're going to talk about IDP, identity-provided discovery via seamless access. We'll briefly touch on the federated identity space. We'll talk about some normative bundles of attributes, which is a way to scale access control and preserve privacy at the same time, and how we might achieve that, and finally how users can be involved in the experience and provide consent and control over what information is being passed. There's still a few small pieces missing, and we'll mention those, including the selective release of values from a multi-valued attribute. The unfortunate example for that is group memberships, all of your group memberships are contained in a single attribute that is multi-valued, and we only want to pass selected group memberships to relying parties, depending upon the relying party. There's a similar set of needs that need to be addressed around signaling what attributes various parts of an entity might need, again with the intention of preserving privacy. Some community standards on how we'd choose the perimeter between what are required and optional attributes. And finally, reporting utilities that would allow management of access control and content. The problems to solve, again, we know about the proxy issues and the theft of content that was certainly a prime motivator in the move away from IP-based access control and proxies towards something more secure. That also can be privacy preserving. The lack of privacy preserving personalization, we'll touch on that in a second, as well as the regulations. There are several ways in which we can personalize experiences and still preserve privacy, and we now have the technologies to do that, and we're looking for opportunities to use those technologies. Certainly accessibility, the ability to customize a screen for blindness, for color sensitivities, for cognitive issues, all of those things can be managed using privacy preserving approaches. There are many use cases around having a gated community where only certain members of the general public can get in, but once you're in, you're privacy preserved, as if you were wearing a mask in the old definition of masks over the eyes. And finally, there are many places where role playing games, et cetera, where using vetted avatars to preserve privacy, but offer continuity of the user, and then those can allow other kinds of identity vetting, such as reputation systems, opportunities. Finally privacy regulations, there's a number of them that have been on the radar now for several years. A GDPR is the most notable one, it covers Europe and by some extension, the rest of the world who interacts with Europeans. It was passed several years ago, it took a couple of years for adoption, it's in the last year that real fines are being leveled, and most interestingly for this talk, in May of 2020, the European Court of Justice tightened release and purpose of use issues, and you can see that in the revised key structures that are now out there on most marketing and business sites with different kinds of cookies and different fine grain cookie control, that's an outcome of that ruling by the EU Court of Justice. Issues that are central in this ongoing privacy space is the basis for release, why is the information being released by the identity provider, and for what purpose will the relying party use those attributes, and again, the cookie paradigm that you see now with I believe three or four categories of use is an example of that. I won't touch on the California Consumer Privacy Act and other state-based initiatives other than to say that they're out there, they're inconsistent, and it's just not clear yet what consequence they have for our communities. One act that is very interesting that you might want to follow both as a consumer of health care and perhaps a librarian of electronic health information is a very large piece of legislation that was passed in 2016, the Cures Act. It's guided by the Office of the National Coordinator in HHS and you will see major impacts both on your use of medical services personally and on issues that institutions that manage electronic health information will need to pay attention to, and there are certainly pockets of those in our universities. I do want to close the survey of drivers with a mention of the Canadian Digital Identity Initiative. In my eyes, it's the gold standard. It has a trust framework that is built on a very simple and useful model. Terms of defined assessment capabilities are specified against the trust framework. The trust framework itself consists of six layers and I appreciate that notice and consent have been pulled out as their own particular layer in a trust framework. In regards to that, that same trust framework specifies with some degree of rigor what when consent and notice need to be used. It's a very useful set of guidelines. Notice that it's opt-in. It can be for transactions or for extended periods of time, explicit in language. And if you're a consent geek like I am, you might follow that PDF. It's an interesting reason. So federated identity, some important pieces have slid in. It's now a somewhat complete user experience. There's identity provided discovery that is consistent among sites via the seamless access work. This federated identity itself is the emergence of some normative bundles of attributes that are of particular interest in the library space. And now there are finally the beginnings of deployment of user control attribute release capabilities. We'll cover each of those briefly and then we'll do a demo of how they fit together in something called slice bread. Identity provided discovery, seamless access has emerged as a paradigm and community standard. It was developed by content providers, identity operators, standards groups. It was a nice process. There's a standard icon that users can know to click on to discover their identity provider. And there are several valuable integration choices that a relying party and a user can opt for that can make this experience of finding your identity provider very efficient. seamlessaccess.org is the site for more information. Federated identity, 20 years in now. It's the default model for internet identity. It emerged from R&E many years ago. There are other forms of identity out there. Centralized identity still percolates the self sovereign identity crowd muddle along as well. But they just haven't gotten the traction across so many different verticals as has federated identity. It comes in two flavors, SAML, which was raised in this environment and OpenID Connect, some of the technologies that are used both in the social space and increasingly on campus as another way to manage identity flows and attribute flows. The idea of federation can either be bilateral or multilateral. This was all designed to be multilateral, such as in common and educating for international R&E activities. But bilateral is a lot easier for cloud service providers to handle. So there is a dynamic about the usefulness of implementations by cloud service providers of federated services. The original focus of this work was inter-domain exchange of attributes. Authentication was just part of the agenda, but it became the mechanism for federated single sign-on early on. And that was a very useful and important business. And so we got a very tight focus on all of the complexities and issues for federated single sign-on. We had to evolve levels of assurance, incident handling mechanisms, a dynamic metadata for the size of the federations that were growing. And now I think the community is beginning to address the exchange of attributes now sort of. Speaking of the exchange of attributes, there are now normative bundles that are used together for common use cases. How might they be used? Well, the IDP might decide that it's going to implement a bundled release and release the set of attributes if a site relying party is so tagged. It can handle requests from the SPs for attributes. And it can also be used, these normative attributes to bundles to configure end user consent mechanisms such as Cora. The need to accommodate a variety of existing campus policies has made some of these attribute bundles more complicated than they need to be because if all universities never reassigned email addresses, it would be that unique perfect identifier. But that's not a policy at all universities. Similarly, there are variations in how one defines affiliations. And sometimes these attribute bundles wind up being either this if your policy is that or do this release of attributes if your policies are these. It adds complexity to the system. The primary existing example out there is very widespread, but not widespread enough as research and scholarship or NS. It's intended for federated login use for the research community. It consists of a shared user identifier, a personal name, an email address, and optional affiliation. So you can see it's identity rich. For the access control space, it's a different story. Overall as a community, we've evolved from identity based access control mechanisms with a list of names in an access control file associated with some data to role based where those list of names might be replaced by a list of roles. But those were two coarse grains, so we went attribute based. And finally, we're starting to think about policy based where we don't get rid of the attribute base, but there's enough work there that we need to create institutional level policies and user based policies that can manage the collection of attributes. That's where we're headed. One of the most important access control attributes is affiliation. We use it a lot in the library community in the content communities. It has coarse semantics. As you can see, those are the values it can have. And so we're looking increasingly at another attribute at your person entitlements that can have a variety of values. And we're beginning to see thoughts in that space and it's very fertile ground. She pointed out that an entitlement may not exist actually in the enterprise directory. It may be a computed value for transfer to the relying party by the IDP as part of the on the wire communication. And finally, it's a member of group memberships are very handy. That's how we manage a lot of attributes on the campus side. It's just a matter of figuring out how to make it a better vehicle for institutional use. Three new bundles are now in the library space that are of interest. They've been proposed and are available for comment. They cover the use cases for authentication only anonymous authorization and Sudan misauthorization, which allows some personalization and state. The standards process for this is community based. We began in a working group convened by seamless access. The proposal was passed to the refeds, the International Army Federation Schema Group for consideration and comment and adoption. And now we're at that stage where hopefully federations and IEPs will begin to adopt it. And it's also being reflected in the contract language working group, which is out there as an activity. Metrics and usage, distance to the attributes. I raised that as a question. Turns out there's some work going on right now. The next piece in the puzzle is consent informed attribute release. We call it CAR. It's a piece of software that's been developed by internet to Duke University from a grant several years ago from NIST. It provides end user management for consent, both in line during a transaction and self service, a debility to manage your stored consents. It has effective enterprise and end user management. It has unexpected compliance benefits as open source. And it's going back in my mind to the original purpose of what we built this infrastructure for. The original shirt t-shirt said we'll work for attributes. This works for attributes. This is what the screens of CAR looks like. Everything is customizable. The name of the identity provider is Amber in this case. You'll see that there's clear guidance on whether you're committing the release or denying the release. A use of standard colors and symbols. The values being released are displayed. The purpose of use is being released. It is being displayed. And then you have the ability to suppress the consent screen and just store that as your persistent consent until you choose to change it. Privacy policies for the site you are going to are also listed. We'll see this as part of the demo. Here's another faculty example. Again, releasing lots of information about access control and nothing about identity. So that's a very privacy preserving option. This is what the self-serve console looks like. Again, we'll see it dynamically in just a minute. The ability to manage your consent policies based upon the relying party you're going to do. There are APIs. Notice there's a couple of roles here. There's the user in a transaction. There's the user doing the self-serve. There's somebody who manages policy and then there's a major admin. This is an interesting branch that we could explore in a longer talk about gathering the informed content that you just saw in those screens that helps the user to make quality decisions. CAR has the ability to consume the new attribute bundles in several different ways, including the release of, without consent by the IDP, configuring a hint to users but requiring consent, or just using it in notice and transparency mechanisms. There's lots of things we can do. So we're going to put these all together in a slice spread demo. We'll leave the PowerPoint behind and go to show you, using seamless access and federated authentication, a variety of users, an undergraduate student and a faculty member accessing different sites and finally a brief window into what the admin interface looks like. Exit this and go to the interactive demo. So first I'm going to go to the research and scholarship site. That was a tag I mentioned. And this is in fact seamless access presenting itself. A list of identity providers. In this demo we only have one. This could be a managed list. Here's the useful icon. Here's what I was trying to access. Seamless access does a good job of keeping that continuity of user experience. I'm going to log on. I'm going to log on as an undergraduate with a password. This is the federated identity and authentication. And then I get to the consent screen that CAR presents as part of the Shibboleth experience in this case. The values that are being released and their consequence. This is dynamic. I've picked something that is identity rich. Though I've concealed some information. I can suppress the experience. I can look at the privacy policy. I'm going to just save and continue. And you'll see that the relying party will acknowledge that this is the information it received, display name, et cetera. In fact, that display name is right up here to give me a customized experience. And also that I didn't release my affiliation. I'm going to sign out. I'm going to go back. And I'm going to go as a faculty member to a commercial content site. Again, I see content always is where I'm going. Seamless access as the user experience for identity discovery. I'm now going to log on as a faculty member after the password. And you can see that the information now being released to content or us has some interesting information. I've concealed identity. But I've said I'm in the school of law so I can get to departmentally licensed content. And then I have some group memberships because they're sensitive according to at least GDPR contexts. I can obfuscate them and display them and choose whether to release them or not. If I just release this information I'll be able to preserve privacy but still get to some content which is licensed for the school of law where I'm located. You can see I can get to LexisNexis and here's the information that's been released. Some groups that I'm a member of my identity provider my law school access but nothing that identifies me. You can see you know this group. I'm going to sign out. I'm going to go now back to the self-serve console and show you what we made sure that was the right sequence. I'm going to do a stack of these self-serve content. Yes, okay. We're always going back to the recording. So the last demo that we'll do is looking at the self-service interface at the Safari. We're going to log in as a faculty member and I have to release attributes to the self-service screen that was that flicker and now I'm in here and I can see my console of release policies. I can manage what's being released so if I want to change whether my permit would deny I can edit that information. However, I just wanted to show you that self-serve console. The last part of the demo is to come in to the interface the admin interface. I'm now going to log in you just saw a seamless access to the last time in this demo and I can configure relying parties with different tags so that adding one of the new attribute bundles consists of creating a new policy if I wanted to and I can create the policies for institution or for users. The policies can include what might get released and when and under what considerations. There's extensive admin capabilities some of those can be delegated out to individuals for example technical librarians to manage the attribute bundles themselves. Let's get back to the PowerPoint to talk briefly about what's missing and thank you for attending. What's missing? Well as I alluded to you saw that group memberships had a pretty clunky interface in CAR about what attributes to release if there were many different group memberships that interface would have been really ugly and that's the best one I've seen so we need to change that. We need some good purposes of use so that users can know what attributes are being released in our community what therefore taxonomy not dissimilar in nature perhaps to what's happening in the advertising industry. We need fine-grained signaling so that various parts of the Wiki can say this part of the Wiki is only open to these group memberships only send these attributes if you're these group memberships if you come into this part of the Wiki. There's community standards that would say when is something really required? When is it really necessary? We need thinking applications this is kind of reflecting some of the privacy by design there's some reporting utilities that we want to see and there's some interesting work just starting up now a consultation on some analytics that would allow of the library community to do some privacy-preserving reporting of usage. Follow FIMFA-L it's a group of librarians contact your campus IDM people so that you understand what the environment is what capabilities they have for new attribute bundles for user consent etc how they think about entitlements and then finally we're going to be working with publishers and community groups for making these new kinds of attribute bundle capabilities reflect in purpose of use in contract language and I would imagine these standard activities will continue Finally I'll put this slide up for contact information and I thank you for listening to this presentation