I'm really struggling with Google's reliance on mutable Email identifiers for inbound federation. It really breaks a broad partner federated model where email is definitely not a unique identifier. The only valid identifier is Issuer+Subject across various IDPs - as also required by the OIDC specification.
Email is not considered unique, neither are usernames as those may vary between providers. Has anyone gotten a broad federation setup with Google using proper Immutable ID associations end-to-end?
E.g.,
MyOrg Identifier = MyOrg-123456-xyz | Email = someuser@myorg
Logingov Identifier = Logingov-1234-abc-19d8c7s9 | Email = someuser@myorg
Partner1 Identifier = Partner1-someRandomThing | Email = thisotheruse@partner1
Email within any organization may not have their own domains and share them. They may be duplicated across lots of different IDPs. And each log in has to be handled as a unique identity unto itself to avoid cross-contamination, impersonation or re-use across potentially hundreds of IDPs.
Creating Google users with unfriendly "identities" like {immutableid}@domain would not be good for users.
We really need a way to link on Issuer+Subject end-to-end with emails/usernames as informational points and in a user-friendly way while using external federated log in.
Google <-> Identity Broker -> Dozens of IDPs
Has anyone accomplished this without overly burdensome Identity processes to create unique Google email addresses they require?
Are there any known plans to use Immutable IDs, not mutable emails, for actually binding accounts?
LinkedIn
Twitter
