RE: [security-services] Re: Proposed Agenda for SSTC Call (May 18, 2010)

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

> Also, there is a use case where target IdP may required to initiate
> account linking,  because the SAML federate pseudonum identifier may not
> applicable to telco enviroment.  Thus, I prefer that the
> <ManageSubjectRequest/Response><AddSubject> can be initiated by either
> SP or target IdP for account linking during SSO authentication.

Account linking is SSO. It's just a thing you do as a relying party if you
choose to attach a particular meaning to the user's data.

So again, the protocol for account linking is the existing SSO protocol. As
I understood the use case, it's about a need for an SP to communicate some
set of user information *to* the IdP as part of helping the user register
with a new IdP.

I don't think it's complex to use an AuthnRequest extension for that, or to
communicate sufficient status information back in a Response (which could be
either success or failure) to support various kinds of provisioning
signaling.

Could you copy the entire protocol and stick a new message name around it?
Yes. I just don't see why that's useful.

(FWIW, I also still think that a back channel "provisioning" operation is
the domain of SPML. Or we should have some sort of consensus reached that
SPML isn't viable, so we have to redo it here. Either is fine, but we
shouldn't ignore overlap with other OASIS standards.)

-- Scott