RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue

All,

This comment by Srinivas echoes my sentiments exactly. We should say something about key derivation for the Username Profile, even if it is to say that it is specified elsewhere. Not all developers may be familiar with the WS-I BSP at first and this issue is a major interoperability stumbling block if left open.

Blake Dournaee

Senior Security Architect

Sarvega, Inc.

http://www.sarvega.com/

-----Original Message-----
From: Srinivas, Davanum M [mailto:Davanum.Srinivas@ca.com]
Sent: Friday, January 09, 2004 5:05 AM
To: Anthony Nadalin; wss@lists.oasis-open.org
Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue

Anthony, Team,

My 2 cents...We should address this issue in WSS-TC as there is already a precedent (WSE 2.0 Tech Preview) and is one of the first stumbling blocks a customer would face when doing an interop. A customer will find that 2 toolkits claiming to support the same version of the WSS spec and profiles from OASIS will NOT work out of the box and the customer will find out that he needs to request information from the Vendors about not just WSS spec compliance, but also WS-I BSP compliance which will reduce the importance of this spec.

thanks,

dims

PS: FYI, i ran into this in may of last year, see attached email on how difficult it was to get details if the spec is not complete.

From: Anthony Nadalin [mailto:drsecure@us.ibm.com]
Sent: Thursday, January 08, 2004 9:12 PM
To: wss@lists.oasis-open.org
Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue

> What do others think? I still feel strongly that this issue is a bane on interoperability for the Username Token profile.

It seems like this would be best handled by the WS-I BSP since there are many different mechanisms that could be used. Now is the prime time
to bring this up since we are in early phase of the BSP.

Anthony Nadalin | work 512.436.9568 | cell 512.289.4122

wss message