w3c-fedid / idp-registration

A proposal to extend FedCM to allow RPs to accept "any" registered IdP
4 stars 0 forks source link

IdP Registration API: allow enumerating all registered `configURL`s #5

Open samuelgoto opened 5 months ago

samuelgoto commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

samuelgoto commented 5 months ago

@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 commented 5 months ago

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

sebadob commented 5 months ago
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 commented 5 months ago

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.