W3C home > Mailing lists > Public > www-xkms@w3.org > December 2003

RE: XKMS and SOAP Message Security tokens

From: <Frederick.Hirsch@nokia.com>
Date: Tue, 16 Dec 2003 09:38:14 -0500
Message-ID: <E320A8529CF07E4C967ECC2F380B0CF901E421BC@bsebe001.americas.nokia.com>
To: <stephen.farrell@cs.tcd.ie>
Cc: <www-xkms@w3.org>, <wsi_secprofile@lists.ws-i.org>, <wss@lists.oasis-open.org>

Stephen

Yes I will be on the call, sounds good.

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Tuesday, December 16, 2003 8:35 AM
> To: Hirsch Frederick (NMP-MSW/Boston)
> Cc: www-xkms@w3.org; wsi_secprofile@lists.ws-i.org;
> wss@lists.oasis-open.org
> Subject: 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 09:39:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:21 GMT