Actually, it was George who pointed out to me that the qualified and unqualified forms are different as far as XML is concerned.
I think ideally, WSS4J would need to be configurable by the service provider as to what should happen when the wsse:Type attribute is present. If you don't need/want to accommodate VS 2008/WCF clients then the current behaviour is correct. However, from a practical point of view, it would be nice to be able to configure WSS4J to accept wsse:Type when Type is absent. Naturally, this would imply that there couldn't be application specific semantics to a wsse:Type attribute. Perhaps it would make sense to implement this as a distinct UsernameTokenProcessor so as to not contaminate the current one with deviations from the spec? I wouldn't expect the default behaviour to accept wsse:Type, but a simple FAQ entry could refer to this other UsernameTokenProcessor and point people to the appropriate place to bug MS to fix WCF. M. On Sat, May 30, 2009 at 3:01 AM, Werner Dittmann < werner.dittm...@t-online.de> wrote: > Just some info about "MS compatibility modes": some time ago (in > WSS4J 1.0) we had built in a specific MS proprietary mode for > password handling. This mode caused several problems later about > interoperability with other, non-MS implementations. > > Implementing a MS-specific handling could also lead to interop > problems with other implementations that are compliant to the spec. > > As Marc said "wsse:Type" and "Type" and different entities. The > spec allows to specify _additional_ implementation specific > attributes. If an implementation now adds such an attribute and uses > "wsse:Type" for its purposes - what should WSS4J then do? Is it > a "MS misbehaviour" and interpret it as the standard password type > or leave interpretation and handling to the specific implementation? > > That's why XML has name spaces and why implementation must use > name spaces in the correct way. > > Best Regards, > Werner > > > Marc Tremblay schrieb: > > 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 > >>> > >> > > > >
