[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Random Overdue Question on SubjectConfirmation
> Thanks Scott, I'll admit to being in the 99.9% of the population that > doesn't fully understand subject confirmation but aren't NotOnOrAfter and > Recipient in SubjectConfirmationData also redundant > AudienceRestriction/Audience and NotOnOrAfter Conditions? Recipient (badly named, it's inherited from SAML 1.1), is a location, not an identity. Audience is an identity. Who as opposed to where. They are largely redundant from the standpoint of the SSO threat model, but they aren't at all the same thing. One is also assertion-wide and one is limited to satisfying a particular confirmation. The NotOnOrAfter attributes are separate because a limit on satisfying one confirmation method doesn't have to be a limit on use of the assertion for some other purpose, or a limit on an additional confirmation method. A typical use case would be to limit bearer confirmation, but leave a holder of key confirmation for delegation unbounded (other than by the Condition as an upper bound). Subject confirmation really isn't that complicated. An assertion without one is just data. An assertion with one is a security token that is bound to the client(s) that can satisfy the confirmation. The method determines what the underlying security technology for the token is, because SAML has none itself. In effect, you need "subject confirmation profiles" for any of the possible proof mechanisms you want to support, just like WSS needed token profiles. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]