Another way to look at this is from the point of view of the peer
implementation. That is, if my IDP implementation is talking to your SP
implementation, and I want to ensure that you have terminated any
persistent record of a federation for a given user, then I need to know
that either:
a) you support Name ID Management and will terminate any persistent
record for a given user if I tell you to do so (which, I guess, could
be a no-op if you don't store persistent records)
b) you don't support Name ID Management, but you don't store persistent
records of federations either
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).
-Greg
On Jul 30, 2004, at 12:25 PM, Steve Anderson wrote:
> I can appreciate that, but I don't think that will be the universally
> held
> view. And for those that don't, I think this is a problem.
>
> Overall, it's an issue of insufficient granularity in the conformance
> claims.
> I understand we're trying to move away from too much granularity, but
> this
> has swung to the opposite extreme, IMO.
> --
> Steve Anderson
> OpenNetwork
>
>
>
> -----Original Message-----
> From: Scott Cantor [mailto:]
> Sent: Friday, July 30, 2004 2:57 PM
> To: Steve Anderson;
> 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.
>