Skip to content

Latest commit

 

History

History
232 lines (162 loc) · 8.69 KB

2022-08-08-notes.md

File metadata and controls

232 lines (162 loc) · 8.69 KB
Raw

FedID CG Agenda - 8 August 2022 (Atlantic)

  • Moderator: Heather Flanagan

  • Scribe: Cameron

Call-in details: see https://www.w3.org/events/meetings/

Charter: https://github.com/w3c/fedidcg

Agenda

Notes

  • Decision Tree Flows: https://gitmind.com/app/flowchart/85e12187438

    • Kris: Version of decision tree flows for Safari (looking for feedback from Apple). Goal to help developers oriented toward Safari. Will have version for Chrome and Firefox as well.

    • Heather: Chrome team says they are working on theirs as well

    • Kris: Login Status API is one of first things. It’s used to signal to browser if user should be considered logged in or not (used for actual decision though). Things as they stand today, hope to do a version comparing Safari today versus next year. Biggest thing for Federation is Storage Access API. Makes sense, when there's a trigger to at least access API. Apple Posted on Webkit that popups was a temporary solution (hope to remove in future).

    • George Fletcher: Can be separated from the browser, for back channel logout. The IDP context of the session across multiple RPs is somewhat dependent on deployment strategy. Only needed in context where you want the IDP being killed to trigger a global log out.

    • Kris: if you go down the flow for the 1st decision. If there’s an active RP cookie, Should be a 1st part Cookie option on other side of flow, but basicall for the IDP at that point it’s about access/1st party cookie.

    • George: in todays world if someone redirects to my IDP, I will know about it in that context. And iFrames are broken, could seperate from full page redirects. Were you thinking iframes in this context?

    • Kris: I was thinking iframe sin general federated login.

    • George: pop-ups could be complicated if triggered from iFrame

    • Kris: yes flow is similar to iFrame

    • George: is there an active RP server side session? How would you know outside RP Session cookie context? No way to connect to server side session unless corresponding cookie

    • Kris: okay I will update that text.

  • Federated Sessions: https://gitmind.com/app/flowchart/5c211437209

    • Kris: first choice, is there an iframe doing the tracking or not? Then follow to see if status has changed from IDP. If has then RP will update status. Alternatively there is no iFrame, rp tested to see if can access valid token. Can RP test themselves for Access token or should RP ping IDP to test token validity. If not valid, prompts user to log in again, otherwise do refresh to show user content. Didn’t go down path of IDP & RP owned by same org but I could if that is useful

    • Heather: aren’t there a lot of questions about how you signal that

    • Kris: yes, and if folk could send feedback about whether we need more or less detail that would be appreciated

    • Brian: Are we discussing use cases for ID token only?

    • Kris: yes I was thinking this was just access token and we do a different flow to centralize down to different options. The 2 “?” are fairly similar in all the flows they appear in. I have flow for the #3 step for Storage Access vs CHIPS, etc. Would it be better to break it out versus duplicate in each flow (is that more or less complicated?)

    • Heather: I think for the viewer it is better to be repeated on each slide but Kris as the editor it’s probably easier to update in one place.

    • Kris: I might make its own thing then later copy across. I may also add all flows to their own login versus session folders so it’s better organized.

    • Heather: We talked about fleshing out the table and using it as foot notes, maybe we use that as an alternative for a reasonable path. Peter asked a question in issue 15 (fedidcg/use-case-library#15). Peter asked several questions we covered in the pacific call, the user sessions set in browser we’d like more context of single user session case set in browser. Anyone have examples of where we have seen this in the wild?

    • George Fletcher: I mean the browser managing user state is also not common so unless a user is trying to PoC these API’s

    • Heather: this is a non-single page app

    • Vittrio: I don’t understand what this means in practice

    • Kris: so this is RP managing Session in browser

    • Vittorio: this is where a cookie is presented to persis a session. Cookie is controlled by browser. For single page apps they instead use a background access token to run the session.

    • Kris: Here we are talking 1st party cookie managed in the browser.

    • George: or you could be calling login status API to manage token. Right now login status API, the IDP needs to be able to say person is logged in to this RP

    • Vittorio: Is logged in is not an API anymore but a bit you set. To me “siLoggedIn” is something you call after you are logged in on the login page. The Browser checks the bit automatically to investigate login.

    • George: maybe this will allow for additional functionality so the browser thinks someone is already logged in to this behavior.

    • Vittorio: I suspect that may not be the case because this domain was marketed as IDP and use as user access (RP may want to do step up. Anything that doesn't use cookie doesn’t tell you it’s signed in or not.

    • Heather: There are many services like Amazon that will identify you without sign in, but other services, even without login state, still like to personalize. Writing JS isn’t going to make the browser give you data unless in the fed CM case they can negotiate it

    • Peter: I am not sure storing session in 1st party cookie, I am not sure if it is shared with other RPs with same IDP but you can probably get by with redirects.

    • George: only need for FedCM to do 3rd party logout (in global logout context) or in iframe and want to confirm user has active session where FedCM required. Full circle this comes back to the charter to see what we need to add to FedCM to maintain current functionality.

    • Peter: One of the first questions we ask is am I single page versus web app where we do most work server side, meaning java script would be fine. Do we need to return data before we run JS

    • Vittorio: we are falling back into theory land, I don’t think the principle JS is incompatible. Most common is autopost that says on load post this form. I wouldn’t be too worried about use of JS in cases where we may not use JS. But do we use RP in redirect is more important for where do we need to transfer data without having something stripped out or not. You providers in FedCM can you do it or do we need something else? I suggest we keep discussion as specific as possible.

    • Peter: AS someone on browser side things that scare me most are the less specific elements.

    • Kris: what I see is when the RP (a series of domains) meant to be logged in to are owned by same company (3rd party or 1st party cookie I see running in to issues.

    • George: Cross domains owned by same companies are cases we can show right. Today we make that work with full page redirect and each domain gets full page session cookie. The pure browser impact is basically a 1st page redirect on visit. This is in iframe in meta container and behavior that’s broken, but that’s a separate discussion.

Attendees (sign yourself in):

  • Kris Chapman (Co-chair)

  • Peter Kotwicz (Google)

  • Michael Knowles (Google/Chrome)

  • Vittorio Bertocci (Okta)

  • Cameron Boozarjomehri (Mozilla)

  • Dani Katzman (Cross River)

  • Peter Gietz (DAASI International)

  • Brian Daugherty (Google)

  • Nicolas Pena Moreno (Google)

  • Achim Schlosser (EnID)

  • George Fletcher (Capital One)

  • Yi G (Google Chrome)

  • Brian Campbell (Ping)

  • Bjorn Hjelm (Verizon)