[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WSS Issues List 37
<<wss-issues-37.htm>> Vijay GajjalaTitle: WSS Issues List 37
Version 37, Modified on Tuesday April 06, 2004 05:02:45 -0700
The previous version of the issues list (Version 36) is at http://www.oasis-open.org/apps/org/workgroup/wss/download.php/6047/wss-issues-36.htm. An archive of the document can be found on the mailing list at http://lists.oasis-open.org/archives/wss/200403/msg00052.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 Vijay Gajjala and John Shewchuk.
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. http://lists.oasis-open.org/archives/wss/200211/msg00184.html |
Closed |
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 |
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 | 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? |
http://lists.oasis-open.org/archives/wss/200302/msg00017.html |
Closed |
20 | Technical | Closed | Core: Define security token propagation. | http://lists.oasis-open.org/archives/wss/200212/msg00037.html | Closed |
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 | 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 | Closed |
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 |
Closed |
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! |
Closed |
26 | Technical | Closed | Core: What does it mean to process a BinarySecurityToken? |
http://lists.oasis-open.org/archives/wss/200301/msg00000.html |
Closed |
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 |
http://lists.oasis-open.org/archives/wss/200302/msg00017.html |
Closed |
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)? |
http://lists.oasis-open.org/archives/wss/200212/msg00037.html |
Closed |
30 | Technical |
Closed |
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 | Closed | Should use OASIS Namespace |
http://lists.oasis-open.org/archives/wss/200306/msg00025.html Karl Best had formed committee to solve this problem. A proposal has been sent to the email archive http://lists.oasis-open.org/archives/wss/200309/msg00064.html Kelvin to send a proposal on what comes after tcname. Kelvin's proposal (http://lists.oasis-open.org/archives/wss/200312/msg00006.html) was approved.
|
Closed |
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? |
http://lists.oasis-open.org/archives/wss/200301/msg00000.html |
Closed |
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? | 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. | 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 |
Closed |
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/200301/msg00073.html Hal: follow up and find out what the real issue is. Hal followed up: http://lists.oasis-open.org/archives/wss/200305/msg00006.html |
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html
|
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html
|
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html |
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html |
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html
|
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html |
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200211/msg00184.html
i) to be corrected in drafts . ii) corrected in draft 4 of core specs iii) need to correct draft iv) closed. v) closed. vii) closed. viii) closed. |
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? |
http://lists.oasis-open.org/archives/wss/200301/msg00000.html |
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html |
Closed |
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. http://lists.oasis-open.org/archives/wss/200211/msg00036.html |
Closed |
58 | Technical | Closed | Various editorial comments |
http://lists.oasis-open.org/archives/wss/200211/msg00036.html |
Closed |
59 | Technical | Closed | Various editorial comments on XrML binding |
Thomas sent mail closing this. http://lists.oasis-open.org/archives/wss/200302/msg00019.html |
Closed |
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. |
http://lists.oasis-open.org/archives/wss/200301/msg00073.html |
Closed |
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 http://lists.oasis-open.org/archives/wss/200302/msg00017.html |
Closed |
62 | Technical | Closed | Versioning Mechanisms. |
http://lists.oasis-open.org/archives/wss/200306/msg00025.html 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 http://lists.oasis-open.org/archives/wss/200307/msg00067.html |
Closed |
63 | Technical | Closed | XML Token Wrapper |
http://lists.oasis-open.org/archives/wss/200302/msg00017.html |
Closed |
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 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 |
Closed |
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. |
TC |
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. |
Closed |
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 |
Closed |
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. |
Closed |
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. |
Closed. |
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 |
Closed |
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. |
Closed |
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? |
http://lists.oasis-open.org/archives/wss/200306/msg00025.html
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. http://lists.oasis-open.org/archives/wss/200306/msg00005.html |
Closed |
75 | Technical | Closed | Denial of service attacks and error reporting. |
http://lists.oasis-open.org/archives/wss/200306/msg00025.html Use standard SOAP language. Must generate a fault, however, generating a fault does not mean sending a fault. Review editorial changes. |
Closed |
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. |
Closed |
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. |
Closed |
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. |
Closed |
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. |
Closed |
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. |
Closed |
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? |
http://lists.oasis-open.org/archives/wss/200305/msg00026.html
Will fix in schema. Fixed in schema? |
Closed |
82 | Procedural | Closed | Scrub specs and update links to other specifications | Kelvin Lawrence: http://lists.oasis-open.org/archives/wss/200303/msg00056.html |
Closed |
83 | Technical | Closed | <xenc:EncryptedData> element should precede the
<xenc:EncryptedKey/> element in the interop scenario. |
http://lists.oasis-open.org/archives/wss/200305/msg00026.html
Closed as there were no comments. |
Closed |
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:
http://www.oasis-open.org/archives/wss/200305/msg00022.html 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. |
Closed |
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 Open |
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. |
Closed |
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. |
Closed |
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 Fixed in specs |
Closed |
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 |
Closed |
93 | Technical | Closed | Error in WSS interop example #2. | http://lists.oasis-open.org/archives/wss/200305/msg00005.html
Fixed in latest draft. Closed. |
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. |
http://lists.oasis-open.org/archives/wss/200306/msg00027.html
Editorial update done. |
Closed |
96 | Technical | Closed | Various edits.
Some small issues/edits from reading half of the doc. |
http://lists.oasis-open.org/archives/wss/200306/msg00040.html
editorial update approved for v. Editorial update done |
Closed |
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? |
http://lists.oasis-open.org/archives/wss/200306/msg00041.html
i) Resolution: Whitespace should be preserved. ii) Update document to define an order and schema should match the
document. |
Closed |
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}. |
http://lists.oasis-open.org/archives/wss/200306/msg00044.html
|
Closed |
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" |
Closed |
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. |
Closed. |
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. |
Closed |
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. |
Closed |
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. |
Closed |
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. |
Closed |
106 | Editorial | Closed | Editors to add common interop pitfalls to spec | Interop action item http://lists.oasis-open.org/archives/wss/200306/msg00097.html |
Closed |
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 http://lists.oasis-open.org/archives/wss/200306/msg00097.html |
Closed |
108 | Editorial | Closed | Editors to look into SHOULD vs MUST for order of encrypted elements | Interop action item http://lists.oasis-open.org/archives/wss/200306/msg00097.html |
Closed |
109 | Editorial | Closed | Editors to update spec to require time be expressed as Zulu time | Interop action item http://lists.oasis-open.org/archives/wss/200306/msg00097.html Text added. |
Closed |
110 | Editorial | Closed | Editors to change text on reporting faults | Interop action item http://lists.oasis-open.org/archives/wss/200306/msg00097.html |
Closed |
111 | Procedural | Closed | Compile the list of contributors to the spec. | Interop action item http://lists.oasis-open.org/archives/wss/200306/msg00097.html; Kelvin to update contributor list and forward to editors. |
Closed |
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. |
Closed |
114 | Editorial | Closed | Editors to add common interop pitfalls to spec. | Interop action item http://lists.oasis-open.org/archives/wss/200306/msg00097.html Resolution: Duplicate |
Closed |
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. |
Closed |
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. |
Closed |
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 |
Closed |
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. |
Closed |
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 |
Closed |
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 |
Closed |
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 |
Closed |
123 | Editorial | Closed | Some typos
99s;information..;information.; |
http://lists.oasis-open.org/archives/wss/200307/msg00033.html
|
Closed |
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 | Closed | 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: http://lists.oasis-open.org/archives/wss/200311/msg00058.html |
Clsoed |
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 |
Closed |
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 |
Closed |
130 | Technical | Closed | Phil Hallam-Baker: Continuing Encryption discussion - new proposal |
http://lists.oasis-open.org/archives/wss/200308/msg00002.html http://lists.oasis-open.org/archives/wss/200308/msg00033.html |
Closed |
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 | Closed | 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: http://lists.oasis-open.org/archives/wss/200310/msg00017.html Change accepted. Editors to make change. |
Closed |
134 | Editorial | Closed | Merlin Hughes - Changes to examples in core specification |
http://lists.oasis-open.org/archives/wss/200308/msg00043.html Merlin: Recommend closing: http://lists.oasis-open.org/archives/wss/200310/msg00017.html |
Closed |
135 | Editorial | Closed | Kelvin Lawrence: (Post committee spec) Need to rename document filies |
http://lists.oasis-open.org/archives/wss/200308/msg00068.html
Will be addressed with issue 31. Kelvin's proposal (http://lists.oasis-open.org/archives/wss/200312/msg00006.html) was approved. |
Closed |
136 | Editorial | Closed | Frederick Hirsch - Core: minor example issues | http://lists.oasis-open.org/archives/wss/200309/msg00007.html | Closed |
137 | Technical | Closed | PasswordDigest in Username profile |
http://lists.oasis-open.org/archives/wss/200309/msg00008.html Issue resolved via list. Hal to provide text. http://lists.oasis-open.org/archives/wss/200311/msg00059.html |
Closed |
138 | Editorial | Closed | Core - Line 416 - 'MAY' should be 'can' - "The prepending rule ensures that receiving application MAY process sub-elements in the order..." | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
139 | Editorial | Closed | Core - Line 422 - The "SHOULD" phrase is confusing, just simply say that key-bearing element SHOULD be ordered to precede the key-using element |
Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
140 | Editorial | Closed | Core - Line 459 - We suggest that 'SHALL be' is replaced with 'are' - "This chapter specifies different types of security tokens and how they SHALL be attached to messages..." | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
141 | Editorial | Closed | Core - Line 599 - Typo - "reference". | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
142 | Editorial | Closed | Core - Line 613, 615 - Grammar of sentence confusing, including use of "SHALL". |
Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
143 | Editorial | Closed | Core - Line 832, 833 - Even though RFC 2119 does not require capitalization, we suggest that 'should' needs to be 'SHOULD' and it needs to say that order of elements represents order of operations - "Finally if a sender wishes to sign a message before encryption they should alter the order of the signature and encryption elements inside of the <wsse:Security> header". |
Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
144 | Editorial | Closed | Core - Line 838-839 - Awkward wording, and questionable use of "SHOULD" and "MUST"- "Senders SHOULD take care to sign all important elements of the message, but care MUST be taken in creating a signing policy..." | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
145 | Editorial | Closed | Core - Line 937-938 (Section 8.3) - It is not clear in the document
what are 'x' and 'y'. Are they placeholders, if not they should probably be
in quotes. |
Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
146 | Editorial | Closed | Core - Section 13 - Is section 13 supposed to be non-normative? If that is indeed the case, there should be no SHOULD/MAY/MUST in this section. | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
147 | Editorial | Closed | WSS Username Token Profile: Lines 32, 33, 34, 39 (Table of Contents) - The section numbers in those lines are out of order. | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
148 | Editorial | Closed | WSS Username Token Profile: Line 67 (Section 2.1) - There is a reference to SOAP 1.2 namespace. However, there seem to be some old URI in the table | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
149 | Editorial | Closed | WSS Username Token Profile: Line 107 - Typo, the word 'security' has been misspelled as 'securty'. | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
150 | Editorial | Closed | WSS Username Token Profile: Lines 155-156 - It is recommended that the element is passed when a secure transport is being used. It is not clear what 'secure transport' means. Does this include SOAP-element level encryption | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
151 | Editorial | Closed | WSS Username Token Profile: Line 170 - This should be a 'MUST' instead of the 'should', if you are interested in detecting replay attacks | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
152 | Editorial | Closed | WSS Username Token Profile: Line 236 - The recommendation should reference the security consideration in WSS SOAP Message Security document, section 13, Line 1475, since it is a better description of using signatures to prevent replay attacks. | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
153 | Editorial | Closed | WSS Username Token Profile: The core document says that each token profile MUST define the value of QName. This document does not define the value of the QName. | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html . Needs URI. Editors to clarify sentence saying what Q name to be used | Closed |
154 | Editorial | Closed | WSS Username Token Profile: The Username token profile does not address KeyIdenfier and KeyName. The profile should either state that these are not used or define their meaning. Token profile should define their default values | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html . Editors to add a note saying Key ID and Key Name does not apply to username tokens | Closed |
155 | Editorial | Closed | WSS Username Token Profile: Some of the references are not used in this document. It will help if the normative one are in a separate section | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html . Editors to remove non-normative reference | Closed |
156 | Editorial | Closed | WSS X.509 Certificate Token Profile: Line 182 - [] should be used consistently and reference like WS-Security should not be used when also used in the text. E.g. line 182, blue, no bracket | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
157 | Editorial | Closed | WSS X.509 Certificate Token Profile: Line 221 - Misuse of capital 'MAY'. Line 224 - Misuse of capital 'MAY'. |
Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
158 | Editorial | Closed | WSS X.509 Certificate Token Profile: Line 230 - Subsection starts after a ':' | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
159 | Editorial | Closed | WSS X.509 Certificate Token Profile: Line 237 - example should be explained | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html . Philip to add text | Closed |
160 | Editorial | Closed | WSS X.509 Certificate Token Profile: Line 281/318 - The document should
explain the meaning of core reference. Probably should be a wsse:Reference |
Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html. Philip to add text | Closed |
161 | Editorial | Closed | WSS X.509 Certificate Token Profile: Line 398 - Error code section is inconsistent about references | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html . Philip to add text | Closed |
162 | Editorial | Closed | WSS X.509 Certificate Token Profile: Section 3.6 - is not normative | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html . Philip to add text | Closed |
163 | Editorial | Closed | WSS X.509 Certificate Token Profile: "Line 411 - We don't understand the meaning of this sentence" | Initial issue raised by WS-I BSP WG: http://lists.oasis-open.org/archives/wss-comment/200310/msg00000.html | Closed |
164 | Technical | Closed | Password digest - storing passwords in the clear is not secure. | http://lists.oasis-open.org/archives/wss-comment/200310/msg00001.html | Closed |
165 | Technical | Closed | Passing binary data in SAML Assertion Token | http://lists.oasis-open.org/archives/wss-comment/200309/msg00000.html | Closed |
166 | Editorial | Closed | Documents and sections should be marked as normative or non-normative | http://lists.oasis-open.org/archives/wss/200310/msg00013.html | Closed |
167 | Editorial | Closed | Add clarifying text to point out explicitly that the normative schema can be found at the URL specified and downloaded | http://lists.oasis-open.org/archives/wss/200310/msg00013.html | Closed |
168 | Editorial | Closed | STR-Transform test vectors & New Issue - The bullet point on
lines 950-953 (17/merged) (of core?) is incorrect and should be removed: "If the canonicalization algorithm is inclusive XML canonicalization and a node-set is replacing an element from N whose parent element is not in N, then its apex elements MUST inherit attributes associated with the XML namespace from the parent element, such as xml:base, xml:lang and xml:space." |
http://lists.oasis-open.org/archives/wss/200310/msg00016.html | Closed |
169 | Editorial | Closed | WSS Username Token Profile: In lines 126-134 of the Username Token
Profile, counter measures are given to thwart replay attacks. The
counter measures involve timestamps and nonces. This works as a
counter measure when the attacker attempts
to replay the token to the same receiver that legitimately received the
token previously. However, it does not cover the case where the token is replayed to a different receiver |
http://lists.oasis-open.org/archives/wss-comment/200310/msg00015.html http://lists.oasis-open.org/archives/wss/200310/msg00043.html Hal's proposal: http://lists.oasis-open.org/archives/wss/200311/msg00007.html Jerry's proposal: http://lists.oasis-open.org/archives/wss/200310/msg00042.html |
Closed |
170 | Procedural | Closed | Meta: The list should be open to non-subscribers rather than requiring commentators to join a mailing list. | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
171 | Editorial | Closed | WSS: Soap message security - There are numerous grammatical and punctuation errors - recommend a proof reading scrub | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
172 | Editorial | Closed | WSS: Soap message security - SOAP 1.2 recommendation and explicit support for SOAP 1.1. |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html Editors to add statement that either SOAP 1.1 or SOAP 1.2 be used, and we don't make a specific recommendation. |
Closed |
173 | Editorial | Closed |
WSS: Soap message security - Usage of SOAP related terminology should
follow SOAP 1.2 terms. Where 1.1 is used, explain differences use of WSS in
both environments. |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html Editors to ensure SOAP terminology is consistent. Hal to investigate inconsistencies between uses of SOAP 1.1 and 1.2, and possibly add material in an Appendix. Agreed to Hal's approach. Editors to make edits - splitting Hal's issue as separate point |
Closed |
174 | Editorial | Closed | WSS: Soap message security - Examples use earlier versions of SOAP or early drafts of SOAP 1.2. Pass thro examples. Editors to make examples consistent with SOAP 1.1 | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
175 | Editorial | Closed | WSS: Soap message security - Status section - still says interim draft. Should say committee spec status | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
176 | Editorial | Closed | WSS: Soap message security - Abstract - "No specific type of security token is required the specification is designed to be extensible (e.g. support multiple security token formats).": insert a comma after 'required', change 'e.g.' to 'i.e. to' | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
177 | Editorial | Closed |
WSS: Soap message security Line: 110 "This specification provides three
main mechanisms: ability to send "security token as part...": 'a security
token' or 'security tokens'. |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
178 | Editorial | Closed |
WSS: Soap message security 139, looks like this should be part of the
bulletted list rather than a standalone paragraph. |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
179 | Editorial | Closed | WSS: Soap message security Suggest usage of other formatting mechanisms for refering to bibliographic information than color coding. |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html Editors to add square bracket notation. |
Closed |
180 | Editorial | Closed | WSS: Soap message security Lines 150-155 seem to be in a different font though the reason for this is unclear | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
181 | Editorial | Duplicate, Closed |
WSS: Soap message security 170, 171: Its surprising to see the WSS namespace URIs using the xmlsoap.org domain. This domain is the property of Microsoft Corp and they maintain control over what such namespace URI resolve to. For an OASIS standard one would expect namespace URIs to use the oasis-open.org domain instead | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
182 | Editorial | Closed |
WSS: Soap message security 175: Update the soap namespace to use the one
from the SOAP 1.2 Recommendation. |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
183 | Editorial | Closed | WSS: Soap message security 252 "This document defines syntax and semantics of signatures within <wsse:Security> element.": 'a ... element' or 'the ... element'. 253 "This document does not specify any signature appearing outside of <wsse:Security> element.": 'a ... element' or 'the ... element' | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
184 | Editorial | Closed |
WSS: Soap message security: 255 "The message recipient SHOULD reject a
message with an invalid signature, a message that is missing necessary
claims and a message whose claims have unacceptable values as such messages
are unauthorized (or malformed) message..": Bad grammar, replace with
something like "A message recipient SHOULD reject messages containing
invalid signatures, messages missing necessary claims or messages whose
claims have unacceptable values. Such messages are unauthorized (or
malformed)." |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
185 | Editorial | Closed, Duplicate |
WSS: Soap message security 3.4 Example Example uses a SOAP 1.1 envelope, change to use SOAP 1.2 |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
186 | Editorial | Closed | WSS: Soap message security: 400 change 'in a form of a' to 'in the form of a'. | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
187 | Technical | Closed | WSS: Soap message security: 406 "a message MAY have multiple <wsse:Security> header blocks if they are targeted for separate recipients." why can't a message contain multiple wsse:Security header blocks targetted at the same recipient, this seems like an uneccessary/arbitrary restriction. | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
188 | Editorial | Closed | WSS: Soap message security: 410 The <wsse:Security> header block without a specified S:role MAY be consumed by anyone, but MUST NOT be removed prior to the final destination or endpoint." What does 'consumed' mean? | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
189 | Technical | Closed | WSS: Soap message security: 450 "All compliant implementations MUST declare which profiles they support": how must they declare this ? This seems like an untestable assertion and should probably be dropped | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html Editors to remove untestable assertion in line 450 | Closed |
190 | Technical | Closed | WSS: Soap message security: 455 "The optional mustUnderstand SOAP attribute on Security header simply means you are aware of the Web Services Security: SOAP Message Security specification, and there are no implied semantics.": No ! |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html http://lists.oasis-open.org/archives/wss/200310/msg00052.html Irving to write up new proposal for mustUnderstand. We identified the specific intent, Irving to provide verbage |
Closed |
191 | Editorial | Closed |
WSS: Soap message security: 495 change 'to be the' to 'to be added to the'. |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
192 | Technical | Closed | WSS: Soap message security 503: "All compliant implementations MUST be able to process a <wsse:UsernameToken> element." The element is extensible, what should compliant implementations do with extensions they don't understand - ignore them, fault |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html Editors to remove the sentence at line 503 |
Closed |
193 | Editorial | Duplicate | WSS: Soap message security 506 change example to use SOAP 1.2 | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
194 | Editorial | Closed | WSS: Soap message security : 545 "This attribute is extensible using XML namespaces.": Confusing | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
195 | Technical | Closed | WSS: Soap message security : 548 /wsse:BinarySecurityToken/@EncodingType: this seems to be reinventing XML schema to a certain extent |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html TC voted to switch to URIs |
Closed |
196 | Editorial | Closed | WSS: Soap message security: General: Also, why use qualified names instead of URIs for identifying encoding types |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html TC to review http://lists.oasis-open.org/archives/wss/200311/msg00016.html Too late to accommodate with changes. In the last two calls we have had unanimous agreement to not address this in V1 (if at all -- needs further research) TC voted to switch to URIs |
Closed |
197 | Editorial | Closed | WSS: Soap message security: 558 "All compliant implementations MUST be able to process a <wsse:BinarySecurityToken> element.": same comment as for UsernameToken, what should an implementation do with a token of unknown type or one containing an extension that is not understood | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
198 | Editorial | Closed | WSS: Soap message security: 578 "This section presents the basic principles and framework for using XML-based security tokens." Is this section complete ? There's no trace of any principles or a framework | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
199 | Editorial | Closed | WSS: Soap message security: Section 7.1 STR Same comment as for BinarySecurityToken re extensibility semantics and requiring all implementations to be able to process the element. | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
200 | Technical | Closed |
WSS: Soap message security Section 8.1 Algorithms: Surprised that there
is no mention of SOAP Message Normalization sop12-n11n) here: http://www.w3.org/TR/2003/NOTE-soap12-n11n-20030328/ |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
201 | Editorial | Closed | WSS: Soap message security : 832: "Finally, if a sender wishes to sign a message before encryption, they should alter the order of the signature and encryption elements inside of the <wsse:Security> header.": alter in what way, this needs to be more specific | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
202 | Editorial | Closed | WSS: Soap message security: 839 "care MUST be taken in creating a signing policy that requires signing of parts of the message that might legitimately be altered in transit.": shouldn't this say "care MUST be taken not to create a signing policy that requires signing of parts of the message that might legitimately be altered in transit." | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
203 | Editorial | Closed | WSS: Soap message security: 841 "SOAP applications MUST satisfy the following conditions: The application MUST be capable of processing the required elements defined in the XML Signature specification.": SOAP applications or WSS implementation ? The latter is used elsewhere in the specification | W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
204 | Editorial | Closed | WSS: Soap message security: 855 "If overall message processing is to remain robust, intermediaries must exercise care that their transformations do not affect of a digitally signed component.": again a reference to soap12-n11n would seem to be in order here |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html In line 855, editors to clarify what we mean. |
Closed |
205 | Editorial | Closed |
WSS: Soap message security: 9.3.1 Encryption: The suggested process for
performing encryption would only include the data from the original message that was encrypted. All other data would be ommitted, suggest adding an additional step to copy in all the non-encrypted data. |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
206 | Editorial | Closed | WSS: Soap message security: 1166 "Parts of a SOAP message may be encrypted in such a way that they can be decrypted by an intermediary that is targeted by one of the SOAP headers. Consequently, the exact behavior of intermediaries with respect to encrypted data is undefined and requires an out-of-band agreement.": more detail required, why is the behaviour undefined |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html
Hal to write up explanation for 206. Approach is agreed upon. Just have to
make text clear. |
Closed |
207 | Editorial | Closed | WSS: Soap message security: 12 Error handling: The specification should define the values of the Fault/Reason/Text, Fault/Code/Value and Fault/Code/Subcode/Value EIIs |
W3C XMLP WG Feedback
http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html Editors to fill out whole table |
Closed |
208 | Editorial | Closed |
WSS: Soap message security: Section 16. References. This should be
updated to point to the SOAP 1.2 Recommendation. |
W3C XMLP WG Feedback http://lists.oasis-open.org/archives/wss-comment/200310/msg00016.html | Closed |
209 | Editorial | Closed | Username Token Profile: General: Needs a thorough proof reading session | W3C XMLP WG Feedback. | Closed |
210 | Editorial | Closed | Username Token Profile: Status: Should status change to achieved committee spec. | W3C XMLP WG Feedback. | Closed |
211 | Editorial | Closed | Username Token Profile: Notations: 2,1 Notational Conventions (should this be 2.1 - ie '.' instead of ',') ? | W3C XMLP WG Feedback. | Closed |
212 | Editorial | Closed | Username Token Profile: Lines 54-59 seem to be in a different font though the reason for this is unclear. | W3C XMLP WG Feedback. | Closed |
213 | Editorial | Closed | Username Token Profile: 67 "The current SOAP 1.2 namespace URI is used herein...": an old URI is used, needs updating to refelct the ns URI of the SOAP 1.2 | W3C XMLP WG Feedback. | Closed |
214 | Editorial | Closed |
Username Token Profile: Repeats much of the text from section 2 ! It
looks to me like section 3 should be a subsection of section 2. The repeated
text needs to be removed. |
W3C XMLP WG Feedback. | Closed |
215 | Editorial | Closed | Username Token Profile: 87 Section number seems to be 'compromised'. There are two section 3s and two section 4s ! Renumbering required. | W3C XMLP WG Feedback. | Closed |
216 | Editorial | Closed | Username Token Profile: 93 "providing": the letters 'd' and 'i' are colored purple for some reason | W3C XMLP WG Feedback. | Closed |
217 | Editorial | Closed | Username Token Profile: 99 "For example, if a server does not have access to the clear text of a password but does have the hash, then the hash is considered a password equivalent and can be used anywhere where a "password" is indicated in this specification.": its not clear from this description whether such a hash should be contained in a wsse:PasswordText or wsse:PasswordDigest typed Password element. Please also clean up the formatting for this line. | W3C XMLP WG Feedback. | Closed |
218 | Editorial | Closed | Username Token Profile: 106 "..": there are quite a few instances of double full stops throughout the document, a simple search and replace of ".." for "." is required | W3C XMLP WG Feedback. | Closed |
219 | Editorial | Closed | Username Token Profile: 126 "1. First, it is recommended that web service providers reject any UsernameToken not using both nonce and creation timestamps.": recommended or RECOMMENDED as per RFC 2119 ? | W3C XMLP WG Feedback. | Closed |
220 | Editorial | Closed | Username Token Profile: 186, 204 Both examples use out of date SOAP 1.2 namespace URIs. | W3C XMLP WG Feedback. | Closed |
221 | Editorial | Closed | X.509 Token Profile: General: Examples use earlier versions of SOAP or earlier drafts of SOAP 1.2. | W3C XMLP WG Feedback. | Closed |
222 | Editorial | Closed |
X.509 Token Profile: Notational conventions - 142 "This document uses
the notational conventions defined in SOAP Message Security [WS-Security].": SOAP Message Security is colored blue, the reason for this isn't clear. 148 "The XML namespace URIs": XML namespace is colored blue, perhaps this should be followed by [XML-ns] ? Further occurances of this are not noted, the editors need to settle on a single citation format |
W3C XMLP WG Feedback. | Closed |
223 | Editorial | Closed, Duplicate |
X.509 Token Profile: 151, 152 Its surprising to see the WSS namespace URIs using the xmlsoap.org domain... | W3C XMLP WG Feedback. | Closed |
224 | Editorial | Closed | X.509 Token Profile: 153 The SOAP namespace is out of date, needs updating to the SOAP 1.2 Recommendation namespace. | W3C XMLP WG Feedback. | Closed |
225 | Editorial | Closed | X.509 Token Profile: 238, 285, 362 Update envelope namespace to SOAP 1.2 Recommendation namespace | W3C XMLP WG Feedback. | Closed |
226 | Editorial | Closed |
X.509 Token Profile: 233: Editorial s/deferencing/dereferencing/. This
could do with some rewording to make the intent clear, spelling out exactly
what is being recommended (signing the ds:KeyInfo via an Xpointer reference
along with the actual data to be signed ??). Also a reference to the
definition of the wsse:SecurityTokenReference dereferencing transform
would be useful here. |
W3C XMLP WG Feedback. | Closed |
227 | Editorial | Closed | X.509 Token Profile: Section 4 References. It would be useful to give URLs to those referenced specifications that are available online | W3C XMLP WG Feedback. | Closed |
228 | Editorial | Closed | X.509 Token Profile: 417 SOAP reference is to SOAP 1.1, should be to SOAP 1.2 Recommendation | W3C XMLP WG Feedback. | Closed |
229 | Editorial | Closed | X.509 Token Profile: 426, 427 references need to be filled in | W3C XMLP WG Feedback. | Closed |
230 | Editorial | Closed | WSS: Soap message security - should clarify if non-repudiation is a goal. | http://lists.oasis-open.org/archives/wss-comment/200310/msg00019.html | Closed |
231 | Editorial | Closed | WSS: Soap message security - Terminology should be cleared up - Remove terms like Proof of possession and "Trust domain" which are not used. Clarify and consistently use "Signature" (vs "Digital Signature" | http://lists.oasis-open.org/archives/wss-comment/200310/msg00019.html | Closed |
232 | Editorial | Closed | WSS: Soap message security - Security considerations section includes a list of concerns and potential attacks. This can be misinterpreted to be a complete list. |
http://lists.oasis-open.org/archives/wss-comment/200310/msg00019.html Editors to clarify that this is a partial list of security considerations. |
Closed |
233 | Editorial | Closed | WSS: Soap message security - We recommend moving the username token specific security considerations to the Username Token Profile and the X.509 certificate token considerations to the X.509 Certificate Token Profile. We further recommend removing the other specific security considerations for this section |
http://lists.oasis-open.org/archives/wss-comment/200310/msg00019.html
Editors to move the Username and X509 specific security considerations to
their own profiles. Paula to provide security considerations material Paula: http://lists.oasis-open.org/archives/wss/200311/msg00052.html
Editors to incorporate Hal's changes for 233, with Chris's QName suggestion.
Hal to work with Paula to add more detail to Security. More notes in meeting
minutes:
http://lists.oasis-open.org/archives/wss/200311/msg00068.html |
Closed |
234 | Editorial | Closed | Clarify SAML requirements in SAML profile - which version of SAML. |
http://lists.oasis-open.org/archives/wss/200310/msg00034.html
Ron to look at the issue and see if it can be closed. |
Ron |
235 | Editorial | Closed | WSS editorial questions | http://lists.oasis-open.org/archives/wss/200311/msg00026.html | Closed |
236 | Technical | Closed |
To preserve overall integrity of each <wsu:Timestamp> element, it is strongly RECOMMENDED that each SOAP role only create or update the appropriate <wsu:Timestamp> element destined to itself (that is, a <wsse:Security> header whose actor/role is itself) and no other<wsu:Timestamp> element |
http://lists.oasis-open.org/archives/wss/200311/msg00061.html. Editors to incorporate Hal's text. | Closed |
237 | Editorial | Closed |
The description of the SecurityTokenReference/Reference/@ValueType
attribute would have been more understandable if it hadn't referenced the
BinarySecurityToken. After reading that section, I am not sure I understand
how these attributes differ in purpose. It seems odd that usage of the
ValueType attribute would be recommended for both the
wsse:BinarySecurityToken and the wsse:SecurityTokenReference that points to
it. |
http://lists.oasis-open.org/archives/wss/200311/msg00062.html Editors to provide explanation / example of text. | Closed |
238 | Technical | Closed |
WSS: Soap message security - Usage of SOAP related terminology should
follow SOAP 1.2 terms. Where 1.1 is used, explain differences use of WSS in
both environments. |
Hal to investigate inconsistencies between uses of SOAP 1.1 and 1.2, and possibly add material in an Appendix. | Closed |
239 | Technical | Closed | ds:X509IssuerSerial element is not a global element |
http://lists.oasis-open.org/archives/wss/200312/msg00005.html Irving to request change to DSIG to expose elements (waiting for DSIG ack to close) |
Closed |
240 | Technical | Closed | STR transform: <ds:Transform> doesn't allow ds elements but we require ds:CanonicalizationMethod |
http://lists.oasis-open.org/archives/wss/200312/msg00004.html
Agreement to introduce a <wsse:TransformParameters> element which has elements from any namespace and we put C14N method inside of it |
Closed |
241 | Technical | Closed |
Timestamp has value type to allow format other than xs:dateTime, doesn't
allow schema checking, proposal to required xs:dateTime |
Editors to make this change | Closed |
242 | Editorial | Closed | Update SAML profile to use new URLs | Editors to make this change | Closed |
243 | Editorial | Closed | Update XrML profile to use new URLs | Editors to make this change | Closed |
244 | Editorial | Pending | Update Kerberos profile to use new URLs | Editors to make this change | Editors |
245 | Editorial | Closed | Rename SAML profile document | Editors to make this change | Closed |
246 | Editorial | Closed | Rename XrML profile document | Editors to make this change | Closed |
247 | Editorial | Pending | Rename Kerberos profile document | Editors to make this change | Editors |
248 | Editorial | Closed | Rename schema files and use new URLs | Editors to make this change | Closed |
249 | Technical | Closed | the saml token profile depends on non-global attributes in keyidentifier/wsse schema does not support keyIdentifier element extensibility - |
http://lists.oasis-open.org/archives/wss/200401/msg00120.html
Resolution: |
Closed |
250 | Technical | Postponed | Should ValueType attribute of STR reference element be moved to toplevel STR definition? - post v1 review period |
http://lists.oasis-open.org/archives/wss/200401/msg00121.html
Resolution: Postponed to v1.1. http://lists.oasis-open.org/archives/wss/200402/msg00062.html |
Closed |
251 | Technical | Closed | keyIdentifier valuetypes of Username and X509 profiles are defined relative to wsse schema - post v1 review period |
http://lists.oasis-open.org/archives/wss/200401/msg00122.html
Resolution: http://lists.oasis-open.org/archives/wss/200402/msg00062.html |
Closed |
252 | Editorial | Closed | Trivial editorial bug on SOAP Message Security - post v1 review period | http://lists.oasis-open.org/archives/wss/200401/msg00117.html | Closed |
253 | Editorial | Closed | minor editorial comment on SOAP Message Security - post v1 review period | http://lists.oasis-open.org/archives/wss/200401/msg00116.html | Closed |
254 | Editorial | Pending |
comments on core spec- Line 853 (Table) Soap message security 011504 -
merged: SOAP Message Normalization may be used as a"Transform" algorithm, not a "Canonicalization" algorithm - post v1 review period |
http://lists.oasis-open.org/archives/wss/200401/msg00104.html Resolution: Move to Errata | Editors |
255 | Editorial | Closed | Editorial comments on core spec - post v1 review period | http://lists.oasis-open.org/archives/wss/200401/msg00101.html | Closed |
256 | Technical | Pending | STR attributes are not protected. |
http://lists.oasis-open.org/archives/wss/200402/msg00042.html Resolution: Move to Errata |
Editors |
257 | Technical | Postponed | STR attrubutes are not protected | http://lists.oasis-open.org/archives/wss/200402/msg00042.html | Closed |
258 | Editorial | Closed, Duplicate |
Comments on core spec - post v1 review period | http://lists.oasis-open.org/archives/wss/200401/msg00104.html | Closed |
259 | Editorial | Pending | Editorial comments on Username Token profile - post v1 review period. |
http://lists.oasis-open.org/archives/wss/200401/msg00113.html Resolution: Move to Errata |
Editors |
260 | Editorial | Pending | Editorial comments on X.509 Token profile - post v1 review period. |
http://lists.oasis-open.org/archives/wss/200401/msg00114.html Resolution: Move to Errata |
Editors |
261 | Editorial | Pending | How do we handle the sender voucher scenario for SAML |
http://lists.oasis-open.org/archives/wss/200402/msg00034.html Resolution: Will leave the part of the SAML token spec. relating to sender-vouches unchanged. There will be no key in sender-vouches, subject confirmation. http://lists.oasis-open.org/archives/wss/200402/msg00062.html |
Ron |
262 | Editorial | Closed | Comments on sender voucher signed section in SAML interop draft. |
http://lists.oasis-open.org/archives/wss/200402/msg00032.html
Resolution: document ok until SAML discussions require change. http://lists.oasis-open.org/archives/wss/200402/msg00042.html |
Closed |
263 | Technical | Postponed | Open enumerations - post v1 review period. | http://lists.oasis-open.org/archives/wss/200402/msg00011.html | Closed |
264 | Editorial | Pending | Post review period comments: Errors in WSS core and username/x.509 profile examples. |
http://lists.oasis-open.org/archives/wss/200403/msg00034.html
Resolution: Editors to place typos in errata. Text changes to be sent to the list before being incorporated into errata. |
TC |
265 | Technical | Postponed | Encryption of wsse: security header | http://lists.oasis-open.org/archives/wss/200403/msg00011.html | Closed |
266 | Technical | Open |
Manesh: Are AttributeStatements the only statements pertinent to the SAML TP? Are AuthenticationStatements and AuthorizationDecisionStatements useful in the WSS scenarios? |
http://lists.oasis-open.org/archives/wss/200403/msg00074.html | TC |
267 | Editorial | Open | Typos in Sender-Vouches and Holder-of-Key examples listed in Saml interop document. | http://lists.oasis-open.org/archives/wss/200404/msg00007.html | TC |
268 | Technical | Open | How do we secure SOAP attachments? | http://lists.oasis-open.org/archives/wss/200404/msg00004.html | TC |
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]