Cadmore media player playing video Browser Changes and Identity Federation: The Impact on Identity Flows Webinar
Video Player
Accessibility
Using forms mode, you can utilize keyboard shortcuts to make usability more efficient.
Space bar will play and pause the video. Pressing escape will close all displays and pressing it again will jump to the end of the player.
You can press A to open the Keyboard Shortcut Dialog which also provides an audio description of the player and all of its features.
Language
1x
Play Speed
Adjust Volume
Transcript
Search
Result Count
of
Click to jump to result
Search
Re-center
Segments
Result Count
of
Click to jump to result
Search
Name:
Browser Changes and Identity Federation: The Impact on Identity Flows Webinar
Description:
Browser Changes and Identity Federation: The Impact on Identity Flows Webinar
Thumbnail URL:
https://cadmoremediastorage.blob.core.windows.net/b9471595-1df8-4c29-bdcc-420bc40fd271/thumbnails/b9471595-1df8-4c29-bdcc-420bc40fd271.jpg
Duration:
T01H00M20S
Embed URL:
https://stream.cadmore.media/player/b9471595-1df8-4c29-bdcc-420bc40fd271
Content URL:
https://cadmoreoriginalmedia.blob.core.windows.net/b9471595-1df8-4c29-bdcc-420bc40fd271/GMT20200526-163322_Seamless-A_1920x1080.mp4?sv=2019-02-02&sr=c&sig=MWkJ4VUXs%2FmdFbVd8mglh8BZu1RveIKc3ovRoGEG1H4%3D&st=2025-01-15T05%3A16%3A39Z&se=2025-01-15T07%3A21%3A39Z&sp=r
Upload Date:
2021-06-30T00:00:00.0000000
Transcript:
Language: EN.
Segment:0 .
JASON GRIFFEY: Hello, everyone. Thank you so much for joining us today. This is Jason Griffey. I am the director of strategic initiatives at NISO. And I am so very pleased to have with me today Heather Flanagan and George Fletcher, who will be delivering a presentation on Browser Changes and Identity Federation-- The Impact on Identity Flows. Couple of little housekeeping pieces before we throw over to Heather.
JASON GRIFFEY: The first is you will have two things going on simultaneously. You hopefully can see my slide, and you can hear my voice. If you have any issues with hearing me, it is possible for you to dial in over a telephone. The numbers are there on the screen. And the webinar ID that you will need is at the bottom. If you have any issues as the presentation moves forward, please contact Zoom directly-- support.zoom.us. They will be able to help solve any technical problems that may be going on.
JASON GRIFFEY: And you will also need the webinar ID for that, so please make a note of it in case something goes wrong. A couple of things that everyone always wants to know. The slides be made available? Yes, they will. And the webinar is indeed being recorded so that you can come back and view it later. Shortly after the end of the webinar, you'll receive an email with links and information on how to access all of those things.
JASON GRIFFEY: NISO does a number of educational events throughout the year. We have several coming up in June-- No More Big Deal? Picking and Choosing Titles for Use, Changes in Higher Ed, and 13th annual BISG-NISO Changing Standards Landscape Forum. All of these and further into the year are available at NISO.org/events. We'd love to have you at any or all of the educational events we put on online.
JASON GRIFFEY: We also do a regular newsletter, NISEO IO. That is available online, and you can sign up to have it delivered directly to you with all of the efforts and activities that NISO is involved in. niso.org/niso-io. We'd love to have you as part of that as well. And with that, I am going to go ahead and throw it over to Heather Flanagan, who will introduce George Fletcher.
JASON GRIFFEY: I'm going to stop sharing while she does that and let George pull up his slides. Thank you everyone for being here, and take it away, Heather.
HEATHER FLANAGAN: Great. Thanks. So yes, thanks everyone for joining us today. As Jason noted, my name's Heather Flanagan, and I am, among other things, the program director for SeamlessAccess. SeamlessAccess is a service designed to help streamline the online access experience for researchers using scholarly collaboration tools, information resources, and sharing research infrastructure.
HEATHER FLANAGAN: It's a free service governed by a coalition of five organizations-- [INAUDIBLE],, Internet2, the National Information Standards Organization also known as NISO, who are hosting today, Orchid, and the International Association of STM Publishers. Participants in our various working groups include researchers, service providers, librarians, identity providers, federation operators, vendors, all of the above.
HEATHER FLANAGAN: Our niche is specifically in the federated identity space at that point where an end user needs to find their identity provider. Now, as it turns out, federated identity looks a lot, from a purely technical perspective, like what a cross-domain advertising service looks like. So today's webinar is not actually about SeamlessAccess itself. The SeamlessAccess technical steering committee identified the potential browser changes geared towards cross-domain advertising but therefore also impacting federated identity as an area of interest and possible concern and decided to put together a webinar so that other people can learn about this as well.
HEATHER FLANAGAN: And with that, I'd like to introduce George Fletcher, identity standards architect for Verizon Media and OpenID Foundation board member. George is going to talk to us about changes in the way browsers interact with and support cookies and how that impacts services that rely on cross-domain identity flows. Please post your questions in the chat. We'll get to as many as we can during and at the end of our slides.
HEATHER FLANAGAN: And if we don't get to your questions, please feel free to take this to your favorite social media site. I personally like to keep an eye on Twitter. And we'll continue the discussion there. With that, now I'm handing over to George. Who's still on mute.
GEORGE FLETCHER: Can you all hear me and see my slides?
HEATHER FLANAGAN: Yes, perfect. Thanks.
GEORGE FLETCHER: Good. I took a quick scan through the attendees list and noticed a number of my esteemed colleagues in the identity and federated space. So anything that I misspeak, they can correct. So this is excellent news. And we'll get started. So there's a bunch of different things we want to talk about today, largely-- and you can actually find more information about this as a whole largely within the W3C Privacy Community Group.
GEORGE FLETCHER: There's been a number of browser makers have been sharing about different technologies and different things that we're looking at to help protect users of the internet as a whole and protect their privacy, protect them from, basically, add-targeted profiling and tracking. And Google presented-- Sam got to Google presented a great talk that outlined the problem space at the OpenID Foundation Workshop that was on the 21st of May.
GEORGE FLETCHER: So when those slides get available, you can find them on the website there. It was an excellent summary of the problem space they're looking at. And so a lot of the specifics that we're going to talk about today come out of that mindset of how do we protect the user and stop the sort of tracking behavior that is so prevalent especially within the ad environments.
GEORGE FLETCHER: So we'll start with the SameSite impacts, because those are the ones that are actively rolling out or close to be rolling out, as well as some of the ITP policy impacts as it relates to changes Apple has made in their Safari browsers. And then, the last four things I would say are more future things but are things to be watching and tracking because they could also have an impact on the way identity and federation flows work.
GEORGE FLETCHER: So a quick summary of what is SameSite and what does it mean from a cookie perspective. Effectively, SameSite is another cookie attribute like secure or HTP only, if you're familiar with those. And basically, there's three modes to SameSite. There's Strict, which is really an attempt to allow a site to protect against cross-site request forgery. The cookies that are marked with the SameSite Strict attribute basically will only be sent from the browser if the top-level domain matches.
GEORGE FLETCHER: So if the domain the cookie was written on matches the domain in the browser, then the SameSite cookie equal Strict cookie will be sent. Otherwise, it won't be sent. Some of you, I'm sure, as you hear this will start thinking through what does that mean for my identity flow perspective. And we'll cover some of that as we go forward. SameSite equal Lax is basically-- it it will be sent if the user takes a explicit action.
GEORGE FLETCHER: So you can think of this as I search for something on Google.com, and there was a link, and I clicked that link. That's an explicit user action. So that site, if it had set a cookie as SameSite equal Lax, will get it. But otherwise, it won't be sent. Just browsing and reaching out to that site to grab a URL or an image or something like that without an explicit user action, the cookie would not be sent.
GEORGE FLETCHER: SameSite equal Lax cookies are also sent today on full top level page redirect. So a 302 or a 307, if the cookie's set as lax, the cookie will still be sent. And then, SameSite equals None, basically this is the default behavior of cookies today on the web. So today, if you don't explicitly set a SameSite cookie attribute, then it defaults to None, which is how all the third-party cookies work.
GEORGE FLETCHER: So basically, what the changes are is that you can no longer set a cookie, a SameSite equal None cookie, on a URL that is not HTTPS. So basically, now any domain that you want to have a third party like cookie you work on, that URL must be an HTTPS URL. So those are basically the policy changes of SameSite.
GEORGE FLETCHER: We'll look at what affects-- if you were to set a cookie from an identity flow perspective to Strict, what does that mean? And effectively, this breaks pretty much everything, because in identity federation flow, when you do a redirect, you want to get the identity provider's SSO cookie or authentication state or whatever, and you won't get it if you set that to be strict. Similarly, any cookie that handles nonce or state or a CSRF token prevention mechanism, it's not there.
GEORGE FLETCHER: And then, of course, any sort of chain flows, which we often have a lie and identity federation, they also start to break because you're just converting the role of the intermediate IDP into an RP of the downstream IDP. SameSite equal Lax. Basically, what this causes a problem for is basically iframes.
GEORGE FLETCHER: So within OpenID Connect, there has been a lot of times where people will basically, whether they're using the implicit flow or some other mechanism, they will use an iframe to silently refresh the cookies for the logged in session. And pretty much, no-- if your cookie is SameSite equal Lax, it is not set in an iframe when the iframe is talking to a domain that's other than the top-level domain, which is what you're trying to do in this context.
GEORGE FLETCHER: So that is broken. And then there's some other session management and log out specifications from an OpenID Connect perspective that also start to break when you're trying to do a log out again within an iframe. So iframes become the problem with SameSite equal Lax. The cookies just aren't set. So if you have any identity flows that are working in iframes, this as something to research and investigate.
GEORGE FLETCHER: Another impact of SameSite equal Lax is basically POST based protocol messages. So I know SAML had sort a form. I don't remember what the exact name is. You guys could tell me. But basically, the IDP returns a little bit of JavaScript that form posts to the RP or the Relying Party the data. And we often use that mechanism if the redirect URL itself would get too big.
GEORGE FLETCHER: So this was a way to send much larger payloads. And unfortunately, in that model, any cookie that's written as SameSite equal Lax is not sent when that form posts because it posts without an explicit user interaction, and it's posting to another site. So this basically breaks any of those form POST response modes in both SAML and OpenID Connect.
GEORGE FLETCHER: And then, SameSite equal None, the big impact here is the requirement for the secure flag. So if you're trying to do development testing on a endpoint that isn't running on HTTPS, then that becomes a problem. It's minor here. The really big issue with SameSite equal None is that the expectation is-- in fact, there's actually an-- I don't know, Sam, if you want to drop something in the chat here if you can.
GEORGE FLETCHER: But when I looked through the chrome experimental flags for SameSite, there's actually an option to basically allow UI. And so my expectation here-- this is George's expectation, not something I know-- is that browsers will be looking at this and saying, hey, if you've got SameSite equal None cookies and you haven't visited that site in some period of time, the browser may pop up something that says, hey, you've got these cookies that can be used for tracking.
GEORGE FLETCHER: Do you want to clear them? And now, all of those cookies are explicitly tagged. So where this comes back around-- and I think I have a slide for it, but I'll touch on it right now-- is where this comes back around is that the one way to make iframes work is to set SameSite equal None. But that may have a limited shelf life in the sense of how long it will work.
GEORGE FLETCHER: So in the sense of where is this now, Chrome started rolling this out late February, March timeframe, starting with version 80 of Chrome. They then stopped it due to COVID-19. But you can go into any Chromium based browser and go to the flags page and search for SameSite, and you should get three values. And if you just turn them on, from default to on, you'll get the SameSite behavior and it will make it easy to test your flows to see if things break or not.
GEORGE FLETCHER: So when the change rolls out, the big impact here is that today, cookies default to SameSite equal None. And with this change, they will default the SameSite equal Lax. So all of those implications that we talked about with SameSite equal Lax that were in those previous slides, that will become the default. So effectively, your iframe flows just broke.
GEORGE FLETCHER: Any form POST response mode where you're expecting cookies to follow that reader, the form POST for CSRF protections, those just broke. Now, there is a caveat around that that I'll come to in a minute. So the impacts to authorization servers. Really, the main thing here is, if you're using iframes or if you want a short-term fix, you could explicitly set all of your cookies to SameSite equal None, both the RP and the authorization server.
GEORGE FLETCHER: The bigger, ugly piece here-- and it depends on how much of your traffic comes from Safari-- there are certain older versions of Webkit that if you set-- that don't recognize the SameSite equal None setting. I think I'm remembering this correctly. And so if you try and set it, they will default to SameSite equal Strict. So the two cookie solution is really around-- you may have to write one cookie with no SameSite attribute and another cookie with the appropriate SameSite equal attribute and then, based on your browser, see which one you get and handle it accordingly.
GEORGE FLETCHER: It's pretty ugly. Or you can just basically say, we're not going to support-- our flows will be broken in those older versions of Webkit. So for relying parties, the biggest issue are ones that are either using iframes or using a form post response mode because the default will be Lax, and if you're using top level redirects, the Lax will still work.
GEORGE FLETCHER: The cookies set with SameSite equal Lax will still follow the redirects today. But if you are using iframes or the form post mode, then you definitely want to look at how to handle this. Now, the one caveat or concession that was made on a temporary basis when this started rolling out was the browser-makers decided that if the cookie has been written within the last two minutes, then on the form post, it'll send the cookie.
GEORGE FLETCHER: Now, this is great for most-- for an SSO scenario or a simple sign-in scenario. But if you have to-- It creates an inconsistent experience for users, because if they hit your site and you're like, hey, we'd like you to update your alt email address or your recovery email address, and that process of taking them through that flow takes more than two minutes, then when you redirect, your cookie you won't be sent, and now it will fail.
GEORGE FLETCHER: The CSRF protections will fail, and the user has to start over. Now, that may be a seamless redirect again, but it still is a pain. So I would recommend moving in a direction that doesn't depend on this workaround. But that does impact both relying parties-- that impacts relying parties, which sometimes can be a harder process to get them to roll out updates.
GEORGE FLETCHER: We just talked about this one. I was one slide ahead. Yes. And so basically, here is the slide, as I mentioned coming up, that if you try and set a cookie explicitly to SameSite equal None, this older version of Webkit will basically default it to strict instead, which is a very different behavior.
GEORGE FLETCHER: And so this is ugly. And in reality, the recommended solution-- there's really two solutions. One of them is try and detect all of the Webkit user agents that have this old behavior and manage it that way so that you set a cookie one way if it's an old Webkit. You set a cookie a different way if it's everything else. Or just set two cookies.
GEORGE FLETCHER: And the recommendation I believe from the browser-makers themselves was to use the two cookie method. And so I'm going to stop there and see if there's any questions specifically around SameSite behavior and whether any of that made any sense or was so deep in the weeds that everybody's horribly confused.
GEORGE FLETCHER: Any questions?
JASON GRIFFEY: I don't see any questions in the chat.
GEORGE FLETCHER: OK. We can keep going. So ITP. ITP is basically Apple's Intelligent Tracking Protection, if you're wondering what it stands for. And they've been rolling out enhanced capabilities to this effort over time. And you can go to their Webkit.org blog and you can find these topics on different capabilities from ITP and how this impacts things.
GEORGE FLETCHER: So we're going to talk through about some of what these ITP 2 dot exchanges are. And so the first one with ITP 2.1 was basically that Apple was going to-- they have a machine learning algorithm inside the browser for this. But if the machine learning algorithm determines that your site is tracking users, then basically, if the user doesn't visit your site for 30 days, they will wipe all local storage and cookies.
GEORGE FLETCHER: They'll just be gone. So any sort of persistent cookie you are using, even for first party tracking, could potentially be gone. The next sort of ITP 2 thing was basically, if a persistent cookie is written via JavaScript from one of these trackers, it gets wiped after 24 hours. And also, basically, pretty much third party cookies are disabled in Safari at this point.
GEORGE FLETCHER: So if somebody tries to write a cookie in a third party context, it doesn't get set. With ITP 2.3, they basically shortened the time window for sites that are flagged as trackers. So if their machine learning algorithm determines that your site is a tracking site-- And again, remember that redirects with link decoration, i.e., a state value on the redirect URL or a code on the redirect URL is link decoration.
GEORGE FLETCHER: Then too many of those in the browser get you classified. And there are probably other ways to do it, like if you go to one site and then it bounces to another site to do some things and it comes back and it bounces somewhere else. All of that stuff feeds into their algorithm as to whether you're tracking. So now, in this case, starting in Safari 13, your local storage and your cookies will be wiped if the user hasn't interacted with your site in seven days.
GEORGE FLETCHER: So depending on how long your authentication sessions are, this could have a big impact. So I go to hiking.example, and it redirects me to coolidp.com. I log in. I go back to hiking.example. And potentially, because it looked like that could be a tracking scenario, if I don't visit hiking.example for seven days, all my cookies are gone.
GEORGE FLETCHER: And they don't know that I'm still logged in, even if my session was good for two weeks. If your sessions are only good for 24 hours, then it probably as less of an issue.
HEATHER FLANAGAN: So there's a question on this one.
GEORGE FLETCHER: Great.
HEATHER FLANAGAN: Is this just cookies, or does it include everything in browser local storage?
GEORGE FLETCHER: Local storage. I'm not 100% sure about the separation between the local storage and index DB or those kinds of things. But definitely local storage and cookies.
HEATHER FLANAGAN: OK. And another question. This one is actually from me. Is this purely Safari, or is this across the board with browsers, what ITP 2 is doing?
GEORGE FLETCHER: So this is specific to Safari, though other browsers are doing similar kinds of things. They just all have different rules. So basically, Mozilla has a similar sort of thing, but I think they're their deadline is-- they're still at 30 days. Mozilla uses a-- doesn't use machine learning. They use basically block list white list from disconnect.me. I think Brave is also using a pre-generated block list.
GEORGE FLETCHER: Their settings may be a little more aggressive than Mozilla. In that sense, there's not a standard here in the sense of exactly when things should be cleared from a user perspective or from the local storage cookie perspective. Other questions?
HEATHER FLANAGAN: Nope.
GEORGE FLETCHER: All right. So there are a couple of additional things that Safari is testing. By the way, almost all of these features you can get in the Safari Technology Preview. Just go to their website and sign their agreement and download the Safari Technology Preview. And they have an experimental menu option. I think it's under Developer. And you can basically turn all of these things on and then look at the Java-- look at the console log under Web Inspector, and it will tell you when different things are happening, like when they've set a site to be a tracking site or whatever.
GEORGE FLETCHER: So that can be useful in testing. Not everything is 100% perfect. In certain cases, it's really hard to try and figure out, how do I force a particular behavior in the Safari Technology Preview? But in general, it's definitely helpful if you want to turn on some of these things. Just like in the Chrome flags, you can force the SameSite behavior to be on even though it's not on by default.
GEORGE FLETCHER: So the next set of things. This next one here is, again, a tracking prevention mechanism. So the thinking here is, if the browsers can tell that your IP address is effectively a unique identifying value-- and definitely, jurisdictions across the world sometimes classify IP address as PII-- then the options here are, hey, let's route all of your web traffic through some sort of multiplexer so that many users are coming from the same IP address and you can't use that IP address as a unique mechanism for tracking the user.
GEORGE FLETCHER: And I threw a bunch of links in there from different people about how they want to track this. There's some aspects for this concept of a privacy budget and things of that nature. So you can follow those links once the deck is published. But that's generally the rationale for this kind of behavior. I think the thing that this-- how this impacts identity providers, especially those that are either the identity provider or the authorization server, is that, oftentimes from a security perspective, we need a certain level of information to determine that this is a device we've seen before, this is a browser we've seen before, because that creates a better experience.
GEORGE FLETCHER: Just the other day, I fired up a browser, cleared all of my state, went to log in to Google with a couple of different accounts because I was testing something, and every time I logged in with one of these accounts, I got the challenge of, hey, we're not really sure this is you. Could you please verify your phone number? It's effectively what I would call a second-level challenge to ensure it's really you.
GEORGE FLETCHER: Well, if you lose that kind of environmental data that tells you, hey, this is a browser I've seen before, it's a browser for George, this is a day he normally logs in, all of that stuff, then effectively, you can't tell George from Fred, which is kind of the point of some of these changes from an ad tracking perspective. But from a security perspective and an identity perspective, it's actually a degradation of behavior, because now my experience interacting with the IDP as a user gets much more complicated because the local storage is getting cleared or my IP address is randomly changing or things of that nature.
GEORGE FLETCHER: And so I have less assurance is an identity provider from a security perspective that you're really you, and so I'm going to surface additional challenges to ensure that you are really you. And I think that that aspect of the conversation hasn't really happened within the context of identity and browsers and anti-tracking behavior. And I think it's one of the conversations that we all can-- we who are involved in the identity space can contribute back into this discussion for how do we help protect users from a privacy perspective but don't break their experience on the web and still give them a secure experience.
GEORGE FLETCHER: And it is a bit of a difficult scenario, because how do you separate identity behavior from tracking behavior, which I think is what the browser-makers are struggling with right now. Any questions on this one?
HEATHER FLANAGAN: Looks to be just one. Are there signs that the security and identity teams at browser vendors are able to have a voice in browser changes at their respective companies?
GEORGE FLETCHER: That's an excellent question, and I'm not sure one that I can answer. I think it's a great question. How do we-- how do internal to a company that makes a browser, how do they share this behavior? For certain things-- for certain browsers, a la let's call it a Brave or something like that whose main product is a browser, that may be a little bit less relevant. But from a Google or a Microsoft or maybe even an Apple, I think it's a great question, but I don't have any inside knowledge to know whether those conversations are happening or not.
GEORGE FLETCHER: So there is a ton of text on the next slides. Mostly I just put it in there so people could read it in an offline setting, so I will summarize. So please do not try and read on the screen. I don't normally put slides like this up, but this was just a simple way to put these things together. Fundamentally, the browser-makers do recognize that identity federation is an important aspect of the web.
GEORGE FLETCHER: And so they're looking at how can the browser be more involved in the identity federation flow so that we can separate what is an identity login, an identity flow, from, let's say, a tracking flow. So I think this is the rationale behind this. This particular proposal comes from Apple, John Wilander. And there is another one that I've summarized a little bit-- hopefully, I didn't completely mess it up, Sam, because I know you're listening-- on Web ID, which is from Google.
GEORGE FLETCHER: And I've got a slide for that later. But generally, the concept is, how do the browsers become more-- can they intermediate the login flows in a way that they can know with high assurance that, yes, the user wants to be logged in to site A via IDPP is really the goal. So then, we can do that. So as you see in the very last paragraph, we can't let people just set the status whenever they want.
GEORGE FLETCHER: We have to ensure that the state is logged in can only be set when the browser is convinced that the user meant to log in or the user is already logged in and wants to stay logged in. So here were some suggestions around this. Use something like WebAuthn which the browser is already mitigating. If you're unfamiliar with WebAuthn, it's FIDO2. It's the way to do strong authentication out of a browser using a navigator.api. So you can trigger it through JavaScript.
GEORGE FLETCHER: So that would be a clear sign, one, that the browser could understand that the IDP is challenging the user for a credential. The browser can know that they invoke the credential. The user did accept the credential. It went back. Therefore, this is a trusted login session. Obviously, the redirect-based federated flows are a little bit more complicated.
GEORGE FLETCHER: You could do things like continuously show a browser UI indicating an active logged in session on a particular website, whether that's the URL bar indicator or something else. You can-- the browsers could do things in the sense of protecting the user's privacy, like, hey, you logged in to news.example five days ago, but you haven't been back.
GEORGE FLETCHER: Do you want to stay logged in? And if the user says, no, then what the browser does, it just clear all the cookies in local storage because that's how they clear the session for the user. Of course, that puts us back in that security problem of now we don't-- this is a brand-new browser. How do we know who it is? How do we associate trust and out of the environment for that?
GEORGE FLETCHER: The other piece of this proposal was that there was this concept of, if the user-- this is the last bullet. The user needs to already have the "is logged in" status set for the federated identity provider. And there was a link to this proposal, and I'm sure you can find follow-on doc from the Git repositories.
GEORGE FLETCHER: I highly encourage anyone who's really interested in this to go dig through those and make sure I read this correctly. But the way it read to me is that if I want to log in with Google, then I already have to be logged in at Google for this thing to work, which I don't think is a viable starting place. A user could start at their browser, not be logged into anywhere, want to go do something at a site, see the Log In with Google button, click it, and it shouldn't fail just because they aren't already logged in at Google.
GEORGE FLETCHER: But again, I could have read that wrong, but that's the way it read to me. So again, how does the browser mediate this redirected-based identity federation flow? Actually, I'll do the WebID one and then do more questions. So WebID is a proposal from Google, which is a JavaScript-specific API focused on identity federation flows.
GEORGE FLETCHER: Again, same sort of idea. How do I intermediate? Can we use a browser provided chrome? In other words, the browser creates the window in which the identity flows happen, so they're more involved and can mediate that. And the proposal is trying to leverage as much as possible out of existing standards to make it easier for adoption within relying parties.
GEORGE FLETCHER: Exactly how that's all going to work is still being determined. It's still very early days. And Google's been, like I said at the beginning of this talk, very proactive in trying to work with the identity community on understanding what the issues are. So they presented at the OpenID Foundation Workshop just last week. And I think that there's a good opportunity there to work together to ensure that we can maintain the security of the user while also protecting their privacy.
GEORGE FLETCHER: But again, still early days of this. How this works either in concert with or in place of the proposal from Apple on is logged in is still unclear to me. So any comments or questions here around the browser wanting to disintermediate the login flows?
HEATHER FLANAGAN: Yep. We have two comments. They're not exactly questions, but they might be worth discussing. One of them is that a lot of these proposals assume that there is only a single IDP, which is definitely not necessarily the case.
GEORGE FLETCHER: Well, so I don't-- I think it's less about a single IDP. I think it's about, for a given user at a given point in time, they are logged into a site with one IDP. So in other words, it's unusual to log into hiking.example.com at the same time in the same browser with three different IDPs. And so it's not trying to say that there's only a single IDP.
GEORGE FLETCHER: If you get to the relying party and they say, hey, we want to support sign-in with Google and sign-in with Facebook, or in the federated education space where you might have hundreds or at least more than hundreds of IDPs, the aspect of which one-- how does the user choose which IDP to start with on the site is a little bit outside the scope of what they've been targeting so far.
GEORGE FLETCHER: It's just, when you start that identity federation flow, what are the impacts of these changes for what the user chose?
HEATHER FLANAGAN: It's not entirely unusual to be logged in at multiple IDPs in some use cases when you're trying to get to some scholarly communications material and you have affiliation with three separate universities. Not at all uncommon, say, in the Boston area or in parts of California. And they'll just try and flip from one to the other to see what's going to get me the most access to the material.
GEORGE FLETCHER: Right. And so I don't think any of these flows would stop the-- so I think that's an interesting use case and we should add it to the list. Effectively, what this amounts to-- and some people consider this to be a sort of tracking behavior that they want to prevent. I've seen-- there are web pages you can go to that basically will try every sort of IDP out there and ask you-- and see if they can silently log you in to any of those sites because of SSO.
GEORGE FLETCHER: And that's a little bit the use case you're describing here, is I go to a relying party or a service provider, and the service provider sends back some JavaScript that says, I'm going to start iterating through the 1,500, 200 top IDPs that this user may be logged into right now and see if they're logged in, and if they are, see if that will get them seamlessly into my site. That sort of redirect checking out of an iframe or something like that would almost assuredly turn on the anti-tracking-- or trigger the anti-tracking behavior in Safari and potentially get you labeled as a tracking site.
GEORGE FLETCHER: And then you run into these additional ITP rules. So that behavior may be impacted by these kinds of things. I think as far as it relates specifically to is logged in or the WebID stuff in the sense of the browser understanding where the user is logged in, it would be fully expected that you as a user would be logged into multiple IDPs at the same time. It's just, is that logged into the IDP disjointed from where the IDP has been used for a relying party, and how is that model represented?
GEORGE FLETCHER: And I haven't seen anything about how that sort of model gets represented within the browser. Are they disconnected with loose affiliations, or is it more tightly bound where they're tracking who you're logged in at specifically one-to-one for a relying party or a service provider?
HEATHER FLANAGAN: So we have a couple other questions. One is, for the is logged in proposal, is that purely Safari, or has that been accepted for implementation by any other major browser vendors?
GEORGE FLETCHER: Right now, it's purely Safari, though I believe it is available in the Safari Technology Preview if you want to play with it. It's a little bit unclear how they're determining that this logged in state in IDP or in session are trustworthy. But I believe John has dropped the code for that feature in Safari.
HEATHER FLANAGAN: So another person points out that is logged in and WebID would both restrict the authentication methods that we can deploy which could make it a little hard to develop new authentication methods.
GEORGE FLETCHER: So I think that one-- I think we have opportunity at least on the WebID one to work with Google and the browser-makers on that proposal. What does it mean when I want to do an identifier first flow, and in this particular context I want to use WebAuthn, but in that other context, I don't on a completely different device? And I think identity providers must have the ability to manage those flows.
GEORGE FLETCHER: Hey, somebody's been-- we saw unusual activity on your account. We've flagged you that you need to re-verify, change your password, do whatever. The identity provider has to still be in control of the actual UI that's rendered. So I think in the WebID proposal, it's more about the browser would open a special window that still has a browser-like tab in it.
GEORGE FLETCHER: It still has an HTML renderer and JavaScript and CSS renderer in it. But it's especially browser chromed, and the IDP can run all of their flows through that. And then, when they're done and it's successful and they're redirecting back to the relying party saying, OK, the user's logged in, then the browser could detect that transfer of control and deal with the state.
GEORGE FLETCHER: In some cases, at least in one of the proposals I've seen related to WebID, if the browser doesn't believe your IDP is trustworthy, they may give the user an additional challenge to say, hey, are you really sure you want to log in from this IDP to that site? But again, still lots of-- nothing set in stone here. Still lots of opportunity to work together to try and find something, again, that I think protects the user, protects their security, and doesn't negatively impact their being tracked across the web.
HEATHER FLANAGAN: It will be an interesting question as to whether the browser vendors themselves are going to play by the same rules that they'll be applying to other folks.
GEORGE FLETCHER: Yes. I think that's an interesting question, always an interesting question. Right now, to be super blunt about it, your options are build your own browser or work within the-- work with the browser community to try and help navigate that space, or work within whatever they come up with.
HEATHER FLANAGAN: So you mentioned that WebID is still very early days. Is there any story you can tell about the uptake for that? How much traction is it getting?
GEORGE FLETCHER: Well, the proposer is actually one of our attendees.
HEATHER FLANAGAN: Hi, Sam.
GEORGE FLETCHER: And so I think some of it is looking at where's the best place to have that conversation, or maybe best places to have that conversation. Unfortunately, the privacy community group within the W3C doesn't have a whole lot of identity people in it, at least from what I could tell. And of course, the OpenID Foundation or some other organization might not have a lot of current browser people involved.
GEORGE FLETCHER: So I think that's part of our problem at the moment. We don't have a common place where we're all working that we could have some of these more deeper conversations. But Sam has definitely been very open to input into understanding use cases and how does this relate to general consumer use cases versus enterprise use cases versus maybe educational use cases, which might be slightly different as well.
GEORGE FLETCHER: So I think it's really about, how do we start the conversation? I think Google is wanting, instead of having generic storage access level APIs-- and again, this is just George's interpretation from a couple of conversations-- they're looking for, how can we have much more targeted APIs within the browser so there could be a set of-- a suite of APIs for doing identity and a suite of APIs for doing something else as opposed to just generic storage access APIs?
GEORGE FLETCHER: So I think within the browsers themselves, some of that conversation is still going on and what is the best direction to take.
HEATHER FLANAGAN: Going back a little bit to the browser VPN question, so one of the-- I'm going to have some free interpretation of a comment in the chat. You mentioned that the browser VPN was looking more at the uniquely identifiable IP address. Now, a lot of the library and publisher world still relies on IP address authorization models.
HEATHER FLANAGAN: Is this going to-- would this impact that as well? When it's an IP address for an institution, is that unique enough?
GEORGE FLETCHER: Well, lots of thoughts there. One, IP address-based authorization models are probably not the best option these days. I would much more encourage people to move to a mutual TLS if you're doing server-to-server side things. There are open source projects out there that make management of MTLS certificates and automatically rotating them and all of that kind of stuff available.
GEORGE FLETCHER: Verizon Media says Yahoo open sourced one called Athenz, A-T-H-E-N-Z. But I'm sure there are others out there. So that would probably be my first recommendation.
HEATHER FLANAGAN: Wait. Here, here. Unfortunately, we're dealing with a lot of legacy right now.
GEORGE FLETCHER: Totally understand. I think the next piece is, are you really looking at IP authorizations from a browser? Are you authorizing it because the IP address that's inbound is from the local network? I think that question is a little bit interesting for the browser VPNs, and I don't know that I have a direct answer for that topic. Is there a way for the browser to recognize that it's effectively inside a corporate network and not change the-- and not route the traffic through some external identity provider?
GEORGE FLETCHER: Is there a setting for a user to turn it off to enable that sort of on-network authorization? But it's kind of weak. So I don't know that I have an answer for you, but as an authorization model, it's a pretty weak authorization model.
HEATHER FLANAGAN: Do we have other questions? Doesn't look like it.
GEORGE FLETCHER: I think I have one more topic, and then-- actually, two more topics. So one of them is bounce tracking protection-- or prevention. So as we said before, the-- and this is, again, an Apple proposal, but it is dropped into the Safari Technology Preview in version 105 and beyond. And effectively, what it amounts to is if the browser believes that your site is engaged in this sort of bounce tracking mechanism-- So think about it this way.
GEORGE FLETCHER: You're an ad provider. And when the page loads from some hiking.example, it reaches out to ads.com. It redirects to ads.com, who redirects back to hiking.example with a value. And then hiking.example writes that value into the browser on hiking.example. So effectively, it becomes a first-party cookie. But it was a first-party cookie value that was set by the ad provider.
GEORGE FLETCHER: And so then, when you render that page, the site will get that value. It can back channel go to the ad provider and say, what ad should I show? And it could return a URL and you could load it back in the browser. And so this is a way to keep the global ad tracking working amongst these behaviors. So this is what Safari is going after in regards to prevention.
GEORGE FLETCHER: And their current solution is that if they deem that you're involved in bounce tracking, it will automatically rewrite all your cookies with the SameSite equal Strict flag, which as we said in the beginning blows up identity providers, both the RP and the IDP. So this is something to watch. There was also another code dropped that specifically said-- almost making Apple move a little bit away from their machine learning only to basically say, if you're interacting-- if the user is interacting with the site on a regular basis, the stuff-- the cookies keep living and it keeps continuing.
GEORGE FLETCHER: And so they were going to add an explicit way for, even if the user's interacting with the site but it's been flagged as a bounce tracker, then we will set all the cookies to Strict. So this is something, again, it's just in preview. Turn it on as an experimental feature in their Safari Technology Preview build. But this could have a big impact if your IDP or relying party-- if you're doing a bunch of redirects and the redirects have link declarations on them, it could track you.
GEORGE FLETCHER: They do have debug statements, again, in the console log for you to be able to see what happens or see when Safari turns it on. What isn't available today is a way within Safari to explicitly say, hey, I want foobar.com to be flagged as a bounce tracker and then use the browser and see what happens. So if you think about what SameSite equal Strict means is that when the redirect comes from the relying party to the IDP, it sees no cookies.
GEORGE FLETCHER: And today, the only way to see the cookies that the IDP had set would be for the IDP to redirect to itself, because now it's coming from the same site. And they explicitly call that out as a current problem in their current implementation. So if they continue down the path of trying to block this kind of tracking, then the redirect to self may no longer be a work around.
GEORGE FLETCHER: And then, the final thing-- and we've got five minutes, and then this won't take that long-- is basically another proposal from Google called HTTP state tokens. This is from Mike West. And the original documentations that he wrote up are long expired, so I'm not quite sure whether this is continuing or not.
GEORGE FLETCHER: If anybody was involved in any of the work either within the W3C or the IETF around this topic called token binding, for me, the really interesting piece of state tokens was that you may be able to use them as a token binding mechanism. But that's a little bit hard to tell because it doesn't appear that there's much work going on here.
GEORGE FLETCHER: What the reference to the state tokens-- in one sense the navigator is logged in. Proposal referenced them. And basically, the connection there was instead of using a cookie for the authentication state, you would use one of these HTTP state tokens. And that would then represent the authenticated session. And so your authentication sessions are no longer in cookies themselves.
GEORGE FLETCHER: They're in this new state mechanism called HTTP state tokens. And a few people I want to thank, some from Verizon Media, some no longer with Verizon Media, and others from other places. So Filip is involved in the OpenID Foundation certification test group as well as the [INAUDIBLE].. And of course, poor Sam's had his name called out multiple times.
GEORGE FLETCHER: But I appreciate his help. And that's it.
HEATHER FLANAGAN: Great. Well, then I have one question to wrap this up. I had mentioned if there are more questions, we should move to social media, but it sounds like there really needs to be a place where we can continue these conversations. My first thought was that the privacy community group at the W3C might be a good spot, because goodness knows they need more identity people on there.
HEATHER FLANAGAN: But I'm wondering if you have a thought. Where should we keep talking?
GEORGE FLETCHER: That's a great question. I'm not 100% sure. I don't know how easy it is to actually get involved in the privacy community group.
HEATHER FLANAGAN: Community groups are easy peasy to join in. And I'll actually put a link to the privacy group in the chat. You just join.
GEORGE FLETCHER: Well, I know when I went through it and entered my email address, it went to our W3C representative from a corporation perspective, and then someone else had to approve, and then they had to make a recommendation for me to be able to join the group. It was not a very simple process. So I don't know, if your organization has no W3C affiliation, what the mechanism is. But yes, if there is a simple process, that's awesome.
GEORGE FLETCHER: I think for some of us that are involved in multiple of these working groups across the industry, yet another one becomes a little bit-- there is a fair amount of overhead there. But maybe that is the best place to have the conversation. That's where all the browser-makers are for sure. So I think that's a possibility. I don't know how we get identity topics into a discussion for an upcoming call or something like that.
GEORGE FLETCHER: That's one of the things I wanted to work on, is figuring out how to propose some of those kinds of topics. For sure, we'd be happy to host a discussion group within the OpenID Foundation. The things there are-- not all the browser manufacturers are members.
GEORGE FLETCHER: Working groups with the OpenID Foundation are free to join as well. It's just an IPR thing to sign, similar to community group.
HEATHER FLANAGAN: Well, we definitely have work to do. And we're at the top of the hour.
JASON GRIFFEY: We are indeed. Thank you both. Thank you, George. Thank you, Heather. This has been a fantastic discussion. As Heather just said, there's lots and lots and lots of work to be done here. And we hope to be a part of that. Just a reminder to everyone that you will receive an email that will include links to the presentation, including the slides, audio, video, and the chat as well.
JASON GRIFFEY: And there will be a feedback form. We would very much like to hear from you about what you liked, what you did not like concerning this presentation. Thank you all, and I hope you all have a great day.
HEATHER FLANAGAN: Thanks, everyone. I appreciate your time.
Segment:0 .
JASON GRIFFEY: Hello, everyone. Thank you so much for joining us today. This is Jason Griffey. I am the director of strategic initiatives at NISO. And I am so very pleased to have with me today Heather Flanagan and George Fletcher, who will be delivering a presentation on Browser Changes and Identity Federation-- The Impact on Identity Flows. Couple of little housekeeping pieces before we throw over to Heather.
JASON GRIFFEY: The first is you will have two things going on simultaneously. You hopefully can see my slide, and you can hear my voice. If you have any issues with hearing me, it is possible for you to dial in over a telephone. The numbers are there on the screen. And the webinar ID that you will need is at the bottom. If you have any issues as the presentation moves forward, please contact Zoom directly-- support.zoom.us. They will be able to help solve any technical problems that may be going on.
JASON GRIFFEY: And you will also need the webinar ID for that, so please make a note of it in case something goes wrong. A couple of things that everyone always wants to know. The slides be made available? Yes, they will. And the webinar is indeed being recorded so that you can come back and view it later. Shortly after the end of the webinar, you'll receive an email with links and information on how to access all of those things.
JASON GRIFFEY: NISO does a number of educational events throughout the year. We have several coming up in June-- No More Big Deal? Picking and Choosing Titles for Use, Changes in Higher Ed, and 13th annual BISG-NISO Changing Standards Landscape Forum. All of these and further into the year are available at NISO.org/events. We'd love to have you at any or all of the educational events we put on online.
JASON GRIFFEY: We also do a regular newsletter, NISEO IO. That is available online, and you can sign up to have it delivered directly to you with all of the efforts and activities that NISO is involved in. niso.org/niso-io. We'd love to have you as part of that as well. And with that, I am going to go ahead and throw it over to Heather Flanagan, who will introduce George Fletcher.
JASON GRIFFEY: I'm going to stop sharing while she does that and let George pull up his slides. Thank you everyone for being here, and take it away, Heather.
HEATHER FLANAGAN: Great. Thanks. So yes, thanks everyone for joining us today. As Jason noted, my name's Heather Flanagan, and I am, among other things, the program director for SeamlessAccess. SeamlessAccess is a service designed to help streamline the online access experience for researchers using scholarly collaboration tools, information resources, and sharing research infrastructure.
HEATHER FLANAGAN: It's a free service governed by a coalition of five organizations-- [INAUDIBLE],, Internet2, the National Information Standards Organization also known as NISO, who are hosting today, Orchid, and the International Association of STM Publishers. Participants in our various working groups include researchers, service providers, librarians, identity providers, federation operators, vendors, all of the above.
HEATHER FLANAGAN: Our niche is specifically in the federated identity space at that point where an end user needs to find their identity provider. Now, as it turns out, federated identity looks a lot, from a purely technical perspective, like what a cross-domain advertising service looks like. So today's webinar is not actually about SeamlessAccess itself. The SeamlessAccess technical steering committee identified the potential browser changes geared towards cross-domain advertising but therefore also impacting federated identity as an area of interest and possible concern and decided to put together a webinar so that other people can learn about this as well.
HEATHER FLANAGAN: And with that, I'd like to introduce George Fletcher, identity standards architect for Verizon Media and OpenID Foundation board member. George is going to talk to us about changes in the way browsers interact with and support cookies and how that impacts services that rely on cross-domain identity flows. Please post your questions in the chat. We'll get to as many as we can during and at the end of our slides.
HEATHER FLANAGAN: And if we don't get to your questions, please feel free to take this to your favorite social media site. I personally like to keep an eye on Twitter. And we'll continue the discussion there. With that, now I'm handing over to George. Who's still on mute.
GEORGE FLETCHER: Can you all hear me and see my slides?
HEATHER FLANAGAN: Yes, perfect. Thanks.
GEORGE FLETCHER: Good. I took a quick scan through the attendees list and noticed a number of my esteemed colleagues in the identity and federated space. So anything that I misspeak, they can correct. So this is excellent news. And we'll get started. So there's a bunch of different things we want to talk about today, largely-- and you can actually find more information about this as a whole largely within the W3C Privacy Community Group.
GEORGE FLETCHER: There's been a number of browser makers have been sharing about different technologies and different things that we're looking at to help protect users of the internet as a whole and protect their privacy, protect them from, basically, add-targeted profiling and tracking. And Google presented-- Sam got to Google presented a great talk that outlined the problem space at the OpenID Foundation Workshop that was on the 21st of May.
GEORGE FLETCHER: So when those slides get available, you can find them on the website there. It was an excellent summary of the problem space they're looking at. And so a lot of the specifics that we're going to talk about today come out of that mindset of how do we protect the user and stop the sort of tracking behavior that is so prevalent especially within the ad environments.
GEORGE FLETCHER: So we'll start with the SameSite impacts, because those are the ones that are actively rolling out or close to be rolling out, as well as some of the ITP policy impacts as it relates to changes Apple has made in their Safari browsers. And then, the last four things I would say are more future things but are things to be watching and tracking because they could also have an impact on the way identity and federation flows work.
GEORGE FLETCHER: So a quick summary of what is SameSite and what does it mean from a cookie perspective. Effectively, SameSite is another cookie attribute like secure or HTP only, if you're familiar with those. And basically, there's three modes to SameSite. There's Strict, which is really an attempt to allow a site to protect against cross-site request forgery. The cookies that are marked with the SameSite Strict attribute basically will only be sent from the browser if the top-level domain matches.
GEORGE FLETCHER: So if the domain the cookie was written on matches the domain in the browser, then the SameSite cookie equal Strict cookie will be sent. Otherwise, it won't be sent. Some of you, I'm sure, as you hear this will start thinking through what does that mean for my identity flow perspective. And we'll cover some of that as we go forward. SameSite equal Lax is basically-- it it will be sent if the user takes a explicit action.
GEORGE FLETCHER: So you can think of this as I search for something on Google.com, and there was a link, and I clicked that link. That's an explicit user action. So that site, if it had set a cookie as SameSite equal Lax, will get it. But otherwise, it won't be sent. Just browsing and reaching out to that site to grab a URL or an image or something like that without an explicit user action, the cookie would not be sent.
GEORGE FLETCHER: SameSite equal Lax cookies are also sent today on full top level page redirect. So a 302 or a 307, if the cookie's set as lax, the cookie will still be sent. And then, SameSite equals None, basically this is the default behavior of cookies today on the web. So today, if you don't explicitly set a SameSite cookie attribute, then it defaults to None, which is how all the third-party cookies work.
GEORGE FLETCHER: So basically, what the changes are is that you can no longer set a cookie, a SameSite equal None cookie, on a URL that is not HTTPS. So basically, now any domain that you want to have a third party like cookie you work on, that URL must be an HTTPS URL. So those are basically the policy changes of SameSite.
GEORGE FLETCHER: We'll look at what affects-- if you were to set a cookie from an identity flow perspective to Strict, what does that mean? And effectively, this breaks pretty much everything, because in identity federation flow, when you do a redirect, you want to get the identity provider's SSO cookie or authentication state or whatever, and you won't get it if you set that to be strict. Similarly, any cookie that handles nonce or state or a CSRF token prevention mechanism, it's not there.
GEORGE FLETCHER: And then, of course, any sort of chain flows, which we often have a lie and identity federation, they also start to break because you're just converting the role of the intermediate IDP into an RP of the downstream IDP. SameSite equal Lax. Basically, what this causes a problem for is basically iframes.
GEORGE FLETCHER: So within OpenID Connect, there has been a lot of times where people will basically, whether they're using the implicit flow or some other mechanism, they will use an iframe to silently refresh the cookies for the logged in session. And pretty much, no-- if your cookie is SameSite equal Lax, it is not set in an iframe when the iframe is talking to a domain that's other than the top-level domain, which is what you're trying to do in this context.
GEORGE FLETCHER: So that is broken. And then there's some other session management and log out specifications from an OpenID Connect perspective that also start to break when you're trying to do a log out again within an iframe. So iframes become the problem with SameSite equal Lax. The cookies just aren't set. So if you have any identity flows that are working in iframes, this as something to research and investigate.
GEORGE FLETCHER: Another impact of SameSite equal Lax is basically POST based protocol messages. So I know SAML had sort a form. I don't remember what the exact name is. You guys could tell me. But basically, the IDP returns a little bit of JavaScript that form posts to the RP or the Relying Party the data. And we often use that mechanism if the redirect URL itself would get too big.
GEORGE FLETCHER: So this was a way to send much larger payloads. And unfortunately, in that model, any cookie that's written as SameSite equal Lax is not sent when that form posts because it posts without an explicit user interaction, and it's posting to another site. So this basically breaks any of those form POST response modes in both SAML and OpenID Connect.
GEORGE FLETCHER: And then, SameSite equal None, the big impact here is the requirement for the secure flag. So if you're trying to do development testing on a endpoint that isn't running on HTTPS, then that becomes a problem. It's minor here. The really big issue with SameSite equal None is that the expectation is-- in fact, there's actually an-- I don't know, Sam, if you want to drop something in the chat here if you can.
GEORGE FLETCHER: But when I looked through the chrome experimental flags for SameSite, there's actually an option to basically allow UI. And so my expectation here-- this is George's expectation, not something I know-- is that browsers will be looking at this and saying, hey, if you've got SameSite equal None cookies and you haven't visited that site in some period of time, the browser may pop up something that says, hey, you've got these cookies that can be used for tracking.
GEORGE FLETCHER: Do you want to clear them? And now, all of those cookies are explicitly tagged. So where this comes back around-- and I think I have a slide for it, but I'll touch on it right now-- is where this comes back around is that the one way to make iframes work is to set SameSite equal None. But that may have a limited shelf life in the sense of how long it will work.
GEORGE FLETCHER: So in the sense of where is this now, Chrome started rolling this out late February, March timeframe, starting with version 80 of Chrome. They then stopped it due to COVID-19. But you can go into any Chromium based browser and go to the flags page and search for SameSite, and you should get three values. And if you just turn them on, from default to on, you'll get the SameSite behavior and it will make it easy to test your flows to see if things break or not.
GEORGE FLETCHER: So when the change rolls out, the big impact here is that today, cookies default to SameSite equal None. And with this change, they will default the SameSite equal Lax. So all of those implications that we talked about with SameSite equal Lax that were in those previous slides, that will become the default. So effectively, your iframe flows just broke.
GEORGE FLETCHER: Any form POST response mode where you're expecting cookies to follow that reader, the form POST for CSRF protections, those just broke. Now, there is a caveat around that that I'll come to in a minute. So the impacts to authorization servers. Really, the main thing here is, if you're using iframes or if you want a short-term fix, you could explicitly set all of your cookies to SameSite equal None, both the RP and the authorization server.
GEORGE FLETCHER: The bigger, ugly piece here-- and it depends on how much of your traffic comes from Safari-- there are certain older versions of Webkit that if you set-- that don't recognize the SameSite equal None setting. I think I'm remembering this correctly. And so if you try and set it, they will default to SameSite equal Strict. So the two cookie solution is really around-- you may have to write one cookie with no SameSite attribute and another cookie with the appropriate SameSite equal attribute and then, based on your browser, see which one you get and handle it accordingly.
GEORGE FLETCHER: It's pretty ugly. Or you can just basically say, we're not going to support-- our flows will be broken in those older versions of Webkit. So for relying parties, the biggest issue are ones that are either using iframes or using a form post response mode because the default will be Lax, and if you're using top level redirects, the Lax will still work.
GEORGE FLETCHER: The cookies set with SameSite equal Lax will still follow the redirects today. But if you are using iframes or the form post mode, then you definitely want to look at how to handle this. Now, the one caveat or concession that was made on a temporary basis when this started rolling out was the browser-makers decided that if the cookie has been written within the last two minutes, then on the form post, it'll send the cookie.
GEORGE FLETCHER: Now, this is great for most-- for an SSO scenario or a simple sign-in scenario. But if you have to-- It creates an inconsistent experience for users, because if they hit your site and you're like, hey, we'd like you to update your alt email address or your recovery email address, and that process of taking them through that flow takes more than two minutes, then when you redirect, your cookie you won't be sent, and now it will fail.
GEORGE FLETCHER: The CSRF protections will fail, and the user has to start over. Now, that may be a seamless redirect again, but it still is a pain. So I would recommend moving in a direction that doesn't depend on this workaround. But that does impact both relying parties-- that impacts relying parties, which sometimes can be a harder process to get them to roll out updates.
GEORGE FLETCHER: We just talked about this one. I was one slide ahead. Yes. And so basically, here is the slide, as I mentioned coming up, that if you try and set a cookie explicitly to SameSite equal None, this older version of Webkit will basically default it to strict instead, which is a very different behavior.
GEORGE FLETCHER: And so this is ugly. And in reality, the recommended solution-- there's really two solutions. One of them is try and detect all of the Webkit user agents that have this old behavior and manage it that way so that you set a cookie one way if it's an old Webkit. You set a cookie a different way if it's everything else. Or just set two cookies.
GEORGE FLETCHER: And the recommendation I believe from the browser-makers themselves was to use the two cookie method. And so I'm going to stop there and see if there's any questions specifically around SameSite behavior and whether any of that made any sense or was so deep in the weeds that everybody's horribly confused.
GEORGE FLETCHER: Any questions?
JASON GRIFFEY: I don't see any questions in the chat.
GEORGE FLETCHER: OK. We can keep going. So ITP. ITP is basically Apple's Intelligent Tracking Protection, if you're wondering what it stands for. And they've been rolling out enhanced capabilities to this effort over time. And you can go to their Webkit.org blog and you can find these topics on different capabilities from ITP and how this impacts things.
GEORGE FLETCHER: So we're going to talk through about some of what these ITP 2 dot exchanges are. And so the first one with ITP 2.1 was basically that Apple was going to-- they have a machine learning algorithm inside the browser for this. But if the machine learning algorithm determines that your site is tracking users, then basically, if the user doesn't visit your site for 30 days, they will wipe all local storage and cookies.
GEORGE FLETCHER: They'll just be gone. So any sort of persistent cookie you are using, even for first party tracking, could potentially be gone. The next sort of ITP 2 thing was basically, if a persistent cookie is written via JavaScript from one of these trackers, it gets wiped after 24 hours. And also, basically, pretty much third party cookies are disabled in Safari at this point.
GEORGE FLETCHER: So if somebody tries to write a cookie in a third party context, it doesn't get set. With ITP 2.3, they basically shortened the time window for sites that are flagged as trackers. So if their machine learning algorithm determines that your site is a tracking site-- And again, remember that redirects with link decoration, i.e., a state value on the redirect URL or a code on the redirect URL is link decoration.
GEORGE FLETCHER: Then too many of those in the browser get you classified. And there are probably other ways to do it, like if you go to one site and then it bounces to another site to do some things and it comes back and it bounces somewhere else. All of that stuff feeds into their algorithm as to whether you're tracking. So now, in this case, starting in Safari 13, your local storage and your cookies will be wiped if the user hasn't interacted with your site in seven days.
GEORGE FLETCHER: So depending on how long your authentication sessions are, this could have a big impact. So I go to hiking.example, and it redirects me to coolidp.com. I log in. I go back to hiking.example. And potentially, because it looked like that could be a tracking scenario, if I don't visit hiking.example for seven days, all my cookies are gone.
GEORGE FLETCHER: And they don't know that I'm still logged in, even if my session was good for two weeks. If your sessions are only good for 24 hours, then it probably as less of an issue.
HEATHER FLANAGAN: So there's a question on this one.
GEORGE FLETCHER: Great.
HEATHER FLANAGAN: Is this just cookies, or does it include everything in browser local storage?
GEORGE FLETCHER: Local storage. I'm not 100% sure about the separation between the local storage and index DB or those kinds of things. But definitely local storage and cookies.
HEATHER FLANAGAN: OK. And another question. This one is actually from me. Is this purely Safari, or is this across the board with browsers, what ITP 2 is doing?
GEORGE FLETCHER: So this is specific to Safari, though other browsers are doing similar kinds of things. They just all have different rules. So basically, Mozilla has a similar sort of thing, but I think they're their deadline is-- they're still at 30 days. Mozilla uses a-- doesn't use machine learning. They use basically block list white list from disconnect.me. I think Brave is also using a pre-generated block list.
GEORGE FLETCHER: Their settings may be a little more aggressive than Mozilla. In that sense, there's not a standard here in the sense of exactly when things should be cleared from a user perspective or from the local storage cookie perspective. Other questions?
HEATHER FLANAGAN: Nope.
GEORGE FLETCHER: All right. So there are a couple of additional things that Safari is testing. By the way, almost all of these features you can get in the Safari Technology Preview. Just go to their website and sign their agreement and download the Safari Technology Preview. And they have an experimental menu option. I think it's under Developer. And you can basically turn all of these things on and then look at the Java-- look at the console log under Web Inspector, and it will tell you when different things are happening, like when they've set a site to be a tracking site or whatever.
GEORGE FLETCHER: So that can be useful in testing. Not everything is 100% perfect. In certain cases, it's really hard to try and figure out, how do I force a particular behavior in the Safari Technology Preview? But in general, it's definitely helpful if you want to turn on some of these things. Just like in the Chrome flags, you can force the SameSite behavior to be on even though it's not on by default.
GEORGE FLETCHER: So the next set of things. This next one here is, again, a tracking prevention mechanism. So the thinking here is, if the browsers can tell that your IP address is effectively a unique identifying value-- and definitely, jurisdictions across the world sometimes classify IP address as PII-- then the options here are, hey, let's route all of your web traffic through some sort of multiplexer so that many users are coming from the same IP address and you can't use that IP address as a unique mechanism for tracking the user.
GEORGE FLETCHER: And I threw a bunch of links in there from different people about how they want to track this. There's some aspects for this concept of a privacy budget and things of that nature. So you can follow those links once the deck is published. But that's generally the rationale for this kind of behavior. I think the thing that this-- how this impacts identity providers, especially those that are either the identity provider or the authorization server, is that, oftentimes from a security perspective, we need a certain level of information to determine that this is a device we've seen before, this is a browser we've seen before, because that creates a better experience.
GEORGE FLETCHER: Just the other day, I fired up a browser, cleared all of my state, went to log in to Google with a couple of different accounts because I was testing something, and every time I logged in with one of these accounts, I got the challenge of, hey, we're not really sure this is you. Could you please verify your phone number? It's effectively what I would call a second-level challenge to ensure it's really you.
GEORGE FLETCHER: Well, if you lose that kind of environmental data that tells you, hey, this is a browser I've seen before, it's a browser for George, this is a day he normally logs in, all of that stuff, then effectively, you can't tell George from Fred, which is kind of the point of some of these changes from an ad tracking perspective. But from a security perspective and an identity perspective, it's actually a degradation of behavior, because now my experience interacting with the IDP as a user gets much more complicated because the local storage is getting cleared or my IP address is randomly changing or things of that nature.
GEORGE FLETCHER: And so I have less assurance is an identity provider from a security perspective that you're really you, and so I'm going to surface additional challenges to ensure that you are really you. And I think that that aspect of the conversation hasn't really happened within the context of identity and browsers and anti-tracking behavior. And I think it's one of the conversations that we all can-- we who are involved in the identity space can contribute back into this discussion for how do we help protect users from a privacy perspective but don't break their experience on the web and still give them a secure experience.
GEORGE FLETCHER: And it is a bit of a difficult scenario, because how do you separate identity behavior from tracking behavior, which I think is what the browser-makers are struggling with right now. Any questions on this one?
HEATHER FLANAGAN: Looks to be just one. Are there signs that the security and identity teams at browser vendors are able to have a voice in browser changes at their respective companies?
GEORGE FLETCHER: That's an excellent question, and I'm not sure one that I can answer. I think it's a great question. How do we-- how do internal to a company that makes a browser, how do they share this behavior? For certain things-- for certain browsers, a la let's call it a Brave or something like that whose main product is a browser, that may be a little bit less relevant. But from a Google or a Microsoft or maybe even an Apple, I think it's a great question, but I don't have any inside knowledge to know whether those conversations are happening or not.
GEORGE FLETCHER: So there is a ton of text on the next slides. Mostly I just put it in there so people could read it in an offline setting, so I will summarize. So please do not try and read on the screen. I don't normally put slides like this up, but this was just a simple way to put these things together. Fundamentally, the browser-makers do recognize that identity federation is an important aspect of the web.
GEORGE FLETCHER: And so they're looking at how can the browser be more involved in the identity federation flow so that we can separate what is an identity login, an identity flow, from, let's say, a tracking flow. So I think this is the rationale behind this. This particular proposal comes from Apple, John Wilander. And there is another one that I've summarized a little bit-- hopefully, I didn't completely mess it up, Sam, because I know you're listening-- on Web ID, which is from Google.
GEORGE FLETCHER: And I've got a slide for that later. But generally, the concept is, how do the browsers become more-- can they intermediate the login flows in a way that they can know with high assurance that, yes, the user wants to be logged in to site A via IDPP is really the goal. So then, we can do that. So as you see in the very last paragraph, we can't let people just set the status whenever they want.
GEORGE FLETCHER: We have to ensure that the state is logged in can only be set when the browser is convinced that the user meant to log in or the user is already logged in and wants to stay logged in. So here were some suggestions around this. Use something like WebAuthn which the browser is already mitigating. If you're unfamiliar with WebAuthn, it's FIDO2. It's the way to do strong authentication out of a browser using a navigator.api. So you can trigger it through JavaScript.
GEORGE FLETCHER: So that would be a clear sign, one, that the browser could understand that the IDP is challenging the user for a credential. The browser can know that they invoke the credential. The user did accept the credential. It went back. Therefore, this is a trusted login session. Obviously, the redirect-based federated flows are a little bit more complicated.
GEORGE FLETCHER: You could do things like continuously show a browser UI indicating an active logged in session on a particular website, whether that's the URL bar indicator or something else. You can-- the browsers could do things in the sense of protecting the user's privacy, like, hey, you logged in to news.example five days ago, but you haven't been back.
GEORGE FLETCHER: Do you want to stay logged in? And if the user says, no, then what the browser does, it just clear all the cookies in local storage because that's how they clear the session for the user. Of course, that puts us back in that security problem of now we don't-- this is a brand-new browser. How do we know who it is? How do we associate trust and out of the environment for that?
GEORGE FLETCHER: The other piece of this proposal was that there was this concept of, if the user-- this is the last bullet. The user needs to already have the "is logged in" status set for the federated identity provider. And there was a link to this proposal, and I'm sure you can find follow-on doc from the Git repositories.
GEORGE FLETCHER: I highly encourage anyone who's really interested in this to go dig through those and make sure I read this correctly. But the way it read to me is that if I want to log in with Google, then I already have to be logged in at Google for this thing to work, which I don't think is a viable starting place. A user could start at their browser, not be logged into anywhere, want to go do something at a site, see the Log In with Google button, click it, and it shouldn't fail just because they aren't already logged in at Google.
GEORGE FLETCHER: But again, I could have read that wrong, but that's the way it read to me. So again, how does the browser mediate this redirected-based identity federation flow? Actually, I'll do the WebID one and then do more questions. So WebID is a proposal from Google, which is a JavaScript-specific API focused on identity federation flows.
GEORGE FLETCHER: Again, same sort of idea. How do I intermediate? Can we use a browser provided chrome? In other words, the browser creates the window in which the identity flows happen, so they're more involved and can mediate that. And the proposal is trying to leverage as much as possible out of existing standards to make it easier for adoption within relying parties.
GEORGE FLETCHER: Exactly how that's all going to work is still being determined. It's still very early days. And Google's been, like I said at the beginning of this talk, very proactive in trying to work with the identity community on understanding what the issues are. So they presented at the OpenID Foundation Workshop just last week. And I think that there's a good opportunity there to work together to ensure that we can maintain the security of the user while also protecting their privacy.
GEORGE FLETCHER: But again, still early days of this. How this works either in concert with or in place of the proposal from Apple on is logged in is still unclear to me. So any comments or questions here around the browser wanting to disintermediate the login flows?
HEATHER FLANAGAN: Yep. We have two comments. They're not exactly questions, but they might be worth discussing. One of them is that a lot of these proposals assume that there is only a single IDP, which is definitely not necessarily the case.
GEORGE FLETCHER: Well, so I don't-- I think it's less about a single IDP. I think it's about, for a given user at a given point in time, they are logged into a site with one IDP. So in other words, it's unusual to log into hiking.example.com at the same time in the same browser with three different IDPs. And so it's not trying to say that there's only a single IDP.
GEORGE FLETCHER: If you get to the relying party and they say, hey, we want to support sign-in with Google and sign-in with Facebook, or in the federated education space where you might have hundreds or at least more than hundreds of IDPs, the aspect of which one-- how does the user choose which IDP to start with on the site is a little bit outside the scope of what they've been targeting so far.
GEORGE FLETCHER: It's just, when you start that identity federation flow, what are the impacts of these changes for what the user chose?
HEATHER FLANAGAN: It's not entirely unusual to be logged in at multiple IDPs in some use cases when you're trying to get to some scholarly communications material and you have affiliation with three separate universities. Not at all uncommon, say, in the Boston area or in parts of California. And they'll just try and flip from one to the other to see what's going to get me the most access to the material.
GEORGE FLETCHER: Right. And so I don't think any of these flows would stop the-- so I think that's an interesting use case and we should add it to the list. Effectively, what this amounts to-- and some people consider this to be a sort of tracking behavior that they want to prevent. I've seen-- there are web pages you can go to that basically will try every sort of IDP out there and ask you-- and see if they can silently log you in to any of those sites because of SSO.
GEORGE FLETCHER: And that's a little bit the use case you're describing here, is I go to a relying party or a service provider, and the service provider sends back some JavaScript that says, I'm going to start iterating through the 1,500, 200 top IDPs that this user may be logged into right now and see if they're logged in, and if they are, see if that will get them seamlessly into my site. That sort of redirect checking out of an iframe or something like that would almost assuredly turn on the anti-tracking-- or trigger the anti-tracking behavior in Safari and potentially get you labeled as a tracking site.
GEORGE FLETCHER: And then you run into these additional ITP rules. So that behavior may be impacted by these kinds of things. I think as far as it relates specifically to is logged in or the WebID stuff in the sense of the browser understanding where the user is logged in, it would be fully expected that you as a user would be logged into multiple IDPs at the same time. It's just, is that logged into the IDP disjointed from where the IDP has been used for a relying party, and how is that model represented?
GEORGE FLETCHER: And I haven't seen anything about how that sort of model gets represented within the browser. Are they disconnected with loose affiliations, or is it more tightly bound where they're tracking who you're logged in at specifically one-to-one for a relying party or a service provider?
HEATHER FLANAGAN: So we have a couple other questions. One is, for the is logged in proposal, is that purely Safari, or has that been accepted for implementation by any other major browser vendors?
GEORGE FLETCHER: Right now, it's purely Safari, though I believe it is available in the Safari Technology Preview if you want to play with it. It's a little bit unclear how they're determining that this logged in state in IDP or in session are trustworthy. But I believe John has dropped the code for that feature in Safari.
HEATHER FLANAGAN: So another person points out that is logged in and WebID would both restrict the authentication methods that we can deploy which could make it a little hard to develop new authentication methods.
GEORGE FLETCHER: So I think that one-- I think we have opportunity at least on the WebID one to work with Google and the browser-makers on that proposal. What does it mean when I want to do an identifier first flow, and in this particular context I want to use WebAuthn, but in that other context, I don't on a completely different device? And I think identity providers must have the ability to manage those flows.
GEORGE FLETCHER: Hey, somebody's been-- we saw unusual activity on your account. We've flagged you that you need to re-verify, change your password, do whatever. The identity provider has to still be in control of the actual UI that's rendered. So I think in the WebID proposal, it's more about the browser would open a special window that still has a browser-like tab in it.
GEORGE FLETCHER: It still has an HTML renderer and JavaScript and CSS renderer in it. But it's especially browser chromed, and the IDP can run all of their flows through that. And then, when they're done and it's successful and they're redirecting back to the relying party saying, OK, the user's logged in, then the browser could detect that transfer of control and deal with the state.
GEORGE FLETCHER: In some cases, at least in one of the proposals I've seen related to WebID, if the browser doesn't believe your IDP is trustworthy, they may give the user an additional challenge to say, hey, are you really sure you want to log in from this IDP to that site? But again, still lots of-- nothing set in stone here. Still lots of opportunity to work together to try and find something, again, that I think protects the user, protects their security, and doesn't negatively impact their being tracked across the web.
HEATHER FLANAGAN: It will be an interesting question as to whether the browser vendors themselves are going to play by the same rules that they'll be applying to other folks.
GEORGE FLETCHER: Yes. I think that's an interesting question, always an interesting question. Right now, to be super blunt about it, your options are build your own browser or work within the-- work with the browser community to try and help navigate that space, or work within whatever they come up with.
HEATHER FLANAGAN: So you mentioned that WebID is still very early days. Is there any story you can tell about the uptake for that? How much traction is it getting?
GEORGE FLETCHER: Well, the proposer is actually one of our attendees.
HEATHER FLANAGAN: Hi, Sam.
GEORGE FLETCHER: And so I think some of it is looking at where's the best place to have that conversation, or maybe best places to have that conversation. Unfortunately, the privacy community group within the W3C doesn't have a whole lot of identity people in it, at least from what I could tell. And of course, the OpenID Foundation or some other organization might not have a lot of current browser people involved.
GEORGE FLETCHER: So I think that's part of our problem at the moment. We don't have a common place where we're all working that we could have some of these more deeper conversations. But Sam has definitely been very open to input into understanding use cases and how does this relate to general consumer use cases versus enterprise use cases versus maybe educational use cases, which might be slightly different as well.
GEORGE FLETCHER: So I think it's really about, how do we start the conversation? I think Google is wanting, instead of having generic storage access level APIs-- and again, this is just George's interpretation from a couple of conversations-- they're looking for, how can we have much more targeted APIs within the browser so there could be a set of-- a suite of APIs for doing identity and a suite of APIs for doing something else as opposed to just generic storage access APIs?
GEORGE FLETCHER: So I think within the browsers themselves, some of that conversation is still going on and what is the best direction to take.
HEATHER FLANAGAN: Going back a little bit to the browser VPN question, so one of the-- I'm going to have some free interpretation of a comment in the chat. You mentioned that the browser VPN was looking more at the uniquely identifiable IP address. Now, a lot of the library and publisher world still relies on IP address authorization models.
HEATHER FLANAGAN: Is this going to-- would this impact that as well? When it's an IP address for an institution, is that unique enough?
GEORGE FLETCHER: Well, lots of thoughts there. One, IP address-based authorization models are probably not the best option these days. I would much more encourage people to move to a mutual TLS if you're doing server-to-server side things. There are open source projects out there that make management of MTLS certificates and automatically rotating them and all of that kind of stuff available.
GEORGE FLETCHER: Verizon Media says Yahoo open sourced one called Athenz, A-T-H-E-N-Z. But I'm sure there are others out there. So that would probably be my first recommendation.
HEATHER FLANAGAN: Wait. Here, here. Unfortunately, we're dealing with a lot of legacy right now.
GEORGE FLETCHER: Totally understand. I think the next piece is, are you really looking at IP authorizations from a browser? Are you authorizing it because the IP address that's inbound is from the local network? I think that question is a little bit interesting for the browser VPNs, and I don't know that I have a direct answer for that topic. Is there a way for the browser to recognize that it's effectively inside a corporate network and not change the-- and not route the traffic through some external identity provider?
GEORGE FLETCHER: Is there a setting for a user to turn it off to enable that sort of on-network authorization? But it's kind of weak. So I don't know that I have an answer for you, but as an authorization model, it's a pretty weak authorization model.
HEATHER FLANAGAN: Do we have other questions? Doesn't look like it.
GEORGE FLETCHER: I think I have one more topic, and then-- actually, two more topics. So one of them is bounce tracking protection-- or prevention. So as we said before, the-- and this is, again, an Apple proposal, but it is dropped into the Safari Technology Preview in version 105 and beyond. And effectively, what it amounts to is if the browser believes that your site is engaged in this sort of bounce tracking mechanism-- So think about it this way.
GEORGE FLETCHER: You're an ad provider. And when the page loads from some hiking.example, it reaches out to ads.com. It redirects to ads.com, who redirects back to hiking.example with a value. And then hiking.example writes that value into the browser on hiking.example. So effectively, it becomes a first-party cookie. But it was a first-party cookie value that was set by the ad provider.
GEORGE FLETCHER: And so then, when you render that page, the site will get that value. It can back channel go to the ad provider and say, what ad should I show? And it could return a URL and you could load it back in the browser. And so this is a way to keep the global ad tracking working amongst these behaviors. So this is what Safari is going after in regards to prevention.
GEORGE FLETCHER: And their current solution is that if they deem that you're involved in bounce tracking, it will automatically rewrite all your cookies with the SameSite equal Strict flag, which as we said in the beginning blows up identity providers, both the RP and the IDP. So this is something to watch. There was also another code dropped that specifically said-- almost making Apple move a little bit away from their machine learning only to basically say, if you're interacting-- if the user is interacting with the site on a regular basis, the stuff-- the cookies keep living and it keeps continuing.
GEORGE FLETCHER: And so they were going to add an explicit way for, even if the user's interacting with the site but it's been flagged as a bounce tracker, then we will set all the cookies to Strict. So this is something, again, it's just in preview. Turn it on as an experimental feature in their Safari Technology Preview build. But this could have a big impact if your IDP or relying party-- if you're doing a bunch of redirects and the redirects have link declarations on them, it could track you.
GEORGE FLETCHER: They do have debug statements, again, in the console log for you to be able to see what happens or see when Safari turns it on. What isn't available today is a way within Safari to explicitly say, hey, I want foobar.com to be flagged as a bounce tracker and then use the browser and see what happens. So if you think about what SameSite equal Strict means is that when the redirect comes from the relying party to the IDP, it sees no cookies.
GEORGE FLETCHER: And today, the only way to see the cookies that the IDP had set would be for the IDP to redirect to itself, because now it's coming from the same site. And they explicitly call that out as a current problem in their current implementation. So if they continue down the path of trying to block this kind of tracking, then the redirect to self may no longer be a work around.
GEORGE FLETCHER: And then, the final thing-- and we've got five minutes, and then this won't take that long-- is basically another proposal from Google called HTTP state tokens. This is from Mike West. And the original documentations that he wrote up are long expired, so I'm not quite sure whether this is continuing or not.
GEORGE FLETCHER: If anybody was involved in any of the work either within the W3C or the IETF around this topic called token binding, for me, the really interesting piece of state tokens was that you may be able to use them as a token binding mechanism. But that's a little bit hard to tell because it doesn't appear that there's much work going on here.
GEORGE FLETCHER: What the reference to the state tokens-- in one sense the navigator is logged in. Proposal referenced them. And basically, the connection there was instead of using a cookie for the authentication state, you would use one of these HTTP state tokens. And that would then represent the authenticated session. And so your authentication sessions are no longer in cookies themselves.
GEORGE FLETCHER: They're in this new state mechanism called HTTP state tokens. And a few people I want to thank, some from Verizon Media, some no longer with Verizon Media, and others from other places. So Filip is involved in the OpenID Foundation certification test group as well as the [INAUDIBLE].. And of course, poor Sam's had his name called out multiple times.
GEORGE FLETCHER: But I appreciate his help. And that's it.
HEATHER FLANAGAN: Great. Well, then I have one question to wrap this up. I had mentioned if there are more questions, we should move to social media, but it sounds like there really needs to be a place where we can continue these conversations. My first thought was that the privacy community group at the W3C might be a good spot, because goodness knows they need more identity people on there.
HEATHER FLANAGAN: But I'm wondering if you have a thought. Where should we keep talking?
GEORGE FLETCHER: That's a great question. I'm not 100% sure. I don't know how easy it is to actually get involved in the privacy community group.
HEATHER FLANAGAN: Community groups are easy peasy to join in. And I'll actually put a link to the privacy group in the chat. You just join.
GEORGE FLETCHER: Well, I know when I went through it and entered my email address, it went to our W3C representative from a corporation perspective, and then someone else had to approve, and then they had to make a recommendation for me to be able to join the group. It was not a very simple process. So I don't know, if your organization has no W3C affiliation, what the mechanism is. But yes, if there is a simple process, that's awesome.
GEORGE FLETCHER: I think for some of us that are involved in multiple of these working groups across the industry, yet another one becomes a little bit-- there is a fair amount of overhead there. But maybe that is the best place to have the conversation. That's where all the browser-makers are for sure. So I think that's a possibility. I don't know how we get identity topics into a discussion for an upcoming call or something like that.
GEORGE FLETCHER: That's one of the things I wanted to work on, is figuring out how to propose some of those kinds of topics. For sure, we'd be happy to host a discussion group within the OpenID Foundation. The things there are-- not all the browser manufacturers are members.
GEORGE FLETCHER: Working groups with the OpenID Foundation are free to join as well. It's just an IPR thing to sign, similar to community group.
HEATHER FLANAGAN: Well, we definitely have work to do. And we're at the top of the hour.
JASON GRIFFEY: We are indeed. Thank you both. Thank you, George. Thank you, Heather. This has been a fantastic discussion. As Heather just said, there's lots and lots and lots of work to be done here. And we hope to be a part of that. Just a reminder to everyone that you will receive an email that will include links to the presentation, including the slides, audio, video, and the chat as well.
JASON GRIFFEY: And there will be a feedback form. We would very much like to hear from you about what you liked, what you did not like concerning this presentation. Thank you all, and I hope you all have a great day.
HEATHER FLANAGAN: Thanks, everyone. I appreciate your time.
Form Title Download
Video
Transcript
Form Title Bookmark
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Form Title Share
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Form Title Accessibility and Keyboard Shortcuts
The cadmore media player is a professional video and audio player experience designed to deliver media as well as relevant transcript, segmentation, and metadata. On the screen is a traditional html video player with buttons such as play, pause, forward, captioning, language and play speed selection and more. Adjacent to the video player are generally tabs, one of which shows a scrolling transcript of the video and the other shows any segmentation of the media, sometimes referred to as chapters. At the top of the video is a menu bar containing an Explore button and Tools button. The Explore button allows you to dig deeper into the video by opening up an explore dialog which contains tabs for a visual navigation of the video using thumbnails, an about tab which contains rich metadata about the media, a segments tab which contains further information about the video, and a related tab which contains links to other media related to this media. The tools button opens a menu with options for sharing the media on social media, creating bookmarking links, creating embed codes for your website, generating citations, and more.
Keyboard Shortcuts
Keyboard shortcuts only work while you are in forms mode. By entering forms mode, you will be able to quickly access portions of the media player with single key commands.
Spacebar: Play/Pause Toggle
I: Info Menu,
O: Tools Menu
T: Transcript Tab,
S: Segments Tab
F: Forward 15,
R: Rewind 15
L: Languages,
P: Playspeed
M: Mute Toggle,
V: Volume Bar
N: Video Only Toggle,
B: Full Screen Toggle
C: Captions Toggle
Escape: Closes dialogs and menus / Exits Player
Z: Next Transcript Chapter
X: Previous Transcript Chapter
Q: Next Transcript Paragraph
W: Previous Transcript Paragraph
Entire Media
Segment(s)
Custom Clip
Start At:
End At:
Embed Size
-
You Size - Responsive
-
We Size - Responsive
-
Picture Overlay Popup
-
400 x 225
-
512 x 288
-
400 x 700
-
768 x 1024
-
1024 x 512
-
1280 x 608
Form Title Cite
No citation provided.
Info
Segments
Related
Thumbnails
Exit Clip Mode
You have requested to see a portion of the video outside of the clip.
Click OK to switch to the full video or click if you would like to stay inside the clip. You can always go back to the clip with Tools and Clip Mode