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] Clarifying validity times in profile proposal

> But I think plain old notbefore/after conditions have a simple general
> use:  when some application (or profile, if you prefer) defines doing
> something with SAML assertions, at some point an assertion recipient is
> processing the assertion, and the first step is figuring out if it's
> valid.  If the "effective time of processing" is outside the validity
> period, then the assertion is invalid, and the application rules say what
> to do in that case (or say that nothing more can be said about that case,
> or something).  This time-constraint concept may not be useful in all
> apps, in which case the app should say that these conditions 
> should not be put into assertions for use with that app.

So the primary validity attributes are profile dependent. Fine, we need to
say that in core.

> I think what you're saying here is that the assertion containing the
> authentication statement has *only* the meaning: "this authentication
> event happened".  Making this simple statement into a protocol message
> that is to be interpreted by a recipient as "establish a security context
> for the subject, as part of this overall profile" is what is done by
> wrapping it in a Response.

Not just the wrapping, but the use of the protocol and an endpoint at an SP
that is specifically defined as that protocol's endpoint.

> Are there other kinds of BindingConditions that you have in 
> mind that are imilar enough to make this a general mechanism?

Yes. I originally just included things like InResponseTo and Recipient, the
"response trappings" that are used to secure the protocol when used with the
POST binding.

> Seems to me the point of this is to constrain the validity period for
> bearer assertions to be used for authentication; why not just say that in
> a condition and be done with it.  "BearerAuthenticationValidity" is
> cumbersome but precise IMHO (assuming that this special condition is
> needed at all).

It may be that the only such trappings are bearer issues. If so that might
make sense.

-- Scott

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