RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?

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

> I believe it should be the principal. If the IDP assigned NameID is 
> updated, you shouldn't throw away the SP assigned NameID.

Not quite my intent. If you modify the NameID, sure. What I mean is other
formats. For example:

IdP assigns "persistent" NameID
SP registers SPProvidedID
IdP uses existing X.500 DN NameID

Does the X.500 NameID contain the SPProvidedID? I would say it's up to the
IdP and would be legal either way.

> While it may be true that attributes may foil the use of pseudonyms in 
> persistent or transient NameIDs, by revealing too much information,

Not necessarily, the attribute itself might just be a persistent NameID, or
equivalent.

> I don't see how they render AllowCreate pointless. The point of 
> AllowCreate is to prevent an assertion from being generated 
> in response to an AuthnRequest under certain circumstances: namely, when
> the requester has not already been assigned a persistent identifier for
> the user (in-band from a previous authentication, or out-of-band by some 
> other means). In other words, AllowCreate=false is meant to prevent the 
> requester from learning a persistent name for a user that they don't 
> currently already know.

Right, but it doesn't. An IdP is allowed to issue a transient NameID in an
assertion with an attribute that is persistent (could be an IdP assigned
pseudonym, could be something else) in response to an AuthnRequest with
AllowCreate false. So what does it prevent?

Sure, this is use case specific. But that's the point. Without knowing the
use case, you don't know how to set the flag or what it means. I contend
that it's not a "format" issue, but a use case issue. As we agreed,
"persistent" in and of itself doesn't imply dynamic. Nor does, IMHO, X.500
imply static.

So, the formats themselves don't have processing rules pertaining to
AllowCreate. It's a deployment specific issue that isn't visible in the SAML
spec. I think that's what Brian was concerned about.

If we can reach some kind of consensus on that, then at least there's a way
to explain it to implementers, even if they don't like it. ;-)

-- Scott