[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - sstc-saml-holder-of-key-browser-sso-draft-03.odt (sstc-saml-holder-of-key-browser-sso-draft-03.odt) uploaded
> > Sec 4, line 489: I think this is confusing in context because in fact as > the profile is written, you're NOT issuing reusable assertions and they > should still have short confirmation windows. In SSO now, the assertion > *validity period* is independent of that anyway, even with bearer. > > Can you explain this further? What is it about these assertions that > makes them not reusable? If you read the sequence diagram and the steps and follow the text, there's no opportunity to do what you're trying to do. The Response comes from the IdP, NOT the client. So there's no way for this reuse to happen unless you're talking about spoofing. The profile as conceived is a browser profile. A browser does not hold onto assertions, therefore for consistency with the existing profile, I wouldn't attempt to change the requirements in this fashion. I assumed all of the existing assertion requirements from the original profile were in effect. Since I don't see that in the text, I would say the text needs clarification one way or the other. As it's written, an SP has to guess whether to check replay, for example, and that alone would preclude reuse. My argument is the same as it was originally. I don't think it serves either use case to attempt one profile that addresses SSO with a browser and stand-alone clients. They share commonality and they also have significant differences. I would leave it to implementations to decide how to overlap them. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]