RE: [security-services] Stateless Conformity To SAML

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

So, a SAML product/component is part of a system of (here)
name ID mgt. It may carry out that job through it's own
devices or through integration with some other (standard,
say) facilities. Is that the base sense? 

And that beyond that there may be a name ID mgt participant
that wishes to be entirely stateless (well, single state,
Prateek's #1), with no sense of changing state of its initial 
name ID mgt state as internalized, not even through associated 
facilities?

Interpreting this from the Liberty Alliance interoperability 
conformance perspective effort, I'd guess we'd expect, in the
base sense, that the product/component represent itself as 
"Liberty Alliance Interoperable" conformant to name ID mgt 
only in conjunction with details on the specific additional 
facilities needed. Thus the component is a plug in, or feature, 
or embedded capability, or some such. LAP has several cases of 
this. (Scott wins that bet!)

This just demonstrates how conformance is carried out in one way
(as Scott mentions) and the deployment and marketplace claims are 
represented in complimentary by different ways (and ... how the 
requirements of a conformance program might help to moderate that).

But the second case is one apart. This seems to me to fail
the test of an appropriate *general* name ID mgt participant. 

As I suggested in the call, it might be useful to consider the 
perspective from a third party, not the SP, not the IdP, but 
rather an auditor of the network state. Here, after an update, 
the auditor will expect the "single state" participant to respond 
with the updated state information. The only mitigation for 
failure would be, e.g., metadata that informs the auditor of 
the 'special' configuration of the 'single state' participant.

To me this suggests we have the requirement that any product
or component claiming conformance to name ID mgt profiles must 
be able to demonstrate state awareness, however effectively 
marshalled (Prateek's #2, #3, etc).

And the additional possibility that we create a conformance 
profile for this "Stateless assertion consumer/generator" which 
can require they participate the name id mgt, but only at that
"stateless" level.

My own intuition is that this latter case, although a bit
interesting, will find only specialized use. This is a bit
at odds with another intuition I have, that there will be
many more IdPs in this world that we might now think. But
I suspect that folks engineering such "stateless" participants
will engineer the environment in which the devices work to 
respond more like the "base" sense above ... failure of
particular assertions will invoke network rerouting. In this
case we have to ask whether they (or the SSTC) needs a special
conformance class/role/fred/rolf at all.

Best,
--Nick

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu] 
> Sent: Friday, July 30, 2004 11:57 AM
> To: 'Steve Anderson'; security-services@lists.oasis-open.org
> Subject: RE: [security-services] Stateless Conformity To SAML
> 
> 
> > And that's my point -- a conformance claim should offer a 
> > helpful clue, and at the very least, not be misleading.  
> > Claiming conformance to Name ID management messages seems 
> > very misleading if the product doesn't have any notion of 
> > "remembering" users.
> 
> But let's be clear...I don't believe it's always the job of 
> the SAML product to do this in general. It's the job of the 
> product to inform the surrounding infrastructure that the 
> change happened. And I believe that that's how at
> least some people would expect to deploy it. It's certainly 
> how I intend to (I do wear both hats).
> 
> In such a case, my product isn't remembering the change 
> (except perhaps to modify some transitory state), but I would 
> claim that it's perfectly reasonable for me to claim conformance 
> and that it's a useful claim and not
> at all misleading. That's the crux of my argument.
> 
> -- 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.