[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Minutes for Telecon, Tuesday 18 November 2003
Seems to have bounced, so resending ... -- Steve Anderson OpenNetwork > -----Original Message----- > From: Steve Anderson > Sent: Wednesday, November 19, 2003 1:16 AM > To: OASIS WSSTC (E-mail) > Subject: Minutes for Telecon, Tuesday 18 November 2003 > > Minutes for WSSTC Telecon, Tuesday 18 November 2003 > Dial in info: 1-706-679-8701 Passcode: 5086288251 > Minutes taken by Steve Anderson > > ====================================================================== > Summary > ====================================================================== > > Votes: > > - Minutes from 4 November 2003 meeting accepted (unanimous) > > New (General) Action Items: > > - none > > Issues List Action Items & Status Updates: > > - 233 > - Editors to incorporate Hal's changes for 233, with Chris' > QName suggestion > - Editors to move Username token specific security considerations > to Username profile > - Hal to work with Paula to add more detail to Security > Considerations material > - PENDING > - 234 > - PENDING > - 235 > - Editors to clarify > - PENDING > - 127, 137, 206 > - Editors to incorporate Hal's text > - PENDING > - Hal's new issue (236?) > - Editors to incorporate Hal's text > - PENDING > - Mike's new issue (237?) > - Editors to provide explanation/example text > - PENDING > - Chris' new issue (238?) > - OPEN > - 173 > - agreed to Hal's approach > - 190 > - Irving to write up revised proposal for mustUnderstand > - 196 > - agreed that this issue arose too late to accommodate with > changes > > ====================================================================== > Raw Notes > ====================================================================== > > > > > Agenda: > > > > 1. Roll call > > > > - Attendance attached to bottom of these minutes > - Quorum achieved > > > > > 2. Review minutes from previous meeting (11/4/2003) > > < http://lists.oasis-open.org/archives/wss/ > > 200311/msg00041.html > > > > > - [VOTE] unanimous consent, accepted > > > > > 3. Status of updated documents (Editors) > > > > - Ron: SAML profile update > - worked on doc last week, but no update ready for posting > - trying to get ready by US Thanksgiving > - Phill: X509 profile > - put out new rev a week ago > - closed out all existing issues, except namespace URIs > - Phill: XrML profile > - handing ownership over to Thomas DeMartini > - Chris: need to start getting feedback on these other profiles > - Tony not on call > > > > > 4. Issues list review > > > > - 233 > - Paula was to provide info > - Paula: sent something to mailing list last week > < http://lists.oasis-open.org/archives/wss/200311/msg00052.html > > - Martijn: wondering if we have this same replay problem with all > tokens > - ref issue 100 & 69 > - why should we do something special for username token? > - why shouldn't we wait for WS-Addressing? > - Hal: had argued that domain can be included as part of the string > - can also include destination > - Chris: likes Hal's proposal > - seems that it's missing ability for two parties to agree on a > mechanism, and express it in a message, like via a QName > - Hal: this proposal isn't normative, since he didn't expect TC to > accept a new hash algorithm > - Steve: agrees with this direction > - [ACTION] Editors to incorporate Hal's changes for 233, with Chris' > QName suggestion > - back to main substance of issue 233 ... > - Hal: agrees with preamble and approach, but thinks it needs more > detail around some of these > - [ACTION] Editors to move Username token specific security > considerations to Username profile > - [ACTION] Hal to work with Paula to add more detail to Security> > Considerations material from issue 233 > - PENDING > - 234 > - Ron: thinks this is a version requirement > - we discussed this on the last call > - expect to address it in next doc rev > - PENDING > - 235 > - Frederick: processing rules are confusing > - other point was a clarification too > - Chris: thinks the second point was also made by WS-I > - PENDING > - [ACTION] Editors to clarify, per issue 235 > - Hal: sent some email concerning old issues > - there were several issues that we couldn't address before the > public review, but intended to address before finalization > - dug up the background on those, for 127, 137, 206, and posted > last night > < http://lists.oasis-open.org/archives/wss/200311/msg00058.html > > < http://lists.oasis-open.org/archives/wss/200311/msg00059.html > > < http://lists.oasis-open.org/archives/wss/200311/msg00060.html > > - Chris: all seem reasonable to give to editors > - [ACTION] Editors to incorporate Hal's text for issues 127, 137, > and 206 > - PENDING > - Hal: new issue, sent last night > < http://lists.oasis-open.org/archives/wss/200311/msg00061.html > > - Chris: looks like leftover from previous incarnations > - [ACTION] Editors to incorporate Hal's new issue > - PENDING > - Mike: new issue, sent this morning > < http://lists.oasis-open.org/archives/wss/200311/msg00062.html > > - Hal: caused this confusion > - even so, it's odd to have 2 places to represent the same thing > - Chris: reason was because some tokens may be represented via a > URI that isn't a fragment URI > - this helps you determine which is which > - Mike: can we get some explanation/example text? > - Chris: good idea > - [ACTION] Editors to provide explanation/example text for Mike's > new issue > - PENDING > - Chris: new issue, not posted yet > - in out signature transform, we define it as requiring a c14n > element > - turns out to be not schema valid > - Hal: related issue is that there may be a need to use 2 transforms > - Chris: do we want to remove the element or change its namespace > - Hal: in the signature, you can have as many transforms as you > want, so why not just use that > - Chris: Merlin did the most work in this area > - will leave open, and get more discussion on what to do > - Irving: issue 190 has had lots of discussion, but no apparent > resolution > - Hal: also have open issue of SOAP 1.1 vs 1.2 (issue 173) > - had posted direction agreed upon on previous call > < http://lists.oasis-open.org/archives/wss/200311/msg00009.html > > - but email traffic that followed indicates we don't have consensus > on this > - devolved into Issue 190 > - Chris: so where are we now on issue 173? > - [discussion] > - Chris: does anyone object to approach proposed by Hal? > - [none] > - back to issue 190, mustUnderstand semantics > - Irving: simplest approach is, at every extensibility point, if > you see something you don't comprehend, you toss the whole > message > - Chris: am I the only one that finds that unacceptable? > - similar to X509 criticality flag > - Phill: senders should avoid using this flag unless they have > reasonable expectation that receiver can understand > - Irving: up to the sender to correctly mark portions as > mustUnderstand > - Ron: seems like there's been less time spent considering when it > is reasonable to set this > - Hal: there are two issues getting confused here > - first, is that this is complementary to SOAP default of > "mustIgnore" > - second, is that receivers may reject message due to their policy > requirements > - Ron: doesn't know of many cases where sender is driving policy > > causing receiver to reject message > - Hal: this is supposed to be an interop facility > - Phill: this is why in SAML this is defined in terms of revocation > - Hal: thinks key problem is the granularity is at SOAP header, and > we need an overall rule that has to apply to entire header > - Phill: could say for X509 profile, if mustUnderstand is set, you > must process anything marked critical, and for SAML ... > - Tim: rule could be different for every extension point > - Phill: X509 folks started marking lots of things critical, but > later found that wasn't always a great idea > - Chris: doesn't see a concrete proposal yet > - Phill: suggests we put text in each profile addressing how to > handle it > - Thomas: doesn't think the mustUnderstand semantics are distributed > like that > - have to address at Security header, so must address in core > - Irving: so we got here because SOAP defers semantics to us > - we've been waiving our hands alot, but we need to document what > it means to us before taking our spec public > - problem is in all the extension points > - Thomas: had made a catalog of all the extension points in an > earlier email > - Irving: from there we can identify which extension points are > critical, and which aren't > - Don: reiterates the lack of usecases for this > - Chris: this setting can't be secured anyway > - Hal: if you can understand it, you shouldn't be affected one way > or the other by the presence/absence of mustUnderstand > - Ron: didn't follow that, but reiterates that security policy > shouldn't be based on this fragile SOAP mechanism > - would be simpler to say "don't sent this, and if it is sent, > ignore it" > - Hal: in absence of explicit set of rules like Irving described, it > isn't doing much good anyway > - Don: agrees with Ron > - Chris: this is really about interop, as Hal mentioned earlier > - Hal: our mechanism isn't granular enough to take advantage of that > - Chris: need a concrete proposal to either tweak or pick between > - Eric: can put together at least one > - Irving: have heard 3 proposals so far > - mU must be false > - specific for each ext point whether it's mU is true or false > - adding a more granular mU flag at each token > - Chris: but there can be more than tokens included > - which of these 3 do we want to pursue further? > - Chris: [restates what we agreed to at SF F2F] > "mU on sec header means you understand what sec header is, and any > subsequent processing is at your discretion" > - Irving: that may be sufficient, but thinks the reason we got push > back was because we didn't say that clearly in spec > - Chris: so do we just need to clarify this? > - Tim: have we given sufficient consideration to Ron's proposal? > - would like to see the damaging consequences laid out if we say > never set this to true > - Chris: this violates the SOAP rules > - Hal: no, it doesn't > - injunction by SOAP is set on receiver, and we can put injunction > sender > - Chris: so what does receiver do if message has it set to true? > - Hal: then receiver has to understand everything > - Irving: disagrees, we have to define what "understanding" means, > and we can define it to mean as little as ability to parse it > - Chris: two proposals emerging > - sender MUST not set mU, and receiver MUST only be able to > parse if mU set > - sender SHOULD not set mU, and receiver MUST be able to parse > and abide by wss semantics > - Hal: reiterates that mU is NOT a security mechanism, and it can't > be signed > - Don: should we add text stating that this is not security-related?> > - Chris: yes, sounds like a good idea > - doesn't think we should eliminate the original utility of this by > forbidding senders to set it > - Irving: we may need to add our own criticality flags, so security > policy can be set by sender, as a separate issue > - Chris: suggests that mU requires receiver to be bound by any MUSTs > in core spec > - Irving: if that is the case, we don't really have to say anything, > since SOAP already requires that > - Phill: thinks it comes down to handling namespaces and QNames > - Ron: doesn't want a way for senders to force my implementation to > process additional stuff > - [ACTION] Irving to write up revised proposal for mustUnderstand > - 196 > - Chris: was there discussion on last call? > - Hal: TAG finding had just come out, and most people hadn't had a > chance to digest > - question is whether we want to replace all QNames with URIs > - Chris: QNames can provide value, by pointing to a dereferenceable > location of other information > - Phill: thinks it's too late for such a change > - Chris: any objections? > - Hal: TAG doc recommended making corresponding URIs > - Chris: but schema type can't be QName or URI, because of ambiguity > - Chris: any objections to declaring this too late? > - [none, no change will be made] > > > > > 5. WS-I BSP WG Update (Paul Cotton, if available) > > > > - not on call > > > > > 6. Other business > > > > - TJ Pannu: XrML interop scenario doc sent out > < http://lists.oasis-open.org/archives/wss/200311/msg00055.html > > - if people have other scenarios, please let him know > - would like feedback > - RichL: posted SAML interop scenario update > - should be consistent with latest SAML profile > - should have addressed issues from Ron > - if SAML profile gets rev'ed again, will rev interop doc > - Don: so where are we? > - Chris: will get with editors to produce updates > - will give everyone a week or so to review > - still have a couple issues to resolve > - Kelvin will be producing proposal for namespace > - Don: can chairs provide a schedule > - Chris: will work with Kelvin > > > > > 7. Adjourn > > > > - Adjourned > > > ----------------------------------------------------------------------- > > Attendance of Voting Members: > > Gene Thurston AmberPoint > Frank Siebenlist Argonne National Lab > Peter Dapkus BEA > Hal Lockhart BEA > Symon Chang CommerceOne > Thomas DeMartini ContentGuard > Guillermo Lao ContentGuard > TJ Pannu ContentGuard > Sam Wei Documentum > John Hughes Entegrity > Tim Moses Entrust > Toshihiro Nishimura Fujitsu > Kefeng Chen GeoTrust > Irving Reid HP > Jason Rouault HP > Yutaka Kudo Hitachi > Derek Fu IBM > Ron Williams IBM > Don Flinn Individual > Bob Morgan Individual > Chris Kaler Microsoft > Ellen McDermott Microsoft > John Shewchuk Microsoft > Prateek Mishra Netegrity > Frederick Hirsch Nokia > Senthil Sengodan Nokia > Abbie Barbir Nortel > Lloyd Burch Novell > Howard Melman Novell > Ed Reed Novell > Charles Knouse Oblix > Steve Anderson OpenNetwork > Vipin Samar Oracle > Eric Gravengaard Reactivity > 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: > > Blake Dournaee Sarvega > Richard Levinson Netegrity > Davanum Srinivas CA > Andrew Nash RSA Security > Paula Austel IBM > Michael McIntosh IBM > > > Membership Status Changes: > > Blake Dournaee Sarvega - Granted voting status after 11/18/2003 call > Richard Levinson Netegrity - Granted voting status after 11/18/2003> > call > Davanum Srinivas CA - Returned to prospective status 10/24/2003 > Andrew Nash RSA Security - Requested membership 11/18/2003 > Paula Austel IBM - Requested membership 11/18/2003 > Maryann Hondo IBM - Lost voting status after 11/18/2003 > Jonathan Tourzan Sony - Returned to voting status under extenuating > circumstances > > -- > Steve Anderson > OpenNetwork >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]