Why does STS WS-Trust spec differ for SAML usage?

WS-Security SAML token profile lists usage of 3 types of tokens represented using the confirmation-method element.

• bearer
  
• sender-vouches
• holder-of-key (HOK)

But, WS-Trust RST template (which is also exposed through WS-SecurityPolicy) lists the following token types - SAML 11, SAML 20. It doesn't list any confirmation methods - bearer, sender-vouches, HOK

Instead, it lists key-type with these values

• Symmetric
• Public
• Bearer

To request STS for SAML 2 bearer token one sets

token type = SAML2

key type = Bearer

 

To request STS for SAML 2 HOK asymmetric token one sets

token type = SAML2

key type = Public

 

To request STS for SAML 2 HOK symmetric token one sets

token type = SAML2

key type = Symmetric

What does one set to get SAML sender-vouches token? WS-Trust spec doesn't handle it today.

Why did the WS-Trust spec authors come up with another representation mechanism instead of reusing the SAML token profile mechanism of representing tokens using confirmation-method?
Hope these issues can be fixed in a later version of WS-Trust spec.