Can you elaborate on what you means by “as long as B and C are separate”?
So we are talking about a scenario mapping together multiple services. The statement “you are logging in into either A & B or A & C, but not both” only holds if B does not set C as a derivationOrigin or vice versa (i.e. they are using different principals). This is what I meant by being separate.
Also, you’re then saying that when into logging into app A, I can log into only one additional derivation origin at a time - is this correct?
The correct statement would be one at a time (it is not additional). But you can chose which one by setting the derivationOrigin.
But then wouldn’t “creating your account on service B using the principal of A” allow logins to A to make calls directly to B, or any other service (C, D, …N) that has A listed for this set up (they all use the same principal)?
Ah, you think of a scenario where one application coerces all the other applications to set derivationOrigin (and not the /.well-known/ii-alternative-origins asset) essentially giving up their own principal space.
Yes, I think this is possible. But it would force existing applications to go through a user migration (otherwise they would lose all user accounts) and give up control over all their users. I.e. the application that you are trusting (whose derivationOrigin you are using) could cut you off from all your users at any moment. Developers (as others have already pointed out) should hopefully realize that giving up control that way is a terrible idea. But we will add a warning to the feature specification shortly, to make this point more clear.
Your proposed solution of listing all other aliases seems to be good and simple way of detecting this if developers were to ignore all warnings and start doing this anyway. I will discuss this with the research team and update this thread accordingly. Thanks for creating this thread and kicking off the discussion!