wss message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: XKMS and SOAP Message Security tokens
- From: <Frederick.Hirsch@nokia.com>
- To: <www-xkms@w3.org>
- Date: Fri, 12 Dec 2003 15:20:44 -0500
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/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]