Scribe: Tom Rutt, Fujitsu
Email from Jonathan:
“
wsdlLocation is defined in the WSDL 2.0 spec [1] but that section does
not actually constrain it identification of WSDL 2.0 documents (this is
probably unintentional, and we should confirm with the WSDL WG.)
The examples in Rebecca's mail [2] (as interpreted by me):
<wsa:EndpointReference
xmlns:my="http://example.com/mynamespace">
...
<wsa:service>my:Service</wsa:service>
<wsa:serviceDescription>
http://example.com/fetch/the/wsdl/here
</wsa:serviceDescription>
...
</wsa:EndpointReference>
can thus be rewritten as:
<wsa:EndpointReference
xmlns:my="http://example.com/mynamespace"
xmlns:wsdli="http://www.w3.org/@@@@/@@/wsdl-instance"
wsdli:wsdlLocation="http://example.com/mynamespace
http://example.org/fetch/the/wsdl/here">
...
<wsa:service>my:Service</wsa:service>
...
</wsa:EndpointReference>
My proposal is to:
1) Confirm (or lobby) with the WSDL WG that wsdli:wsdlLocation applies
to WSDL 1.1 as well as WSDL 2.0.
2) Show examples in our spec using wsdli:wsdlLocation on
wsa:EndpointReference.
I'm not sure we'd need a wsa property [description(s)], the wsdlLocation
implies that and I think cleanly composes without a property but I don't
see real harm in defining that property either. If a property is
useful, perhaps it should be defined in the WSDL spec so it is
associated with the syntax more closely.
[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?cont
ent-type=text/html;%20charset=utf-8#wsdl-uri-references
[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0297.ht
ml
“
Jonathan: This extension attribute could also be placed on child elements of the endpoint ref.
Rebecca: This meets our needs.
Hugo: I support this proposal. We do not have to change our spec.
No objection to accepting Jonathan’s proposal.
Issue 33 closed with proposal from Jonathan.
Action: Jonathan to coordinate resolution of Issue 33 with WSDL working group.
Jonathan took action to take wsdl 1.1 based approach, with a port to wsdl 2.
Hugo took action to define a wsdl 2 based approach with a back port to wsdl 1.1:
Hugo email: “
Here is a proposal for using WSDL 2.0-like URIs with a WSDL 1.1
description for the default of the [action] property.
As a reminder, my motivation for sending this proposal is to:
- have similar default values for WSDL 1.1 and 2.0
- not introduce another URI for essentially identifying a WSDL 2.0
message reference as the WSDL 2.0 specification already defines one,
which can be dereferenceable
The proposal is, for a WSDL 2.0 description, use the message reference
component designator as a default value for action. It is defined in
appendix C of WSDL 2.0, and looks like:
[target namespace]#wsdl.messageReference([interface name]/[operation name]/[message label])
For WSDL 1.1, it would be:
[target namespace]#wsdl.messageReference([portType name]/[operation name]/[message name])
The example in the spec would be:
http://example.com/stockquote#wsdl.messageReference(StockQuotePortType/GetLastTradePrice/GetQuote)
and, in case the name attribute is absent:
http://example.com/stockquote#wsdl.messageReference(StockQuotePortType/GetLastTradePrice/GetLastTradePriceRequest)
I don't think that we should get in the business of specifying what
the fragment identifier means, just say that this is a URI reference
identifying the action associated with a message when none has been
specified.
Cheers,
Hugo
“
Marc H: what is “name”.
Don: Optional attribute “name” on input and output child of “operation”
Marc H: This can also name fault messages.
Mark N: media type in wsdl 2 cannot apply to WSDL 1.1 document. Using fragment identifier adds risk to our schedule.
Jonathan: there has to be a separate media type for defining a subset of fragment IDs.
Mark N: with Hugo’s approach someone would have to register a media type. If we do not register it somebody might.
Straw Poll:
Anish: Jonathan approach has to be enhanced to allow for new MEPs.
Jonathan: we have to explain how to deal with extension MEPs.
Mark N: majority is toward Jonathan’s approach.
Jonathan: need to clarify that the action URI is an opaque identifier, not intended to be dereferenced.
Action: Jonathan to modify his proposal to include new MEPs. By next Thursday.
Anish: does it apply to port type.
Jonathan: I intended the attribute to be used at epr level (e.g, if it applies to both service and port type) or just on Port type.
Action: Jonathan should apply editorial license to clarify that the location attribute can be applied at multiple levels.
No objection to close as duplicate of 33.
Issue 27 closed as duplicate of issue 33.
Action: Anish to propose resolution for discussion at next Monday teleconf.
Don Box was invited to explain the design in the member submission.
Jonathan: the three possible solutions discussed so far are:
1) wrap properties into new header
2) use attribute to flag header as refP
3)
EPR embedded into “To”
David O: pointed out his earlier email discussion, with concern about ref props/params being duplicates of user headers, particularly a security hole that allows a hacker to put a bad RefP into the EPR, ie
<SendAssetsToGrandCayman amount="all" fromacct="chris" toacct="hacker"/>
Not sure if the three proposals help.
Don: the idea of RefPs has been used in several prior MIB specs. Earlier versions of WS addressing started with EPR in “To”. We abandoned this approach because people were already using soap headers to address the thing they are talking to behind the soap boundary. The Microsoft management group also used top level header blocks to address particular management entities. We wanted to support these common scenarios. Having refPs in separate headers allows different intermediaries to act on different headers. Putting these into the single “to” header, would require definition of extensibility points analogous to the soap processing model. Allowing people to give out addresses involves a trust relationship. Sending an EPR in To is such a case. In the end it did not make sense to add a new extensibility point.
Glen: Despite the fact that soap headers are data, soap headers are speech acts. They are implying triggering something. Keeping what is being triggered opaque to sender means it does not know what the contract is. There is a two way relationship happening here, forcing the sender to send them as individual soap headers.
Don: we view this as just data being send to the receiver.
Glen: the wsa:to header is required to be used. With the current approach, wanting to be able to talk to a system with ws-addressing requires processing other headers. Given a qname of a wrapper signalling “ws-addressing” lets the receiver know that the header is for ws-addressing.
Anish: I agree with Glen. If in an EPR there is a “transfer money” property, it is supposed to be opaque. One cannot make decisions about soundness of refP because they are supposed to be opaque.
Gudge: I view Opaque as meaning you do not have to look at them, but if you want to you can.
Marc H: refPs are components of address, they are not verbs. People should not be using them as verbs.
Don: As an example, NT SACL protects a resource, and does not depend on verb.
Marc H: we keep saying refPs are opaque, however they do need to be understood.
Gudge: eg. Should not put in a refP which is a security header. Don’t do things that can break other things.
Don: the language we use to describe the opacity model is causing an inordinate concern. There is no real solution to the security problem.
Dims: If we cannot distinguish soap headers on the wire from refPs how can policy be applied?
Gudge: it is what the message looks like that matters, not the EPR.
Dims: intermediaries do not have access to what generates the eprs.
David O: Google trust example is a good one. The composibility issue is not the core problem (do not issue bad eprs). However the security problem is different. If I ask google for a ref, I have a contract. However this case is different because the receiver did not ask for the EPR. The problem is when a receiver returns a “replyTo” with a hack of its original epr.
Steve: what is original reason for refP opacity?
Paco: client should understand it has no say in manipulating those properties. The spec assumes pure echo semantics.
Rebecca: we are not going to ever be able to remove all security holes.
David O: the question is how far down the security rat hole do you go. I am talking about a single security hole. The threat I am talking about is not fixed by putting the EPR into the “to”.
Jeff: I do not understand the issue. You have to use software that is part of a trusted computer base. The example of hacked browser is strange. Also, we do not mean opaque, the wording of Paco is more appropriate.
Bob: without a mechanism to sign data all bets are off. The only way to protect against echo modification i to use signatures.
David O: we can add text to that affect.
Gudge: I am not going to trust anything unless I know it cannot be modified on the wire.
Anish: I am missing some sublety in the security scenario, could Dave expand the example.
David O: I already have done this several times in emails. Look for mail sent on 11/24.
Mark N: though we need more discussion,
Last week we asked “Should we be able to identify refPs by examining messages.”
Mark asked same question again as straw poll;:
Mark: need more discussion on Security threat alleviation.
Paco: Should ask how many people would have their opinion on the resolution of this issue depending on solving this security risk?
David O: if this security hole did not exist, I would push for status quo.
Jonathan: writing policy is easier if you know what has been inserted for ws addressing.
Straw question
If we can prove that the security hole does not exist who would be in favor of status quo?
Dave O is the only one who would change his mind.
Mark: continue discussion on the mailing list.
Issue text:
The [action] property identifies
the input/output/fault message within a WSDL port type and conveys the
semantics implied by the message. A WSDL operation name/message name does
exactly the same thing. Given this, why is it necessary to provide a WSDL
extensibility attribute wsa:Action
to set the value of the [action] property? Additionally, there is no
requirement that the value of the wsa:Action
property uniquely identify the message/operation. An issue related to this is
-- What is the relationship of the [action] property with the operation name
mapping requirement in WSDL 2.0?
Anish: part of this goes away with our new mapping for default action being applied to both wsdl versions. The only thing remaining with this issue is coordination with wsdl working group. They also may have a need to identify each individual message in an operation (due to a minority opinion on operation name feature). Our algorithm generates a URI for each message, which would satisfy this need. If the operation name feature is the same as our action property, we do not want two solutions.
Mark N: can we close this with an action item for coordination with wsdl working group?
Hugo: cases of same message name used in two interfaces may cause problems, but this should be a comment on Jonathan’s proposal.
Anish:. Wsdl Uniqueness is confined to a port type, not an operation.
Anish: same front end for multiple services needs disambiguation. We do not provide guidance on the uniqueness requirements for the user specified actionID.
Mark N: the registry or URIs solves this.
Action: Anish to look at clarity of uniqueness requirements for action id.
Action: Hugo to provide comment on Jonathan’s proposal regarding the uniqueness of Interface name included in action ID default mechanism.
Anish: this would be a good topic for a joint meeting.
Anish will raise this coordination topic with the WSDL working group.
Marc H: I would like to change algorithm to generate a non-static action id for faults, just as for non fault messages.
Anish: In and out messages are always specified, however the type of the Fault messages is not always described in the WSDL.
Marc: we could you the fixed generic fault action ID for that case. I am only concerned bout the ones that are defined in the WSDL description.
Mark N: does anyone see this as a bad thing.
Action: Marc H will enhance Jonathan’s proposal to cover wsdl defined faults as well as input and output messages.
Mark N: we had straw poll two weeks ago on this. 15 for status quo, 1 to require, 1 unsure.
Anish: I have an open Action item on this one. However I do not anticipate changing anyone’s mind. I would like a vote on this one before closing.
Mark N: Formal vote:
Does anyone object to closing Issue 23 with the status quo (i.e., destination required, all others are optional).
Oracle objects (they want service ID required, in addition to address).
Roll call for vote:
Support status quo
Sap,
Object: Oracle
Abstain: sun, HP,
Issue 23 Closed with no change required to spec.
Paul: this is orthogonal to issue regarding multiple routes in an epr.
Paul: From earlier discussions we came up with two options for solution:
Option 1: status quo.
Option 2: allow multiple in core, but limit in explicit bindings.
Now I would like to introduce a third option: leave use of multiple information headers as an extensibility point.
Paul: my preferred solution is keep the status Quo. Option 2 is the worst.
Marc H: I speak for option 2. That is, the Core should not constrain cardinality, but have the wsdl and soap bindings constrain them down to not more than one. Option 3 would produce chaos in my opinion.
Marc H: I have a trouble with knowing what to do with option 3 when someone sends multiple replyTo in the message.
Marc H: I could see people inventing other wsdl meps (not Soap MEPs).
Mark N: maybe we should wait for resolving a few more binding issues.
Proposal 1 (9)
Proposal 2 (6)
Proposal 3 (0)
Mark N: lets leave this open with both proposals 1 and 2 as possible solutions.