Re: XKMS and SOAP Message Security tokens

Hi Frederick,

If you're available for the xkms telecon on Thursday, I'd
suggest we add this to the agenda, for discussion after
we get past the "get to CR" things we have to handle first.
(If we don't get to it, I'll kick the list discussion on
Friday.)

That sound ok?
Ta,
Stephen.

Frederick.Hirsch@nokia.com wrote:
> 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/
> 
>  
> 
>  
> 
>  
>  
> 
> 
>

Received on Tuesday, 16 December 2003 08:34:07 UTC