RE: [security-services] Stateless Conformity To SAML

["Nick Ragouzis" <nickr@enosis.com>]

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.