Skip to content
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

Open
samuelgoto opened this issue Sep 24, 2024 · 6 comments
Open

Is effectiveQueryURL necessary? #47

samuelgoto opened this issue Sep 24, 2024 · 6 comments

Comments

@samuelgoto
Copy link

samuelgoto commented Sep 24, 2024

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?

@ekovac
Copy link
Contributor

ekovac commented Sep 25, 2024

It does feel that way, now that the token is not provided at store-time. When there was a possibility there was something sensitive in there, we definitely needed that control. Now that that's being retrieved using something compatible with the Identity Assertion endpoint (which has the Origin in the headers etc) this shouldn't be necessary.

That is to say, +1 to this (and ditto for effectiveOrigins, probably?)

@johannhof
Copy link
Member

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.

@ekovac
Copy link
Contributor

ekovac commented Sep 26, 2024

This starts to come back around to "Is Lightweight FedCM for all IdPs or is Lightweight FedCM for small IdPs," I think.

@bvandersloot-mozilla
Copy link
Collaborator

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.

Precisely. And many IdPs, not just large ones, can't disclose their RP lists, so they require a dynamic fetch.

@bvandersloot-mozilla
Copy link
Collaborator

This starts to come back around to "Is Lightweight FedCM for all IdPs or is Lightweight FedCM for small IdPs," I think.

My position is that it should work for all IdPs.

@samuelgoto
Copy link
Author

And many IdPs, not just large ones, can't disclose their RP lists, so they require a dynamic fetch.

If it requires a dynamic fetch, maybe it belongs into the client_metadata_endpoint rather than navigator.credentials.store()?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants