RE: [security-services] Stateless Conformity To SAML

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

> So if we refer to the "implementation" as the vendor product, and the
> "deployment" as what I do with the product, then...if I chose not to
> allow my SAML environment to write to my internal enterprise data
> stores, will I then be in a position of having a non-conformant
> deployment?  I think we would like to be in the position of claiming a
> conformant deployment.

I didn't think deployments were evaluated on the basis of conformance,
implementations are. You pick the features you need to use for your
deployment, and you expect them to work to the spec.

> If the vendors are required to implement Name Identifier management and
> companies are not willing to allow the internal write interaction (a
> very possible scenario) then the vendors must design for this
> restriction.

That seems like a pretty significant restriction. It seems strange to me to
expect a SAML product to manage data that is going to be a part of my
customer information when I already have an infrastructure for that, and
presumably one that's much more well equipped to do so.

But even if I did, so what? I don't see how conformance to a protocol says
anything about the way the implementation does or doesn't manage data. In
other words, I think I can implement a conformant product that doesn't
internally handle all this in any but the most rudimentary way, and that I
wouldn't expect anyone to use in practice. So does that make the claim of
support for the protocol worthless?

> Last, I took the term "statefulness" in this thread to mean the ability
> to write to a persistent information store.  Probably not the correct
> use of the term, but that was how I connected it to Name Identifier
> management.

We're (or maybe just I'm) mixing issues in the thread. I presume the state
concerns are more around the ability to implement a back-channel message,
meaning at least some state would have to be maintained off the client. That
may or may not be a persistent store.

Whereas the identifier mgmt stuff to me is entirely about management of
information associated with persistent identifiers, and the SAML end of it
is purely a communications vehicle for getting information propagated in the
context of SSO. Storing it internally seems like a limiting idea to me. And
I realize you don't mean that you'd expect to have to store it internally,
but I'm not sure why I'd ever want to.

-- Scott