OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [security-services] Proposed DoNotCache Condition

As we discovered during the interop dry runs, short validity periods can
cause real problems due to time synch issues.  In an environment with lax
time synch, you have to keep a wider window on the NotBefore and
NotOnOrAfter values.  Some sort of doNotCache option seems to be a
reasonable way to force the receiver to not hang onto the assertion.

Rob Philpott 
RSA Security Inc. 
The Most Trusted Name in e-Security 
Tel: 781-515-7115 
Mobile: 617-510-0893 
Fax: 781-515-7020 

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, November 05, 2002 9:06 PM
To: 'Hal Lockhart'
Cc: 'SAML'
Subject: RE: [security-services] Proposed DoNotCache Condition

>But the SSO Assertion can contain attribute statements. Since
>decisions may be based on those attributes, it would be nice to know
>they are expected to change soon. However, this is not the use case I
>really interested in. (see below)

Ok, but if you think about it, putting other statements in the SSO
assertion has some serious problems. The assertion has to be short
lived, so it doesn't seem very practical.

OTOH, one could embed an additional assertion with different validity in
the samlp:Response, and that seems to have the semantics one would want.
The SSO assertion is rendered invalid quickly, but the additional data
can last however long is proper.

-- Scott

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC