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

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

> I see. Sure, I think we've said that NameID Management only 
> applies to persistent ids.

No, we definitely don't say that (and it wasn't my intent). An SP can link
itself to any kind of ID it wants (except transient for practical reasons).
The question is whether the link is to the principal (like the text says) or
to the specific NameID construct (my intent).

> Perhaps we can simply say that the IdP should take care when including 
> attributes in assertions using 'persistent' or 'transient' NameIDs so 
> as not to thwart the privacy protections that they are attempting to 
> afford.

That's a very good idea.

> So, perhaps the mistake was moving the ID-FF 'federate' flag into SAML 
> NameIDPolicy and calling it AllowCreate? I think we need to focus on 
> explaining what was intended and not reverse engineering what's implied 
> by the syntax that we ended up with.

Well, it was more or less changed in 1.2, but since I did that too, it's
pointless to base anything on that. I agree with the sentiment except that
it wasn't clear to me what was intended, so I tried to propose a definition
that SAML could treat as more in-scope, but it may not be working.

Without delving further into the rationale, I'm still not sure why it's a
huge problem to leave it at "if you're not dynamically assigning
identifiers, then you should ignore this flag". People are free to implement
SAML without any notion of dynamic assignment and the flag has no place
there.

I think the trickier problem is explaining how an SP implementation would
manipulate the flag, and I think it simply depends on the use cases the SP
wants to address.

-- Scott