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] | [List Home]

Subject: RE: [security-services] SSO validity period

> I think it would be far better to look at the needs of SSO as being a case
> of an app/profile needing an app-specific validity period distinct from
> the general-purpose validity period.  Scott suggested this in his
> BindingCondition proposal.  I don't know if I buy that construct, but I
> think if we don't separate SSO-validity from overall assertion validity
> (and from session lifetime) thta multi-tier will be much harder than it
> should be.

I thought about this a little on the way back, and my suggestion is that one
way of thinking about this "special" condition is more or less like what Bob
suggested in his response to my original note on this topic, that it's
really a Bearer confirmation condition.

And of course, as Irving and others have noted, subject confirmation is
really just a condition.

So my idea would be to define a set of attributes in SubjectConfirmationData
when the method is bearer. Among them would be NotOnOrAfter and probably any
other stuff that needed to be signed as part of profiles that use this
confirmation method.

That frees up the "general" validity period in Conditions to be used for
whatever other purpose makes sense, or not used at all as Conor suggests
(it's optional). IOW, you can bound the use of the assertion "in general"
which would apply to its use in any other profiles or exchanges later, but
for SSO, the bearer confirmation is the real check.

-- Scott

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