IDP account transfer

[kdenhartog]

One tradeoff that occurs with the current federated identity design in OIDC is that the user often times gets locked into specific IDPs available to them in a way that account transfer could help mediate. Has this spec consider the tradeoffs that occur with account transfer between two IDPs so that a user can have the option to migrate IDPs if they choose?

[npm1]

That seems like something that the user would need to do directly in the sign up page of their new IDP of choice, not via the FedCM API.

[kdenhartog]

Agreed, it wouldn't be a requirement of the browser APIs, but since we're defining IDP apis as well in section 5 wouldn't it fall under the considerations of that section? Especially since it requires coordination between the two IDP parties? I can see where people would want to make the argument for this being out of scope or not a required capability, but it is a common scenario that's used in certain industries such as telecom. Additionally when students transfer schools that's another common scenario where I would think this would be used.

It's something defined as an implementer's draft in OIDC MODERNA WG as the account porting spec so I was thinking this is something that would be useful to meet feature compatibility if we're going to be making OIDC obsolete with this work.

[timcappalli]

if we're going to be making OIDC obsolete

This is not a design goal of any work stream I'm aware of.

[kdenhartog]

This is not a design goal of any work stream I'm aware of.

I would certainly hope not, but I'm a bit concerned that's the direction that might accidentally occur if we leave section 7.5 to a last minute consideration. Architecturally, everything defined here seems to align with OIDC, but based on what's in the spec it's hard to tell that it's being considered.

[npm1]

It is an interesting point that there is an account porting spec over there. I don't think we're opposed to new features. I don't know if we've heard about a feature request for something like this in particular though. Since account porting looks like a fairly involved flow, I think it would likely be done in a completely different method/flow. How about we keep this open as a feature request? We can action upon it when there is strong developer demand.

[kdenhartog]

👍🏻 that makes sense to me. The main advantage to account porting is that it prevents the IDP lock in concern, but it comes with a tradeoff that the subject identifier typically needs to be globally unique which may conflict with the directed identifier approach that appears to be going right now.

[kdenhartog]

Same here @npm1 you can assign it to me and I'll open a PR for it

[samuelgoto]

I'm in strong agreement that portability is a really important feature and that being able to recover your accounts as move around IDPs is super important, so +1 to this.

What's unclear to me here is whether this is a FedCM concern or an IDP concern.

That is, what's actionable on the FedCM spec here to allow the OIDC Account Porting spec? Skimming through it, this seems like something that can be done with our spec unchanged? Similarly, I'd expect OIDC's SIOP to be also implementable over FedCM (without any changes).

[samuelgoto]

this seems like something that can be done with our spec unchanged

I'm confident that this isn't something that the user agent should have to handle, but rather IdPs.

I'm going to add a non-normative note on the spec with a pointer to this issue and close it.

[kdenhartog]

Sounds good, I'm +1 to leaving this up to OIDC and non-normatively noting it

[samuelgoto]

if we're going to be making OIDC obsolete

I just wanted to note that this is an explicit non-goal: FedCM is an alternative to third party cookies (and actively trying to make that obsolete). It relies on OIDC and SAML to continue to exist and proper in the absence of third party cookies.

[kdenhartog]

Thanks for clarifying that. I was confused what the plan was for this originally because that backwards compatibility section wasn't defined yet and the RP/IDP APIs didn't seem aligned with that view point. Choosing to not break OIDC/SAML definitely seems like the best choice here so I'm glad to see it's going that direction.