You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As consent flows become increasingly complex for the sites' users to interact with and want to sign in to, the point-of-log-in is frequently the surface in which user data privileges are mediated. Sites should be able to inform the API that they want either structured (an additional list of text with a designated form element like "checkbox" or additional disclosure section predefined in the API) or non-structured (here is an HTML fragment including a FORM with a checkbox or other form element, return to me the user's selections if they complete the log-in flow) data for the UI to display when it presents itself to the user.
Some example flows might include:
Providing a checkbox for specific marketing consents.
Providing a switch that allows the user to initiate their logged-in session in a Do Not Sell mode
Prompting a user for login before a legally required consent banner to retrieve their previous consent settings, but which would require a request to opt in to specific permissions.
The limitation of capacity to add to the UI with site-specific language or consent checkboxes ends up requiring sites leveraging the FedCM sign-in flow to present additional screens which end up completely negating the ease of use that this UI presents, or requiring sites that do not wish to present additional screens to meaningfully limit commercial activity and therefore potentially limit the access a user might gain through log in.
What would be a desirable solution?
Allow sites to identify to the API additional UI with logical limitations on what can be inserted (for example, we might not want to allow images because it potentially opens up tracking).
Allow the additional UI provided by the site to contain some degree of FORM state.
Return to the site the selections made by the user in the additional UI when the user completes login.
(I feel like I'm constantly behind on the status of this project, but I think this is the right place to add this and this hasn't been raised yet? Please correct me if that's not the case)
The text was updated successfully, but these errors were encountered:
As consent flows become increasingly complex for the sites' users to interact with and want to sign in to, the point-of-log-in is frequently the surface in which user data privileges are mediated. Sites should be able to inform the API that they want either structured (an additional list of text with a designated form element like "checkbox" or additional disclosure section predefined in the API) or non-structured (here is an HTML fragment including a FORM with a checkbox or other form element, return to me the user's selections if they complete the log-in flow) data for the UI to display when it presents itself to the user.
Some example flows might include:
The limitation of capacity to add to the UI with site-specific language or consent checkboxes ends up requiring sites leveraging the FedCM sign-in flow to present additional screens which end up completely negating the ease of use that this UI presents, or requiring sites that do not wish to present additional screens to meaningfully limit commercial activity and therefore potentially limit the access a user might gain through log in.
What would be a desirable solution?
(I feel like I'm constantly behind on the status of this project, but I think this is the right place to add this and this hasn't been raised yet? Please correct me if that's not the case)
The text was updated successfully, but these errors were encountered: