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