 Okay, I think we'll go ahead and get started. Welcome, everyone. Thanks for coming to our presentations. And I'm Tracy Tolliver. I'm the Director of Library IT from the University of Illinois at Urban Champagne Library with Ken Klingenstein today from Internet2. They suggested we combine our proposals for this session. So we're going to do basically all kind of give my presentation. We'll have a very short question and answer and then we'll go into Ken's presentation. I think he's hoping to have more of a conversation solicit feedback from folks. Since joining the library community over four years ago, I've heard a lot of concern with how users are relentlessly tracked across the Internet, how it is nearly impossible to provide e-resources to patrons privately, and how it is contrary to the Library's Bill of Rights and the ALA Code of Ethics for librarians. To do this. And so, in fact, last spring, there was the plenary, the opening plenary for this exact meeting, was all about privacy landscape, policy and practice in the library and university context, panel and university library privacy issues. So they're very important to the library. This reminds me of an old adage, be careful what you wish for. For context today, I'm going to categorize tracking into five buckets. We're going to have third-party cookies, IP addresses, browser fingerprinting, link decoration, and bounce tracking. Cookies are little pieces of information that's stored in your web browser to help different services provide preferences, possibly ads, help you log in, all sorts of things. These can be first-party cookies, which are accessible only to the domain that created it, or they can be third-party cookies, which are accessible to any site in any domain. IP addresses are often used to identify geographic location or machines and services. Tracking mitigations for browser fingerprinting can impact IP address information, and it's often used to make authorization decisions, particularly in libraries or LMSs, learning management systems on campuses, or ERP systems as well. Browser fingerprinting, you've probably all seen lots of presentations on this before, but just kind of a quick review and give some context. Information collected about the software and hardware of a remote computing device for the purpose of identification. They keep track of all of the information like your browser used or your fonts used or the add-ons installed and the browser security configurations and your IP address and all these things put together. They can uniquely identify you across the internet. As well as link decoration, this is that extra bit of information that often gets added to the end of a URL. This could support query strings. For example, if you post a link on your website to get you a particular search result, you know, from your campus search process for your library, it can support some authentication tokens. It's also tracking information as well. And an example of that is below where you've got the question mark and the search charge and it gives some information to tell the browser what to do and where to go. Balance tracking is used by trackers to get around some of those third party cookie limitations. And it's also known as redirect tracking. Website A may send browser to the tracker to get a first party cookie. The tracker then sends the browser onto the user's destination with additional information stored. And then that browser will allow the tracker to follow the user around the web. The end user does not see this transition. Typically, they only see Website A and the destination page that they go to. But the good news is privacy is coming. GDPR has really accelerated the adoption and pursuit of privacy amongst services and particularly the web browser community. Their GDPR became effective May 25th of 2018. And that's when it really gained some teeth to really incentivize people to pay attention. Since then, we've had the California Consumer Privacy Act that became effective in January 1st, 2020. We've had the PIPL or China's Personal Information Protection Law went in effect November 1st, 2021, which is kind of a whole different take on things. But it also has some teeth that could potentially reach beyond its boundaries. The California Privacy Rights Act amends the first California Consumer Privacy Act in its effective January 1st of 2023. The Virginia Consumer Data Protection Act is effective January 1st of 2023 and Colorado Privacy Act, here in the state we're in today, is effective July 1st, 2023. And so there's a lot of things becoming effective in 2023. The Connecticut Personal Data Privacy and Online Monitoring Act, as well as the Utah Consumer Privacy Act at the end of the year. Iowa then has a Consumer Data Protection Act that will go into effect January 1st of 2025. Those are the six states that currently have legislation that has been passed and that will become effective. There's a number of other states that are in the process of doing things also. So there's more and more impetus for companies to respond, right? International, that's all the detail there. But to understand since the browser is the primary gateway to the web for most people, the browser developers are on the front line making changes. At first it appeared that they may all pursue different solutions, making the online experience for our users very different from browser to browser. And also making that very difficult for application development, troubleshooting across platforms. And there is some of that right now. But they're actually working together to agree on some standard approaches at least around the authentication authorization mechanisms using third party cookies right now. So that's good news. But to understand that, a little bit of architecture. So the browsers are dependent. The behavior you see as a user is dependent on the operating system, the browser engine, as well as the actual web browser itself. And so pretty much everything on iOS is much more private. Because everything on iOS has to use WebKit as its browser engine. And so regardless of what browser you're using on an iOS device, it's basically using WebKit. And so any privacy features implemented in WebKit will kind of flow through that browser to the user. But in most cases, if you're on a Windows machine or say, you know, an Android device or something along those lines, it'll use whatever engine is typically paired up with that browser. So Chrome is typically blink behind the scenes. Edge and Brave are also blink behind the scenes. So any development done to blink will affect Chrome Edge and Brave. Any development done to get go is what affects Firefox. And so it's kind of important to understand how those things interlink and how they depend on each other as we move forward. So I was out doing a little bit of investigation to provide more context. And so we're back to the five buckets of tracking. And each of the web browsers, the main web browser that's typically used in the US, 50% of the market shares Chrome. So regardless of what device you're on in the US, 50% of that use is Chrome. 35% of that is Safari and 7.5% is Edge and 3.5% is Firefox as of yesterday. The, right now there are a lot of development efforts underway and so to kind of summarize some of those and what section of those tracking aspects they impact fits together with this table. So right now IP addresses, you're already seeing those fail, I'm sure your eResources groups are already seeing IP addresses fail. They may not know why, but they're probably seeing it. And it's because right now iCloud Plus, their private relay went live fall of 2021. Now this doesn't affect everyone using Safari, it's people on those subscription services right now, but it's only a matter of time before they roll it out to everybody using that browser. The Microsoft Edge Secure Network, they have some IP address prevention, but it's still only on their Canary branch. Firefox has their private network extension and it's in beta and then VPN by Google One just rolled out in March of this year, just a couple of weeks ago. And that again is more of a subscription service right now but eventually it'll be available to everyone more than likely. So IP addresses are by far at the forefront of being affected and I know many of our libraries and campus services rely on IP address access and we're going to have to look at changing that. Cookies are the next area where there's a lot of focus and development right now. And so to summarize that a little bit, third-party cookie fate, well, we'll get to them last. Safari is usually at the forefront of most of these efforts. Apple is very, very cognizant of privacy so their intelligent tracking prevention was updated to block third-party cookies in March of 2020 and Firefox is probably next, they're very privacy-oriented. They're blocked third-party cookies by default in summer of 2019 for known trackers and the total cookie protection went rolled out in February of 2021 for all third-party cookies on Firefox. Again, Edge is pretty much going to follow Chrome because they're all on blink. And so Chrome was going to disable cookies, third-party cookies in 2022 and they realized how many things that was going to break. So they backed off a little bit. At that point, Edge went ahead and said users can disable all third-party cookie tracking in July of 2020 but it's optional. That's a setting that you'd have to actively go in and set yourself. And so they're working towards phasing out and their target right now is third quarter of 2024 to start phasing out third-party cookies in their browser. So if you think about how many people are using Chrome and they start phasing out third-party cookies, you probably better make sure you don't have anything else that's gonna break. Authentication folks are working with them. The advertising folks are working with them. Keep in mind Apple and Google don't just provide browsers, they provide products and services, particularly advertising services on the Google side. So they backed up, said how can we fix some of these things so that they work for everybody when we phase out cookies? And that's in process and I'll get into that a little bit later. Browser fingerprinting, there are extensions that exist that will allow you to reduce your browser fingerprinting risk and then there's also a privacy budget proposal in the works under the Google Chrome area. Safari put out their privacy overview white paper in November of 2019. Their approach is to design everything from the ground up with privacy in mind. So they delete a lot of information that aids in that browser fingerprinting now in very short time frames. Often a day or even hours, they're deleting some of your history and cache and things so that it's less likely that people are able to do that. There's extensions that exist in Edge as well and there's experimental development under Firefox. Bounce tracking, same, there's a proposal for Chrome. The first party bounce was addressed in June of 2018 by Safari and the delayed bounce was addressed in March of 2020 by Safari and they actually have proposed standards updates to W3C in order for that to be implemented across all web architecture. Chrome will likely follow or Edge will likely follow what Chrome does and enhanced tracking protection, 1.0 was introduced in June of 2019 by Firefox and enhanced tracking protection, 2.0 was implemented in August of 2020 by Firefox. So as you can see, there's a lot of activity going on here to address a lot of the privacy concerns that particularly this audience has had in the past and continues to have. But as I mentioned, this is the privacy sandbox timeline. So this is Google's kind of coordination effort of changing the way kind of the web architecture works and replacing those third-party cookies with other APIs in particular that will do certain things so that they can get rid of those third-party cookies. And so I know that's probably a little small to read, but each of those projects are basically have already been trialed and the last one that they're closing out is the Federated Credential Management API which is to support the authorization, authentication authorization mechanisms. So their goal is by Q3 of this year, those features will all be rolled out, made generally available to people and by Q3 of next year, they will start phasing out third-party cookies. They have incentive to do that, there's already lawsuits against them in Europe and other places, they will follow through. So it's not a threat, it's there. So in particular, the authentication authorization update hits us because we're a little bit different than the consumer web, which is really driving a lot of the changes that they're making. Academic environments, the research and education environments, we have built up these large trust environments using our federations like Incommon and Edugain and we use SAML standards to do a lot of that exchange and then facilitate that, that authentication authorization process. And so we were getting really concerned that they were moving forward without us, which they had no incentive to listen to us because we're pretty small fish in the whole scheme of things for most of these companies. And so we have been successful in getting their attention. There was a hackathon February 28th and March 1st in Mountain View with about 15 people representing Apple and Microsoft and Firefox as well as our federations and the Shibboleth community and Seamless Access. And I forgot to mention, I'm also a member of Seamless Access Outreach Community so I'm kind of sporting two hats today. And so there were two proposals born out of that. So the results of that were that we better understand their FedCMAPI and they now hopefully better understand our use case in higher ed. And so during that workshop, they kind of got together, we're gonna get farther with them if we can make proposals and provide possible solutions than we are any other way. So it's very important that we continue to engage with these groups, that we continue to be interactive and that we look at everything and try to provide proposals. So there are two proposals right now that's kind of being iterated through to see what parts of that they solve and what parts they don't. There are still some outstanding areas of concern that's being quantified and worked right now. There's a follow up session with that group at the Internet Identity Workshop at the end of April. And so we're hoping to continue that really strong close engagement for the next several months to hopefully get our use cases handled. But that's the attempt and it's being coordinated by several key people, Heather Flanagan who actually, I reuse some of her content for the earlier part of the presentation. She's been out trying to drum up interest and get people to participate. So that's where that's at. The additional privacy sandbox efforts are related to some of the other functions. So there's things like the bounce tracking, privacy budget, the IP protection, different things along those areas. And as these get finished and launched, they're going to continue to try to eliminate some of these tracking mechanisms that exist today. I think what you'll see a table I had up earlier is they're addressing IP addresses, they're addressing third party cookies. Now they're kind of waiting to see which way the water flows around the rock to kind of figure out where they need to start focusing their efforts next because they don't really know exactly how some of these other entities will react that we're using these things and what other methods they might start employing to try to get people's data in order to either sell them ads or track them or whatever they're trying to do. So they're kind of waiting to see a little bit on some of these other developments to see which direction they need to go and deploy their resources to first. That's my sense of things. Other efforts that's supporting privacy is an improved access. It's the seamless access effort. I've been involved with that for the last four years. It started as the RA-21 effort and really our intention was to provide really that discovery, the Identity and Access Management Discovery layer where you can designate where are you from and then you can use your home credentials to log in to all these publications and things that your library might subscribe to. That was our original goal. What we found out in the Outreach Committee is particularly the library community with people usually wearing multiple hats, particularly any resources, a lot of people just didn't understand federated authentication. And so we set out mostly to start educating people on federated authentication and so they'd understand what it is so then they would be more comfortable moving in that direction. Now with all of these browser changes under foot, we've actually kind of spun to focus a little bit more on that and the engagement in that effort and make sure that all of our authentication authorization mechanisms continue to work. But the IP addresses you might as well just start moving off of those now. I'm not an advocate. There's a lot of effort going on in seamless access to help support privacy and improved access. The new entity categories that were accepted and published by RFEDS is the anonymous, pseudonymous and personalized categories. These are bundles of attributes that's used when you're using federated authentication to transfer information between the identity provider and the service provider. So the idea is is we would create these predefined bundles of attributes that could easily be used by say a publisher to say, I just need anonymous information to know that this person belongs to your school and that they're a student or a faculty member. And you could just send them that and that's all they would need. And then they could get access to those resources without providing a bunch of personal information that the user maybe didn't intend or want to provide. Those have just recently been put out so they need to be adopted. There's also been a lot of work around licensing privacy and current contract. So there was a Mellon grant that Lisa Hinchliffe was one of the PIs on that did a lot of work around gathering up information around that. And they have put out current contract assessment rubric to look at your current contracts as well as some model contract language. She also was part of our contract language group within seamless access. There was probably a dozen, 15 people on that. And they also added model contract language for the authentic federated authentication piece of what we would like to see in contracts. If you don't get it in the contract, you can't hold anyone accountable later. So the first step is ideally we could get some of these things into our contracts around privacy and licensing. And then later we can enforce that and use SAML and federated authentication to actually support it. But those are efforts that's going on. So, you know, I've heard a lot of talk about how many people are concerned about all of the tracking that's done and how do we get around this? There are actually things under foot that are addressing this now. So that's good news. But it's probably going to be a little bit of a bumpy ride for everybody to get aligned with those changes. So if you're interested and want to know how you can get involved, there's the seamless access learning center. We have several videos up to just kind of explain federated authentication. We're keeping FAQs up there for both publishers and librarians so they can help troubleshoot eResources and we're posting about these browser updates. We're blogging about those. So the seamless access page, if you don't want to get really technical, is probably a good place just to hit to get a high-level update. If you're more interested, there are three different W3C groups, that community groups that you might want to follow or get involved with the privacy community group, the federated identity community group and the private advertising tech community group. That one isn't directly related to us but it's interesting to watch what they're doing because it may impact us later. And then if you're really, really technical and want to get really down into the weeds, there was the RFeds working group that just spun up related to browser changes and federation. So that's how you can get involved and then you might ask, what can I do now? And I would encourage all of you to implement federated authentication authorization as fast as you can because that is what's going to at least keep your resources available. That is probably the path that has the best future right now. Out of the different access methods that's currently used. Promote and use and enforce privacy preserving contract language, promote adoption of the new entity categories and be compliant with standards, specs and specs practices, particularly around SAML. And this is a call out particularly to vendors. We get a lot of them who don't necessarily implement SAML the way it was intended to be implemented or they may not be using the best practices adopted by the federations and using that and it would be really helpful if they would do that from the start. So that's all I have. I can take a couple of questions now and then I'll pass it to Ken for his and then we'll have time for questions again at the end. Does anybody have any questions right now? Okay, well then we'll pass it to Ken now. Thank you, Tracy. I guess I wanna begin by confessing some sins and so I go way back. I'm older than dirt as the expression goes and I'm actually in the internet hall of fame which no one knows about. And I'm... Oh really? In 2021? Yes, and I don't know Charles if it's for the damage I've done or the good work that it is for the damage. So let me confess some of the damage. In 1987 I was at an international meeting and we were just getting emails started and there was gonna be some very complex mechanisms to ensure that the sender was who it claims to be. And the technology that it was going to use was really crude, it still is pretty crude. And so at an international meeting, I stood up and said, look, I'm trying to roll this sucker out. It's really hard, don't make it any harder. Besides, who would ever send mail to someone they didn't know? And that carried the day, unfortunately. I did damage later on when I took the eyes of a few people off the real prize. So when Google came onto the scene, I thought the damage that Google was gonna cause was that they were gonna steal all of your eyeballs. They were gonna steal our accounts. They were gonna steal our authentication. They were gonna repurpose things to meet their own sales and marketing needs. And marketing needs. What I didn't realize, and some colleagues also didn't realize, is that the damage was gonna be twofold. One is a move away from multilateralism to bilateralism. So we were trying to encourage multilateral federations because the business of higher ed is to encourage knowledge serendipities. And to encourage knowledge serendipities, you're gonna wanna connect with lots of other people. In the bilateral business world, you have a relationship with another entity. Let's just go bilateral. It makes things simpler. And as a result of that, the software that we rolled out for our multilateralism, which Tracy alluded to, Shibboleth, I think it has the characteristic that by making hard things possible, it makes easy things harder. We added knobs, we added things to accommodate the multilateralism that turns out to make it a lot harder than taking a simple product that is just oriented towards a bilateral relationship. The other damage that I wasn't aware of that Google created was that it's not the marketing, it's not the advertising. It's that as Tracy alluded to, Chrome has become the operating system of the web. So the degree to which they fiddle with Chrome makes everything different about the web. That's what all these mechanisms are. And we've invested now everything in Chrome and its derivatives. And so that's an inordinate amount of power that Google has. That said, let me get to my particular angle on this concept of access. And Charles and Christina ran an awesome workshop on Sunday with NSF sponsorship around open access. And I love open access because it's not really gonna be open, it's gonna be managed. I wanna understand what are the conditions around the management of open access. And so I'm really here to learn, I'm gonna do a few slides, but I'm really here to encourage a conversation. I got my note pad here, to look at the exceptions around open access that institutions and organizations are going to have to want to implement to make things still private and privacy-preserving, but constrained, gated communities, et cetera. And we all probably have those pockets of use cases around, oh, it's gonna be open except to that crowd or except to that citizenship, or maybe in six months. Those are the kinds of use cases I wanna encourage because I think we can serve those use cases. And that's the intent of my talk and hopefully I'll shut up in a minute and you'll tell me all of the great use cases that you have in your special collections, in your PII based data sets, et cetera, that are gonna require gating. One of the other concepts that came out of the workshop that I wasn't aware of is we all know fair, there's something called care, which is around cultural sensitivities and indigenous populations in particular wanna have requirements and rules around the access to their artifacts and data. I think that's gonna be a rich space to get those exceptions to the rules. I don't know what they are now. You might, I'm seeing heads nod. I'll take notes in a minute. One of the other things, just as an overarching comment since Tracy invited you to get to the table, come to the table. I've been on refed steering committees since God, 1700, it feels like. I've been on in common steering committees. I've been around a lot. We don't have you folks at the table. We have the big scientists. We have the big dogs of some data. We don't have the rest of the community that we wanna serve. If he got to the table, we would change what we do. So please come to the table. That said, I wanna talk a little bit about the history of federated identity and access control. I wanna have the discussion, looking for those exceptions. And then I'll leave and I'll try to help implement an approach that implements the rules and the exceptions. Every rule has exceptions. Everything has small print. I wanna find out what those are. I wanna build the mechanisms that accommodate that. So one of the questions that percolated up and maybe somebody in the audience knows the answer. I've already asked David as my long-time colleague and he's working on it too, I hope, is I live in the landscape of identity federations. And then I dropped into courtesy of this workshop federated repositories. So federated as an adjective around various nouns like identity and repositories. And I'm trying to do a mapping of identity federations and repository federations. It's thick. It's thick stuff. In some cases there's good overlap. In some cases, one group doesn't know about the other. My guess is that a lot of institutional repositories are part of an institution that's in common, but that particular repository isn't connected to the fabric to get access that way. So we're gonna have a last mile problem. Some things I'm not gonna talk about are basic identity options. Somebody may raise their hand and go, what about sovereign identity? I'd be willing to take you out in the hall and have that conversation. Can't get to that topic here. Attribute release issues and approaches. This hasn't worked out well. In the original vision in 2000, the user was gonna moderate the information flows about themselves and their attributes. Hasn't happened and perhaps the opportunity for that has passed. I'll get back to that in a second. That would be because of AI stuff. And then finally, middle things. So especially in America, middle things happen, middlemen, et cetera. Middle things turn out to break the model of identity providers and relying parties. There's now a broker in between. Or is that broker faithful? What are the rules around operating that? So all of the portals out there, all of the proxies represent something that wasn't in the original model and won't be in this conversation either. So again, I was there at the beginning. And all of our use cases were around libraries. We had three driving use cases. They were wonderful. They warmed our souls. We were looking at scalability, privacy, and flexibility all in that mechanism. But we took a 20 year detour. Largely because the federal government, which was funding a lot of this early development through some grants I had, they wanted authentication well understood. Really mission critical stuff. And so we got into it. And we stayed into it. And the water got deeper. And we got multi-factor authentication. And we got levels of assurance about the identity proofing. And now we've got incident handling mechanisms so that if something goes wrong in authentication, we can pursue it. Nice, but not what we wanted originally. We served the market. I think we've served it well. Christina was talking about being able to be in northern Norway and log into her credentials seamlessly. So I think we got that infrastructure rolled out. I'd love to get back to the access control mission that we originally had. The infrastructure's in place. It's just utterly unexploited. By the infrastructure, we really mean institutional directories that could hold attributes about individuals, things like citizenship, things like cultural background, things like accessibility issues. All of those things we have schema that can store that information. We don't have ways on campuses to populate those schema, with the exception of citizenship, which we capture because of a federal standard. We don't have ways to control the release of that. I'd love to get back to that. I'd love to be able to combine accessibility with privacy. And we never talk about those two things in the same sentence. But wouldn't it be nice if I could go to a website and say, you know, I'm colorblind. I'd love to be able to see the screen in a way that I can read it. But you don't have to know that I also am wheelchair bound at this point. And so that, you know, that's another accessibility issues that I don't want to reveal. So we don't have that fine-grained control over that. Again, there's a schema that captures it. One of the nice things about that schema is it captures, among other accessibility issues, cognitive issues. And as we age, we're gonna face more cognitive accessibility issues. Wouldn't it be nice? It turns out that there's a fair bit of cognitive damage that affects your ability to do depth-first search. It seems to be one of the characteristics that gets damaged a lot in some cognitive issues. Wouldn't it be nice if I could reformat the content? So it's not the deep trees that we typically build for content. We'll see. So I'm gonna launch into the discussion in just a second. Here's the kind of open access management considerations I wanna pursue. Time and space embargoes. So I think we're familiar with time embargoes. I think there's various countries out there that have embargoes on research being available outside their country. They wanna give their own scientists and researchers the chance first to get to this stuff. Looking for those kinds of use cases. Consortial relationships. I saw an open books activity, I think, from JSTOR, good people, but it's only available to people who are members of the JSTOR Consortium. Okay, tell me about that stuff. Give me the use cases so I can go off and try to engineer that. Sensitive data. This is an interesting one. Daniel Solov is a George Washington University privacy professor. He's very good. He's talking a little bit about the limits of GDPR right now. He's also talking about the concept of sensitive data saying, gosh, with machine learning, isn't all data sensitive now? Can it be scaffolded together and identified? Yes. So the concept of sensitive data is gonna need a refresh, but we're gonna need to understand what that stuff is. Special collections restrictions. I think it's the case that when people donate, let's say official papers to a library for curation and sharing, that they may also put special considerations about the access. No camera, again, I follow this back when Yale got Henry Kissinger's papers and you couldn't carry a camera into the room that had the papers. Well, now it's online. How did they take that restriction and move it forward into the online world? I don't know the answer to that, but those are the kinds of considerations. I wanna do all of this in ways that protect privacy, that reveal just enough attributes to get you into the content but without identifying you without revealing other aspects of your situation. So with that, I'm gonna turn it over to you and ask you, what are the extenuating circumstances that affect who can access what and when? Gonna also ask, are there any constraints out there that are purpose oriented? So one of our failures in the attribute release space and you can see this with cookies in the EU is in the EU, the advertising industry created a taxonomy of purpose of use for basic functionality, for analytics, for cross-site tracking. We've all had those, which cookies do you wanna select when you go to a site, especially if it's an EU site? Well, there's a taxonomy of purpose that doesn't fit our world at all. Our purpose is a different. Are there any constraints on access that you're aware of relative to purpose of access, purpose of use? The third party downstream and derivative use cases, are there constraints over when you do that access who can receive your extraction of the content or your digestion of that? And how are these issues addressed today? So I'm gonna be quiet for a second and invite someone who has a Jones about this to suggest, yeah, you know, now that you mentioned it, there's PII data. And in fact, I rummage through the NIH databases. They're extraordinary. There's a rich set of stuff. And certainly the pandemic and the, has raised all of the genomics database issues a lot. They don't provide raw access to their data sets. They provide moderated access where you specify your search criteria, they'll return results unless the size of the result bundle, it's called a bin technically, is too small. So if you say, I want genomic characteristics in this particular county, because I wanna be able to track how disease progressed. Well, if there's less than 10 people in that county, you're not gonna get any results. I'm looking for those kinds of considerations out there. I'm quiet. Somebody had, oh, Charles, thank you. So yeah, I'm Charles Watkins and I'm from University of Michigan. We have a particular issue related to care with indigenous peoples in Michigan, Native American tribes particularly. So the issue is that skeletal remains represented in books and journals, they would like some restriction of access. The open access is not a, is it good? The open access is a good thing because it could raise cultural awareness among widely scattered members of the community in the upper peninsula, for example. So that's fine. But skeletal remains are a problem and they are sort of stepping stone because we can't work out how to restrict access to just those skeletal remains. So the intermediate stage is to have a health warning. So basically just to have a label that pops up and says be aware, you're about to encounter a picture of skeletal remains. But that's not really fitting what they want. So that's the use case. So would they restrict access then to qualified researchers? What would be the token of admission to be able to get to view that stuff? Do you have any ideas? Not yet. Because we haven't, we've said we just can't work out how to restrict this. This has also come up, this is coming up more and more in archeological associations. So the Southeastern Archeological Association has just put a policy in place that they will not show mortuary remains in their journal which is published by Taylor and Francis. But a number of biological anthropologists have pushed back and they've said that makes it impossible for us to do our work. So they've reached a compromise that those mortuary remains can be put in the supplemental data. So the pictures can be put in the supplemental data and then that supplemental data will require that there's an email received to access it. So that suggests that there would be some group who would be potentially allowable based on their specialist expertise but there needs to be some filter, some discussion before the access is granted. Superb, so if I was a biological anthropologist and I had a credential to assert that I might be able to get inside the gate. And potentially if you also had permission from the NAGPRA representative, so the North American Graves Repatriation Act. So there is an individual on every campus where this is happening who would be able to give to do the sign off. And we know how to do that latter part. We know how to assign roles and permissions on campuses. It's, as I indicated, it's not a developed area but the infrastructure accommodates it easily. That's superb. And I'm hearing more and more about having representatives on a campus who will actually handle inquiries related to other marginalized communities. So I was hearing at Emory, for example, having a liaison individual with the African American community in Atlanta just to prevent communities getting too many researchers appearing on their doorstep at once. So I think the idea of a NAGPRA-like individual on a campus for other marginalized communities might be gaining more traction. Wonderful. Any other edge cases? I'm all about edge cases. Yeah, I have a kind of an odd set and I don't know if it falls into your earlier description that you're not looking at the things that are in the middle, the little things. But mobile web browsers don't necessarily contain the same affordances as a desktop or PC browser. One example is when we tried to implement SAML, the mobile web browsers could store the last cookie but you could not query any cookie prior to that. And that might be the cookie that you set for your SAML authentication. So in the, I guess, in your advocacy, is there a way that we could establish some type of guidelines that would at least help implementers that may be working on these type of platforms and the browsers that we require that are built into the very frameworks of the applications but don't have that same capability as like a PC or a desktop browser? Great question. We're pretty agnostic about protocols. Okay. So it is the case now that you can do OIDC, which is what you would need for your mobile browser. So I don't think that's going to be problematic going forward. The web kit that Tracy talked about is also another mechanism where we've been able to implement OIDC and that protocol. So I think it's viable. Okay. But again, we wanna understand what attributes you might need and then where would those attributes flow from? So the analogy here is verifiable credentials, badges, et cetera, micro-credentials, big, buzzy thing, right? And everybody's working on what's the format of that credential? How can we make it self-verifying? Nobody's really looking at the issue of who can issue that in the institution. So if we wanna give you a, say, you're capable of pipetting as a micro-credential, you're gonna need a credential that says you're authorized by the institution to issue that kind of assertion. You more will also probably need something from the domain that says you're a trained pipeter courtesy of the Pipetting Institute of America or Nursing Institute or whatever. So that side of the picture has not been fleshed out as we've all spent time about what should be inside the credential, not how to issue it. And one kind of following question is one of the things that we struggled with was on the flow of the redirects for the SAML-based authentication. Where does it stop? So we've seen things like multi-factor authentication get layered on top of it. And so at what point does the browser know that the redirects are done so that you can, because it has to kind of make an arbitrary choice and like, okay, I'll count to two or three redirects till I can get back to the resource where I started. Is there a way that we could maybe enumerate that or let the client know in that authentication flow when does the redirect stop? So we can implement it. I hear you. It turns out that the challenges there are not in a technology but in the process for standardization. I have a T-shirt that says privacy was easy before continental drift. And in fact, what you just described is something where both the MFA standards and other kinds of related standards, what we've done in the US typically is more advanced because we had the federal government driving a lot of this stuff. And the rest of the world doesn't have that urgency. So it's a question of finding issues that have a shared urgency. And so I can carry your issue forward but at this point we've been so successful that unless we can do globally we're screwed. Okay, thank you. Fair, fair. Yeah, wonderful, thank you. Make it gnarly. Okay, I'll try, thanks Ken. Alicia Salas, University of Oregon. So I've got a case. So we've got special collections, quite a few that the extenuating circumstance around who can use those is that whether they're print or digital we don't hold the copyright for those. So an example would be that we hold all of the personal papers and correspondence and archives of Ken Keezy, the author. And the people who can access those materials at the moment are people who can physically travel to our location to work with materials because the family, the descendants of Ken Keezy still hold the copyright and will for many years until probably as long as they can. And they don't want us to digitize it and put it online openly. So we would love to make those materials more widely available to users at a geographical distance, authenticated researchers, users for non-commercial, educational research use. We would love to make those materials available as well for computational inquiry for researchers through digitization. But those are things that we struggle to, we don't have the authentication or the infrastructure to be able to do that currently. It's sort of like it's either just physically in our site or it's completely open, which is not an option. So that's the room. That's great. That's gnarly. Thank you. Okay, gnarly enough. That's gnarly, yes indeed. I think we have time for one or two more difficult collections or, yeah, go ahead, please. This is probably a superset of what, Richard? Cheryl, I'm sorry. Offered, but are you familiar with local contexts, Ken? From what? Localcontext.org. I don't know that. So localcontext is an initiative to provide both indigenous communities and cultural organizations with two different means to apply attributes to piece of cultural content. And so my understanding is that the two are labels and notices. Notices are for institutions, labels are for indigenous communities. And you're looking for use cases that I noticed in an earlier slide, a temporal constraint. So one of the more recent additions to the labels, that is to say the set of attributes that an indigenous community can apply to piece of content that they have sovereignty over, is temporal label. So as an example, and I'm sorry if this is colonial reduction of an important idea, the thing depicted in this image deals with a springtime right. And it can only be viewed in the spring. So check it out. So it's called, it's a temporal label. So if you go to localcontext.org, enjoy. Localcontext.org. Yeah, you'll see that there's a whole library of these tags, sorry, labels and notices. And I think they may give you a lot of examples of assertion of control over something that's tagged with these in a very specific set of ways. That's awesome. Thank you. Yeah, no, it's very much the case that at national policy levels, blanket statements come out and then life adds nuance. And identity management is all around nuance and trying to accommodate that. I think we're almost out of time. Any other comments people want to make or questions for Tracy? Folks, you've been fertile territory. Thank you.