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

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

> 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