Amy: really big - one thing to note is that they didn't do the s&p questionnaire yet but they do have a threat model document. Probably a good idea to fill it out?

Tess: yes - it's to prod them to have those thoughts. so if they've already done the work then filling out the questionnnaire should be easy for them.

Amy: i couldn't map the things they've comment into the s&p questionnaire... They also said they want our feedback on the problem space more than the solution...

Tess: it's kind of tricky... part of the design reviews is an implicit assumption that the problem you're trying to sovle is worth solving... so we tend to focus on the how. this is a bigger picture question.

Tess: the web is littered with previous attempts to solve things in this space. some of them are reasonably successful and some of them less so. given the fact that there is so much prior art - it does seem prudent that someone who is trying to do this tell us why this is going to be different this timne. why previous solutions didn't work...

Peter: they are looking at how existing systems are breaking given changes in the browsers...

Peter: someone should look at the history.

Dan: I'm not sure the is a right way. "identity" is a very philosphical concept, very slippery notion. What do people mean.. there are so many edge cases, it's such a complicated topic, and a human thing.. mapping this ill defined social construct onto technology is not very .. possible.

Peter: scope of this issue is there are existing systems, openID, SAML, and with other changes with third party cookies and whatnot some of the capabilities of these systems are breaking More specifically how do we continue with the improvements in privacy without breaking existing identity systems.

Amy: by inserting the browser into the flow..

Peter: some examples of monkeypatching other things.. fenced frames

Rossen: a good one to take to a dedicated discussion with additional prep ahead of time. Either as a separate breakout or f2f. Aligned with Peter. It has a great summary of a lot of the pain points, it is doing a good job of staying as neutral as possible and focussing on technical challenge and solution. We should give it time and provide additional feedback.

Dan: I'm up for a separate breakout

Peter: figure out next week and invite sam

Rossen: we should probably have a session ahead of time that will focus and get us on the same page, so if we want Sam as part of the discussion we will be ready. That can be during the face to face.

Dan: that sounds different than one of our two person breakout

Present: Dan, Tess, Peter, Amy, Rossen, Lea Guests: Sam Goto, Ken Kaan, Alex Russell, Kastuba Govind, Majid, Christ Wilson, Heather Flanagan, Michael Knowles, Yi Gu, Majid Valipour, Kaan

Dan: circulated notes from f2f. We were curious about this and have a back and forth.

Rossen: one of the topics was how does WebID fit into the overall umbrella of efforts around identity?

Dan: it's a big topic. Everyone has some battle scars from something to do with digital identity, so when something comes up about that it raises a few eyebrows. It has the potential to touch every single piece of the web platform. That's why we're trying to give it a lot of energy and try to understand it so we give you some value.

Sam: thanks for taking this on. We apologise for verbosity and lack of clarity with a massive amount of documents. This feels like a big project, and a massive stream of dead bodies in the past. WebID was formed as a preservation effort, looking at how other browsers were moving and how Chrome was intentding to move to a more privacy oriented world, and how some of that was in conflict with federation. General observation that federation was something we'd want to have in the future. Alternatives are usernames and passwords and native applications. Anchored itself into this preservation effort, federation is very good, better than usernames and passwords. Let's find ways to get ourselves out of the existential threat to federation as browsers are moving towards mor eprivate things. That's the overall contet. We started to understand more some of the breakages of federation, as they are locking down third party cookies, certain aspects of federation break. There's a sequency art of understanding what's going to break when 3p cookies go away and being very pragmatic and finding alternatives ot the things that will break. A lot of the things federation was built on are also the things being abused by tracking. What I go over in the explainer is the classification problem. A problem that browsers cannot tell the difference between federation and tracking. They are both using the same low level primtiives. iframes, 3p cookies, redirect and top level navigation. The first order has been how to tell these things apart so we can apply different policies. Let's continue to tighten up the low level primtives like iframes and 3p cookies and redirects, and offer high level alternatives that make a tradeoff for the browser to apply identity specific policies. That was the overall context in which this project forms. Early on attempt to preserve federation so it doesn't go away with 3p cookies. Lead us to high vs low leve primitives.

Dan: from our discussion last week, I wanted to drill down on this statement that 3p cookies being deprecated or no longer working doesn't allow for federation. All the browsers I use have 3p cookies turned off, an option to turn it off, I regularly log into services with other services. I use medium where I'm logged in via twitter, dev.to via github. In those cases identify federation seems to be working. What is perceived as not working when 3p cookies are off? The specific things that are not working?

Sam: meta point - generally understood that breakages of 3p cookies in federation are substantially smaller than when link decoration gets tidied up. Not something we expect to be an existential threat. Most things can fall back to other mechanisms. One of the challenges we expect federation to evolve as 3p cookies go away is things to look like redirect and link decoration so we may corner ourselves. It's why you'r enot feeling a massive amount of tension - there isn't one, the things are light. They're not zero. In the link it enumerates the things we expect to break. Sprinkles over social login and some enterprise use cases. Button personalisation is a good example - when they know your name and profile pic. iframes and 3p cookies. Other thing, less sprinkle, is session management. The ability to log yourself out of all the rps you have logged into. More for enterprise than consumers. Things like refresh tokens too are something we're learning. Going around the industry asking for things that are going to break when 3p cookies go away, those are the hands raised. This is the use case we want to preserve.

https://github.com/WICG/WebID/blob/main/cookies.md

Kaustubha: ITP and ... they have heuristics, Safari has it in an earlier version, I tried digging through and didn't see a mention of this being removed, if clicking on signing invokes a popup and user interacts with popup then the popup gets access to the cookies and you can communicate that back.. in the case of safari and firefox they have heuristics to ensure that federated login keeps working.

Dan: what are the mechanisms being proposed?

Sam: we're going through and understanding all of the surface area, low level primtives, every single one that federation uses and trying to come up with alternatives. 3p cookies and iframes. What makes it more broken is top level navigations and post messages across sites. If you use federation for the most part it's a cross-site communcation. You get redirect to twitter, from eg. medium, twitter gets 1p cookies, you log into twitter, twitter asks do you want to allow medium to know who you are, then use a post request on twitter across to medium.com. That is a cross site communication channel like 3p cookies and iframes in popups. This is a uncontrolled cross site comms channel that allows one origin to talk to another in an uncontrollable fashion, and to exchange things like global identifiers, when you log into medium with twitter medium is getting access to your twitter account or any other global identifier like your email. Having access to these it can build it sown profile and also join that profile with someone else. Medium can take all your articles read and sell that to NYTimes. if you log into NYTimes with twitter both can join your twitter handle as the key and build a larger profile. That constitutes uncontrolled cross origin comms. What we imagine is all thes elow level primtiives, post messages etc, are indistinguishable from tracking. Trackers go to this after 3p cookies being blocked. We're imagining high level apis as opposed to general purpose api like top level navigation or iframes. High level apis that allow comms to be done with IDP in a way a browser can reason over it. There are only so many protocols for federation, OIDC being the largest. It is not inconveiveable for a browser to enumerate, OIDC, SAML.. all these are interoperable, so browser can control that channel and gather the users consent as the users are running into trouble oversharing information. ... tl;dr - replace window.location.href or form.submit with a credential manager api like navigator.credentials.get that makes the brokering between ther elying party and IPD in a channel that is well understood and controlled.

Dan: what's to stop those parties having that out of band comms in any case?

Sam: that's a good question. We cannot once you have that initial identifier exchanged there's nothing to preven them from colluding. The point is to make sure that first connection, exchange, is the browser gathering enough user understanding and consent such that they can feel comfortable knowing that collusion could happen. The other thing is for collusion to happen at scale it becomes observable. If twitter as an IDP provides a service for RPs saying here's how you can dereference your global identifiers, that becomes known, the web as a whole can see this is where they are colluding. While the browser cannot enforce that offline collusion it can make it observable.

Dan: point of clarity - in this world, the browser would prompt the user for 'would you like to be identified through this federated approach'? We're trying to balance security & privacy & fingerprinting concerns, ensuring that, I go to site xyz.com and I don't want that site to know that I am logged in or have an identity on github.com or twitter.com. Is that encompassed in your model? that everything is under user control in terms of.. even allowing that site to know informatin that could let them know that I participate in this other identity that is federated?

Sam: yes, absolutely. As a privacy-forward api its preserving that confidentiality of your status with your IDP as you go through websites. We would protect. That is how federation works today - if you are on medium and you click s ign in with twitter you get redirected to twitter. If you're logged out of twitter it does a page auth. After you consent then you get redirected back. An RP today with redirects doesn't get to learn that bit of your status on twitter unless twitter does it. Which isnt' the case for most of the big consumer IDPs.

Dan: what we're trying to focus on is more the thinking about the TAG design principle 'safe to browse'. You could receive a link to any website.. limiting the amount of damage when someone clicks on a link is one of the core design principles.

Sam: 100% in aligment. Recently ran into this personally. I had comment widgets on my blog, I didn't know I was imposing on the readers of my blog telling your IDP that you were reading my blog. I didn't know I was imposing that by sending people link to my blog, they were paying the price of their IDP knowing they were reading my blog without your consent.

Dan: this has been thrown at different identity schemes - a few years ago in the UK the NHS decided to put facebook like buttons on every single page of their website ,including if you were researching symptoms a disease, whether you were interacting with the button or not facebook could correlate that information back. Was all written up. Exactly that. Good to hear it's on your mind.

Sam: a couple of philosophical things - we've been asking ourselves the role of the browser when it comes to ID. We have drawn very cleary privacy and security that the browser should pull for itself. Between ID providers in a secure and private way, all clear. but whether a browser should b eopinionated about intrusiveness or UX. What are the principles that one should use to make an asssessment over intrusiveness of UX. What are the principles that decide if a notifications api is put behind a user gesture. Or starting a download behind a gesture? or a Webauthn flow? Popup blocker? What is the principle that made us say you can only window.open if you have a user.. aside from privacy and security they are all intrusiveness consequences. Any guidence?

Dan: in the design principles we have .. this has come up on a few reviews .. certainly part of safe to browse, and in security and privacy self.

Tess: a couple of others. Meaningful user consent for dangerous or powerful actions. All three documents - ethical web, design principles, and security & privacy questionnaire touch on this, though not under a single heading.

Dan: one thing that comes to mind is the discussion we had about the clipboard api. The view in the TAG when we discussed this was a user gesture or affirmative user action of some kind must take place in order for the webpage to gain access to the clipboard. Whereas that information might be available to a native app, coming back to safe to browse, there's an expectation of more safety when it comes to running in the web context. Between ethical web, design principles, and security and privacy we do address some of those. We'll raise an issue to discuss more clarity on that.

Sam: yes, looking for guidence there. Hadley mentioned some of this. Some may be percieved as abusive or intrusive . Wondering where to draw the line there.

Dan: especially because this could be construed as trusted UI. Any time you have trusted UI ncluding things like permission prompts we see people in the wild gaming that system. The famous screenshot of the webpage that says a popup okay with notifications and an arrow pointing to it saying prove you're not a robot by clicking okay.

Sam: the notification api is the best to derive principles from. None are easy questions. Struggling with the ossification problem . Problem you get as you trade genralisation to specialisation with high level apis. By browser being opinionated about the transaction the exchange of information between RPs and IDPs. There are fewer browser engineers than idnetity people. Whath todya is done by an army of facebook/google/etc engineers will be done by fewer in the future. The mor ethe browser pulls for itself in terms of UX the more it strangles innovation and accessibility. We're trying to minimise that to have our privacy and security goals. We don't know an answer but want to see ifthere's precdence.

Dan: clarify ..? worried about the UX becoming too ..?

Sam: concrete example - in authentication, Basic Auth. Browsers invented an HTTP header. that has never been use because it's faster to innovate in user land than browser land.

Dan: web payemnts more recent - struggles because of its advantage that it provides the payment UI in a very single way that is not customisable. That's both an advantage but from a service designer perspective a disadvantage. You can't differentiate as easily.

Sam: we imagine progressive disclosure of identification - to pull as little as we can for ourselves, but have that as the starting point. Things we believe are common between federated auth. A numeric identifier, first name, last name, email, etc. To have that as the things the browser can be opinionated about, but very quickly open into a web view like feature that enables an IDP to offer more things. But to be opinionated on that very first instance. I just wanted to give you a sense of the struggles here. We have to opine on privacy & security but by doing so we're also struggling innovation. As opposed to basic auth, we expect that a lot of the other leaky ways you can do cross site comms can be tightened up and that's going to drive demand for the safer way. IDPs and RPs are going to use the weakest link, but as browsers are tightening up every link that becomes the most streamlined way to do federation o the web.

Dan: hw can we guarantee that this new system enables anybody to become an IDP and also doesn't enable spammy IDPs and bad actors? Two conflicting requirements. What we don't want in the web is we don't want in place a system where only large orgs can become IDPs. I should be able to provide my own IDP facilty on my blog. Anybody should be able to take advantage of that without having to register or become part of an allow list.

Sam: this is the NASCAR flag problem. We have never as an industry been able to make progress on this. For the most part for consumers IDPs are not interoperable. THey don't interoperate with one another. Email is the opposite. SMPT and POP interop. IPDs don't today. it's not th einitial pull for webid, but a positive unintended consequence, that by being opinionated by how that initial thing gets exchanged in browser land you're forcing them to interop with one another. You're in a much better position to decouble identity providers. Not only a technical problem, also economic. That initial point of interop is one step forward.

... Also.. we're planning to do a workshop on WebID in a couple of weeks, May 25/26 after PrivacyCG f2f. Browser engineers, and IDPs, where they stand on this problem. All invited.

... TAG is uniquely positioned - to look at all browsers at the same time. You can see what we cannot see. You can see how firefox positions itself, Edge, Chrome, and find commonalities. Be specific about versions. We were doing approximations, but we could use some guidence in helping us understand how browsers are evolving to a more private web.

Dan: I don't think we have privileged knowledge.. we try not to operate with privileged knowledge about the internal workings of different browser groups. we do put a high value on interoperability. That's one of the first thing swe look at in review process. What's the multi stakeholder buyin? Is it one browser engine? Something with multiple parties engaged? Looked to us like there were good signals wrt to WebID. Also look to see published standards positions.

... If there are issues with that we will comment. We don't necessarily.. it's a red flag. We can't stop work. We will raise lack of multi stakeholder support. If things move into a WG with W3C process you have to demonstrate multiple implementations. We see it as part of our guidance to push as muc has we can to get people to talk to each other.

Rossen: to me stands out as one of the much better well organised proposals in terms of how much prior leg work brought to this issue. This highlights how huge of an uptaking this is and I'm looking forward to see if this is going to be covered in this one reivew. This is such a huge undertaking. Curiosu to see how and where this goes. The highlight of prior art and transparency to the process is really well organised for this review. Great job.

Dan: we discussed this a lot during our discussion.. referenced everything

... appreciate being able to have this discussion. We're going to come back to this and try to provide further value. And address the issues you have raised on this call. If you have further points you'd like to raise with us, put them on our issue.

Sam: appreciate the time, we'll take the feedback seriously, I'll try to articulate better the things we're struggling with in the issue for the review. To Rossen's point, we expect this to be a decade long project not a quarter long project. We want to know if it's directionally correct, not a spec to bikeshed on.

Rossen: What is the expectation of this particular review, you answered it. This is the right direction, obviously not the last review.

Dan: thanks everybody!

Curated comments from whereby chat:

[Heather Flanagan] This might be of interest: this is a list of issues put together by the OIDF browser interactions group. The items noted as being impacted specifically by 3p cookies are tagged: https://github.com/IDBrowserUseCases/docs/issues

[Kaustubha Govind (Chrome)] https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage_Access_Policy#storage_access_grants See "Temporary Compatibility Fix: Automatic Storage Access for Popups" on https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/

[Heather Flanagan] It's tricky because it's not always the user's choice. I'm thinking of examples in federal government where they are explicit that they are tracking All The Things for their users.

[Alex Russell] should point out that the benefit of putting that in trusted UI and using our long-agreed promise-based request pattern allowed browsers to build trust mechanisms about that sort of thing that is, the work we (the TAG) did back in '14 and '15 on this enabled exactly what we hoped it would

[Heather Flanagan] https://github.com/WICG/WebID/blob/main/meetings/2021/25-26_May_2021.md

Amy: bundling identity with credentials

Hadley: talking a lot about the problem but I'm missing the user need.

Amy: I get an idea that it's about 3rd party cookies going away so it's about federated login...

Hadley: it would be nice to have it spelled out.

Dan: what breaks without 3rd party cookies?

Peter: SAML doesn't require 3rd party cookies but the logout is fragile - and some solutions people have come up with iframes... fragile. Flourishes and add-ons e.g. embedding your github identity into dev.to so it skips that step - that requires a 3rd party cookie.

Dan: But maybe I don't want Dev.to to know what my github ID is...?

Peter: once you've logged into github via dev.to then they can cache the information but until you've done that login why do they have access to that information? Fundamentals of these systems aren't broken, other aspects.. single logout issue is more complicated but there are other solutions. They're driving towards something where federated identity is moderated through the UA, and I'd like to see something like that.

Dan: that could allow your UA to display.. you go to dev.to, your UA says this thing accepts 'WebID' based logins from github would you like to use your github identity? If I select no dev.to is none the wiser. If I select yes then there's an interaction.

Peter: I don'nt want to stop the work, the goal is a good goal. Not sure if all of this is justified

Hadley: agree with both. I like anonymity on the web. But aware that if I'm on a reputable site that I don't go to often and it gives me the usual 'would you liked to log in with facebook etc' I'll make a new account. If It said 'hi Hadley would you like to log in with your google account' I'm more likely to continue. A UX flow thing. If you have an interest in keeping people using your ecosystem I can understand that you'd wantthis

Peter: dark pattern

Dan: having it mediated by the UA could make it less of a dark pattern

Hadley: definitely

Dan: I don't know if we can say federated login is a dark pattern

["Federated Dark", the new film from Christopher Nolan]

Peter: the dark pattern is enticing you to bind your identity on this site to your facebook/google/etc

Tess: distinctions between federated login providers where the purpose is to join your identity across sites, vs other login providers whose goal is not to do so. One problem with status quo is that user agent cannot distinguish between the two. The threat of signing in with facebook is real. If there was an equivalent sign in with Tor kind of thing where you knew they won't join identity across site... if the user is concerned about the kind of identity joining, how do you tell the difference? The mediated variants are trying to address that, where the federated login provider can't reuse the same thing across sites because the browser introduces some kind of complexity to it. There are existing federated identity providers that try to mitigate this today. How does the browser know that they're doing that well? without being involved in the process. If you involve the browser in the process of doing the differentiation between the identities then the browser knows the identity..

Hadley: people want fewer usernames and passwords to remember..

Tess: status quo is signing in with email addresses, most logins are not federated identity. That's extremely joinable. People do that all the time. I don't want us to conclue that a private web doesn't support federated identity at all, we'll be back at square one.

Dan: are the privacy considerations around websites participating in the federation not knowing that the user is part of a particular identity ring until the user gives their consent through the UA part of the proposal?

Tess: looking....

Hadley: [leaving comment about user need]

Tess: yes.. identify the problems here but doesn't say the identity provider shouldn't be able to do that... IDP shouldn't be involved without justification.. doesn't say they aren't join your identity across sites. Is in threat model

Peter: Mozilla did work on Persona...

Rossen: is cited in their prior art section. About BrowserID proposed, and link to post mortem

Tess: threat model bit does talk about this

Rossen: do we have enough to write a comment?

Dan: feels like we should organise a separate session with Sam about this. Initial comments.. and schedule a separate breakout.

Both: Think this can be closed during plenary