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] | [Elist Home]


Subject: RE: [wss] Latest docs published (with correct links)


General observations

 

Why aren’t we using XML Schema?  It would be more precise and familiar.

Shouldn't we be using OASIS namespace declarations?

It should be stated clearly that the protections described are intended to persist for the duration of the transmission only.

Section 3 should be titled “Security mechanisms”.  It does not address what is commonly

referred to as “Quality of protection”.

The term “Timestamp” is used a little bit unconventionally.  Often the term means the time AND its cryptographic binding to a message.  In this document it is used to mean just the time.  It would be preferable to use (say) “SubmitTime” or “SigningTime”.

 

Technical

 

A couple of parameter values are prescribed (e.g. SHA-1 in the case of the password digest and “five minutes” in the case of message freshness).  The specification should be flexible in these respects.

The specification should prescribe clear behaviour for all parties in regard to freshness safeguards.  And it should require that time values be enclosed in integrity mechanisms.

<wsu:Created> appears to be just a convenient way for the originator to create a nonce.  Therefore, it seems unnecessary to require processing different from that required for the <wsu:Nonce> element.

Is it necessary to support the HexBinary encoding of tokens?

In section 10.2.2, why not just specify that the <Created> element type be xsd:dateTime?

 

Editorial

 

It is not stated what the significance of the blue text is.

The term “prepended subsequently” is jarring to the reader.  The word “subsequently” is unnecessary here.  So, it would aid readability if it were to be left out.

In line 482 say “confidential channel”, not “secure channel”.

In line 566, change “is used in a signature” to “is used for verifying a signature”.

In line 571, change “signing key” to “verification key”.

Section 6.3.4 is entitled “Processing rules”.  It doesn’t describe processing rules.  So, is there a more appropriate name?

On line 712, replace “identifiers, however” with “identifiers.  However”.

In section 8.3 use the word “element” instead of “entry”.

In section 9, replace “they will add” with “they MUST add”.

In Section 9.2, as it is strongly RECOMMENDED to use key identifiers, the examples should follow this recommendation.

In Section 9.4, replace “stream replaces” with “stream SHALL replace”.

The phrase “meaning and semantics” is tautological.

In line 1414, instead of just saying “Care should be taken …”, why not indicate that the use of a nonce guards against this?

 

-----Original Message-----
From: Kelvin Lawrence [mailto:klawrenc@us.ibm.com]
Sent: Thursday, October 17, 2002 9:42 PM
To: wss@lists.oasis-open.org
Subject: [wss] Latest docs published (with correct links)


I forgot to include the link to our page [1] in the last posting and to the draft documents [2]

[1] http://www.oasis-open.org/committees/wss/
[2] http://www.oasis-open.org/committees/wss/#documents

Cheers
Kelvin



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


Powered by eList eXpress LLC