Conor's Bi (directional argument)

I'm sure he would have preferred to actually get in and invoke 'editorial privileges' to modify my post but Conor has settled for a response.

While I'll admit there's a certain level of consistency to Paul's proposal, I still think that the right way is to put the identifier in the NameID value rather than the SPProvidedID. My reasons include:

* The NameID carries the value chosen by the "IdP" to represent the user at the "SP". In this case, the Former-SP-Now-Acting-As-An-IdP has chosen to use the identifier that it had received from the Former-IdP-Now-Acting-As-An-SP. Therefore that value belongs in the NameID elementnot in the SPProvidedID attribute.

The other interpretation is that, when playing their initial roles, the SP and IDP made the following commitment to each other:

SP: Dear IDP, when I communicate with you I will use the 'abc' identifier (in the NameID) that you created for me.
IDP: Dear SP, when I communicate with you I will use the 'def' identifier (in the SPProvidedID) that you created for me.

The question is, does this commitment still apply when the two providers switch roles?

Conor will argue that the initial commitment is more along the lines of:

SP: Dear IDP, when I (acting as an SP) communicate with you I will use the 'abc' identifier (in the NameID) that you created for me. When however I (acting as an IDP) might communicate with you, I will use the 'def' identifier (in the NameID) that I created for you.
IDP: Dear SP, when I (acting as an IDP) communicate with you I will use the 'def' identifier (in the SPProvidedID) that you created for me. When however I (acting as an SP) might communicate with you, I will use the 'abc' identifier that I created for you.

I don't know which it is (and don't really care). I just don't believe its straighforward to infer the right choice from the specs.

* The SAML 2.0 Core Specification does not allow for a null value in a persistent identifier (see section 8.3.7).

I wasn't arguing that the Former-SP-Now-Acting-As-An-IDP should insert the null string, but rather that consistency with the double identifier case as he laid it out forced it to. More precisely, consistency with the double identifier case required it to insert the identifier previously created by the Former-IdP-Now-Acting-As-An-SP in the SPProvidedID attribute, and that it had no other identifier to place in the NameID element - thus 'null'.

So, consistency between the single and double identifier cases breaks SAML (as SAML doesn't define a null.

Reductio ad absurdum.

* Lines 3326-3332 and 3350-3356 of the SAML 2.0 Core Specification actually discuss the case of an SP using the same identifier provided to it by an IdP when that SP-now-acting-an-IdP issues assertions pointing out that they would need to identify the original issuing party using the NameQualifier attribute.

As I read them, these two paragraphs from the SAML spec require that the Former-SP-Now-Acting-As-An-IDP, if they use an identifier initially created by the Former-IDP-Now-Acting-As-An-SP, to use the NameQualifier attribute. So, the example from my first response was incorrect, it should have been

<saml2:NameID Format="persistent" SPProvidedID="def" NameQualifer="IDP.com">
     abc
</saml2:NameID>

Ironically, I believe that this sentence (Line 3352):

If a service provider that receives such an identifier takes on the role of an identity provider and issues its own assertion containing that identifier, the NameQualifier attribute value does not change (and would of course not be omitted).

supports my model as it implies that the SP, in a reverse assertion, would use (in the NameID element) the identifier previously created by the IDP, and not the identifier it has previously created.