In the WS-Security SAML Token Profile, how do holder-of-key and sender-vouches subject confirmation differ, and what must the receiver verify for each?

## Where the assertion sits The **SAML Token Profile 1.1.1** (OASIS) explains how a SAML assertion, a set of statements an authority makes about a subject, is used as a WS-Security token. The assertion is either placed directly inside `wsse:Security` or referenced from it through a `wsse:SecurityTokenReference`: - A key identifier with ValueType `#SAMLAssertionID` (SAML 1.1, whose identifier attribute is `AssertionID`) or `#SAMLID` (SAML 2.0, whose attribute is `ID`). - A `wsse11:TokenType` of `#SAMLV1.1` or `#SAMLV2.0` on the reference to say which version is meant. - For an assertion that is not in the message at all, a remote reference the receiver resolves itself. The profile notes two version differences that matter to it. Besides the renamed identifier attribute, SAML 1.1 lets each statement carry its own subject and confirmation methods, while SAML 2.0 allows at most one subject and one set of confirmation methods for all the statements of an assertion. The structure of the assertion (its subject, conditions and statements) belongs to SAML itself; this profile is about **how the receiver decides the assertion applies to the message in front of it**. ## The question every confirmation method answers The profile calls the party that supplies the evidence the **attesting entity**. The receiver MUST establish the relationship between the subject and claims of the statements and that attesting entity, and systems implementing the profile MUST support both **holder-of-key** and **sender-vouches**. It also strongly RECOMMENDS an XML signature to tie message and statements together, especially over an unprotected transport. ## Holder-of-key 1. The issuing authority puts a `SubjectConfirmation` with the holder-of-key method into the assertion, and it MUST include a `ds:KeyInfo` identifying a public or secret key. The assertion SHOULD itself be signed so that key binding cannot be altered. 2. The sender demonstrates knowledge of that key. The profile says it MAY do so by signing content within the message and putting that `ds:Signature` into the `wsse:Security` header. 3. The receiver MUST NOT accept the statements on that basis unless it has validated the assertion's integrity **and** seen the key demonstrated. 4. If both hold, the statements MAY be attributed to the sender, and message content protected by that key MAY be treated as coming from it. The sender MAY also include the assertion, or an unambiguous reference to it, under the same signature, which stops a different assertion naming the same key from being swapped in. ## Sender-vouches 1. The attesting entity is presumed to be **different from the subject**: typically an intermediary that has already authenticated a user and now calls a service on that user's behalf. 2. It MUST protect the vouched-for message content, and the binding of the statements to it, against undetected modification. The profile says it MAY do this with a `ds:Signature` over the relevant content and assertions, made with **its own** key. 3. The receiver MUST have an **existing trust relationship** with that attesting entity, and MUST NOT accept the statements unless they and the message are protected by an entity it trusts to act for those subjects. In sender-vouches, the user's own key never appears; trust collapses onto the party that vouches. ## Side by side | | Holder-of-key | Sender-vouches | Bearer | |---|---|---|---| | Who attests | whoever knows the confirmation key | a third party acting for the subject | whoever presents the assertion | | Proof in the message | signature with the key named in the assertion | signature by the vouching party over assertion and content | none required by this profile | | What the receiver must already trust | the assertion's issuer | the vouching party, by prior arrangement | outside this profile's scope | | Required by the profile | yes | yes | must be conveyable, no binding check | For bearer assertions (`urn:oasis:names:tc:SAML:1.0:cm:bearer`), the profile states that it does **not** require receivers to establish any relationship between the message and the statements; conformant implementations only have to be able to carry and reference them. ## What still has to be checked - Every processor MUST apply SAML's own validation rules: the assertion's signature, its conditions and its subject confirmation data. - The profile notes that its high-level model does not separate the attesting entity from the message sender in a way that would stop replay; freshness needs timestamps or other tracking.