-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is effectiveQueryURL
necessary?
#47
Comments
It does feel that way, now that the That is to say, +1 to this (and ditto for effectiveOrigins, probably?) |
I think the concern we're trying to mitigate here is the "reputation attack" where an IdP might want to prevent its prompt being shown on unreputable / illegal sites to avoid the impression of endorsement. Would be interested in @bvandersloot-mozilla's thoughts. |
This starts to come back around to "Is Lightweight FedCM for all IdPs or is Lightweight FedCM for small IdPs," I think. |
Precisely. And many IdPs, not just large ones, can't disclose their RP lists, so they require a dynamic fetch. |
My position is that it should work for all IdPs. |
If it requires a dynamic fetch, maybe it belongs into the |
Can't IdPs enforce valid RPs post account selection? What happens if an IdP changes their mind about which RPs to allow after the
navigator.credentials.store()
(e.g. from an abuse system made asynchronously a determination that an RP is abusive)? Isn't that typically a decision that is made on the server side? Have we heard from any IdPs that can actually use this in production in a real deployment scenario?The text was updated successfully, but these errors were encountered: