[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] Minutes for Telecon, Tuesday 12 August 2003
Minor nit... The new action item "Chairs to followup with OASIS on namespace issues" is actually an Issues List action item for Issue-31. Rob Philpott RSA Security Inc. The Most Trusted Name in e-Security Tel: 781-515-7115 Mobile: 617-510-0893 Fax: 781-515-7020 mailto:rphilpott@rsasecurity.com > -----Original Message----- > From: Steve Anderson [mailto:sanderson@opennetwork.com] > Sent: Tuesday, August 12, 2003 2:38 PM > To: OASIS WSSTC (E-mail) > Subject: [wss] Minutes for Telecon, Tuesday 12 August 2003 > > Minutes for WSSTC Telecon, Tuesday 12 August 2003 > Dial in info: 1-517-267-1044 Passcode: 502413 > Minutes taken by Steve Anderson > > ====================================================================== > Summary > ====================================================================== > > Votes: > > - Minutes from 29 July 2003 meeting accepted (unanimous) > > New (General) Action Items: > > - Tim to set up conference call for end of week for X509 > profile discussion > - Chairs to followup with OASIS on namespace issues > > Issues List Action Items & Status Updates: > > - Editors to make editorial change from issue 99 > - 100 > - mis-marked, should be CLOSED > - 115, 120, 121, 122, 123, 124, 125 > - incorporated into last versions > - CLOSED > - 127 > - consensus on 2 points > - remove recommendation for exclusive c14n > - add brief discussion under interop considerations, > which > can be done in public review, since interop > considerations are non-normative > - Hal to propose wording for issue 127 by end of week > - PENDING > - 128 > - Tony to change example to refer to custom token rather > than username token, and to add description text > - PENDING > - 129 > - Editors to remove remaining text on SOAP attachments > - PENDING > - 130 > - Tim to provide clarifying text > - PENDING > > ====================================================================== > Raw Notes > ====================================================================== > > > > > Agenda: > > > > 1. Roll call > > > > - Attendance attached to bottom of these minutes > - Quorum achieved > > > > > 2. Review minutes from previous meeting (7/29/2003) > > < http://lists.oasis-open.org/archives/wss/ > > 200307/msg00067.html > > > > > - [VOTE] unanimous consent, accepted > > > > > 3. Review outstanding actions > > > > - everything has been moved to the issues list > > > > > 4. Editorial updates/document status [Editors] > > > > - Chris: X.509, Username & Core have been updated > - Phill: X.509 changes > - reorganized, doc now flows better > - had email from Tim this morning, seems roughly in agreement > - some changes still needed > - need to reference Merlin's signature transform > - Tim suggested we have a conference call later this week to > close these out > - [ACTION] Tim to set up conference call for end of week for X509 > profile discussion > - interested parties can email Tim, and he will provide call-in > details > - Hal: suggests Thurs at 3pm EDT > - Tony posted Username & Core, and indicated that changes are done > - Ron: thought we agreed to add statement to core relating to > ValueType, stating what the default is, for keyIdentifier > - Tony apparently couldn't find record of such decision > - Hal: it is in issues list, under resolution of issue 99 > - "Profiles must define what value is implied if specific value is > not specified" > - [ACTION] Editors to make editorial change from issue 99 > - Hal: did have an issue to post updated spreadsheet from June interop > - has done it > > > > > 5. Discussion of second interop scenarios > > > > - Hal: there has been a little feedback on the draft > - will roll them into an update, hopefully published today > - Chris: people should be looking at draft, and indicating when they > can do an interop > - has about 6-8 names so far > - any additional interested parties should email Chris quickly > - interop discussion (other than IP address info) will be carried out > on main email list > - Chris: need to know when people can provide a ready date for interop > - Kelvin: intent is to do virtual version of June interop event > - Merlin: need to schedule specific days, with IRC channel open > - Chris: are the interop draft changes significant enough that we need > to see the update before providing a ready date? > - (apparently not, no responses) > - Chris: will solicit commitments on list > > > > > 6. Address remaining V1 issues > > > > - Version 22 > - 115 > - Phill: has been folded in > - CLOSED > - 120, 121, 122, 123 > - all Frederick's edits > - Tony said all were incorporated > - Frederick: hasn't been able to get on to verify > - will re-raise if not acceptable > - CLOSED > - 124 > - Chris: believes all done > - editors can re-raise if not > - CLOSED > - 125 > - Simon's edit, should be folded in > - CLOSED > - 127 > - Peter not on call, Hal trying to summarize > - Hal: seems unacceptable to require receivers to know about all > schemas in the message > - Merlin: suggests using regular, inclusive c14n > - doesn't anticipate needing to sign something that will be moved > into another context > - Phill: disagrees, does anticipate moving to different context > - Chris: is there a specific edit here? > - Hal: yes, we need to make constraints very clear > - Merlin: agrees, and there are more issues with moving signed data > into new contexts beyond c14n, e.g. ID value collisions > - Hal: we need some proposed wording, along lines of Merlin's > warning > - Ron: this only shows up with exclusive c14n, right? > - Chris: no, can show up with inclusive c14n > - Merlin: solution can be to deal with separately signed XML > documents as attachments > - Phill: suggests we punt on this, and leave it for another > committee to work on > - Merlin: suggests we not recommend exclusive c14n, and that we > advise the spec reader to only use c14n algorithms after > understanding their limitations > - plain c14n is required for XML Sig compliance > - Ron: SSTC originally recommended inclusive, but has now changed > to recommend exclusive in order to support WSS > - Chris: all our interop work has been around exclusive c14n, so > we can continue to recommend that, with proper caveats > - Merlin: disagrees, we shouldn't recommend something with such > problems > - Jeff: we can learn from SSTC's pattern > - Merlin: this is different usage environment, since the signed > material in this case is in the SOAP header rather than the body > - Jeff: then we need to include the rationale > - Ron: there is some text around this already, around line 940 > - Tony: proposes that we document the challenges, as Phill > suggested > - Hal: thinks the only contention is whether we recommend a > particular c14n, and if so, which one > - Jerry: looking at exclusive c14n doc, and they intended this to > be used with signatures > - Merlin: again points out the difference in our usage vs. what > was intended with exclusive c14n > - Merlin: proposes we drop recommendation of exclusive c14n, and > that we recommend the use of an "appropriate" c14n, based on > spec reader's clear understanding of limitations of chosen c14n > - Don: are we saying that there isn't a c14n that covers all the > cases? > - Hal: yes > - Ron: we're also saying that the one we've recommended isn't the > best fit either > - Tony: disagrees, thinks we've identified limitations, but there > isn't a 'best' one > - Merlin: believes inclusive fits better > - Tony: disagrees, and will post issues with inclusive c14n > - Kelvin: can we address this during the public review? > - Merlin: yes, it's just a change to a recommendation > - Rob: cautions that substantive changes require repeating the > public review > - Hal: thinks that just saying "use an appropriate c14n" isn't > enough, thinks we need to provide description of issues around > using either inclusive or exclusive > - Chris: remaining neutral wrt c14n means inclusive must be > supported, but not necessarily be used > - John: and if another c14n algorithm emerges tomorrow, it can be > used by WSS implementations > - Ron: thinks this will impact profiles, e.g. MProf, SAML, X509 > - Hal: SAML in general should still use exclusive > - Phill: X509 profile shouldn't be affected > - Ron: we're not actively working on MProf currently > - consensus on 2 points > - remove recommendation for exclusive c14n > - add brief discussion under interop considerations, which can > be done in public review, since interop considerations are > non-normative > - [ACTION] Hal to propose wording for issue 127 by end of week > - Merlin: so 2nd interop will use inclusive? > - doesn't sound like there will be time to accommodate this > - Chris: choice of c14n is an interop choice anyway, and since > we've begun with excl, continue with it for now > - could have a 3rd interop using inclusive > - Merlin: fine with that > - PENDING > - 128 > - Hal: the example shows something not supported by the spec > - Ron: seems that example supports doing something cool, but > contradicts one of the non-goals of the spec > - Chris: yes, normatively defining mechanisms to identify out-of- > band keys is a non-goal, but parties are free to agree on a > mechanism on their own, and to use WSS to express it > - [ACTION] Tony to change example to refer to custom token rather > than username token, and to add description text > - PENDING > - 129 > - Chris: thought we removed the attachment section > - sounds like we missed a piece > - PENDING > - [ACTION] Editors to remove remaining text on SOAP attachments > - 130 > - Phill: issue is how much description about how we do encryption > belongs in core vs. X509 profile > - seems that some of the discussion is germane to any use of > encryption, not just X509 > - involves interaction with multiple roles > - Hal: had concluded that this multi-party decryption scenario > wasn't feasible > - Jerry: it's totally ambiguous now whether encrypted data is > replaced by decrypted data as the message is passed along > - Chris: why would it ever be replaced? > - Hal: that seems to be a common usecase, involving intermediaries > - Chris: why would we normatively discuss that, rather than leave > that to implementations? > - Hal: current spec doesn't say what intermediaries have to do, > which is ok, but it seems odd that people are interpreting it > differently > - Chris: any objections to leaving text way it is? > - Tim: ok with that, but would like some clarifying text on what > could be expected by intermediaries > - [ACTION] Tim to provide clarifying text > - PENDING > - (new) 131: Do we have a conformance list > - related to issue 130 > - post-v1.0 issue > - RESCINDED BELOW > - 31 > - Chris: still waiting for OASIS > - Kelvin: pessimistic that this will get resolved in time > - Rob: concerned that it will block the spec > - Chris: thought we'd continue to use the generic address we > already have, which is guaranteed to be persistent > - Rob: in private discussion with Karl, it doesn't sound like that > will be permitted with OASIS > - they have a namespace chosen, but there's no disk space behind it > yet > - [ACTION] Chairs to followup with OASIS on namespace issues > - 100 > - Jerry: mis-marked, should be CLOSED > - CLOSED > - Jerry: concerning 131/127, mandatory to implement discussion, thinks > that changing such text during public review will require another > review > - Chris: how is this outside WS-I work? > - [more discussion] > - result is that issue 131 is to be rescinded > > > > > 7. V1 committee spec vote ? > > > > - Kelvin: looks like we need one more rev before voting > - expectation is to have them posted by end of this week > - Phill: will be out all of next week, so all changes will be this week > - Kelvin: if we get revised versions out end of this week, can we have > a vote next week, with 7 days to vote, will that work to achieve > Committee Spec? Then, with results in hand, on next call, we can > vote to begin public review > - doc set will be Core, X509 and Username > - sounds acceptable > - Plan, restated: > - Get new versions of Core, X509 and Username docs by Friday > - Kavi votes will open beginning next week on each doc > - Voting will close after about 7 days > - On next call, we'll review voting results and consider voting to > begin public review > > > > > 8. Other business > > > > - none > > > > > 9. Adjourn > > > > - Adjourned > > > ----------------------------------------------------------------------- > > Attendance of Voting Members: > > Gene Thurston AmberPoint > Frank Siebenlist Argonne National Lab > Merlin Hughes Baltimore Technologies > Irving Reid Baltimore Technologies > Hal Lockhart BEA > Symon Chang CommerceOne > Thomas DeMartini ContentGuard > TJ Pannu ContentGuard > Seshu Madabhushi Convergys > Shawn Sharp Cyclone Commerce > Tim Moses Entrust > Toshihiro Nishimura Fujitsu > Yutaka Kudo Hitachi > Kelvin Lawrence IBM > Anthony Nadalin IBM > Nataraj Nagaratnam IBM > Don Flinn Individual > Bob Morgan Individual > Chris Kaler Microsoft > Chris Kurt Microsoft > John Shewchuk Microsoft > Frederick Hirsch Nokia > Lloyd Burch Novell > Steve Anderson OpenNetwork > Vipin Samar Oracle > Jerry Schwarz Oracle > Eric Gravengaard Reactivity > Andrew Nash RSA Security > Rob Philpott RSA Security > Edward Coyne SAIC > Martijn de Boer SAP > Pete Wenzel SeeBeyond > Jonathan Tourzan Sony > Yassir Elley Sun Microsystems > Jeff Hodges Sun Microsystems > Ronald Monzillo Sun Microsystems > Jan Alexander Systinet > Don Adams TIBCO > John Weiland US Navy > Phillip Hallam-Baker VeriSign > > > Attendance of Observers or Prospective Members: > > Howard Melman Novell > << awaiting email >> > << awaiting email >> > > > Membership Status Changes: > > Derek Fu IBM - granted voting status after call > Howard Melman Novell - granted voting status after call > > > -- > Steve > > > You may leave a Technical Committee at any time by visiting > http://www.oasis- > open.org/apps/org/workgroup/wss/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]