Hi George,
Yeah I agree that we need to support these non-standard Username Tokens. Maybe one way of doing this is to allow a namespace'd Type by default, but to reject it if WSSConfig.isWsiBSPCompliant() is true? It seems like overkill to me to add another configuration variable to support a fairly minor difference. Any opinions? Colm. ________________________________ From: George Stanchev [mailto:[email protected]] Sent: 29 May 2009 20:48 To: 'Marc Tremblay'; [email protected] Subject: RE: WSS-148 WCF interop issue: Namespace not honored incase of attributes. >From the specs: line 239: /wsse:UsernameToken/wsse:Password/@Type The Type attribute is clearly not namespaced. If it were WSS namespaced, then the line above should have been /wsse:UsernameToken/wsse:Password/@wsse:Type, but its not. For reference look at line 328 in the spec and you will see clearly wsu:Id attribute namespaced properly. Microsoft is clearly breaking the standard of requiring Type to be namespaced. That being said, the reality is what it is. I wonder if WSS4J devs would accept some kind of MS-compatibility mode that is turned off by default but can be turned on for WCF interoping deployments (may be via configration)... George ________________________________ From: Marc Tremblay [mailto:[email protected]] Sent: Friday, May 29, 2009 12:27 PM To: [email protected] Subject: WSS-148 WCF interop issue: Namespace not honored incase of attributes. Hello, I have recently encountered the issue described at https://issues.apache.org/jira/browse/WSS-148 and am wondering if it doesn't make sense to allow for the Type attribute to be namespace qualified. I've examined Page 8 of the Web Services Security, UsernameToken Profile 1.1 spec and while the example XML doesn't namespace qualify the Type attribute, I don't see anywhere in the spec where it states that the Type attribute must not be namespace qualified. If fact there is no mention of namespace qualifying attributes in the spec that I can see. As such, I'd like to suggest that WSS-148 be reopened and wss4j modified to accept both unqualified and namespace qualified Type attributes on the Password element. I'd be happy to create the necessary patch. Thanks, Marc
