XKMS and SOAP Message Security tokens

The Oasis WSS technical committee [1] is producing a specification that outlines how XML Digital Signature and XML Encryption may be used in the context of SOAP messaging to provide integrity, confidentiality and origin authentication.
 
Part of this work has involved defining new methods for conveying key information within ds:KeyInfo, specifically, defining a SecurityTokenReference element that allows a URI reference to a security token in the SOAP header, this token being used to convey key information, for example. This specification allows but does not encourage other uses of KeyInfo to carry keys.
 
A SecurityTokenReference may provide a direct reference, very similar to RetrievalMethod, with URI and Type. A difference is that the SecurityTokenReference has an id attribute. A SecurityTokenReference may also provide a key identifier reference,  allowing  a reference to tokens that do not support an id attribute. This has no analog in the XML Sig recommendation. A SecurityTokenReference may also contain an embedded token, one within it, and in conjunction with a STR Dereference transform (Security Token Reference Dereference Transform) this allows references to the SecurityTokenReference's content itself.
 
Thus the SecurityTokenReference provides an extensible means of referencing key information, allowing possibilities not directly defined in the XML Signature recommendation. The SOAP Message Security specification also allows for binary security tokens that may carry keys, providing an extensible means to convey keys in a security header. An example is an X509 binary token type.
 
In discussion at WS-I [2] is the possibility of disallowing certain methods of conveying keys, such as ds:RetrievalMethod within a ds:KeyInfo, in favor of supporting SecurityTokenReferences.
 
While it seems reasonable to expect to use an XKMS XKISS service to validate tokens, for example X509 binary security tokens,  will requiring KeyInfo to use SecurityTokenReferences in conjunction with security tokens make this difficult with existing or planned XKMS implementations?
 
This raises some questions about the XKMS recommendation [3]
 
1. Does it make sense to use an XKMS server to validate key information associated with SOAP Message Security signatures?
If so, does XKMS require a ds:KeyInfo to be conveyed to the server, or can an arbitrary security token as defined in SOAP Message Security (or one of its token profiles) be conveyed as well?
 
2. Is there anything to preclude an XKMS implementation from supporting processing of SecurityTokenReferences within a ds:KeyInfo. or processing security tokens from a SOAP header block?
 
Specifically, should KeyBindingAbstractType (Section 5.1.1) be extended to allow a BinarySecurityToken (or other security token) to be conveyed in addition to KeyInfo? Should this type allow extensibility? 
 
Second, is the UseKeyWith table in 5.1.3 the correct place to define identifiers corresponding to WSS security tokens, indicating for example the soap message security application with an x509 token...

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones

[1]  http://www.oasis-open.org/apps/org/workgroup/wss/

[2] http://www.ws-i.org/

[3]   http://www.w3.org/TR/xkms2/