[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]