[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] Web Services Security Issues List - Rev 5
The attached issues list includes issues from the mailing list through Nov 11th and from our Nov 5th telephone conference. If there are issues that were missed or need correction please let me know. Chris/Kelvin: would it make sense to provide a link to the current issues list from our TC page? Regards, -JohnTitle: WSS Issues List
Version 5, Modified on November 13, 2002 08:36:08 PM -0800
This table include issues from the mailing list up to Nov 11th and from the Nov 5th telephone conference ( http://lists.oasis-open.org/archives/wss/200211/msg00044.html).
If you identify items that are missing or need correction please contact John Shewchuk at johnshew@microsoft.com.
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 | Open | Proposal to Label Tokens to Indicate Their Semantics | Ronald Monzillo directed to participate in resolution of labeling and POP. Related to 3 and 23.http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Ronald Monzillo |
4 | Technical | Open | Why is the token in the header, and not a child of KeyInfo? | Related to 5 - note that the resolution should be consistent with 3. http://lists.oasis-open.org/archives/wss/200210/msg00085.html | TC |
5 | Technical | Open | Within the KeyInfo, why not use a ds:RetrievalMethod? | Related to 4. http://lists.oasis-open.org/archives/wss/200210/msg00085.html | TC |
6 | Investigation | Open | Will the authors of the roadmap submit it? | Owners to provide fixed URL. http://lists.oasis-open.org/archives/wss/200210/msg00085.html | Chair |
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 | Open | Approach authors to submit the App Note to the TC | Erick Herring to follow up and make determination http://lists.oasis-open.org/archives/wss/200209/msg00095.html |
Erick Herring |
10 | Investigation | Postponed. | Investigate interop fest at some later time | Postponed pending more feedback on documents. http://lists.oasis-open.org/archives/wss/200210/msg00085.html | Chair |
11 | Investigation | Postponed | Pick date for OASIS submission date after initial drafts available | Covered by issue 10. http://lists.oasis-open.org/archives/wss/200210/msg00085.html | Chair |
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 | Open | State that the recipient SHOULD authenticate the assertion issuer and ensure that the assertion has not been modified | Ron will propose change before next meeting.
http://lists.oasis-open.org/archives/wss/200210/msg00127.html |
Ronald Monzillo |
15 | Technical | Pending | Core: Spec should indicate that it is based on the SOAP messaging model. | Editors instructed to clarify. http://lists.oasis-open.org/archives/wss/200210/msg00085.html | TC |
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 | Open | Core: Why is it necessary to special case a Username/Password POP token? | Ronald Monzillo directed to participate in resolution of labeling and POP. Ronald to work with Tony to get incorporated in document. Phil Griffin to post to list concerning biometrics, and work with Ronald. Related to 3 and 23. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Ronald Monzillo, Phil Griffin |
20 | Technical | Pending | Core: Define security token propagation. | Editors have updated. TC to review. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | TC |
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 | Closed |
22 | Technical | Pending | 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. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Editors |
23 | Technical | Open | Core: Make Proof-of-Possession a fundamental type or relationship within [sic] within the ws-security model? | Combined with 19. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Ronald Monzillo |
24 | Technical | Open | Core: Why is it necessary to treat XML Signature elements as other than security tokens? | Combined with 25. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Ronald Monzillo |
25 | Technical | Open | Core: How can a Signature element occurring outside of the header be referenced? | Combined with 24. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Ronald Monzillo |
26 | Technical | Pending | Core: What does it mean to process a BinarySecurityToken? | Editors have updated, TC to review. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | TC |
27 | Technical | Open | Core: Reference element should have an @any to allow for attribute extensibility | Editors to clarify. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Ronald Monzillo |
28 | Technical | Pending | SAML Binding: Include the use of the URI attribute (on SecurityTokenReference) from the SS TC submission | Ron will make change in bindings document.
http://lists.oasis-open.org/archives/wss/200210/msg00127.html |
TC |
29 | Technical | Open | 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)? | Prateek to post to list on this issue.
http://lists.oasis-open.org/archives/wss/200210/msg00127.html |
Prateek Mishra |
30 | Technical | Open | How should fragments be explained. | http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Editors |
31 | Technical | Open | Should use OASIS Namespace | Use OASIS namespace. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Chair |
32 | Technical | Pending | 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. | Editors to clarify. http://lists.oasis-open.org/archives/wss/200210/msg00127.html | Editors |
33 | Technical | Pending | 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. | http://lists.oasis-open.org/archives/wss/200210/msg00127.html | TC |
34 | Technical | Pending | <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. | Editors to clarify. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Editors |
35 | Technical | Pending | Is it necessary to support the HexBinary encoding of tokens? | Editors to change to list of one encoding type, base64. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Editors |
36 | Technical | Pending | In section 10.2.2, why not just specify that the <Created> element type be xsd:dateTime? | Editors to clarify. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Editors |
37 | Technical | Pending | lines 193-195: Where does the threat of replay attacks belong to? To the first or the second group? | Editors to clarify. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Editors |
38 | Technical | Open | line 238: Since this is a normative text, how "inappropriate claims" is defined here? | Konstantin to post proposed changes. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Konstantin Beznosov |
39 | Technical | Pending | Lines 251-255: Since the UrenameToken element does not have password digest, what is the purpose of the Nonce and Created elements here? | Editors to clarify. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Editors |
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.htm | 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.htm | Closed |
42 | Technical | Pending | Line 1155: the meaning of "materially" is unclear. | Editors to clarify. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Editors |
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.htm | Closed |
44 | Technical | Pending | SAML Cannonicalization | Editors to clarify. http://lists.oasis-open.org/archives/wss/200211/msg00044.htm | Editors |
45 | Technical | Open | 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/200211/msg00062.html | Don Flinn |
46 | Technical | Open | 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. |
http://lists.oasis-open.org/archives/wss/200211/msg00060.html | Rich Salz |
47 | Technical | Open | 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. | http://lists.oasis-open.org/archives/wss/200211/msg00058.html | Zahid Ahmed |
48 | Technical | Open | 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. | http://lists.oasis-open.org/archives/wss/200211/msg00058.html | Zahid Ahmed |
49 | Technical | Open | 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. | http://lists.oasis-open.org/archives/wss/200211/msg00058.html | Zahid Ahmed |
50 | Technical | Open | 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. | http://lists.oasis-open.org/archives/wss/200211/msg00057.html | Ronald Monzillo |
51 | Technical | Open | 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 | Ronald Monzillo |
52 | Technical | Open | 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. | http://lists.oasis-open.org/archives/wss/200211/msg00057.html | Ronald Monzillo |
53 | Technical | Open | 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. |
http://lists.oasis-open.org/archives/wss/200211/msg00056.html | Ronald Monzillo |
54 | Technical | Open | 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. Line 294: Should read Lines (005) to (009) .. 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? Lines 534 & 535: I believe that these lines should read " ... binary or XML tokens ..", not just "binary tokens" Lines 575 to 588: Are these lines needed since we RECOMMEND that Exclusive Canonicalization be used? 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. Section 7.1 & 7.2: These sections also don't mention assertion id's for SAML and license id's for XrML. Section 7.4: This section only discusses BinarySecurityTokens. SAML also has a KeyInfo token. |
http://lists.oasis-open.org/archives/wss/200211/msg00055.html | Don Flinn |
55 | Technical | Open | 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? |
http://lists.oasis-open.org/archives/wss/200211/msg00053.html | Frederick Hirsch |
56 | Technical | Open | 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. | http://lists.oasis-open.org/archives/wss/200211/msg00036.html | Robert Philpott |
57 | Technical | Open | [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. | http://lists.oasis-open.org/archives/wss/200211/msg00036.html | Robert Philpott |
58 | Technical | Open | Various editorial comments | http://lists.oasis-open.org/archives/wss/200211/msg00036.html | Robert Philpott |
59 | Technical | Open | Various editorial comments on XrML binding | http://lists.oasis-open.org/archives/wss/200211/msg00040.html | Thomas DeMartini |
60 | Technical | Open | 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. |
http://lists.oasis-open.org/archives/wss/200211/msg00039.html | Thomas DeMartini |
61 | Technical | Open | Section 8 of WSS-Core-03-1103.pdf Does the following capture the
intended meaning?: "The creator of an XML Signature on a message payload, message header, or message attachment may associate key claims with the signature by using one or more SecurityTokenReferences. A token referenced by a SecurityTokenReference may provide information about the key, serving a similar function as the XML Digital Signature KeyInfo element. Such a token may also be used to convey additional information relevant to the signature, serving a similar function as the XML Digital Signature SignatureProperties element. Appropriate use and interpretation of a token referenced by a SecurityTokenReference depends upon signing and relying party agreement on business and security trust models." Is this the intent? |
http://lists.oasis-open.org/archives/wss/200211/msg00031.html | Frederick Hirsch |
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] | [Elist Home]
Powered by eList eXpress LLC