OASIS Web Services Security Issues List

Version 83, Modified on Tuesday, 15 November 2005 11:01:46 AM -0000

Status

The previous version of the issues list (Version 82) is at http://www.oasis-open.org/apps/org/workgroup/wss/download.php/14858/OASIS%20Web%20Services%20Security%20Issues%20List%2082.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

The first four columns of the table are colour-coded as follows;

Open issues requiring discussion by the TC
Pending issues requiring editors to incorporate resolutions and upload updated documents
Pending Review issues requiring TC review of documents and subsequent closure

338

Technical

Open

Hal: Proposed new work - WSS Templates

http://lists.oasis-open.org/archives/wss/200410/msg00060.html
 

No change in status in the last meeting.

TC
444 Process Pending Request to remove the WS-Security 1.0 errata from WSS page or fix it http://lists.oasis-open.org/archives/wss/200509/msg00112.html
Status: 2005-10-04: Editors to provide an updated errata page with the X.509 token URI that ends with #X509 replaced with a URI that ends with #X509v1
Status: 2005-10-18: After e-mail from Thomas  http://lists.oasis-open.org/archives/wss/200510/msg00037.html  TC instructed editor's to ensure changes in http://lists.oasis-open.org/archives/wss/200503/msg00025.html are present in the errata. This subsumes the status from 2005-10-04.		 Editors

Closed Issues

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

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.
Resolution: closed by 282. 

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

67

Technical

Closed

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.
http://www.oasis-open.org/archives/wss/200408/msg00064.html
Hal has sent out a proposal.

Closed

84

Technical

Close

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.
Action: Editors to review and potentially incorporate the proposed text
Status: Hal and Tony to follow up.
Status: Discussion on the email list on the necessity for decryption transform being always present vs. where we don't: http://lists.oasis-open.org/archives/wss/200411/msg00037.html
Status: Action on Mike to respond to Hal's email before next call.
http://lists.oasis-open.org/archives/wss/200411/msg00053.html
Status: Mike didn't have time to respond. Leave as pending. http://lists.oasis-open.org/archives/wss/200412/msg00038.html
Status from 12/14/04: Mike to follow up with new proposal. Editors to remove transform stuff.
Resolution: Remove the transform section. This was done. The latest document has the changes. Closed.

Status: This was not resolved completely. Latest draft (
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/12305/oasis-2004xx-wss-soap-message-security-1.1-changes.pdf) contains decryption transform section.

Close

86

Technical

Closed

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.
Status: Related to 319.
Propose that we close the issue. If we don't find interest by Tuesday Oct 19 con call, we will close.
Resolution: No action. Rolled into 319.

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

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.
Ron: Revisited? Ron to figure out the status of this issue
Resolution: Add to Errata/1.1 "ValueType is recommended on all non-local URIs (direct references via shorthand xpointer)."
ACTION[Editors]: Update Errata and 1.1 per 103 resolution

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

Closed

165

Technical

Closed

Passing binary data in SAML Assertion Token

http://lists.oasis-open.org/archives/wss-comment/200309/msg00000.html

Closed

196

Editorial

Closed
 

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.
Resolution: Fixed. This was a left over issue.

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

250

Technical

Closed

Should ValueType attribute of STR reference element be moved to top level 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
Action: Ron to generate proposal for STR ValueType.
Status: Ron sent email. http://www.oasis-open.org/archives/wss/200411/msg00005.html
Action: TC to review before next conf call.
Action: Ron and Thomas each forward proposal to TC http://lists.oasis-open.org/archives/wss/200412/msg00003.html
Status: Corinna, Ron and/or other champions of the issue to
garner support. http://lists.oasis-open.org/archives/wss/200412/msg00057.html has more information
Action: Ron to produce updated proposal. Based on above minutes.
http://lists.oasis-open.org/archives/wss/200501/msg00019.html
Status: Ron sent a proposal. http://lists.oasis-open.org/archives/wss/200501/msg00020.html
Action: Ron to send proposal to the list
From meeting notes:There ensued a long discussion of issue 250. The final result was that there be a lead agenda item at the next telecom to vote on accepting either Ron's proposal or Thomas's proposal. However, if Ron and Thomas can come up with a common, combined proposal before the next telecom; that will be accepted.
Status: Motion passed. Editors to make changes. Leave issue 250 (open/pending/Pending Review?) to track changes.

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

263

Technical

Closed

Open enumerations - post v1 review period.

http://lists.oasis-open.org/archives/wss/200402/msg00011.html
Action: Gudge to revive proposal for Open enumerations
Status: Gudge has sent an email. Discussion about whether we should do this or not.
Resolution: No change. TC decided that it was not worth the effort clean up.

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

265

Technical

Closed

Encryption of wsse: security header

http://lists.oasis-open.org/archives/wss/200403/msg00011.html
Resolution: Covered by 317

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

271

Technical

Closed

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
Resolution: Not fixed. Username can contain other fields if necessary.

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

Closed

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.

Closed

282

Technical

Closed

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: Tony to propose text.
Action: Additional section in UserNameToken.vNext describing the mechanism. Additional data in UserNameToken.vNext security considerations.
Action: Tony to update v.next
Status: Updated posted. http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10656/oasis-2004xx-wss-username-token-profile-1.1-changes.pdf
Action: TC to review.
Resolution: Changes in update seem correct. Closed.

Closed

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

Closed

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.

Closed

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

290

Technical

Closed

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
Resolution: Fixed in errata for core.

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

298

Technical

Closed
 

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: Editors to look over the
wording on token ordering in the core and make sure that it is clear
(otherwise clarify in v.next) that token profiles can define ordering
Status: Updated posted. http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10649/oasis-2004xx-wss-soap-message-security-1.1-changes.pdf
Action: TC to review.

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

306

Technical

Closed

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 
Resolution: Clarified text.

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

308

Technical

Closed

Hal Lockhart: License Id in REL token profile

http://lists.oasis-open.org/archives/wss/200407/msg00041.html
Resolution: no action

Closed

309

Editorial

Closed

Dana Kaufman: Example 4.4.5 seems to be missing an <xenc:EncryptionMethod> tag

http://lists.oasis-open.org/archives/wss/200407/msg00103.html
Action: SwA profile to look into this. Resolution: SwA fixed.
Action: Other profiles to look into this. Non-normative comments to be added to core.
Action: Discuss on the list. 
Status: Frederick fixed in the SwA profile; text in the core may need to be changed;
Action: Editors to review other Token profiles and verify that it does not apply to other documents.
Action: Editors to incorporate. Review pending.

Closed

310

Technical

Closed

Hal Lockhart: Clarification on using Key Identifier when SKI extension is not present. Vijay Gajjala; Are there alternative mechanisms that can be used in this case? Revisit.

http://lists.oasis-open.org/archives/wss/200408/msg00008.html
Resolution: Current document meets the alternative #1. Spec + Errata says that KeyIdentifier cannot be used unless token contains an SKI.
Action: Vijay to send out a new proposal.
Status: Vijay sent out proposal. Rich commented that this seemed sufficient.
Status: Discuss on the mailing list if the implementations have concerns about this being optional.
Status: Make it clear that you can include multiple key reference
methods in a single KeyInfo. This allows you to include a potentially more efficient (SKI) mechanism along with a potentially more interoperable mechanism (IssuerSerialNumber) for example.
Action: Ron to review.
Action: Vijay to point out what has changed in the spec.
http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10649/oasis-2004xx-wss-soap-message-security-1.1-changes.pdf
Action: Vijay to get proposal to list working with Ron.
Action: Ron to send out email with comments outlining differences.
Status: Ron sent out observations to the mailing list - http://lists.oasis-open.org/archives/wss/200503/msg00017.html
Status: Editors to make changes
Status: It does not appear that the edits have made it into the documents.
Action: Tony will address these missing edits.

Status/Action: Frederick - the new text in the latest core WSS draft at line 984 seems to be unclear. Tony to review text.

Status/Action: This issue was missing edits.  Still Pending additional text to be added
by Tony.

Status: This was already fixed by Tony. No further action required.

Closed

311

Technical

Closed

Nishimura Toshihiro: SWA Profile comments

http://lists.oasis-open.org/archives/wss/200407/msg00097.html
Resolution: Change incorporated into the spec.

Closed

312

Technical

Closed

Dana Kaufman: Feedback on SWA Profile-1.0-draft-06

http://lists.oasis-open.org/archives/wss/200407/msg00101.html
Action: Dana to work with Frederick on part 2 and 3 and post to list
Action: Review of draft 8 of SwA profile.
Resolution: Fixed in the profile.

Closed

313

Technical

Closed

Manveen Kaur: Errata WSS:SOAP Message Security v1.0

http://lists.oasis-open.org/archives/wss-comment/200408/msg00001.html
Action: Editors to review
Resolution: Fixed in Errata.

Closed

314

Editorial

Closed

Kojiro Nakayama: Comments on final+errata documents

http://lists.oasis-open.org/archives/wss/200408/msg00022.html
Resolution: Fixed in Errata

Closed

315

Technical

Closed

Dana Kaufman: Provide PKI examples?

http://lists.oasis-open.org/archives/wss/200408/msg00024.html
Action: Hal to provide errata text clarifying why token examples are not specified in core. Direct readers to look for examples in relevant profiles.
Status: Hal created text for Errata.
Action: Editors to update Errata/1.1
Status: Tony to post updates. Updated posted. http://www.oasis-open.org/apps/org/workgroup/wss/download.php/10115/oasis-2004xx-wss-x509-token-profile-1.1-changes.pdf
Action: TC to review in 1.1 Errata.

Closed

316

Editorial

Closed

Dana Kaufman: Minor item from SwA profile

http://lists.oasis-open.org/archives/wss/200408/msg00048.html
Resolution: Fixed in draft 8. Minor namespace issue.

Closed

317

Technical

Closed

Vijay Gajjala: Encrypted Header

http://lists.oasis-open.org/archives/wss/200408/msg00057.html
Action: Vijay to propose text
Action: TC to review and provide feedback
Status: Hal - leave open, sent email regarding this
http://www.oasis-open.org/archives/wss/200410/msg00069.html
Requires further discussion on list
Status: Hal okay with the concept.
Action: Hal to review and respond with updated text. http://lists.oasis-open.org/archives/wss/200412/msg00037.html

Closed

318

Technical

Closed

Vijay Gajjala: Encrypted Key

http://lists.oasis-open.org/archives/wss/200408/msg00058.html
Action: Vijay to propose text
Action: TC to review proposed text and provide feedback
Status: Needs review

Closed

319

Technical

Closed

Vijay Gajjala: Signature Confirmation

http://lists.oasis-open.org/archives/wss/200408/msg00059.html
Action: Vijay to do comparison of prior proposal from Eric Gravengard.
Action: TC to review proposed text and provide feedback
Status: Needs review

Closed

320

Technical

Closed

If EncryptedData is referenced from an EK within security header, then you don't need a separate reference list as child of security header.

http://lists.oasis-open.org/archives/wss/200407/msg00101.html
Action: Dana to get status.

Closed

321

Technical

Closed

Dana Kaufman: Clarify how to interpret/transform the encrypted contents of the attachment

http://lists.oasis-open.org/archives/wss/200408/msg00071.html
Action: Review draft 9. Frederick believes it has been addressed in this draft.
Status:  http://lists.oasis-open.org/archives/wss/200409/msg00082.html
Resolution: Addressed in the draft. Dana agrees.

Closed

322

Technical

Closed

Blake Dournaee: Are XML attachments opaque or not

http://lists.oasis-open.org/archives/wss/200408/msg00072.html
Resolution: http://lists.oasis-open.org/archives/wss/200409/msg00012.html

Closed

323

Technical

Closed

Blake Dournaee: Statement in SwA that when <EncyptedKey> element is present, <KeyInfo> element should not be present. This seems wrong.

http://lists.oasis-open.org/archives/wss/200408/msg00073.html

Closed

324

Technical

Closed

Maneesh Sahu: What is the value in canonicalizing the content-length mime header?

http://lists.oasis-open.org/archives/wss/200409/msg00002.html
Resolution: http://lists.oasis-open.org/archives/wss/200409/msg00078.html

Closed

325

Technical

Closed

Which attachment headers to include in signature? Should headers be included in signature?

http://lists.oasis-open.org/archives/wss/200409/msg00014.html
Resolution