Re: [security-services] Does anyone create assertions with more thanone subject? (was RE: [security-services] Retracting earlier SubjectRefsuggestion)

[Ron Monzillo <Ronald.Monzillo@Sun.COM>]

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