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