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

IdP Registration API: allow enumerating all registered configURLs #5

Open
samuelgoto opened this issue May 28, 2024 · 7 comments
Open

Comments

@samuelgoto
Copy link
Collaborator

This was suggested here by @sebadob: breaking it into a smaller issue so that we can explore/discuss/fix it here independently.

I don't know if such a functionality exists, but is it possible to do a registration clean up for an origin or list all registered IdP's?

Yeah, I ran into this problem my self too. I'm thinking that if we could enumerate all registered configURLs it would be easy to have a clean up. For example:

for (const configURL: await IdentityProvider.getRegisteredConfigURLs()) {
  await IdentityProvider.unregister(configURL);
}

Would that work?

It would be good if we would be able to check if "our" origin is already registered, because then there would be no point in even showing such a button to the user, which in the end provides a better UX.

Oh yeah, that sounds useful too. Maybe something like the following?

if ((await IdentityProvider.getRegisteredConfigURLs()).length > 0 ) {
  // skip showing the button to the user
}

WDYT?

@cbiesinger
Copy link

Allowing you to list all registered IDPs could be tricky from a privacy perspective. But we should be able to let you query the current origin's/site's registration status (await IdentityProvider.isRegistered(same_site_config_url) or something)

@samuelgoto
Copy link
Collaborator Author

Ah, interesting. Why do you say that it could be challenging from a privacy perspective? Wouldn't this be equivalent to any other source of site storage (e.g. indexed)?

@cbiesinger
Copy link

@samuelgoto oh were you thinking that getRegisteredConfigURLs() only returns config URLs from the current site?

@samuelgoto
Copy link
Collaborator Author

@samuelgoto oh were you thinking that getRegisteredConfigURLs() only returns config URLs from the current site?

Oh yeah, of course. You don't need cross site to unregister.

@cbiesinger
Copy link

yeah that should work (I might bikeshed to name to include ThisSite in it somewhere)

@sebadob
Copy link

sebadob commented May 28, 2024

for (const configURL: await IdentityProvider.getRegisteredConfigURLs()) {
  await IdentityProvider.unregister(configURL);
}

Something like this would be really nice to have, yes.

Maybe even something like this would be fine:

let config = 'https://example.com/config.json';
if (IdentityProvider.isConfigURLRegistered(url)) {
  // do something useful
}

Or to have an even easier and more future proof API, we could also do it via metadata / webidentity. This would probably be easier in the end for app developers who just want to include the client side. Then you should be able to do something like

if (IdentityProvider.isIdpRegistered('https://iam.example.com') {
  // do something
}

This would even get rid of specifying the exact configURL path, which might change at some point. The webidentity is specified to always be at eTLD+1, but the config location might change, which would be super annoying probably when you need to migrate this later on.

Having an iterator over all configURLs would come in very handy for development processes, so you could clean up your own mistakes (I did them and screwed up my browser ^^). Or if not being accessible via JS, maybe have some cleanup functionality in the browser settings, where you can see all registered URLs, if this would be a privacy issue for someone.

@npm1
Copy link

npm1 commented Jun 3, 2024

If this is just for development then I think the browser setting to show/unregister IDPs will be sufficient. That said, browser settings are generally not in the spec. We can suggest user agents expose the registered IDPs in some setting to allow unregistration but that's about it.

@samuelgoto samuelgoto transferred this issue from w3c-fedid/FedCM Sep 6, 2024
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