[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Does anyone create assertions with more thanone subject? (was RE: [security-services] Retracting earlier SubjectRefsuggestion)
Reid, Irving wrote: Irving, no objection, just an attempt at clarification ... >(here's a tricky aside: when a SAML assertion is used as a WS-Security token, and that token is taken to imply the "sender" of a SOAP message, what happens when there's more than one subject in the assertion?) > The WSS SAML Token Profile (i.e. the STP) does not give any specific significance to the message "sender". It focuses on the entity that is satisfying the confirmation method which it calls the attester or attesting entity. It expects that attesters are always doing some form of crytographic binding of their identity to the message contents. It describes how this can be done with xml signature. SSL is another possibility, and one in which the sender/attester distinction evaporates. With that background, when a multi-statement assertion is bound to SOAP according to the STP, the subjects (and any other content) of all the statements within the assertion whose confirmation methods are satisfied by the attesting entity with respect to some specific message content, may be considered to pertain to the entity from which the message content originated. >And, to try and head off another question: what about doing something like holder-of-key confirmation when there's no subject? Well, my opinion is that you're not doing "subject confirmation", so it's silly to use an element called "SubjectConfirmation" to hold the indicator. Long-time SSTC members have heard this from me before: what we really need is a > I can see the subject being optional, and thus calling the element SubjectConfirmation perhaps belies this optionality. > <Condition> element that says "assertion can be relied upon if used in a context traceable to holder-of-key"; this doesn't imply any relationship between the subject of the assertion and the sender of the enclosing message, but allows the issuer of the assertion to control who can forward the assertion. > IMV, the SAML TC should focus on structures to identify who or what can confirm an assertion and its related content. The relationship of assertion confirmation to message content should be defined by profiles that bind SAML assertions and their confirmation methods to communication protocols. Ron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]