Subject: RE: [wss] HMAC Key Derivation in UsernameToken Profile Issue
At 01:05 PM 1/12/2004, Blake Dournaee wrote: >Jerry, > >It was my understanding that this text is going in Section 3.2 of the >UsernameToken Profile and not the core. My bad. I saw the 7.1 section reference and though it was being proposed for that. >Blake Dournaee >Senior Security Architect >Sarvega, Inc. >http://www.sarvega.com/ > > >-----Original Message----- >From: Jerry Schwarz [mailto:firstname.lastname@example.org] >Sent: Monday, January 12, 2004 1:02 PM >To: NISHIMURA Toshihiro; email@example.com >Subject: Re: [wss] HMAC Key Derivation in UsernameToken Profile Issue > >At 07:00 PM 1/9/2004, NISHIMURA Toshihiro wrote: > >Blake, > > > >I agree. Something should be mentioned about key derivation. > > > >Section 7.1 of the core spec says about <wsse:SecurityTokenReference> > >element as follows and our current discussion is about this case: > >| This element can be used as a direct child of <ds:KeyInfo> to > >| indicate a hint to retrieve the key information from a security > >| token placed somewhere else. > > > >So, how about including sentenses such as: > > When a UsernameToken is referenced from <ds:KeyInfo> element, > > it can be used to derive a key. The detail will be specified > > elsewhere. > > (Please give us better English wording!) > >in Section 3.2 of UsernameToken profile? > >I don't like it. > >If we want to specify the use of UsernameToken to define a key then we >should do so in the UsernameToken profile, not in the core. The >sentence >above would be just as valid if it began > >"When a security token is referenced ..." > >In other words it is essentially vacuous. > > > > >Now, I wonder about other tokens: > > When SAML Token is references from <ds:KeyInfo>, what does it mean? > > Should we say something about it in SAML Token profile? > >If we want to specify it then yes it needs to go in the SAML Token >profile. > > > >--- > >Toshi > > > > > >At Fri, 09 Jan 2004 10:43:12 -0800, > >Blake Dournaee wrote: > > > 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; firstname.lastname@example.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:email@example.com] > > > Sent: Thursday, January 08, 2004 9:12 PM > > > To: firstname.lastname@example.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 > > > >To unsubscribe from this mailing list (and be removed from the roster >of > >the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgrou >p.php. > > >To unsubscribe from this mailing list (and be removed from the roster of >the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup >.php.