I'm working on an ASP.NET 2.0 app with WSE 3.0, that is trying to connect to a web service that was written with ASP.NET 1.1 and WSE 2. It's close, but when I try to actually retrieve data, I'm getting this error:

System.Web.Services.Protocols.SoapHeaderException: System.Web.Services.Protocols.SoapHeaderException: Server unavailable, please try later ---> System.Configuration.ConfigurationException: WSE535: The following SecurityToken QName is unsupported: http://schemas.xmlsoap.org/ws/2005/02/sc:DerivedKeyToken.

I'm not finding hardly anything when searching for any of the phrases in the error - WSE535, qname, anything. Any ideas or pointers? Any more info that I can give that would help? Thanks!

an explanation of that error should be available either from the MSDN (if it's a Microsoft error code), W3C, or WS-I.

Unfortunately, searching for any specifics from that error message ("WSE535", "The following SecurityToken QName is unsupported", etc.) isn't turning up much. A lot of the google hits are Java related for some reason, and I'm not finding much that actually *explains* what that message might mean. Any tips on debugging web services, esp from a client standpoint?

First result from an Apache mailing list:

I've developed a Web service secured with WSS4J. The client is a .NET
client using WSE. I'm using X509 tokens and the current configuration
works fine since early CVS releases of WSS4J. I recently upgraded to
1.5.0 and my java clients works fine. But the .NET client stopped
working with this message:

Message "WSE535: The following SecurityToken QName is unsupported:
http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecurity-secext-1.1.xsd:SignatureConfirmation.
Please check your configuration for registered SecurityToken qnames."

It seems to me that the new version works in WSS1.1 compliance so
following the specification sends the SignatureConfirmation. .NET is not
1.1 compliant so it doesn't expect that element.
I think anyway should exists a way to force WSS4J work in 1.0 mode
anyway, or to be backward compatible.

Thanks, I saw those results and didn't they they applied very well. It's *close*, but seems to be speaking to an Apache option. I'll check again and see if there's an equivalent .NET option. Thanks again for all your help!

This article has been dead for over six months. Start a new discussion instead.