Clone wiki

connect / Browser Interactions Special Topics Call - 20210630

OIDC Browser Interactions Special Topics Call



  • Tim Cappalli (Microsoft Identity)
  • Tony Nadalin
  • George Fletcher (Verizon)
  • Tom Jones
  • Brian Campbell (Ping)
  • Sam Goto (Google/Chromium)
  • Heather Flanagan
  • David Waite (Ping)
  • Mike Jones (Microsoft Identity)



Google's Timeline Change

Blog post announcing change

{Sam} Reinforce that the WebID is mostly detached from the timeline. Focusing on the problems and potential solutions, and not necessarily the timeline. Think of the when after we think about the why, what and how.

{George} Key is to use this time to go solve the problem and not take the foot off the gas. Now we can look at it more holistically.

{Sam} Timeline doesn't change the why or what. Just the when.

{George} Two competing Why or Whats: 1 - 3P tracking, 2 - identity on the web. CG is about defining what is the problem with identity on the web. Approaching the problem from "I want identity on the web to work, and not have companies track me and my data".

W3C Federated Identity WG update

{Heather} Lots of positive feedback. Call scheduled for next week to address questions about the charter, mostly a Q&A. Lots of higher ed folks will be joining. After meeting, official reach out to W3C for creation.

Meeting details:

Topic: FedID CG Charter Review
Time: Jul 6, 2021 06:00 AM Pacific Time (US and Canada)
Join Zoom Meeting
Meeting ID: 810 3315 4512
Passcode: 942941
One tap mobile
+12532158782,,81033154512#,,,,*942941# US (Tacoma)
+13462487799,,81033154512#,,,,*942941# US (Houston)
Dial by your location
 +1 253 215 8782 US (Tacoma)
 +1 346 248 7799 US (Houston)
 +1 669 900 6833 US (San Jose)
 +1 301 715 8592 US (Washington DC)
 +1 312 626 6799 US (Chicago)
 +1 929 205 6099 US (New York)
Meeting ID: 810 3315 4512
Passcode: 942941
Find your local number:
Join by Skype for Business

WebID Logout Updates

{Sam} Actively working on logout and starting to write code and privacy reviews. We can use more IdP partners that use front-channel logout, need feedback. Most feedback thus far has been from Microsoft team. Logout is generally easy in that the mechanisms to enable it are easy. The hard part is binding to observation of the log in flow.

{Mike} Clarification question: sounds like if we can accurately observe log in and lower privacy shields, then the current logout mechnisms, including browser-based logout mechanisms like clear cookies and postMessage will continue to work?

{Sam} Still need to determine what "lower the shields" means. If we lower them completely, aka status quo, then postMessage and iFrames would be able to send credentialed, then the answer is yes. Going through privacy review on what "lower the shields" means. A more privacy preserving mechanism is to make it so that logout can only happen once for every log in.

{Mike} That's probably OK given that in OIDC, sign out is meant to be once and then ignored

{Sam} Potential consequence: iFrame, browser can't tell if its embedded for content or logout. Need a direct classification for a log out iframe. A more constrained version is to replace credentialed iframes with a log out specific API (aka navigator.credentials.logout), in a way that can only be done once.

{Mike} lowering the shields doesn' tneed to be binary.

{Sam} Other consideration: deployment cost. More senstivie to things that require RPs to change than to IdPs.

{Mike} Connect WG has typically tried to make changes to IdP/OP side instead of RP

{Sam} Token renewal: iframe from IdP embedded on RP (opposite of log out flow). This will be harder than log out because of deployment reasons, not technical reasons

{George} ANother use case was less about RTs and more about implicit, open iframe with prompt=none and get a fresh access token so your browser env doesn't need a RT. Similar use case. Back to looking at the overarching identity on the web use cases. RP side is difficult because you don't know when RPs will be able to make a change. Maybe if you can come up with a mechanism where if you use the JS, no interstitial, but if you don't, the interstitial pops. Many deployments where the products aren't being updated (ex: SiteMinder and others). If that breaks, it is usually a major headache to upgrade across multiple versions which creates a ripple effect.

{Sam} Minimizing the deployment costs is certainly desired. Breakages may not be zero. Blocking 3P cookies itself is a backwards incompatible change. Minimize breakage as much as we can, but it likely can't be zero.

{DW} Try to push to IdP as there's a single point of breakage, reduces the stress.

{Sam} One of the hardest pieces is changing user behavior.

{George} What breaks with a particular browser change? And how many deployments will that effect. How do we get that knowledge. With the CG, we can start to be more concrete.

{George} Breaking user experience is really bad. Tweaking is not necessarily super bad if it allows the ecostystem to continue to work.

{Sam} Canonical example for changing user behavior: Solving the NASCAR flag problem

{Sam} best way to go through this process is to raise your hand and partner with us to discuss use cases. Open invitation.

{Tom Jones} via chat: I don't care about logout

Next call topics

{George} start taking existing use cases and walk through them