I think you’re right that the vast majority of cases involves a service provider that serves in the role of “federatable” identity provider (with a persistent account), and one or more service providers that have local accounts but are always consumers/relying parties of “federated info”. It’s not impossible to have an entirely transient connection using SAML protocols, but it’s obviously of much more limited utility. That’s why you’ll see, in the SAML Technical Overview, explanations of typical flows for usage of both persistent and transient pseudonyms that assume a persistent account store on the IdP side. I don’t think the language “designated IdP” is needed because it’s expressed in the protocol flow — it’s the party that does the responding to authentication requests etc.

BTW, the pseudonyms have to be pairwise unique in order to avoid correlation of your activities by multiple RPs, but one common deployment topology is, of course, a hub (IdP)-and-spoke (several RPs) arrangement.

In lots of non-pairwise federation schemes, this party is called the IdP. I.e. a user always has a persistent account with an IdP. If that were’nt the case, then an IdP wouldn’t maintain records about the user and wouldn’t be able to perform its primary function, which is to supply testimory about the accuracy of claims by the user.

In the pairwise schemes that Liberty is fond of, I suppose you could say that one of the parties is the “designated IdP”.

Spock today isn’t trusting LinkedIn or allowing LinkedIn to trust it; it’s impersonating you on LinkedIn to get information you’ve stored there. If the two parties, and you, worked out an arrangement whereby you could introduce them to each other for the purpose of account linking, and you say it’s okay to share (some of) your profile data in one or both directions, each could potentially accept single sign-on assertions containing authentication confirmations and attributes from the other side without knowing your actual authenticator data over there.

Note that, in addition to keeping Spock from knowing your password on LinkedIn, it also decouples the process of using Spock from authentication methods that might involve something more than or different from username/password, like if LinkedIn used a site key for you to authenticate them.

What would be really cool is a generalized “introduction protocol” that sites can make available to users if they want to try and work out account links between any two sites at which they already have accounts (purely local or already linked to some other one). I’d much more readily do that than share all my passwords every which way. If we managed to make the interface easy to understand and use, and give it some level of contractual assurance around what sites are allowed to do with information they rely on (ha! users imposing click-through agreements on the sites they use! yeah, baby), maybe we’d have a true flipping around of who’s in charge.