- From: <Frederick.Hirsch@nokia.com>
- Date: Tue, 16 Dec 2003 09:38:14 -0500
- 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 UTC