OASIS Web Services Security Issues List

Version 46, Modified on Monday August 09, 2004 19:03:15 -0700

Status

The previous version of the issues list (Version 45) is at http://www.oasis-open.org/apps/org/workgroup/wss/download.php/8265/wss-issues-45.htm. 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.

Links to issue categories :

Open/Pending/Post-v1 Issues

53 Technical Closed for v1

Open (post-v1)

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 token makes no mention of its potential value in defining the key to support the 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 than obvious from the description that these tokens could be used to identify a signing (or encryption key); which perhaps is the most significant use case that features such tokens.

The example in section 3.4  beginning at line 248,  seems to depict the use of such tokens (as revealed by lines 299-300), as a means to carry a 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
Resolution: Username token profile has been separated from the core specification. The primary issue of key material for username token will be handled in this document. Follow link above for additional information.
Note: Issue placed here to relate to potential re-opening of this issue.
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
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
86 Technical Postponed

Open
(post v1)

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

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

Closed
103 Editorial Closed
Open
(post v1)
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.
Ron: Revisited?
Closed
196 Editorial Closed
Opened
(post v1)
WSS: Soap message security: General: Also, why use qualified names instead of URIs for identifying encoding types. Ron: editors
chose to use URIs fragments based on ambiguously specified roots
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
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
263 Technical Postponed Open enumerations - post v1 review period. http://lists.oasis-open.org/archives/wss/200402/msg00011.html Closed
265 Technical Postponed Encryption of wsse: security header http://lists.oasis-open.org/archives/wss/200403/msg00011.html Closed
271 Technical Postponed Comments from Wells Fargo: Username token does not provide a mechanism for indicating its type or domain http://lists.oasis-open.org/archives/wss/200404/msg00054.html Closed
282 Technical Pending Password based key derivation - revisited http://lists.oasis-open.org/archives/wss/200402/msg00060.html
Action item: Paul Cotton has action item to research and get back.
http://lists.oasis-open.org/archives/wss/200406/msg00026.html
Action item: Tony to propose text.
Action: Additional section in UserNameToken.vNext describing the mechanism. Additional data in UserNameToken.vNext security considerations.
Editors
290 Technical Pending Inconsistency in the KeyIdentifier encoding type default between core and SAML specifications. Core defines default of Base64Binary while SAML spec defines default to be xsi:string. Issue raised during SAML interop
http://lists.oasis-open.org/archives/wss/200406/msg00066.html

Resolution: Core also defines the unencoded string so the profiles will not have to redefine that themselves.  Any profile that does not have Base 64 will have to change, only one exists presently (SAML).  

Action: Ron to write up and send to list
Action: Editors to make changes as described in http://lists.oasis-open.org/archives/wss/200407/msg00077.html
Action: Editors to fold this into next document of the core.
Note: There is two versions of docs related to core: 1) errata for core 2) errata plus previously closed issues opened for review

Editors
298 Technical Open
 
X509 TP: IssuerSerial - What are the advantages of IssuerSerial as opposed to using SubjectKeyInfo http://lists.oasis-open.org/archives/wss/200406/msg00104.html
Action: Hal to create a proposal - Proposal sent: http://lists.oasis-open.org/archives/wss/200407/msg00066.html
Action:
Hal
306 Technical Pending SwA Profile comments -
a. Specify MIME header canonicalization algorithm
b. Specify how to find details for any content types
c. Can we sign the Content-Transfer-Encoding header itself?
http://lists.oasis-open.org/archives/wss/200407/msg00024.html
Action: Mark pending, editors to make changes to draft.
http://lists.oasis-open.org/archives/wss/200407/msg00047.html 
 
Editors
308 Technical Open Hal Lockhart: License Id in REL token profile http://lists.oasis-open.org/archives/wss/200407/msg00041.html
Action: Leave open till next call. Review on the mailing list.
TC
309 Editorial Open Dana Kaufman: Example 4.4.5 seems to be missing an <xenc:EncryptionMethod> tag http://lists.oasis-open.org/archives/wss/200407/msg00103.html TC
310 Technical Open Hal Lockhart: Clarification on using Key Identifier when SKI extension is not present http://lists.oasis-open.org/archives/wss/200408/msg00008.html TC
311 Technical Open Nishimura Toshihiro: SWA Profile comments http://lists.oasis-open.org/archives/wss/200407/msg00097.html TC
312 Technical Open Dana Kaufman: Feedback on SWA Profile-1.0-draft-06 http://lists.oasis-open.org/archives/wss/200407/msg00101.html TC
313 Technical Open Manveen Kaur: Errata WSS:SOAP Message Security v1.0 http://lists.oasis-open.org/archives/wss-comment/200408/msg00001.html TC


 

Closed Issues related to SAML/XrML/Kerberos and other token profiles

WSS ID Type Status Issue Resolution Owner(s)
3 Technical  Closed, Duplicate of 67? 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
Resolution: Follow link above for resolution.
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
Resolution: Follow link above for resolution.
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
Resolution: Follow link above for resolution
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
Resolution: Follow link above for resolution. 
Closed
30 Technical Closed How should XML be explained. http://lists.oasis-open.org/archives/wss/200306/msg00025.html.
Resolution: Chris has sent mail to Editors for what they are supposed to do!
Closed
35 Technical Closed, Related to 290? 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
Resolution: Follow link above for resolution.
Closed
44 Technical Closed SAML Cannonicalization http://lists.oasis-open.org/archives/wss/200212/msg00037.html Closed
59 Technical Closed Various editorial comments on XrML binding http://lists.oasis-open.org/archives/wss/200302/msg00019.html
Resolution: Thomas sent mail closing this.
Closed
63 Technical Closed XML Token Wrapper http://lists.oasis-open.org/archives/wss/200302/msg00017.html Closed
87 Technical Closed Add a profile for XKMS to WS-Security. Currently no owner for this. 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
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:
 - remove recommendation for exclusive c14n
 - add brief description under interop considerations
Hal to propose wording for issue 127.
Resolution: Doesn't block ship
Hal to provide non normative text.

http://lists.oasis-open.org/archives/wss/200311/msg00058.html

Clsoed
165 Technical Closed Passing binary data in SAML Assertion Token http://lists.oasis-open.org/archives/wss-comment/200309/msg00000.html 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 Closed Update Kerberos profile to use new URLs Editors to make this change Closed
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 Closed Rename Kerberos profile document 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:
non global attributes does not support element extensibility....

SAML has a work around
should schema support mixed content....

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 Closed 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
Resolution: Addressed in Errata.
Closed
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 Closed STR attributes are not protected. http://lists.oasis-open.org/archives/wss/200402/msg00042.html
Resolution: Clarifications added to Errata.
Closed
257 Technical Postponed Duplicate STR attrubutes are  not protected http://lists.oasis-open.org/archives/wss/200402/msg00042.html Closed
259 Editorial Closed Editorial comments on Username Token profile - post v1 review period. http://lists.oasis-open.org/archives/wss/200401/msg00113.html
Resolution: Clarifications added to Errata
Closed
260 Editorial Closed Editorial comments on X.509 Token profile - post v1 review period. http://lists.oasis-open.org/archives/wss/200401/msg00114.html
Resolution: Clarifications added to Errata
Closed
261 Editorial Closed 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
Closed
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
264 Editorial Closed 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 placed text in Errata

Closed
266 Technical Closed 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 Closed
267 Editorial Closed Typos in Sender-Vouches and Holder-of-Key examples listed in Saml interop document. http://lists.oasis-open.org/archives/wss/200404/msg00007.html Closed
268 Technical Closed How do we secure SOAP attachments? http://lists.oasis-open.org/archives/wss/200404/msg00004.html
Resolution: Proposals sent to mailing list
Closed
269 Editorial Closed Need clarification on the URIs for type attributes. http://lists.oasis-open.org/archives/wss/200404/msg00034.html Closed
270 Process Closed Comments from Wells Fargo: support from SAML 1.1 token profile http://lists.oasis-open.org/archives/wss/200404/msg00054.html Closed
272 Editorial Closed SAML interop scenario doc should use 1.1 for version. http://lists.oasis-open.org/archives/wss/200404/msg00061.html Closed
273 Technical Closed Should we have conditions in SAML tokens? Should their presence indicate that they should always be processed? http://lists.oasis-open.org/archives/wss/200404/msg00061.html
Resolution: Condition processing is to be same as in SAML Core.
Closed
274 Technical Closed Format attribute vs NameQualifier attribute of NameIdentifier http://lists.oasis-open.org/archives/wss/200404/msg00061.html Closed
275 Editorial Closed SAML token profile, Interop - dateTime formats - need clarification http://lists.oasis-open.org/archives/wss/200404/msg00076.html Closed
276 Editorial Closed Problem with document URLs http://lists.oasis-open.org/archives/wss/200404/msg00082.html Closed
277 Technical Closed Kerberos profile: Ticket granting ticket should be removed from Kerberos profile http://lists.oasis-open.org/archives/wss/200404/msg00093.html
Action Item: Phil will add text to propose a resolution to this question
http://lists.oasis-open.org/archives/wss/200406/msg00028.html
TC
278 Technical Closed Kerberos profile: Deriving Session Keys from master secret http://lists.oasis-open.org/archives/wss/200404/msg00094.html
Resolution: No action required
Closed
279 Technical Closed XrML: Multiple grants http://lists.oasis-open.org/archives/wss/200404/msg00097.html
Resolution: there should be only one keyHolder
principal across those grants
Closed
280 Process Closed What if any IP issues apply for SAML interop? http://lists.oasis-open.org/archives/wss/200405/msg00001.html
Resolution: http://lists.oasis-open.org/archives/wss/200405/msg00019.html
Action item: Rob will get Andrew to repost the issue to state this.
Resolution: Andrew Nash sent a clarifying note to the TC.
Closed
281 Editorial Closed X509 Token profile - sample still uses QNames. (BinarySecurityToken attributes) http://lists.oasis-open.org/archives/wss/200405/msg00003.html
Resolution: Tony will create errata for each separate document.
Resolution: Addressed in Errata.
TC
283 Technical Closed User To User Kerberos http://lists.oasis-open.org/archives/wss/200405/msg00018.html
Action item: Hal and Phillip will research and report back on this issue.
http://lists.oasis-open.org/archives/wss/200406/msg00028.html
TC
284 Editorial Closed SAML virtual interop scenario typos http://lists.oasis-open.org/archives/wss/200405/msg00021.html
Resolution: Fixed.
Closed
285 Technical Closed Transforms for securing attachments http://lists.oasis-open.org/archives/wss/200405/msg00022.html
Action Item Jerry Schwarz, Fredrick Hirsch and Mike McIntosh to issue a proposal on these issues
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/7236/wss-swa-profile-1.0-draft-04-diff.pdf
Written as interoperability scenarios. Needs more discussion.
Resolution: The proposal has made enough progress. Individual areas will be addressed as necessary.
TC
286 Technical Closed The examples should be made consistent so that the assertion always has the same subject identified and issuer. Should specify how the issuer is specified Issue raised during SAML interop Closed
287 Technical Closed Need to use namespace qualified mustUnderstand for interop Issue raised during SAML interop. Closed
288 Technical Closed When using a signature to bind an on msg assertion to its soap msg, why is it necessary to use an STR to reference the assertion from signedInfo of the signature. Issue raised during SAML interop Closed
289 Editorial Closed minor typo in the interop document. Lines 705-708 should be contained within the ds:Transform.
<dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform"/>
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</wsse:TransformationParameters>

should be

<dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</wsse:TransformationParameters>
</dsig:Transform>
 
Issue raised during SAML interop Closed
291 Technical Closed Clarify that the SAML token profile only covers SAML 1.1 Issue raised during SAML interop
Resolution: Fixed in SAML 1.1
Closed
292 Technical Duplicate Interop scenario #3 has an enveloped signature that signs the assertion (referenced using the AssertionID) and a detached signature signing the assertion as well as the message body. One option is to sign the assertion referenced via a SecurityTokenReference. Another option is to have referenced the assertion directly using the AssertionID attribute. What is the right option?
 
Issue raised during SAML interop
Resolution: Issue 288
Closed
293 Technical Closed Does the x509 token profile standardize an interoperable encapsulation of  an X.509 V1 certificate in a BinarySecurityToken http://lists.oasis-open.org/archives/wss/200405/msg00067.html
Action: Need to fold clarification into Errata:
http://lists.oasis-open.org/archives/wss/200406/msg00068.html
Closed
294 Procedural Closed XrML trademark issues http://lists.oasis-open.org/archives/wss/200405/msg00068.html
Resolution: XRML changed to REL
Closed
295 Technical Closed Ramana Turlapati: Comments on SAML Token profile - sender vouches scenario is too complex. http://lists.oasis-open.org/archives/wss/200406/msg00052.html
Resolution: Friendly amendment suggested and closed.
Closed
295b Technical Closed Ramana Turlapati: Profile does not cover SAML "Bearer" tokens. Is this scoped for future?
 
http://lists.oasis-open.org/archives/wss/200406/msg00052.html
 
Closed
296 Technical Closed Anthony Nadlin: Comments on SAML Token profile and ID usage. http://lists.oasis-open.org/archives/wss/200406/msg00058.html
Resolution: Add clarification to be added to future version. "SAML token profile mandates use of key identifier method of referencing local SAML tokens excluding use of the
direct reference method to local tokens other than wsu:Id"
Resolution: Fix was added to draft.
Closed
297 Technical Closed Attachment Profile Question/Comment http://lists.oasis-open.org/archives/wss/200406/msg00067.html
Resolution: clarification was added to this issue
Closed
299 Editorial Closed Frederick Hirsch: SOAP security errata 1.0 comments http://lists.oasis-open.org/archives/wss/200406/msg00111.html Closed
300 Editorial Closed Frederick Hirsch: X.509 Token profile errata comments http://lists.oasis-open.org/archives/wss/200406/msg00112.html Closed
301 Editorial Closed Frederick Hirsch: Username Token profile errata comments http://lists.oasis-open.org/archives/wss/200406/msg00113.html Closed
303 Editorial Closed Attachment profile question: Sec 2.2.1 MIME Part CipherReference Transform line 265 says: The <xenc:CipherReference> must have a <ds:Transforms> child element,
and this element must have a <ds:Transform> child. But the example (starting line 334) is as follows: <Transforms>
  <ds:Transform ...
Shouldn't it be <ds:Transforms>? 
http://lists.oasis-open.org/archives/wss/200407/msg00007.html
Action: Editors to update
Resolution: Updated.
Closed
304 Editorial Closed REL Profile Lines 294-298: Use of MAY http://lists.oasis-open.org/archives/wss/200407/msg00010.html
Resolution: No changes.
Closed
302 Editorial Closed Nishimura Toshihiro: A small errata for the core spec. http://lists.oasis-open.org/archives/wss/200406/msg00117.html
Action: Tony to add to Errata
Closed
305 Technical Closed Kerberos profile - Exchanging raw tickets, that is without Kerberos authenticators, poses several risks. Related to Issue #283 http://lists.oasis-open.org/archives/wss/200407/msg00014.html
Action: Need a proposal on how to support user to user.
3 actions items

1. User to User is app specific
 2. TGT is app specific  3. service ticket to AP_REQ
 
Closed
307 Technical Closed More SwA comments -
a. Relationship to SOAP versions
b. Processing of sub document parts in an XML attachment
c. Line 108, we should define MTOM.
d. Line 133 still refers to Content-Location
e. Need statement about attachment canonicalization when it is XML.
 
http://lists.oasis-open.org/archives/wss/200407/msg00025.html
Action: Frederick - make editor pass to see  if he can resolve this.
Resolution: Editorial pass resolved the issue.
Closed

Notes on Issues

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