[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Stateless Conformity To SAML
Scott, Am I close when I interpret your distinctions as that between a "categorical" claim and a "contingent" claim of conformance? In a categorical claim of conformance, the implementation would be attesting to the ability to assure these capabilities. Every breakdown would necessarily redound to the SAMLv2-conformant claiming implementation (product/component). In a contingent claim of conformance, the implementation would declare dependencies in deployment for constructing the desired (persistent, transient, whatever) integration and consistency. Every breakdown would involve determination of failure points ... and any one breakdown in a SAMLv2.0 transaction could redound to a non-SAMLv2.0 component. > seems to under[m]ine what conformance is supposed to mean One important perspective, it seems to me, is influence in the context of practicality. Ungoverned conformance claims help, but are valued less than those with some governance. (This is not news here, but it establishes that for some capabilities in a specification there might not even be a conformance profile; while for other capabilities, claims are not creditable in the marketplace unless/until they are independently validated.) At Liberty, to operationalize the SCR we established test procedures that allow licensees to claim *interoperable* conformance within that "contingent" definition. However, the Liberty interoperability conformance program has not tried to reach the levels of assurances as, say, the GSA eAuthentication Interoperability Lab for their SAML1.0 artifact profile in a federated environment. Two of the very same products that have gone through LAP conformance (on ID-FF) are among the 6 having passed through the eGov lab (HP SelectAccess v5.2, Sun Java System Identity Server v6.1) and there the Enspire team goes far beyond Liberty, in taking CoTS packages and combining them with the appropriate systems to complete that "contingent" environment. And then they test the claims. Does that help? --Nick Scott Cantor wrote: > > > I like your approach of thinking from the other view. I think, > > however, it's a bad idea to conceive of a 'general' SP that claims > > support for name id mgt but that cannot/doesn't actually store > > (or cause to be stored) persistent records. > > But "store" and "cause to be stored" are two fundamentally different > implementation strategies that are (as I understood it) > exactly what's at > issue here. > > I can implement a largely stateless system that > implements the protocol by "causing to be stored" the > result of the messages. It's not up to me to make it > happen, and I can't be blamed if the deployer refuses to > implement the necessary write-back because he doesn't > want to. Nor is that non-conformant, but rather a > deployment choice (as long as I return an error when I'm > asked to process the change and the write fails). > > > Where we would run into trouble, I think, is if an > > > implementation stores persistent records of user > > > federations but doesn't support Name ID Management > > > (federation termination in particular). > > Well put. This is one specific way in which the > > 'stateless' implementation is problematic, and for > > which its designers would probably have to rely on > > failure modes ... which would seem to shorten the life > > of two important utilities of such a "device" (speed > > and independence). > > But an implementation may well "support" persistent > records of user identities (I prefer that to the term > federations) without "storing" them. > > Does conformance need to distinguish such a case? From > your previous note, it sounds like this was handled by > making qualified statements of conformance, but that > seems to underline what conformance is supposed to mean, > and I didn't see any guidance in the SCR for how that > works.> -- Scott > > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/security-services /members/leave_workgroup.php.