OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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"?

> It is quite squishy, but mostly it's circular. If you can imagine what
> would delete if you get a Terminate message, it's probably more
> what
> you're not allowed to create up front. But unless we specifically
> 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
> can't get one attached until a NameID is already in place and sent to
> 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

> "Persistent" IDs are *usually* dynamically assigned and stored, and
> these rules become fairly clear. But they *may* be derived somehow
> being explicitly stored (thus in some sense they always existed and
> will), and so again, AllowCreate cannot possibly apply unless it has
> 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
> by
> an SP, for whatever reason, then AllowCreate governs the creation of
> record during authn and Terminate governs one route to its deletion",
> 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.   

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]