OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] proposal for i122, i123, and i124



Martin,

I basically agree with Marc's comments below. One point though regarding the last point that you made.

You wrote:
> - The above question leads to another issue: The <wsrm:
> UsesSequenceSTR> SOAP header does not include sufficient information
> to actually ensure interoperability between an RMS and RMD. Even if
> the RMD understands and implements the STR, it might not be able to
> process the actual token referenced by the STR inside the
> CreateSequence element.

> MG: It is up to clients to conform to the security requirements of
> the service right?

> As an example, the RMS could use a Security Context Token with a
> derived key but the RMD does not support the particular key
> derivation algorithm.

> MG: The RMS must conform to the security requirements of the RMD. It
> could find those out either through SP or some out of band mechanism.

> Given that, doesn't that mean that the RMD must also take the (token
> qualifying) SP assertions into consideration when deciding whether
> or not to return a soap:MustUnderstand fault?


Actually, no. Understanding in the context of soap:mustUnderstand means that you understand the
semantics of the QName of the SOAP header block and agree to process it in accordance with
its specification.

However, you raise a good point. The proposal will need to take into consideration the faulting behavior
when the RM Destination does not grok the referenced token type.

Thanks for taking the time to review the proposal.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295


"Marc Goodner" <mgoodner@microsoft.com> wrote on 06/08/2006 01:42:39 PM:

> Martin, thanks for the quick review of this proposal. I’ve tried to
> answer your questions below.

>  
> From: Raepple, Martin [mailto:martin.raepple@sap.com]
> Sent: Thursday, June 08, 2006 10:15 AM
> To: chrisfer@us.ibm.com; ws-rx@lists.oasis-open.org
> Subject: RE: [ws-rx] proposal for i122, i123, and i124

>  
> A few comments / questions on the proposal:
>  
> - The usage of transport layer security protocols to secure a
> sequence is not mentioned in the proposal at all. Is that
> intentional? Since it refers to WS-SecurityPolicy (WS-SP), there are
> certainly ways to support this scenario, even without the
> requirement to use any of the additional elements introduced by thisproposal

> MG: Yes. Please see issue 75 in the SX TC where additional sub-
> assertions are proposed for sp:HttpsToken that would introduce
> additional authentication modes similar to part of the original
> proposal for 122. This would allow these additional authentication
> modes for HTTPS to compose with RM or without it.

> http://docs.oasis-open.org/ws-sx/issues/Issues.xml#i075
>  
> (one might even recommend to mutually exclude the use of the <wsrmp:
> SequenceSTR> in conjunction with the <sp:TransportBinding> assertion
> in RM?) Shouldn't this be included in the proposal as well?

> MG: We hadn’t considered excluding it, I’m not sure that is
> necessary. I could see the possibility of a transport binding that
> would have an associated token that could be expressed here. I think
> this needs further discussion to determine the correct answer here.

>  
> - The STR (and its RM policy assertion) does not provide any
> information about the actual token type and the security protocol
> used (e.g. an Security Context Token in the case of WS-SC). Again, I
> assume that the intension is to use WS-SP for this purpose.

> MG: Yes.
> But shouldn't the proposal/spec be more precise on that?
> MG: Good suggestion.
> How would the actual policy composition of the (new) RM Security-
> and SP-Assertions look like?

> MG: I can try to get some examples together. I might not be able to
> do so before early next week.

> What SP-Assertions can be nested as child elements of the
> <SequenceSTR> to further qualify the behavior and compatibility
> semantics of that new assertion?

> MG: We hadn’t considered nesting inside SequenceSTR.  You’ll notice
> in this proposal that the assertion does not have extensibility that
> would allow that. We were looking at this from the perspective of
> defining the token with SP on the same binding where the RM
> assertion and the SequenceSTR assertion appear. So as I say we hadn’
> t discussed this, it is worth exploring.

>  
> - The above question leads to another issue: The <wsrm:
> UsesSequenceSTR> SOAP header does not include sufficient information
> to actually ensure interoperability between an RMS and RMD. Even if
> the RMD understands and implements the STR, it might not be able to
> process the actual token referenced by the STR inside the
> CreateSequence element.

> MG: It is up to clients to conform to the security requirements of
> the service right?

> As an example, the RMS could use a Security Context Token with a
> derived key but the RMD does not support the particular key
> derivation algorithm.

> MG: The RMS must conform to the security requirements of the RMD. It
> could find those out either through SP or some out of band mechanism.

> Given that, doesn't that mean that the RMD must also take the (token
> qualifying) SP assertions into consideration when deciding whether
> or not to return a soap:MustUnderstand fault?

> MG: I need to think about this some more. My initial reaction is
> that in the scenario you are describing, which to me sounds like
> incorrect behavior on the part of the RMS, that a security fault
> would be returned and not a soap:mustUnderstand fault. I’ll need to
> look at this a little deeper.

>  
> -- Martin
>  
> Martin Raepple
> Platform Ecosystem Industry Standards
> SAP AG
> Dietmar-Hopp-Allee 16
> 69190 Walldorf, Germany
> T  +49/6227/7-60365
> F  +49/6227/78-44724
> mailto: martin.raepple@sap.com
> http://www.sap.com

>  
>
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Donnerstag, 8. Juni 2006 13:28
> To: ws-rx@lists.oasis-open.org
> Subject: [ws-rx] proposal for i122, i123, and i124

>
> All,
>
> IBM and Microsoft would like to submit the following proposal for
> issues i122, i123 and i124 that defines
> the mechanism that MAY be used to secure an RM Sequence, the means
> by which the RMS can be assured
> that the RMD will correctly process the extension, and the means by
> which the RMD can advertise support for the
> extension.
>
>
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]