I agree that's how the spec is written, but qualifying Type with the same namespace as Password, while redundant, doesn't change the semantics as far as XML is concerned. As the spec doesn't specifically forbid namespace qualifying Type, I would expect non-qualified and redundantly qualified forms to be treated as equivalent.
Or am I failing to understand how XML works? M. On Fri, May 29, 2009 at 3:47 PM, George Stanchev <gstanc...@serena.com>wrote: > 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:marc.tremb...@8020solutions.com] > *Sent:* Friday, May 29, 2009 12:27 PM > *To:* wss4j-dev@ws.apache.org > *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 >
