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: Web Services Security Issues List 24

Title: Web Services Security Issues List 24


OASIS Web Services Security Issues List

Version 24, Modified on Monday September 08, 2003 21:08:17 -0700


This table include issues from the August 26th meeting minutes  http://lists.oasis-open.org/archives/wss/200308/msg00056.html and issues on the email archive through Sep 8th.

The previous version of the issues list (Version 23) is at http://lists.oasis-open.org/archives/wss/200308/msg00053.html. An archive of the discussion list can be found here: http://lists.oasis-open.org/archives/wss/.

If you identify items that are missing or need correction please contact John Shewchuk or Vijay Gajjala.


WSS ID Type Status Issue Resolution Owner(s)
1 Technical  Closed Can we have alternative mechanisms of signature and encryption other than XML DSIG and XML Encryption? Closed on 10/8/02 - http://lists.oasis-open.org/archives/wss/200210/msg00085.html Conformant implementations must support XML sig/enc and MAY support additional mechanisms. Closed
2 Procedural Closed Clarify the IP status and licensing terms for the submissions to the working group Closed on 9/24/02 - http://lists.oasis-open.org/archives/wss/200210/msg00011.html.  References Prateek Mishra's posting.  http://lists.oasis-open.org/archives/wss/200208/msg00011.html. Closed
3 Technical  Closed Proposal to Label Tokens to Indicate Their Semantics

F2F Topic - Ronald Monzillo and Anthony Nadalin will send out a proposed set of changes.


4 Technical  Closed Why is the token in the header, and not a child of KeyInfo? Chris talked with PHB.  Chris will write up a proposal. http://lists.oasis-open.org/archives/wss/200212/msg00037.html  Closed
5 Technical  Closed Within the KeyInfo, why not use a ds:RetrievalMethod? Chris talked with PHB. Depends on 4 and conversation with PHB.   http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
6 Investigation Closed Will the authors of the roadmap submit it? Kelvin to update Road Map URL in WSS TC pages to the permanent URL. http://lists.oasis-open.org/archives/wss/200301/msg00073.html Closed
7 Technical  Closed Does WS-Security assume SOAP 1.1? Per Sept 4 minutes – it will support all versions of SOAP Closed
8 Investigation Closed Determine interest in a Use case document Formed a sub-committee, led by Erik Herring. http://lists.oasis-open.org/archives/wss/200210/msg00127.html Closed
9 Investigation Closed. Approach authors to submit the App Note to the TC http://lists.oasis-open.org/archives/wss/200301/msg00073.html Closed
10 Investigation Closed Investigate interop fest at some later time. http://lists.oasis-open.org/archives/wss/200301/msg00073.html. Closed planned interop event in the middle of June: http://lists.oasis-open.org/archives/wss/200304/msg00049.html Chair
11 Investigation Closed Pick date for OASIS submission date after initial drafts available http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Resolution: Pkan for submission by 7/1

12 Procedural Closed Remove all references to ws-routing and such References were removed. Closed
13 Technical Closed Element ordering in the Security tag. Editors instructed to clarify.  http://lists.oasis-open.org/archives/wss/200210/msg00085.html Closed
14 Technical Closed State that the recipient SHOULD authenticate the assertion issuer and ensure that the assertion has not been modified http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
15 Technical Closed Core: Spec should indicate that it is based on the SOAP messaging model. http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
16 Technical Closed Core: The spec should indicate that nonce and / or timestamp elements should be used to prevent replay. http://lists.oasis-open.org/archives/wss/200210/msg00085.html Closed
17 Technical Closed Core: Should SOAP nodes acting in a particular role create or update the appropriate timestamp element. Editors instructed to clarify. http://lists.oasis-open.org/archives/wss/200209/msg00094.html Closed
18 Technical Closed Core: No attribute or reference to the senders time. http://lists.oasis-open.org/archives/wss/200210/msg00085.html Closed
19 Technical Closed Core: Why is it necessary to special case a Username/Password POP token?



20 Technical Closed Core: Define security token propagation. http://lists.oasis-open.org/archives/wss/200212/msg00037.html
21 Technical Closed Core: Update definition of a security token to reflect role in defining key or broaden definition. Was related to 2 and 22.  http://lists.oasis-open.org/archives/wss/200210/msg00127.html
22 Technical Closed Core: Should the spec preclude security tokens whose purpose is other than to convey or bind a key to an identity or entity? Editors to clarify by added "entity" instead of "client".  http://lists.oasis-open.org/archives/wss/200212/msg00037.html 
23 Technical Closed Core: Make Proof-of-Possession a fundamental type or relationship within [sic] within the ws-security model? http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
24 Technical Closed Core: Why is it necessary to treat XML Signature elements as other than security tokens? http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
25 Technical


Core: How can a Signature element occurring outside of the header be referenced? http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Put scenarios on mailing list. Ron will dig up scenarios. The TC will try to close at the F2F. Ron will put a proposal to close this issue on the e-mail list.  Resolved to not support!

26 Technical Closed Core: What does it mean to process a BinarySecurityToken?


27 Technical Closed Core: Reference element should have an @any to allow for attribute extensibility http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
28 Technical Closed SAML Binding: Include the use of the URI attribute (on SecurityTokenReference) from the SS TC submission


29 Technical Closed SAML Binding: Should there be a reference form that carries what amounts to a SAML assertion Query such that the sender does not need to have acquired the assertion (to be able to apply it to a request)?


30 Technical


How should XML be explained. http://lists.oasis-open.org/archives/wss/200306/msg00025.html. Chris has sent mail to Editors for what they are supposed to do! Closed
31 Technical Pending Should use OASIS Namespace http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Pending, waiting for OASIS to provide solution. For now proceed as is.

Karl Best had formed committee to solve this problem. The target to resolve is in 2 or three months.
32 Technical Closed 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. Closed  in Draft 4 of Core specs.  http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
33 Technical Closed The specification should prescribe clear behavior for all parties in regard to freshness safeguards.  And it should require that time values be enclosed in integrity mechanisms. Closed  in Draft 4 of Core specs.  http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
34 Technical Closed <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. Closed  in Draft 4 of Core specs.  http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
35 Technical Closed Is it necessary to support the HexBinary encoding of tokens? Closed  in Draft 4 of Core specs.  http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
36 Technical Closed In section 10.2.2, why not just specify that the <Created> element type be xsd:dateTime?


37 Technical Closed lines 193-195: Where does the threat of replay attacks belong to? To the first or the second group? Closed  in Draft 4 of Core specs.  http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
38 Technical Closed line 238: Since this is a normative text, how "inappropriate claims" is defined here? Pending owner’s examination of changes in Draft 4.  http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
39 Technical Closed Lines 251-255: Since the UrenameToken element does not have password digest, what is the purpose of the Nonce and Created elements here?  http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
40 Technical Closed Paragraphs in lines 535-537 and 538-540 repeat each other and one of them needs to be eliminated. Closed. http://lists.oasis-open.org/archives/wss/200211/msg00044.html Closed
41 Technical Closed Line 1016: what specification's section 4.5.3 does it refer to? The above text implies XML Encryption. It should be explicit. Closed. http://lists.oasis-open.org/archives/wss/200211/msg00044.html Closed
42 Technical Closed Line 1155: the meaning of "materially" is unclear. Pending Konstantine’s review of current text. http://lists.oasis-open.org/archives/wss/200211/msg00184.html Closed
43 Technical Closed Lines 1430, 1431: The clause "these elements be included in the signature" is unclear. What does "included in the signature" mean? Should they be signed? Closed. http://lists.oasis-open.org/archives/wss/200211/msg00044.html Closed
44 Technical Closed SAML Cannonicalization http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
45 Technical Closed WS_Security Core, Draft 3 uses "Multiple trust domains" on Lines 114 and 141 but never defines this term.  "End-to-end message level security" on line 141 is also not defined.  http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
46 Technical


WSDL definitions - It seems to me that a stand-alone specification should just define the semantics of its elements.  If an application wants those semantics, then the application WSDL should specify the header as being required.


Hal: follow up and find out what the real issue is. Hal followed up: http://lists.oasis-open.org/archives/wss/200305/msg00006.html

47 Technical Closed Add example.  Working Draft 3.  Page 21, Section 7.1, lines 644-648, recommends that <wsse:SecurityTokenReference> element should be used as direct children of <ds:KeyInfo> elements to retrieve signing and encryption certificate when using XML Signature and XML Encryption. Although in section 8.4, there is a XML Signature example for using <wsse:SecurityTokenReferences> element within the <ds:signature>'s <ds:KeyInfo> element, there is no examples provided to using SecurityTokenReference element for XML Encryption in section 9. E.g., Section 9.2 does have a <wsse:KeyIdentifier> contained within the <xenc:EncryptedKey> element. However, it does not have the <wsse:securityTokenReference> element encapsulating the <wsse:KeyIdentifier> as specified in section 7.3.



48 Technical Closed Make URI attribute required.  Working Draft 3. Page 22, Section 7.2, lines 662, indicates that SecurityTokenReference/Reference/@URI is an optional attribute. However, the corresponding XML Schema for WS-Security core specification does not explicitly specify the the attribute "URI" of the ReferenceType complex type as an optional attribute by use of "use=optional". I suggest that the URI attribute be required rather than be optional as stated on line 662.



49 Technical Closed Working Draft 3. Page 26, Section 8.4, lines 852-856, indicates a specifialized type of <ds:KeyInfo> element that although is compatible with Section 7.1, I am concerned that the core specification is silent on the subject of acceptability of processing a signature element that uses an in-line X.509 data (representing, e.g., a signing certificate). What processing behaiour is expected from WS-Security compliant system that may receive a SOAP message that contains a signature element in its SOAP security header, i.e., <wsse:security>, that has a <ds:KeyInfo> element that does not contain <wsse:SecurityTokenReference> element rather contains an in-line X509 data pertaining to the signing cert? I think the specification needs to clearl state that all <ds:KeyInfo> instances that contain in-line cert data are also acceptable in addition to <SecurityTokenReference> element option if indeed we are allowing such in-line X509 cert data type of KeyInfo element be part of signature elements. The motivation of using SecurityTokenReference is mostly in the use case where the same signing certificate, for example, may be used to generate multiple signature elements (i.e., when same signing cert is used for signing multiple SOAP message parts) within a <wsse:Security> header. Having specific wordings of minimum requirements of what a SOAP/WS-Security sending and receiving application must support w.r.t. KeyInfo elements will help in security interoperability tests.


50 Technical Closed Sections 7.1 (beginning at line 617 of Draft 3 of the core) through 7.3 define the Security Token Reference Element, Direct References and Key Identifiers. I find the use of these varying forms of references confusing. Perhaps Direct References and Key Identifiers are the 2 forms of STRs, but it looks like there is also a n elemental form of STR that is neither a direct reference or a key identifier.


51 Technical Closed The example beginning at line 637, seems to contain a "direct reference" (in the section on STRs), which makes thedistinction between STR's and direct references difficult (for me) to understand. http://lists.oasis-open.org/archives/wss/200211/msg00057.html Closed
52 Technical Closed The example in section 3.4 (line 278) seems to have been set up to do a reference bywsu:id attribute value, although the reference is done by URI where the value of theURI is the attribute value. Is this the prefered use model? or would we expect a simpleSTR with a wsu:id value as apposed to a Direct reference/URI to be used? The description of key identifiers seems to imply that Direct references are theprefered form of reference, and where they cannot be used a key identifier isrecommended.



53 Technical Closed Section 6.1 Usernames  and Passwords, beginning at line 422, defines the use of the <wsse:UsernameToken> element "as a way of providing a username and optional password information". The definition of this tokenmakes no mention of its potential value in defining the key to supportthe signing or encryption of the attached SOAP message.  I realize that the
core document is intended to serve as a framework, but it seems less thanobvious from the description that these tokens could be used to identifya signing (or encryption key); which perhaps is the most significant usecase that features such tokens.

The example in section 3.4  beginning at line 248,  seems to depict the useof such tokens (as revealed by lines 299-300), as a means to carrya password derived signing key. However, the importance of this example,warrants further discussion in section 6.1.


54 Technical Closed i) Lines 180 to 184: It is not clear to me whether this definition is meant to describe a case of delegation where the client and sender are two different entities or whether the sender is the channel acting on behalf or a client.  From the definition on lines 217 to 223 it appears that delegation is not intended.  Either way I believe this paragraph should be clarified.

ii) Line 294: Should read Lines (005) to (009) .

iii) Line 461: I believe that this line should read - "This required element specifies the username of the authenticated party or the party to be authenticated"  NOT "of the authenticating party."  A clarifying question - am I correct in believing that this specification does not intend to prohibit the receiving party from using the username and password to authenticate the client?

iv) Lines 534 & 535: I believe that these lines should read " ... binary or XML tokens ..", not just "binary tokens"

v) Lines 575 to 588: Are these lines needed since we RECOMMEND that Exclusive Canonicalization be used?

vi) Section 6.3.2:  We say in the WSS-SAML specification to use the assertion id to reference SAML tokens, not to use the wsu:Id and license id for XrML?  This section should state this and shouldn't unequivocally use "SHOULD" for the wsu:id attribute.

vii) Section 7.1 & 7.2: These sections also don't mention assertion id's for SAML and license id's for XrML.

viii) Section 7.4:  This section only discusses BinarySecurityTokens.  SAML also has a KeyInfo token.

i) to be corrected in drafts - pending.

ii) corrected in draft 4 of core specs - pending.

iii) need to correct draft - pending

iv) closed.

v) closed.

vii) closed.

viii) closed.

55 Technical Closed Is it really appropriate to endorse a claim via encryption? Perhaps line 209 in 3.1
should be changed to read: "that is digitally signed by the authority."

Editorial comment - the word "unendorse" can be misinterpreted as some sort of revocation.
I'd argue, remove it from line 208 ("A claim can be endorsed by a trusted authority.") and
then begin line 213 with "A claim may be trusted without explicit endorsement if there is ..."

Editorial - line 362 in 4.2, spell out "Post-Schema Validation InfoSet". I guess this last paragraph says that for non-schema aware processors, support for wsu:Id is optional but recommended? Wouldn't it be better to require support regardless of implementation?


56 Technical Closed General issue with the use of the "utility" namespace for defining elements and attributes used in wsse. It has not been explicitly stated anywhere that I am aware of that the WS-Security TC is responsible for defining this namespace and its associated schema. WS-Security cannot just presume the existence of the utility namespace schema.  ... If there is an expectation that "utility" is to be a truly general Web Services Utility namespace, then it may need to be defined by another TC with input from other Web Services-oriented bodies. But then, again, WSS won't be able to presume its existence at this time.



57 Technical Closed [Section 4.2 and elsewhere] I do not see any value in using "wsu:Id" when the base XML schema ID Type is available. This is especially true since "wsu:Id" is simply defined in utility as just being of type "xsd:ID".  I believe it can only lead to confusion (and minor additional processing overhead). I recommend removing the use of wsu:Id in vavor of the base xsd:ID.

Related to 56.


58 Technical Closed Various editorial comments


59 Technical Closed Various editorial comments on XrML binding

Thomas sent mail closing this.


60 Technical Closed Proposal for processing rules.  It seems that for certain bindings of WSS (SAML and XrML in particular) there may be a more straight-forward way of describing processing rules. Currently, the bindings for these have processing rules described under "proof-of-possession" (in other words, you start with the token and then try to figure out if there is proof of possession, without even knowing if you need to do that for the purposes of that message). Recall that SAML and XrML express, among other things, things like "A can do B upon C." A statement such as "A can do B upon C" doesn't have any inherent processing rules that need to be associated to it necessarily. A better way might be to look at the message. For instance, if the message is encrypted, we only need an identification of the key that can decrypt it, not a statement like "A can do B upon C." If the message is signed using a key (say k), we need to validate the signature (say it succeeds), check the semantics of the message (say that it is that Alice is requesting two tickets (to see a movie)), check that the request is fresh (say that it is), check that Alice is authenticated to k (say that she is), check that "Alice can request upon tickets" (say that she can), and, finally, process the request and generate the response. (Also, as Phill pointed out in his recent e-mail, we ought to also indicate where the callers should put -- and the receivers expect to find -- the tokens for each of these steps in order to avoid the cost of figuring out the chains on the server side.) In this way, it is clear what the intent and processing rules of the token are, once we establish that there is first some processing to determine what it is we are trying to prove with the tokens based on the message coming in. I think this is clearer rather than just looking at the tokens and explaining some of the things we can prove with them.


61 Technical Closed

Proposed change in wording to address lines [813]-[820] in merged draft 8, 12 Dec 2002. 

"An XML signature may also be used to prove that the claims in a token apply to the signer. Proving possession of a key associated with a token key claim supports applying the other token claims with the signer. The relying party acceptance of the claims may depend on confidence in the token integrity, such as validation of an authority signature on the token. Multiple tokens may have a key claim for a signature and may be referenced from the signature using a SecurityTokenReference. A key claim can be an X.509 Certificate token, or a Kerberos service ticket token to give two examples."

Frederick: Wording on doc is fine: http://lists.oasis-open.org/archives/wss/200302/msg00066.html


62 Technical Closed Versioning Mechanisms.


The TC has to decide whether to address the versioning issue.  If it is decided to address this issue, then put a concrete proposal on the mailing list. 

Anyone interested in looking at what other groups have invented contact John or Hal - Hal, Phil, John to participate so far. This group to report back with a proposal.

Jerry will make a propsal. 

Resolution: Adopt a versioning scheme that has version information in the URIs. For more information see thread: http://lists.oasis-open.org/archives/wss/200306/msg00036.html  


63 Technical Closed XML Token Wrapper


64 Procedural Closed Add glossary http://lists.oasis-open.org/archives/wss/200301/msg00073.html. Terminology section is like a glossary. No additional action required. http://lists.oasis-open.org/archives/wss/200304/msg00049.html Closed
65 Technical Closed Adding support for biometric authentication to the UserName security token. http://lists.oasis-open.org/archives/wss/200301/msg00073.html. Closed, pending changes from Phil. http://lists.oasis-open.org/archives/wss/200304/msg00048.html Closed
66 Technical Closed Open transform http://lists.oasis-open.org/archives/wss/200302/msg00017.html

Add subsection to section 7 to define the case where the a security token can be a subelement of a STR. Related note: http://lists.oasis-open.org/archives/wss/200303/msg00002.html

67 Technical Closed for v1

Open (post-v1)

Resolve usage labels. http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Hal to begin editing a Usage Label document, which may transition into a profile.

68 Technical Closed Review username password hash encryption issues http://lists.oasis-open.org/archives/wss/200302/msg00017.html
Chris: no uniform way to express which shared secret to use, but could define QName values for this.
69 Technical Closed The specification is vague on the topic of Key Identifiers. http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Resolution: All profiles now call out how KeyIdentifiers are used

70 Technical Closed The specification needs to clarify usage of S:mustUnderstand. There were several opinions on what understanding would include: understanding and processing <wsse:Security> header element and all its sub elements when the header element is tagged with mustUnderstand="1", understanding but not processing, tagging all child elements with explicit S:mustUnderstand values of "0" or "1"... http://lists.oasis-open.org/archives/wss/200306/msg00025.html

resolution: mustUnderstand on Security header simply means you are aware of the WS-Sec spec, and there are no implied semantics. Text reflected in core.

71 Technical Closed Inconsistent token pre-pending rules http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Continue to discuss on list.  Related to #84. Please look at issue #84 for resolution.

72 Technical Closed Awkward status of message timestamps in WSS core. Two issues: Timestamp trace and Expires. http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Resolution: Timestamp trace -> remove from the core specification and put into another doc.

Resolution: Expires ->

change lines 1263-1264 of core-13 from
"it is STRONGLY RECOMMENDED that recipients ..." to "Recipients MUST ..."; 2) change introductory paragraph around lines 1234-..., clarifying the expiration for security purposes rather than application purposes, and clarifying the consideration of clock skew - Editors to make Timestamp header a child of Security header, and to remove the ability of Expires to stand alone (section 10.2.2 moves to child of section 10.3) .

73 Technical Closed What tokens are allowed within TokenReference? Add an embedded reference, but this isn't well defined. http://lists.oasis-open.org/archives/wss/200306/msg00025.html

Editors have not yet made a proposal.  Chris will contact the editors to pull this together.

74 Technical Closed Encrypting a password. Points of discussion:
1. Should we encrypt password, username or the entire UsernameToken element? 2. Should we add an XCBF parameter to Username token? Should this be used in interop? 3. If interop model is viewed as guidance from the TC on secure usages, shouldn't it be secure completely? 4. How do we balance against existing deployments, which require passwords in the clear?

The Interop issues, which are part of this issue, have been closed.  Open: text for Security Considerations needs to be done.  Hal has sent proposed text.  Please review.

Resolution: Put in password token profile, internal reference will be fixed in Hal's text. Due phoncon next week.


75 Technical Closed Denial of service attacks and error reporting.


Use standard SOAP language. Must generate a fault, however, generating a fault does not mean sending a fault.  Review editorial changes.

76 Technical Closed X.509 profile issue 1: Is it desirable to use same element as reference and referrent? http://lists.oasis-open.org/archives/wss/200306/msg00025.html

To wait for Tim to join the discussion.

77 Technical Closed X.509 profile issue 2: In Section 3.4, the proposal should be more fully described. Why would one not just put the wsu:id in the ds:keyName element of the ds:keyInfo http://lists.oasis-open.org/archives/wss/200306/msg00025.html

To wait for Tim to join the discussion.

78 Technical Closed X.509 profile issue 3: Under what circumstances would one need to reference an X.509 certificate containing an encryption key? http://lists.oasis-open.org/archives/wss/200305/msg00026.html

Tim Moses will have a chance review in June.

79 Technical Closed X.509 profile issue 4: It might be necessary to carry more than one certificate. It should be explained which element needs to be duplicated in order to convey multiple certificates. http://lists.oasis-open.org/archives/wss/200305/msg00026.html

Tim Moses will have a chance review in June.

80 Technical Closed X.509 profile issue 5: Suggest MUST use common error codes http://lists.oasis-open.org/archives/wss/200303/msg00036.html

Tim Moses will have a chance review in June.

81 Technical Closed Question on STR usage attribute: Does the definition of the usage attribute of STR allow for the
association of multiple usage annotations with an STR?

Will fix in schema. Fixed in schema?

82 Procedural Open Scrub specs and update links to other specifications Kelvin Lawrence:
83 Technical Closed <xenc:EncryptedData> element should precede the <xenc:EncryptedKey/> element in the
interop scenario.

Closed as there were no comments.

84 Technical Closed for v1

Open (post v1)

Comment on Core Spec and Interop Scenario #3 - Decryption Transform. Ordering semantics of the <wsse:Security> header can not be used in all cases to determine the encryption and signature ordering. Perhaps we should require use of the Decryption Transform on all
signatures or at least in every case when both encryption and signatures are being used.
Hal has written an email:


Needs to be reviewed. Hal proposed text for issue: http://lists.oasis-open.org/archives/wss/200306/msg00003.html . Tony to propose edits and/or provide history.

85 Procedural Closed. Post a draft of F2F questions. Paul Cotton has posted draft. http://lists.oasis-open.org/archives/wss/200304/msg00009.html  Closed
86 Technical Postponed

(post v1)

Non-repudiation proposal to be included as part of WS-Security http://lists.oasis-open.org/archives/wss/200304/msg00016.html.

Resolution: Defer till after v1. Resolution date: Jun-17-03.

87 Technical Closed Add a profile for XKMS to WS-Security. Currently no owner for this. Closed
88 Procedural Closed Wrap up and release dates for version 1.0 http://lists.oasis-open.org/archives/wss/200305/msg00000.html Kelvin to meet with Chris and draft a proposal. Others can indicate critical dates. Duplicate of Issue #11. Closed
89 Technical Closed Proposal for making BinaryToken and XML Token to be abstract types.  http://lists.oasis-open.org/archives/wss/200305/msg00046.html :

Chris to post a mail why it would not work in practice.

90 Technical Closed Clarification needed on wsse:Embedded. Is the motivation for wsse:Embedded to have the token literally embedded in an STR? If so, the examples with wsu:Id seem incorrect. http://lists.oasis-open.org/archives/wss/200305/msg00028.html

1. clarify id on line 728 other things can sign this
2. 742 - 743 should show embedded saml token
3. 730 733 contain cut and paste error should say embedded rather than KeyIdenfier.

Fixed in specs

91 Technical Closed Interop spec mustUnderstand uses "true" where as SOAP mustUnderstand attribute is either "1" or "0". The interop schema doesn't validate against SOAP schema. http://lists.oasis-open.org/archives/wss/200305/msg00025.html . Fixed in draft 3. Propose we close. Closed
92 Technical Closed Should we support "multiple recipient" case for encryption? A possible use of multiple EncryptedKey elements in different security headers is to enable multiple roles, possessing distinct private asymmetric keys, to get access to the same data, encrypted with the same symmetric key. In this scenario, the intermediary, should perform the decryptions indicated in the Security header labeled with its role, passing the result to its local application. The problem is there is no way to distinguish this case versus Super encryption case where multiple encryption headers might also exist. http://lists.oasis-open.org/archives/wss/200305/msg00022.html not a separate issue, part of the order of decryption issue. No one commented.
Resolution: if you want support multiple recipient case for encryption, you're on your own
93 Technical Closed Error in WSS interop example #2. http://lists.oasis-open.org/archives/wss/200305/msg00005.html

Fixed in latest draft. Closed.

94 Technical Closed Embedded missing from STR preferred. Embedded References were not added to the list in lines 642-648 http://lists.oasis-open.org/archives/wss/200306/msg00012.html. Editorial update done Closed
95 Technical Closed The xmlenc schema does not specify anyAttribute; I think this means that the permitted attributes of EncryptedData are fixed, and the original unqualified Id attribute would then be correct.

Editorial update done.

96 Technical Closed Various edits.

Some small issues/edits from reading half of the doc.

i) Line 186:

The xsd: prefix is also used in the document.

ii) Line 490 and globally:

"A string label" is, to me, a slightly vague definition for ID attributes; would "An ID label" or some such be better?

iii) Line 544:

... The ValueType attribute s/allows/is/ a qualified name ...

iv) Line 547 and elsewhere:

If EncodingType is unspecified, I presume that means base 64; should we say this explicitly? We say 'default'
in some places, but the meaning of that is not altogether clear to me; I could misinterpret as schema default.

v) Lines 562-566:

Why is it RECOMMENDED that the namespace prefixes be declared within the wsse:BinarySecurityToken element? They have to be declared somewhere, in order for the QName to have meaning; so I'm not sure what this recommendation is adding. If anything, shouldn't we be requiring that exclusive c14n, if used, include any non-visibly-utilized namespace prefixes in its unsuppressed prefix list?

vi) Line 600:

... If a s/SecurityTokenRefeference/SecurityTokenReference is/ used outside ...

vii) Line 601:

... reference s/are// MUST be ...

viii) Line 615:

Does wsse:Usage deserve to be a global attribute? It only appears to be used once.

ix) Lines 703, 708 and elsewhere:

703: The ValueType attribute is used to optionally indicate
708: The optional EncodingType attribute is used to indicate

If we don't intend a different meaning, I'd suggest standardizing on the form of line 708.

x) Line 726:

... is used to s/embedded/embed/ a token ...

xi) Lines 730,733:


xii) Line 765:

... Additionally, s/defined for// e-mail addresses ...

xiii) Lines 768-777:

Is the font off?


editorial update approved for v. Editorial update done
No change required for viii.

97 Technical Closed i) Whitespace

The examples appear to have spaces around usernames, passwords, created. We should state whether or not whitespace is significant, and possibly update the examples. Is the encoded form of the Created element ' 2001...Z ' or '2001...Z'?

ii) Ordering

The schema doesn't specify an element order. Does our UsernameToken profile mandate the order Username,Password,Nonce?,Created? or is any order valid, or should we make the schema more strict?

i) Resolution: Whitespace should be preserved.

ii) Update document to define an order and schema should match the document.


98 Technical Closed Because Interop Scenario #3 uses two key pairs instead of four key pairs, it avoids a security threat in a way that was not apparent to me until a recent internal review. The basic issue is: when the responder encrypts the response, how does it determine that the public key it uses is that of the proper party and not some attacker.

Suppose each party has two key pairs, one for signatures and one for encryption. Let us assume the requester provides a certificate containing the public key to be used for encrypting the response. Checking to see if the certificate is valid is insufficient (and probably unnecessary). That would not prevent an attacker from substituting his or her own (perfectly
valid) certificate.

Interop scenario #3 does not have this problem, because the same key is used to sign the request, thus demonstrating that the requester knows the corresponding private key.

There is more than one way to solve this problem. One possible way would be to require that the SubjectName in the encryption certificate is the same as the one in the signature certificate. I do not think this is a good approach. For one thing there are a least a dozen reasons that even if both certs were issued to the same system entity (person), the SubjectNames won't match. Second it doesn't support the case where the requester and recipient are distinct.

A better solution would be to require that the encryption certificate (or at least the public key) fall under the signature of the request. This proves that the key came from the requester, which is what we are really trying to determine. This might be a good time to use /Usage={receiver}.


99 Technical Closed KeyIdentifier ValueType

The core spec currently takes the position that the ValueType which optionally appears in the KeyIdentifier describes the thing referred to, e.g. an X.509 cert, rather than the type of the KeyIdentifier itself. In fact the spec says even if it does appear, it is only a hint. This doesn't seem particularly useful...

Hal: http://lists.oasis-open.org/archives/wss/200306/msg00076.html
Action: Update text in profiles.
Hal to review, and send email to editors if ok.
Resolution: "Profiles must define what value is implied if specific value is not specified"
100 Technical Closed Issue: Replay attacks and timestamp. Investigate if there are additional implications of using time stamps and other replay detection mechanisms across multiple SOAP roles. Martijn: http://lists.oasis-open.org/archives/wss/200306/msg00078.html

Resolution: rely on WS-Addressing.

101 Technical Closed Key Identifiers Should Not Be Used for Signatures. Using a key identifier to indicate the key to be used for signature validation creates an exposure to a certificate substitution since it is possible for several certificates to exist which refer to the same key pair. Hal: http://lists.oasis-open.org/archives/wss/200306/msg00085.html Closed
102 Technical Closed Remove 7.7 Token Reference Lookup Processing Order. Section 7.7 defines a preferred order for processing the contents of a KeyInfo element, to 'resolve possible ambiguities'. Propose removing this section as it provides no additional benefit. Merlin: http://lists.oasis-open.org/archives/wss/200306/msg00087.html

Resolution: remove section.
Action: Editors remove section

103 Editorial Closed ValueType attribute: docs should state "ValueType attribute is RECOMMENDED for BinarySecurityToken and RECOMMENDED for Reference with non-local URI". Rework the example in 7.2. Merlin: http://lists.oasis-open.org/archives/wss/200306/msg00088.html
Resolution: Change text REQUIRED on BST and RECOMMENDED on Reference.
104 Technical Closed Signature Transform: The signature transform in section 8.3 seems underspecified. In particular, 'echo' isn't particularly meaningful when transforming node sets Merlin: http://lists.oasis-open.org/archives/wss/200306/msg00089.html
Action: Merlin to get text to editors. Merlin posted mail on this. Text added.
105 Technical Closed Signature over EncryptedXXX: Signature over CipherData/CipherReference/@URI to reference the externally-located ciphertext doesn't provide assurances over encrypted data. 
Merlin: http://lists.oasis-open.org/archives/wss/200306/msg00090.html
Action: Merlin to get text to Hal. Text added.
Merlin and Hal
106 Editorial Closed Editors to add common interop pitfalls to spec Interop action item
107 Editorial Closed Editors to update table in core spec that indicates when to use wsu:Id vs Id defined by other schema Interop action item
108 Editorial Closed Editors to look into SHOULD vs MUST for order of encrypted elements Interop action item
109 Editorial Closed Editors to update spec to require time be expressed as Zulu time Interop action item
Text added.
110 Editorial Closed Editors to change text on reporting faults Interop action item
111 Procedural Closed Compile the list of contributors to the spec. Interop action item

Kelvin to update contributor list and forward to editors.

112 Technical Closed Under what circumstances would one need to reference an X.509 certificate containing an encryption key? http://lists.oasis-open.org/archives/wss/200305/msg00026.html Closed
113 Technical Closed Key Identifiers Should Not Be Used for Signatures. Using a key identifier to indicate the key to be used for signature validation creates an exposure to a certificate substitution since it is possible for several certificates to exist which refer to the same key pair. Hal: http://lists.oasis-open.org/archives/wss/200306/msg00085.html
Text added.
114 Editorial Closed Editors to add common interop pitfalls to spec. Interop action item

Resolution: Duplicate

115 Editorial Closed Use of ValueType in X.509 Profile - ValueType should contain specific values and should contain version number http://lists.oasis-open.org/archives/wss/200307/msg00009.html

Resolution: Profiles are reved independent of the core spec and of the underlying spec being profiled.
Incorporated into the latest versions. 

116 Technical Closed Is timestamp a security token? Seems like it is related to issue #73. Marking closed. http://lists.oasis-open.org/archives/wss/200307/msg00010.html Closed
117 Technical Closed X.509 QName versioning - versioning of X.509 Token and versioning of token profile... http://lists.oasis-open.org/archives/wss/200307/msg00020.html

Resolution: Duplicate of issue 115.

118 Technical Closed Remove either PKCS#7 or PKIPath http://lists.oasis-open.org/archives/wss/200307/msg00020.html

Resolution: Leave text as is. Recommend PKIPath, but allow PKCS#7

119 Editorial Closed <Password> and <Nonce> elements in core spec http://lists.oasis-open.org/archives/wss/200307/msg00029.html

Resolution: Move out of core.

120 Technical Closed Frederick Hirsch: Why should Nonce and Timestamp both be used instead of one or the other http://lists.oasis-open.org/archives/wss/200307/msg00033.html

Frederick to provide text

121 Technical Closed Frederick Hirsch: Does this document need any processing rules stated - for example: what the mechanism for generating and exchanging nonce? http://lists.oasis-open.org/archives/wss/200307/msg00033.html

Frederick to provide text

122 Technical Closed How is Created timestamp defined [174]? Is it wsu:Timestamp or some other schema dataType? http://lists.oasis-open.org/archives/wss/200307/msg00033.html

Editors to update

123 Editorial Closed Some typos

118s;SHA-1 has ;SHA-1 hash ;
183 & 201 update wsse, wsu namespaces in examples to match [87] Add wsu to [87]?



124 Editorial Closed boilerplate intro not necessary in each profile, specifically identification/contact info, description and updates; editors to remove 4 bullets in boilerplate intro of each doc http://lists.oasis-open.org/archives/wss/200307/msg00045.html Closed
125 Editorial Closed Chang, Symon: Username Token in Username Token Profile has some misleading information. http://lists.oasis-open.org/archives/wss/200307/msg00048.html Closed
126 Technical Closed Frederick: Namespace stability issue: are the wsse and wsu namespaces stable? http://lists.oasis-open.org/archives/wss/200307/msg00051.html Closed
127 Technical Pending Peter Dapkus: Spec should address the issue of non-visibly used namespaces http://lists.oasis-open.org/archives/wss/200307/msg00070.html

Resolution: Consensus on two points:
 - remove recommendation for exclusive c14n
 - add brief description under interop considerations
Hal to propose wording for issue 127.
Resolution: Doesn't block ship
Hal to provide non normative text.

Hal Lockhart
128 Technical Closed Peter Dapkus: example in section 3.2 has questionable use of UsernameToken http://lists.oasis-open.org/archives/wss/200307/msg00071.html
Resolution: Tony to change example to refer to custom token rather than username token, and to add description text
129 Technical Closed Frederick Hirsch: attachment encryption processing should be clarified. http://lists.oasis-open.org/archives/wss/200308/msg00009.html
Resolution: Editors to remove text on SOAP attachments
130 Technical Closed Phil Hallam-Baker: Continuing Encryption discussion - new proposal http://lists.oasis-open.org/archives/wss/200308/msg00002.html
131 Technical Closed Interop 2 issue: Signed Token. http://lists.oasis-open.org/archives/wss/200308/msg00051.html Closed
132 Editorial Closed Minor errata on core specification http://lists.oasis-open.org/archives/wss/200308/msg00048.html Closed
133 Technical Pending Merlin Hughes - Related to Issue 99: KeyIdentifier without ValueType - security header does not explicitly indicate http://lists.oasis-open.org/archives/wss/200308/msg00040.html Merlin
134 Editorial Pending Merlin Hughes - Changes to examples in core specification http://lists.oasis-open.org/archives/wss/200308/msg00043.html Editors
135 Editorial Open Kelvin Lawrence: (Post committee spec) Need to rename document filies http://lists.oasis-open.org/archives/wss/200308/msg00068.html Editors
136 Editorial Open Frederick Hirsch - Core: minor example issues http://lists.oasis-open.org/archives/wss/200309/msg00007.html TC
137 Technical Open PasswordDigest in Username profile http://lists.oasis-open.org/archives/wss/200309/maillist.html TC


Notes on Issues

There are currently no additional notes on issues.  In most cases the history of an issue can be easily determined by examining the linked meeting minutes or discussion message and/or previous versions of the issues list.

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