[wss] Proposal for <XMLSecurityToken> element

[Jerry Schwarz <jerry.schwarz@oracle.com>]

At the Baltimore meeting I advocated creation of what I called a wrapper 
for XML security tokens. The basic idea is to add an element 
<wsse:XMLSecurityToken> that would have the actual security token as a 
sub-element. So for example instead of putting a <saml:Assertion ...> 
directly inside the <Security> element, one might have

     <wsse:XMLSecurityToken id="samlAssertion"  usage="access-subject" ...>
         <saml:Assertion> ... <saml:Assertion>
     </wsse:XMLSecurityToken>

If there is agreement in principal to the idea, I will provide a more 
formal proposal.

There are several reasons I belive creating <XMLSecurityToken> is a good idea.

A. In Baltimore we worked out a way for the SAML profile to refer to the 
<saml:Assertion> element in a <SecurityTokenReference> using the 
AssertionId, but it seemed a near thing to me. If AssertionId had not been 
present as an attribute of <saml:Assertion> it might not have been possible 
to make the reference. If XMLSecurityToken had been available then a 
standard form of <SecurityTokenReference> could have been used.  It's hard 
to predict what will happen with future profiles.

B. Also in Baltimore we added the usage attribute to 
<SecurityTokenReference> as a way to specify the nature of the referenced 
security token. I believe this is conceptually the wrong location for the 
usage information because the usage attribute is a claim and claims belong 
in security tokens not in signatures or encryption descriptions.  In 
Baltimore I asked  what is the claim asserted by the presence of an X509 
security token in the <Security> element.  The response was that there are 
lots of claims relating to authorities and the owner of the 
certificate.  While this is true, it is also irrelevant because none of 
these claims relate to the message. The claim that the owner of a 
certificate in the access-subject relates directly to the message.

When we look at use cases that ensure the integrity of the message by 
signing a combination of the body with other elements it is clear that the 
element containing the usage attribute must be included in the in the 
signed data.  Doing so is straight forward if it is an XMLSecurityToken 
which contains an id.

C. Consider an environment in which SOAP messages are exchanged within a 
trust domain in which there is no requirement for signatures.  There may 
still be a need for identifying parties, such as the sender in the 
<Security> header.

---------

Ron recently proposed a ProfileVersion attribute be added to 
<SecurityTokenReference>, I think it belongs on <SecurityToken> as well (or 
instead).

--------

It was suggested that some of the functionality achieved by adding a 
wrapper could be accommodated by placing a <SecurityTokenReference> at the 
top level to carry attributes such as usage. So in place of the above one 
could have.

     <SecurityTokenReference usage="access-subject">
         <!- elements to identify the saml assertion -->
         ...
     </SecurityTokenReference>
     <saml:Assertion> ... </Assertion>

I suppose this is a possible alternative, but if it it were used the spec 
would need to contain some discussion of the meaning of a 
<SecurityTokenReference> when such an element is used at the top level of a 
<Security> element.   In effect it would need a profile for 
<SecurityTokenReference>.

I do not see any advantage is using <SecurityTokenReference> in this way.