OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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]