The OASIS WS-Security supports passing security tokens, digitally signing messages for integrity, and encrypting messages for confidentiality. This is a ratified standard that is backed by the industry, and most vendors have implementations for this standard at least in the low level plumbing. WSE 2.0 has fully integrated support for this standard that is tied to the Visual Studio 2003 IDE, with step-by-step wizards to guide you through setting up your services and clients to send/receive messages using this standard. From an interoperability perspective you can use WSE 2.0 on the .NET side, and be sure that you can successfully send/receive WS-Security messages as the standard is described today. Today there are some variations in how platforms support WS-Security as they evolve to support the approved standard, but you can usually overcome those issues by overriding default behaviors of the respective platforms.
On the subject of attachments, that's another story. The specification that has been ratified for attachments as of January 2005 is MTOM. This specification has not been implemented yet in any platform (too new). Today, the Basic Attachments Profile from WS-I recommends the use of SOAP with Attachments (SwA). All Java platforms support SwA today (in the pipeline at least) however .NET does not. Instead, .NET supports DIME/WS-Attachments with WSE 2.0. You CAN use this to interoperably work with attachments since there are also open source Java libraries to support DIME, however since the MTOM specification will be MIME-based, like SwA, and this is a deviation from the current recommendation from WS-I, it would be better to purchase one of the SwA libraries to do attachments with .NET today.
Problem: these aren't integrated with WSE 2.0, so if you want attachments AND security AND routing AND policy…you can't get it with SwA, only with DIME. So, the dilemma? Wait for WSE 3.0 (which should line up with the release of .NET 2.0, Whidbey) or use DIME so that you can have it all, and ask your Java partners to use their DIME libraries. Otherwise, you can forego WSE 2.0 and use SwA. Neither of these are truly acceptable solutions in my opinion, the best solution would be to begin working with MTOM as soon as a WSE 3.0 technical preview is available from Microsoft, and just get moving on releasing the finally approved standard for attachments.
WSE 2.0 keeps up because it leverages some of the extensible support component the standard is not well received, but because most vendors are still catching upthey aren't yet caught up to fully support the Basic Security Profile from WS-I: www.ws-i.org). That makes it possible to send user credentials in a standard fashion (UsernameToken Profile), digitally sign messages with a derived key token from the UsernameToken, or using X.509 digital signatures.