RE: [security-services] NameID mgmt and account "merging"

["Brian Campbell" <bcampbell@pingidentity.com>]

> Anyway, the question arose as to what an SP would do if an IdP sent it
a
> ManageNameIDRequest in which the NewID value matched an existing
identifier
> shared between the IdP and SP.
> 
> Plausible reactions:
> 
> - This is an error.
> 
> - The old identifier and new identifier refer to the same principal
and the
> SP could terminate and cleanup the old identifier/link, merging other
> information or not at its discretion.
> 
> - Panic and terminate both identifiers.
> 
> - Others....
> 
> In my mind, a merge would be the sort of thing that is covered under
the
> broad heading of "what the shared identifiers mean to the deployers",
much
> like AllowCreate, and would be a deployment option how to respond, but
this
> seems like a potential interop issue that should be clarified, even if
it
> precludes supporting the use case.

[Brian Campbell] 
It seems to fall into the same category as the whole AllowCreate issue.
And, if I remember correctly, one of the conclusions from that
discussion was that (with the awkward exception of SP provided ID) all
ManageNameID messages were notification messages only.  The other entity
could take whatever action it deemed necessary based on that
notification but no action was required by the letter of the spec.  It
follows from that that any of plausible reactions you mentioned to the
'merging' situation are perfectly reasonable and legal as far as the
spec is concerned.  It's a deployment issue as you've said many times.
Or perhaps an additional profile is needed if we believe that tighter
constraints need to be put in place for interoperability with respect to
shared/linked identifiers. 

-Brian