[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Errors in WSS core examples?
Some of my comments below are about what appear to be errors in examples on the spec.
> -----Original Message-----
> From: David Rieber
> Sent: Thursday, March 04, 2004 2:14 PM
> To: 'wss-comment@lists.oasis-open.org'
> Cc: David Rieber
> Subject: [wss-comment] WSS core spec
>
> This list includes many comments, mostly on the core spec. I realize some of these issues may have been addressed already.
>
> * Section 3.4 Example, lines 301-304. Should the custom security token be wrapped inside a BinarySecurityToken element? I think the spec should set some guidelines here.
>
> * Editorial: line 417 reads:
> ...namespace} is "http://www.w3.org/2001/XMLSchema"; and which {name} is "Id."
> should be
> ...namespace} is "http://www.w3.org/2001/XMLSchema"; and which {type} is "Id."
> right?
>
> * Section 5, Security Header:
>
> The spec allows active intermediaries to add sub-elements to an existing <wsse:Security> header or add one or more <wsse:Security> headers, but it doesn't say anything about removing individual sub-elements or an entire <wsse:Security> header. This may make sense, for example, after decryption.
>
> When a node is acting on a role, explicitly or implicitly, is it supposed to process the entire header and delete it before forwarding the message or passing it up to the application? or can it process only some parts of the header and keep the rest? are intermediaries allowed to process stuff in a header not addressed to it?
>
> * Lines 474 to 495:
> Line 474: "... elements SHOULD cause a fault"
> Line 478: "... attributes SHOULD cause a fault"
> Lines 482-483: "It is RECOMMENDED that undefined elements within the <wsse:Security> header not be processed" (btw, what is "undefined"?)
> Line 491: "The receiver must (lowercase) generate a fault if unable to interpret or process security tokens..."
> Line 494-495: "Receivers MAY ignore elements or extensions within the <wsse:Security> header element, based on local security policy"
> I find all this very confusing.
>
> * Section 6.2.1, Username tokens. The schema allows a wsu:Id attribute on the <wsse:Username> element and <wsse:UsernameToken>. I think <wsse:Username> should not allow a wsu:Id.
>
> * Lines 602-608 should be deleted. The schema no longer contains QNames.
>
> * Line 630: Minor semantic issue: "If a <wsse:SecurityTokenReference> is used outside of the <wsse:Security> header block the meaning of the response and/or processing rules ... are out of scope of this specification". This fails to consider the case of a <STR> inside <xenc:EncryptedData> outside of the <wsse:Security> header, for example inside the SOAP body or some other SOAP header. Is STR allowed in those cases?
>
> * Line 648: editorial: <wsse:SecurityToken> should be <wsse:SecurityTokenReference>
>
> * Token References:
>
> Lines 661-664 state: "In particular, it is RECOMMENDED when using XML Signature and XML Encryption, that a <wsse:SecurityTokenReference> element be placed inside a <ds:KeyInfo> to reference the security token used for signature or encryption." Why isn't this a MUST?
>
> Lines 673-682 lists the "specific reference mechanisms defined in WSS:SOAP Message Security in preferred order". I do realize the "defined in WSS" part, but aside from that, why is <ds:KeyInfo> (without nested SecurityTokenReference element) not listed? judging from the examples it is allowed. It would be clearer to either include <ds:KeyInfo> on this list, or even better, disallow it.
>
> I personally find it confusing to allow so many different reference mechanisms and combinations of these. I believe this can lead to implementation erros and inter-operability problems. I would like to restrict <ds:KeyInfo> elements to ALWAYS have a <wsse:SecurityTokenReference> element when used inside <wsse:Security> headers or in encrypted data referred to from the <wsse:Security> header. The way I see it, SecurityTokenRefence is the re-usable component, some of the other elements should be restricted to sub-elements of STR.>
>
> * Example inconsistencies:
>
> Consider the extended example in section 11, a <wsse:KeyIdentifier> appears as a direct sub-element of <ds:KeyInfo> (line 1389):
>
> <ds:KeyInfo>
> <=== missing SecurityTokenReference element?
> <wsse:KeyIdentifier
> EncodingType="...#Base64Binary"
> ValueType="...#X509v3"> <=== also, according to the X509
> profile this should be
> ...#X509SubjectKeyIdentifier
> MIGfMa0GCSq...
> </wsse:KeyIdentifier>
> </ds:KeyInfo>
>
> This is arguably against the spec (but I could not find anything in the spec that prohibits this).
>
> Also, the X509 token profile, on line 366, has an example like this (which seems ok to me):
>
> <ds:KeyInfo>
> <wsse:SecurityTokenReference>
> <ds:X509Data>
> <ds:X509IssuerSerial> ... </ds:X509IssuerSerial>
> </ds:X509Data>
> </wsse:SecurityTokenReference>
> </ds:KeyInfo>
>
> but the example on the core spec, section 9.2, line 1191 has:
>
> <ds:KeyInfo>
> <wsse:SecurityTokenReference>
> <=== missing <ds:X509Data>?
> <ds:X509IssuerSerial> ... </ds:X509IssuerSerial>
> </wsse:SecurityTokenReference>
> </ds:KeyInfo>
>
> * Overloaded usage of ValueType: it is used in BinarySecurityToken, KeyIdentifier, Reference and Embedded. These are semantically different. I propose using "ValueType" for BinarySecurityToken and Embedded, "TokenType" for Reference and "IdentifierType" for KeyIdentifier. I think this would be cleaner.
>
> * Line 745: why is wsu:Id allowed on a KeyIdentifier when it is already allowed on an enclosing SecurityTokenReference element?
>
> * Embedded references: where is <wsse:Embedded> allowed? is it allowed as a direct sub-element of <ds:KeyInfo>? is it allowed outside of <ds:KeyInfo> and <wsse:SecurityTokenReference>?
>
> * Section 7.4. The ValueType attribute is missing from the description of embedded references in this section.
>
> * Section 7.4. Line 778. Why is there a wsu:Id attribute on Embedded?
>
> * Section 8. Signatures. Lines 831-832: "Multiple tokens may contain a key-claim for a signature and may be referenced from the signature using a <wsse:SecurityTokenReference>". I don't understand this sentence. One signature is produced using one key. I guess I don't understand the terminology, what does it mean for a token to CONTAIN a key-claim FOR a signature?
>
> * Editorial: Line 859. The URI for soap12-n11n does not point to the latest. The latest is http://www.w3.org/TR/soap12-n11n/
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]