Subject: RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?
> Wasn't there an animated movie with talking mice called The Secret > of NIMH? For us, I guess it would be the Secret of Name Identifier > Management and, uh, Hacking... Indeed. > In your suggested <Terminate> wording, the various kinds of > sender-imposed state are mentioned in illustrative fashion, which > injects a little implementation realism into the normative text > without overwhelming it or making everyone do pairwise IDs. That > part doesn't seem too squishy. The AllowCreate wording seems quite > a bit squishier (but maybe that's because it would benefit from a > bit of editorial tightening-up). It is quite squishy, but mostly it's circular. If you can imagine what you would delete if you get a Terminate message, it's probably more evident what you're not allowed to create up front. But unless we specifically spell out what that state is, I'm not sure it can be defined any better. SPProvidedID is actually a simple case, and it doesn't help because you can't get one attached until a NameID is already in place and sent to the SP. So honoring Terminate is not the same thing as needing to honor AllowCreate, and the mere fact that it results in a pairwise identifier in all cases doesn't mean anything because you could start without that property, and not have to pay any attention to AllowCreate. "Peristent" IDs are *usually* dynamically assigned and stored, and again these rules become fairly clear. But they *may* be derived somehow without being explicitly stored (thus in some sense they always existed and always will), and so again, AllowCreate cannot possibly apply unless it has some other broader meaning that would have to apply equally to other identifiers...policy in other words, and not state mgmt at all. In that case, I think we'd be better off just coming out and saying "if an implementation records the fact that an identifier of any sort is in use by an SP, for whatever reason, then AllowCreate governs the creation of that record during authn and Terminate governs one route to its deletion", and just be done with it. Maybe that's better than all the dancing. -- Scott