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