FW: Resolution - XKMS and SOAP Message Security tokens

FYI
 
Folks on the XKMS list haven't had time to respond, but I've seen no email  traffic from the original issue, so anticipate that this resolution will be acceptable. Anyone with an XKMS client or server implementation that is concerned should indicate that concern.

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones




-----Original Message-----
From: www-xkms-request@w3.org [mailto:www-xkms-request@w3.org]On Behalf Of ext 
Sent: Thursday, December 18, 2003 12:05 PM
To: www-xkms@w3.org
Subject: Resolution - XKMS and SOAP Message Security tokens


At today's XKMS call we discussed this issue, and came to the following conclusions. 
 
1. Clients can map SOAP Message Security SecurityTokenReferences contained in ds:KeyInfo and associated SOAP Message Security tokens to a ds:KeyInfo format acceptable to XKMS server using ds:KeyInfo definitions.
 
1b. Necessary extensions to ds:KeyInfo will be addressed by the W3C in the future, but common forms like X.509 should not be a problem now.
 
2. Because of this approach, potential profiling by WS-I restricting the use of ds:RetrievalMethod in a SOAP Message Security ds:KeyInfo context should not be an issue.
 
3. Deeper thought and further exploration of such issues, including Kerberos token processing, may be considered later as part of XKMS rechartering after the current work is completed.
 
If I captured this correctly and there is no objection to this resolution, I will share this resolution with the Oasis WSS TC and the WS-I Basic security profile group.
 
thanks

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones




-----Original Message-----
From: ext [mailto:Frederick.Hirsch@nokia.com]
Sent: Friday, December 12, 2003 3:21 PM
To: www-xkms@w3.org
Cc: wsi_secprofile@lists.ws-i.org; wss@lists.oasis-open.org
Subject: [wsi_secprofile] 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/