RE: [security-services] Question on SP initiated authentication & provisioning first time user

["Scott Cantor" <cantor.2@osu.edu>]

> I know a use case where the IDP knows the user under his own unique
> identifier. The SP, independently, also knows the user. At this point in
> time the user would like to take advantage of the SSO provided by the
> IDP and cause the SP rely (for his account) on the IDP.

That's standard account linking, and the normal model for that is to login
to both accounts to establish the link. Information about the user needs to
flow only from the IdP to the SP to accomplish this.

> [Joerg]does your statement imply, that if SP1 knows the user as Jim and
> SP2 knows the user as j.owl it is not possible for SP1 and SP2 to share
> an IDP, because at the Auth_Request both would not share the same
> NameIdentifier ? I hope I am wrong.

No, I wasn't implying that. Sharing an IdP is unrelated to sharing
identifiers between SPs.
 
> [Joerg] If the IDP wants to know which NameIdentifier or Alias the user
> has at the SP, there needs to be a way to find out. Why would that not
> change something ?

Why does the IdP want to know this? What value does it have? How does it
facilitate the process of account linking/federation?

> [Joerg] Interesting enough, I see the reverse of the roles also as a
> necessarity, with the big addition, that I would not want to force every
> SP to implement the full IDP protocols.

I don't see it as a necessity at all, but that's beside the point, I'm just
treating it as a problem and identifying the parameters of the solution. But
what you're claiming is "new" is not really new, it's just SSO. I don't see
any other way to tackle the problem with an acceptable range of security
features.

> I would like to have a simple
> IDP initiated way to query the NameIdentifier from the SP.

Please explain how this works from a security point of view. How is the
binding established between the user's actual identity at the IdP and this
piece of data acquired from the SP? In what way is this different than what
SSO does?
 
> Hope this clarifies and satisfies both Phil's and our needs.

Not to me, I can't speak for anybody else.

-- Scott