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

["Brian Campbell" <bcampbell@pingidentity.com>]

> 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.

I don't follow what you are saying here.  

SSO establishes an identifier for a principal with an SP (subject to the
rules of AllowCreate).  NIM allows the identifier to updated or
augmented with additional info (SP Provided).  NIM also allows for
de-establishment of the identifier.  That's just one reading of the spec
- I realize there are others.  But why couldn't it be that simple?  Ok,
so we want to enable stateless implementations which as I understand it
is where the 'light' operational modes came from.  But it's not clear
(to me anyway) exactly what processing rules apply to what modes and
when.  

> "Persistent" 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.

But isn't AllowCreate about policy?  If false, it constrains the IDP to
only use an identifier that has previously been used that SP (or was
provisioned out of band).  If true, the IDP can newly create or
associate an identifier for the given principal with that SP.  It is
policy that looks like state but the IDP doesn't necessarily have to
keep state in any particular way - just behave to SPs in a consistent
spec compliant fashion.

I don't understand why the wording around terminate in NIM doesn't
impose rules on the receiver of a message that would make it consistent
with and complementary to the AllowCreate attribute.   Apparently it's
carryover from Liberty but what's the intent or value of having it so
loose?  If it's only advisory, then why include it 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.

I would think that the more straightforward and clear, the better.  I'm
not claming to be an expert in identity protocols by any means but I
have implemented a few of them and have spent a fair amount of time with
the SAML 2 spec and it is not at all clear to me exactly how this is
suppose to work.  I suspect that I won't be the only one that has
difficulty with it.