IdP registration opens up a whole new world of possibilities. However that world is very large. For the bubbles of RPs/IdPs that aren't explicit OpenID Federations, there are still bubbles defined by which protocols the RP/IdP pair can speak, even though they don't have preexisting relationships or any trust roots. For example, webmention.io expects to be able to speak IndieAuth through FedCM, and wouldn't work if you had registered a SAML IdP in the browser.
Concretely, if a user had registered a SAML provider as an IdP in the browser, it would lead to a dead end if they landed on webmention.io and the account popped up in the chooser.
The solution could be as simple as allowing arbitrary strings in a "type" property, and letting IdPs register as being able to handle that type in the register call:
IdP registration opens up a whole new world of possibilities. However that world is very large. For the bubbles of RPs/IdPs that aren't explicit OpenID Federations, there are still bubbles defined by which protocols the RP/IdP pair can speak, even though they don't have preexisting relationships or any trust roots. For example, webmention.io expects to be able to speak IndieAuth through FedCM, and wouldn't work if you had registered a SAML IdP in the browser.
Concretely, if a user had registered a SAML provider as an IdP in the browser, it would lead to a dead end if they landed on webmention.io and the account popped up in the chooser.
The solution could be as simple as allowing arbitrary strings in a "type" property, and letting IdPs register as being able to handle that type in the register call:
Then RPs could ask for IdPs with a matching type:
This would avoid IdPs showing up in the list when they would be unable to complete an exchange with an RP.