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