Re: [ws-sx] RE: Interop scenarios document issues

[Prateek Mishra <prateek.mishra@oracle.com>]

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-sece
>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
>
>  
>