[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] RE: Interop scenarios document issues
Hi Prateek, From the technical perspective there is nothing wrong with not having wsse:Security element on the replies if it is present on the requests together with wsu:Timestamp element. To problem is that current WS-SecurityPolicy spec cannot be used to describe it. It defines only one property - [Timestamp] (section 6.2) - on the binding scope. This property affects all messages exchanged using the binding. Which means that all requests and responses MUST have a wsu:Timestamp element. My proposal is to change the document to have wsu:Timestamp elements on all requests and responses in order to be able to use WS-SecurityPolicy to describe all the interop message formats. It seems wrong to me to try interop on messages in this TC that cannot be described by WS-SecurityPolicy. Does this make sense? Thanks, --Jan -----Original Message----- From: Prateek Mishra [mailto:prateek.mishra@oracle.com] Sent: Thursday, July 20, 2006 9:32 AM To: Jan Alexander Cc: Marc Goodner; ws-sx@lists.oasis-open.org Subject: Re: [ws-sx] RE: Interop scenarios document issues Hi Jan, Thanks for your comments. Let me know if the resolutions below are acceptable. Generally speaking, the scenarios we have submitted tend to have the minimum amount of information required to demonstrate interoperability between independently constructed implementations. So there is some mild dissonance between the two classes of interoperability examples folded togather in the document. Here are some specifics: [quote] 3. The Username for SAML 1.1 Bearer Token, WSS 1.0 binding does not have <u:Timestamp> in <wsse:Security> header. The response does not have <o:Security> header. MG: Prateek can you take this one? [quote] The lead-in to this interoperability case explains that typically this exchange is secured by HTTPS, which is ommitted here. I have added the timestamp header to the RST message as it does include a security header. I have added text stating that the response has no security header. [quote] 4. The Certificate for SAML 1.1 HoK Token, WSS 1.0 binding does not make much sense as the client does not prove possession of the X.509 certificate private key to the STS when sending the RST. MG: I'm not sure how to address this. Prateek? [quote] The leadin to this interoperability case explains that this step is ommitted here, but that usually proof of possession would be demonstrated via use of SSL or digital signature. [quote] 5. The Certificate for SAML 1.1 HoK Token, WSS 1.0 binding does not have <u:Timestamp> in <wsse:Security> header. The response does not have <o:Security> header. MG: Prateek can you take this one? [quote] I have added the timestamp header to the RST message as it does include a security header. I have added text stating that the response has no security header. [quote] 9. Issued SAML 2.0 client <-> service binding does not have message samples MG: Prateek? [quote] We hadnt planned to include this case as part of the interoperability demo. See also my message to Vijay G. [quote] 10. Delegated SAML 2.0 with Certificate for SAML 2.0 HoK, WSS 1.1 binding does not have <u:Timestamp> in <wsse:Security> header. The response does not have <o:Security> header. MG: Prateek? [quote] I have added the timestamp header to the RST message as it does include a security header. I have added text stating that the response has no security header. ---------------------------------------------------- >I've posted a new version that has been updated as described below. I >have one change left I need to look at more closely to update the >description for the mutual cert wss 1.1 binding. Prateek, can you handle >the other items? > >-----Original Message----- >From: Jan Alexander >Sent: Tuesday, July 11, 2006 1:49 PM >To: ws-sx@lists.oasis-open.org >Cc: Marc Goodner; Prateek Mishra >Subject: Interop scenarios document issues > >I've identified couple of issues in the current interop scenarios >document version: > >1. All sample messages need to be updated to use the IssueFinal WS-A >action for the RSTRC responses >MG: Done. There were a couple of examples with empty soap headers, I did >not update those. > >2. In some samples (SecureConversation binding for example) the WSS, >WSU, WS-SC and WS-Trust namespaces are not using the right URIs. > > 1. The namespaces table and some message samples use the interim >WSS 1.1 namespace before WSS 1.1 was finalized >(http://docs.oasis-open.org/wss/2005/xx/oasis-2005xx-wss-wssecurity-sec e >xt-1.1.xsd) instead of using the final WSS 1.1 namespace >(http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd). >MG: Done. > > 2. The same issue is with @ValueType URIs in STR <Reference> >when referencing encrypted keys and when using ThumbprintSHA1 or >EncryptedKeySHA1 @ValueType in <KeyIdentifier>. >MG: I think I got these, please double check. > >3. The Username for SAML 1.1 Bearer Token, WSS 1.0 binding does not have ><u:Timestamp> in <wsse:Security> header. The response does not have ><o:Security> header. >MG: Prateek can you take this one? > >4. The Certificate for SAML 1.1 HoK Token, WSS 1.0 binding does not make >much sense as the client does not prove possession of the X.509 >certificate private key to the STS when sending the RST. >MG: I'm not sure how to address this. Prateek? > >5. The Certificate for SAML 1.1 HoK Token, WSS 1.0 binding does not have ><u:Timestamp> in <wsse:Security> header. The response does not have ><o:Security> header. >MG: Prateek can you take this one? > >6. Mutual Certificate, WSS1.1 binding in the message example has the ><e:ReferenceList> outside of <e:EncryptedKey> but it needs to be inside ><e:EncryptedKey> because the <EncryptedData> inside <soap-env:Body> does >not have <KeyInfo>. >MG: Done, please double check. > >7. Mutual Certificate, WSS 1.1 binding description should be updated >because it does not use derived keys in the message examples but the >description suggests usage of derived keys. >MG: I need to look at this one more closely to get this right. > >8. The titles for SAML 1.1 client <-> service binding should be changed >as follows: > > 1. Issued SAML 1.1 Token -> Issued SAML 1.1 Token for >Certificate, WSS 1.0 > > 2. Issued SAML 1.1 Token for Certificate -> Issued SAML 1.1 >Token for Certificate, WSS 1.1 >MG: Done > >9. Issued SAML 2.0 client <-> service binding does not have message >samples >MG: Prateek? > >10. Delegated SAML 2.0 with Certificate for SAML 2.0 HoK, WSS 1.1 >binding does not have <u:Timestamp> in <wsse:Security> header. The >response does not have <o:Security> header. >MG: Prateek? > >Thanks, >--Jan > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]