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


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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 

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 

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 

- 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 

- ValueType of <wsse:SecurityTokenReference> ([WSSUSERNAME] Line 236)
  note that the URI fragments are relative to the URI for this 

- 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 

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)

- For URIs defined in "UsernameToken Profile 1.0" ([WSSUSERNAME] line 8)

- For URIs defined in "X.509 Certificate Token Profile" ([WSS-X509] Line 

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 
[WSSUSERNAME] oasis-200401-wss-username-token-profile-1.0.pdf(15 March 
[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 
The location (base URI) of the "repository" where versions of this 
document can be retrieved.

At the beginning of 3rd Interop, some vendors(including Hitachi) used 
the namespace URI of WS-Security, that is;

WS-I Basic Security Profile WG also uses the namespace URI in their 

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:
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";.

TC has to take action within 30 days, and I believe that our choice is
 (a) or (c). (errata or amendment)

(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]