Interesting. Not what I'd expect, but I'm sure there's a reason for it. It's really too bad then that for having been involved in drafting the UsernameToken Profile 1.1 spec that MS would mess up their implementation in WCF.
So what would make the most sense as an approach to accommodate the qualified Type attribute? An allowQualifiedPasswordType field, or something more general perhaps? M. On Fri, May 29, 2009 at 4:54 PM, George Stanchev <gstanc...@serena.com>wrote: > It is not redundant. Read the XML specs. Password is an element. While > non-qualified subelements of a qualified element do inherit the qualified's > parent namespace, this is not true for attributes. Attributes that are not > explictly namespace-qualified do not inherit automatically the namespace of > the element they are declared in. No namspace means excacly this - no > namespace, not implictly inherit the namespace of its element [1]. According > to the specs, attributes "wsse:Type" and "Type" are two different entities. > > George > > > [1] http://www.w3.org/TR/xml-names/#uniqAttrs > > ------------------------------ > *From:* Marc Tremblay [mailto:marc.tremb...@8020solutions.com] > *Sent:* Friday, May 29, 2009 2:24 PM > *To:* George Stanchev > *Cc:* wss4j-dev@ws.apache.org > *Subject:* Re: WSS-148 WCF interop issue: Namespace not honored incase of > attributes. > > 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 >> > >
