Feedback for User Flow Decision Trees

[kdeqc]

Please add any feedback you have on the trees as a comment here. Thx!

[topperge]

Kristen, is there another use case document that helps give some backstory on the decision tree? I have some thoughts but before I start spouting my mouth would love to have more context.

[kdeqc]

I created the flows independently of the use cases just because initially I was hoping to make them a bit more generic. I would say use case issue #7 for the federated login flow is this one.

[pkotwicz]

Here are my questions related to the decision trees:

1. Can we have a decision tree for proof of possession? For the browsers which support proof of possession, is storage access sufficient?

Federated Login Tree
Main Decision Tree:
2. The FedCM experience when the FedCM API is invoked from the RP page and the IDP page will likely be different. FedCM provides the opportunity to not double prompt the user (IDP consent prompt + FedCM consent prompt) in the scenario that the RP only needs basic information about the user (no special permissions, no extra warnings from RP).
3. "Do they want to register?" grey block. It is likely that FedCM prompt will have a button which does either a toplevel redirect or opens a popup to IDP account creation flow.
4. Does "Logging in to RP account?" grey block refer to whether user signs in using non-federated account?

#3 How is the IdP tracking an active session?
5. "Are user sessions set in browser?" Does this refer to whether the RP is a single page app?
6. "RP and IDP from the same org" -> "Can CNames be used?" I think that CNAME's are an option in cases where the RP and IDP are not in the same org https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/
7. "Is the user using Chrome?" -> "Can the IdP's cookie be partitioned to RP?" -> No. Enterprise policy and toplevel redirects are an option.

#6 Information saved about user session
8. "Is information saved in the browser?": Does this refer to whether the RP is a single page app?
9. "Is the user using Chrome?" -> "Yes" -> "Can the IdP's cookie be partitioned to RP?" -> "No": Is this referring to certain IDPs/RPs really needing first party sets?

Federated Session Tree
Main Tree
"Can postMessage be used to talk to IdP iframe?" Yes for Chrome

General Notes (Not related to any decision tree):
In boxes which say "FedCM" it would be useful to distinguish between boxes which refer to "currently implemented FedCM API" vs "future FedCM API"

Currently implemented FedCM API:

• Does not support silent retrieval of identity tokens after user consents to communication between RP & IDP. We expect a future FedCM API to have this ability.
• Does not support retrieving tokens other than id tokens. We will build this if needed
• Does not grant access to third party cookie after the user consents to communication between RP & IDP. The current shape of the FedCM API enables the IDP to return the serialized IDP first party cookie instead of the id token from the token endpoint. The FedCM team is currently not planning on altering the FedCM API to discourage returning the serialized IDP cookie instead of the id token.
• Only supports displaying accounts for one IDP in FedCM dialog. We are actively working on supporting multiple IDPs in the dialog.

[hlflanagan]

@pkotwicz we discussed some of this on the FedID CG call on 1 August 2022 (Pacific-friendly). Notes are here: https://github.com/fedidcg/meetings/blob/main/2022/2022-08-01-notes.md

[pkotwicz]

It sounds like you discussed most of my questions during the FedIDCG call! Thanks for the write up!

"Are user sessions set in browser?": I would like to better understand the non-single-page-app use case where the session is set in the browser. Currently FedCM is a JavaScript API. I would like to understand whether there are scenarios where FedCM, being a JavaScript API, is incompatible with non-single-page-app use cases where the session is set in the browser. I am somewhat familiar with the "webapp version" of the Microsoft Identity Platform API. - https://docs.microsoft.com/en-us/azure/active-directory/develop/index-web-app

Proof of possession: Emily is right that this question is in response to an issue raised with the FedCM team by Microsoft earlier this year. If proof of possession is a direction identity is heading in, it is useful to determine whether the APIs being built will support this use case. The FedCM team has not further investigated supporting proof of possession due to lack of feedback on this github issue w3c-fedid/FedCM#80

[hlflanagan]

Good discussion on that question. See meeting notes from 8 August 2022

[achimschloss]

Adding to that discussion @pkotwicz - you mentioned the question originated from the IDP asking during client registration if the client was a single page application, web app etc. The background here is that these deployment have distinct security requirements given an SPA or a native App are public clients which cannot securely store client secrets.

For an SPA or native application the IDP will use an auth code flow with PKCE (which is not mandatory for a classical web application), or offer support to bind token with DPoP. A good overview can be found in the security best practices https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics

FedCM would need to be factored into these different types of integrations. The extra complexity is that with the current scope it only adds to/partially replaces the usual flows so it will be a mix of both at least for the mid term. There are a bunch of issues filed around this area - w3c-fedid/FedCM#245, w3c-fedid/FedCM#253, w3c-fedid/FedCM#264