[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] RE: Interop scenarios document issues
OK, I understand the issue now. I will update the messages accordingly. - prateek >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]