[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: about Hitachi's negative vote
Dear TC Members, I'm very sorry for late explanation about Hitachi's negative vote. We, Hitachi never had intention to disapprove the proposed standard, but we have a concern to be clarified before publishing this spec. we are just hoping that the spec has to become better for all of readers. We are very sorry to confuse all of TC members especially chairs and editors. Our concern was raised from the 3rd (recent general) Interop. This Interop was done between TC ballot and OASIS ballot, so our (Hitachi's) vote conflicts with prior TC vote. We were very pleased to join the interop and it was very successful, so if our concern is resolved, we really agree that proposed standard to be approved. I show our concern as follows, and I'd like to discuss and clarify it. WS-Security uses URIs for the value of type attribute, e.g. ValueType attribute and EncodingType attribute. In the proposed specification, definition of such URIs is in the form of URI fragment. But the base URIs of these fragments are not clear at least for us. Actually, at the beginning of the 3rd Interop testing, some companies' implementation failed to interoperate. Because I think this is important issue on this spec, I'd like to propose amendment. I'd like to discuss among the TC members whether we should put this amendment into errata document or submit as an amendment specification. The description regarding the URIs are as follows; -------------------- - EncodingType of <wsse:BinarySecurityToken> ([WSS] Line 598) note that the URI fragments are relative to the URI for this specification - ValueType of <wsse:KeyIdentifier> ([WSS] Line 760) Note that URI fragments are relative to this document's URI - STR-Transform algorithm ([WSS] Line 972) Note that URI fragments are relative to this document's URI - Type of <wsse:Password> ([WSSUSERNAME] Line 170) note that the URI fragments are relative to the URI for this specification - ValueType of <wsse:SecurityTokenReference> ([WSSUSERNAME] Line 236) note that the URI fragments are relative to the URI for this specification - Token types ([WSS-X509] Line 178) note that URI fragments are relative to the URI for this specification - ValueType of <wsse:KeyIdentifier> ([WSS-X509] Line 218) note that URI fragments are relative to the URI for this specification). ------------------- It is not clear for us what the "URI for this specification" and "this document's URI" means. At the 3rd Interop, we used the following three values those are the Location URI of each document; - For URIs defined in "SOAP Message Security 1.0" ([WSS] Line 9) http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message -security-1.0 - For URIs defined in "UsernameToken Profile 1.0" ([WSSUSERNAME] line 8) http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username- token-profile-1.0 - For URIs defined in "X.509 Certificate Token Profile" ([WSS-X509] Line 8) http://www.docs.oasis-open.org/wss/2003/12/oasis-200401-wss-x509-token- profile-1.0 It is confusing for us because there are two Location URIs for each docuemnt, "http://www.oasis-open.org/committees/documents.php"; and the URLs listed above. ------ References ------ [WSS] oasis-200401-wss-soap-message-security-1.0.pdf(15 March 2004) [WSSUSERNAME] oasis-200401-wss-username-token-profile-1.0.pdf(15 March 2004) [WSS-X509] oasis-200401-wss-x509-token-profile-1.0.pdf(15 March 2004) ------------------------ Also, we are wondering that the Location URI should be used, because the Location URI is the location of the repository. The meaning of the "Location" is described in "Specification Template Instructions" as follows; -------------------- Location: The location (base URI) of the "repository" where versions of this document can be retrieved. -------------------- http://www.oasis-open.org/spectools/docs/wd-spectools-instructions-02. html#s.metadata At the beginning of 3rd Interop, some vendors(including Hitachi) used the namespace URI of WS-Security, that is; http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity- secext-1.0.xsd WS-I Basic Security Profile WG also uses the namespace URI in their profile. So we propose (1) To obtain the agreement among the TC members about the value of URIs. (2) To use same wording for base URI, "URI for this specification" or "this document's URI" (3) To write the values of URIs clearly in the spec. For reference, I extract the descritption of "XML Encryption". I think this might be a good example for our spec also. -------------------- The experimental XML namespace [XML-NS] URI that MUST be used by implementations of this (dated) specification is: xmlns:xenc='http://www.w3.org/2001/04/xmlenc#' This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML, section 4.2.1], the "xenc" XML namespace prefix [XML-NS, section 2] and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples. Additionally, the entity &xenc; is defined so as to provide short-hand identifiers for URIs defined in this specification. For example "&xenc;Element" corresponds to "http://www.w3.org/2001/04/xmlenc#Element";. -------------------- http://www.w3.org/TR/xmlenc-core/#sec-Versions TC has to take action within 30 days, and I believe that our choice is (a) or (c). (errata or amendment) http://www.oasis-open.org/committees/process.php#standard -- (a) request OASIS TC Administration to approve the specification as submitted despite the negative votes; (b) withdraw the submission entirely; or (c) submit an amended specification. -- Thank you, Yutaka Kudo. Hitachi, Ltd. --------- Yutaka Kudo, Researcher. Web Services, 202 Research Unit. Systems Development Labo. Hitachi, Ltd.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]